ACCENTURE DELIVERY LEAD SYSTEM INTEGRATION
PRACTITIONER PRACTICE EXAMINATION A+
QUESTIONS AND ANSWERS WITH DETAILED
RATIONALES
INTEGRATION STRATEGY & ARCHITECTURE
1. A client has ERP, CRM, e-commerce, and a data lake with many brittle point-to-point
interfaces. Which architecture change best reduces long-term coupling?
Move all transformations into spreadsheets
Adopt reusable integration services and canonical contracts where appropriate
Create another point-to-point interface for each new consumer
Allow every application to define its own incompatible customer model
Rationale: Reusable services and stable contracts reduce duplicated mappings and make change impact more
manageable.
2. During discovery, business owners describe outcomes but not interface details. What
should the delivery lead do first?
Write production code before confirming requirements
Skip stakeholder interviews and infer everything from old interfaces
Facilitate requirements workshops and document business capabilities, data flows, and constraints
Select a middleware product immediately
Rationale: Architecture should be driven by understood business and technical requirements rather than tool-first
decisions.
API LED INTEGRATION FLOW
CLIENT API GATEWAY SERVICE DATA MONITORING
Illustrative technical diagram
3. An integration must connect on-premises systems to SaaS applications while the data
center remains in use. Which architecture is most appropriate?
A desktop-only integration
A single isolated local script with no monitoring
A public database shared by all systems
A hybrid integration architecture with controlled connectivity and shared governance
Rationale: Hybrid architectures explicitly accommodate on-premises and cloud components while preserving security
and governance.
4. A design review finds that the proposed integration is difficult to test because business
logic, transport, mapping, and error handling are tightly mixed. What principle should
guide redesign?
Separate concerns into modular, testable components
Increase code duplication
Remove logging to simplify the flow
Combine all processing into one opaque script
Rationale: Separation of concerns improves maintainability, testing, reuse, and troubleshooting.
Original practice material • Not an actual or leaked Accenture examination Page 1
, 5. A team is choosing between two integration platforms. What should be the strongest
architectural selection criterion?
Which tool was used by a developer on a previous project
Fit with required capabilities, security, operating model, skills, and total cost
Which platform has the most colorful user interface
Which vendor has the longest product name
Rationale: Technology selection should reflect business and technical fit, not superficial preference.
6. A new customer service requires the same customer identity to be shared by six
applications. What should the architect establish early?
Manual re-entry by each department
A shared password for all applications
A governed customer data model and ownership of the authoritative source
Six independent customer identifiers with no reconciliation
Rationale: Clear data ownership and semantics prevent conflicting customer identities and ambiguous integration
behavior.
7. A legacy interface is scheduled for replacement. What is the best first step for migration
planning?
Delete the legacy interface immediately
Migrate without identifying consumers
Change the data format first and ask users later
Inventory dependencies, consumers, data contracts, volumes, and operational behavior
Rationale: Dependency and behavior discovery reduces migration surprises and supports controlled cutover.
8. An integration architecture board asks how a proposed interface will scale. Which
evidence is most useful?
Expected transaction rates, payload sizes, concurrency, latency targets, and scaling strategy
The number of slides in the design deck
Developer preference for a programming language
The age of the project manager
Rationale: Capacity and nonfunctional requirements provide measurable evidence for scalability decisions.
9. A team proposes a shared integration component used by many interfaces. What should
be reviewed before approval?
Whether only one developer understands it
Its contract stability, ownership, versioning, failure behavior, and reuse value
Whether it has the shortest class name
Whether it avoids all documentation
Rationale: Shared components become dependencies, so governance around contracts and failure behavior is essential.
10. A business sponsor asks for delivery in half the original time. What should the delivery
lead do?
Remove all testing
Hide the schedule risk from the sponsor
Reprioritize scope and sequence based on business value and delivery risk
Promise the original scope without analysis
Rationale: Transparent scope and risk management protects quality while aligning delivery with the new constraint.
11. A program spans several teams that each own different interfaces. What governance
mechanism best reduces inconsistent designs?
Independent standards for every team
Original practice material • Not an actual or leaked Accenture examination Page 2
, No review until production incidents occur
A single developer approving every line of code
Shared integration standards, reference patterns, and architecture reviews
Rationale: Common standards and lightweight governance create consistency without requiring one team to implement
everything.
12. A new interface needs a contract that multiple consumers can rely on. Which practice is
strongest?
Define and review the interface contract before implementation
Let each consumer reverse-engineer behavior
Change fields silently after release
Document behavior only after production
Rationale: Contract-first thinking makes expectations explicit and supports independent development and testing.
13. A client wants to modernize a large estate but cannot migrate everything at once.
Which strategy is most pragmatic?
Rewrite every system before integrating any
Use incremental strangler-style modernization with coexistence and controlled cutovers
Perform a single uncontrolled replacement
Freeze all changes for several years
Rationale: Incremental modernization reduces risk and allows value to be delivered while legacy capabilities remain
available.
14. A delivery lead needs to explain architecture to executives. What should be
emphasized?
Only vendor-specific jargon
Unverified technical details
Business outcomes, major risks, dependencies, investment choices, and measurable benefits
Every implementation class and variable
Rationale: Executive communication should connect architecture decisions to outcomes, risk, cost, and timing.
15. A system has multiple interfaces carrying the same business event. What architectural
improvement may reduce duplication?
Send separate hand-coded copies to every consumer forever
Create a new database for each consumer
Disable monitoring
Publish a well-defined shared event or integration capability when semantics and ownership permit
Rationale: Shared event distribution can reduce duplicated producer work when consumers can tolerate the event
contract.
16. A design has a single integration runtime through which every business process must
pass. What should be assessed?
Whether the runtime is a scalability, availability, or organizational bottleneck
Whether centralization automatically guarantees reliability
Whether backups can be removed
Whether all teams should share credentials
Rationale: Centralization can simplify governance but also create concentration risk and a single failure domain.
17. A stakeholder requests a custom integration pattern because it is familiar, but a
standard enterprise pattern already solves the need. What is the best response?
Avoid documenting the decision
Prefer the standard pattern unless a documented requirement justifies deviation
Original practice material • Not an actual or leaked Accenture examination Page 3
, Always reject standards
Always accept custom designs
Rationale: Standards improve consistency and supportability; exceptions should be evidence-based and governed.
18. A data mapping contains business rules that change frequently. Where should those
rules live?
In developer memory
In production logs
In a clearly governed business-rule component or service rather than hidden transport logic
Inside undocumented string replacements
Rationale: Frequently changing business rules deserve explicit ownership, testability, and lifecycle management.
19. An interface is technically correct but causes duplicate orders after retries. What
architectural concern was missed?
UI color selection
DNS naming alone
Source-code formatting
Idempotency and duplicate-handling behavior
Rationale: Reliable integration must define what happens when messages are retried or delivered more than once.
20. A client has conflicting requirements from security, operations, and product teams.
What should the delivery lead establish?
A documented decision process with prioritized requirements, trade-offs, and accountable owners
Let the loudest stakeholder decide privately
Ignore security constraints
Implement all requirements without reconciliation
Rationale: Explicit trade-offs and decision ownership prevent hidden conflicts from becoming delivery failures.
21. A platform team wants to measure integration maturity. Which measure is most
meaningful?
Number of colors in architecture diagrams
Standardization, reuse, observability, automation, incident trends, and delivery lead time
Number of integration developers alone
Number of meeting invitations
Rationale: Maturity is demonstrated by capability and outcomes, not headcount or cosmetic measures.
22. An integration must support both synchronous request/response and asynchronous
processing. What should guide the choice?
A rule that all integrations must be asynchronous
The developer's preferred protocol
Business latency, consistency, user experience, workload, and failure tolerance
A rule that all integrations must be synchronous
Rationale: Interaction style should match business and operational characteristics.
23. A delivery lead notices teams repeatedly solving the same mapping problem. What
should be considered?
Copy the code into every project
Prevent documentation
Ask each team to solve it again
Create a reusable mapping or transformation capability with ownership and tests
Rationale: Reusable assets reduce duplicated effort when the problem and contract are stable enough to justify reuse.
Original practice material • Not an actual or leaked Accenture examination Page 4
PRACTITIONER PRACTICE EXAMINATION A+
QUESTIONS AND ANSWERS WITH DETAILED
RATIONALES
INTEGRATION STRATEGY & ARCHITECTURE
1. A client has ERP, CRM, e-commerce, and a data lake with many brittle point-to-point
interfaces. Which architecture change best reduces long-term coupling?
Move all transformations into spreadsheets
Adopt reusable integration services and canonical contracts where appropriate
Create another point-to-point interface for each new consumer
Allow every application to define its own incompatible customer model
Rationale: Reusable services and stable contracts reduce duplicated mappings and make change impact more
manageable.
2. During discovery, business owners describe outcomes but not interface details. What
should the delivery lead do first?
Write production code before confirming requirements
Skip stakeholder interviews and infer everything from old interfaces
Facilitate requirements workshops and document business capabilities, data flows, and constraints
Select a middleware product immediately
Rationale: Architecture should be driven by understood business and technical requirements rather than tool-first
decisions.
API LED INTEGRATION FLOW
CLIENT API GATEWAY SERVICE DATA MONITORING
Illustrative technical diagram
3. An integration must connect on-premises systems to SaaS applications while the data
center remains in use. Which architecture is most appropriate?
A desktop-only integration
A single isolated local script with no monitoring
A public database shared by all systems
A hybrid integration architecture with controlled connectivity and shared governance
Rationale: Hybrid architectures explicitly accommodate on-premises and cloud components while preserving security
and governance.
4. A design review finds that the proposed integration is difficult to test because business
logic, transport, mapping, and error handling are tightly mixed. What principle should
guide redesign?
Separate concerns into modular, testable components
Increase code duplication
Remove logging to simplify the flow
Combine all processing into one opaque script
Rationale: Separation of concerns improves maintainability, testing, reuse, and troubleshooting.
Original practice material • Not an actual or leaked Accenture examination Page 1
, 5. A team is choosing between two integration platforms. What should be the strongest
architectural selection criterion?
Which tool was used by a developer on a previous project
Fit with required capabilities, security, operating model, skills, and total cost
Which platform has the most colorful user interface
Which vendor has the longest product name
Rationale: Technology selection should reflect business and technical fit, not superficial preference.
6. A new customer service requires the same customer identity to be shared by six
applications. What should the architect establish early?
Manual re-entry by each department
A shared password for all applications
A governed customer data model and ownership of the authoritative source
Six independent customer identifiers with no reconciliation
Rationale: Clear data ownership and semantics prevent conflicting customer identities and ambiguous integration
behavior.
7. A legacy interface is scheduled for replacement. What is the best first step for migration
planning?
Delete the legacy interface immediately
Migrate without identifying consumers
Change the data format first and ask users later
Inventory dependencies, consumers, data contracts, volumes, and operational behavior
Rationale: Dependency and behavior discovery reduces migration surprises and supports controlled cutover.
8. An integration architecture board asks how a proposed interface will scale. Which
evidence is most useful?
Expected transaction rates, payload sizes, concurrency, latency targets, and scaling strategy
The number of slides in the design deck
Developer preference for a programming language
The age of the project manager
Rationale: Capacity and nonfunctional requirements provide measurable evidence for scalability decisions.
9. A team proposes a shared integration component used by many interfaces. What should
be reviewed before approval?
Whether only one developer understands it
Its contract stability, ownership, versioning, failure behavior, and reuse value
Whether it has the shortest class name
Whether it avoids all documentation
Rationale: Shared components become dependencies, so governance around contracts and failure behavior is essential.
10. A business sponsor asks for delivery in half the original time. What should the delivery
lead do?
Remove all testing
Hide the schedule risk from the sponsor
Reprioritize scope and sequence based on business value and delivery risk
Promise the original scope without analysis
Rationale: Transparent scope and risk management protects quality while aligning delivery with the new constraint.
11. A program spans several teams that each own different interfaces. What governance
mechanism best reduces inconsistent designs?
Independent standards for every team
Original practice material • Not an actual or leaked Accenture examination Page 2
, No review until production incidents occur
A single developer approving every line of code
Shared integration standards, reference patterns, and architecture reviews
Rationale: Common standards and lightweight governance create consistency without requiring one team to implement
everything.
12. A new interface needs a contract that multiple consumers can rely on. Which practice is
strongest?
Define and review the interface contract before implementation
Let each consumer reverse-engineer behavior
Change fields silently after release
Document behavior only after production
Rationale: Contract-first thinking makes expectations explicit and supports independent development and testing.
13. A client wants to modernize a large estate but cannot migrate everything at once.
Which strategy is most pragmatic?
Rewrite every system before integrating any
Use incremental strangler-style modernization with coexistence and controlled cutovers
Perform a single uncontrolled replacement
Freeze all changes for several years
Rationale: Incremental modernization reduces risk and allows value to be delivered while legacy capabilities remain
available.
14. A delivery lead needs to explain architecture to executives. What should be
emphasized?
Only vendor-specific jargon
Unverified technical details
Business outcomes, major risks, dependencies, investment choices, and measurable benefits
Every implementation class and variable
Rationale: Executive communication should connect architecture decisions to outcomes, risk, cost, and timing.
15. A system has multiple interfaces carrying the same business event. What architectural
improvement may reduce duplication?
Send separate hand-coded copies to every consumer forever
Create a new database for each consumer
Disable monitoring
Publish a well-defined shared event or integration capability when semantics and ownership permit
Rationale: Shared event distribution can reduce duplicated producer work when consumers can tolerate the event
contract.
16. A design has a single integration runtime through which every business process must
pass. What should be assessed?
Whether the runtime is a scalability, availability, or organizational bottleneck
Whether centralization automatically guarantees reliability
Whether backups can be removed
Whether all teams should share credentials
Rationale: Centralization can simplify governance but also create concentration risk and a single failure domain.
17. A stakeholder requests a custom integration pattern because it is familiar, but a
standard enterprise pattern already solves the need. What is the best response?
Avoid documenting the decision
Prefer the standard pattern unless a documented requirement justifies deviation
Original practice material • Not an actual or leaked Accenture examination Page 3
, Always reject standards
Always accept custom designs
Rationale: Standards improve consistency and supportability; exceptions should be evidence-based and governed.
18. A data mapping contains business rules that change frequently. Where should those
rules live?
In developer memory
In production logs
In a clearly governed business-rule component or service rather than hidden transport logic
Inside undocumented string replacements
Rationale: Frequently changing business rules deserve explicit ownership, testability, and lifecycle management.
19. An interface is technically correct but causes duplicate orders after retries. What
architectural concern was missed?
UI color selection
DNS naming alone
Source-code formatting
Idempotency and duplicate-handling behavior
Rationale: Reliable integration must define what happens when messages are retried or delivered more than once.
20. A client has conflicting requirements from security, operations, and product teams.
What should the delivery lead establish?
A documented decision process with prioritized requirements, trade-offs, and accountable owners
Let the loudest stakeholder decide privately
Ignore security constraints
Implement all requirements without reconciliation
Rationale: Explicit trade-offs and decision ownership prevent hidden conflicts from becoming delivery failures.
21. A platform team wants to measure integration maturity. Which measure is most
meaningful?
Number of colors in architecture diagrams
Standardization, reuse, observability, automation, incident trends, and delivery lead time
Number of integration developers alone
Number of meeting invitations
Rationale: Maturity is demonstrated by capability and outcomes, not headcount or cosmetic measures.
22. An integration must support both synchronous request/response and asynchronous
processing. What should guide the choice?
A rule that all integrations must be asynchronous
The developer's preferred protocol
Business latency, consistency, user experience, workload, and failure tolerance
A rule that all integrations must be synchronous
Rationale: Interaction style should match business and operational characteristics.
23. A delivery lead notices teams repeatedly solving the same mapping problem. What
should be considered?
Copy the code into every project
Prevent documentation
Ask each team to solve it again
Create a reusable mapping or transformation capability with ownership and tests
Rationale: Reusable assets reduce duplicated effort when the problem and contract are stable enough to justify reuse.
Original practice material • Not an actual or leaked Accenture examination Page 4
