AD0-E722 Adobe Commerce Architect Master Exam Topics and Questions

At nearly half the exam, Design is where the architecture credential is won or lost. The domain tests whether you can hold an entire Commerce solution in your head at once: business requirement at one end, technical implementation at the other, with integration and troubleshooting woven through the middle. Gaps here are expensive. A single wrong call on a customization strategy or an integration pattern can cost you several questions at once.

– Translating business needs into architecture decisions

The first pressure in this domain is the translation layer between what a merchant needs and what Commerce can deliver optimally. Optimal is the operative word. Adobe is testing whether you know the difference between a solution that works and one that fits the platform's design intent. Items in this area force you to weigh extension points against core overrides, and to justify a technical approach in business terms. You need to be comfortable articulating why one design is preferable to another, not just that it functions. The examinable judgment call is usually about minimising upgrade risk while still meeting the requirement fully. Candidates who default to the most powerful override mechanism available, rather than the least invasive one that still satisfies the brief, tend to lose marks here.

– Logical and technical flow design

Flow design covers how data and control move through a Commerce solution: event sequences, plugin chains, observer patterns, service contracts, and the order in which Commerce processes a request. The exam probes whether you can trace a flow from entry point to output and identify where a design decision changes behaviour downstream. Knowing that a plugin on one method will fire before or after another, or that a particular flow bypasses the standard service contract layer, is the kind of detail that separates an architect answer from a developer answer. Expect scenarios where two designs are both technically valid and you must identify which one produces the correct sequence under Commerce's execution model.

– Customisation strategy and external integrations

Customising Commerce features and integrating with external systems share a common exam trap: candidates over-engineer. Adobe's preferred pattern for extending Commerce relies on its service contract layer, dependency injection framework, and declared extension points. Items reward choosing the mechanism that hooks into those patterns cleanly rather than one that achieves the same outcome through a less stable path. Integration questions add a second dimension: the data contract between Commerce and an external system. You need to know where to place integration logic inside Commerce's architecture, how to handle asynchronous communication, and what happens when the external system is unavailable. Troubleshooting design flows rounds out the domain. These items describe a symptom and ask you to locate the architectural decision that caused it.

How Design is tested

With 46% of the exam sitting here, you will face scenario-based items that present a business requirement and ask you to select or evaluate an architectural approach. The demand is evaluative, not recall-based. Knowing that a feature exists is rarely enough; you need to know where it sits in the architecture and what choosing it costs in terms of maintainability and upgrade safety.

Candidates lose marks in two main ways. The first is selecting a solution that works but violates Commerce's preferred extension model, for example patching core files or using a class rewrite where a plugin would suffice. Items reward the least-invasive approach that fully satisfies the stated requirement. The second trap is integration questions: candidates confuse where logic should live inside Commerce with where it should live in the external system. Items reward placing integration code at the correct layer within Commerce's own architecture. Troubleshooting items reward tracing a symptom back to a specific design decision rather than to a general category of cause.

Where Design asks you to build, Review asks you to assess what has already been built. The shift matters because the exam expects a different posture: critical rather than creative. You are looking at existing customisations, test coverage, performance characteristics, and code quality, and deciding what to fix, in what order, and why. At 32% of the exam, this domain rewards candidates who have spent time in real codebases that were not entirely their own.

– Auditing and refactoring existing customisations

Reviewing a customisation means more than checking whether it works. The exam asks you to identify whether it was built against Commerce's preferred extension points, whether it will survive an upgrade, and whether a better approach now exists. Refactoring items present existing code or an architectural description and ask you to select the change that improves stability or maintainability without altering behaviour. The trap is selecting a refactor that fixes one problem while introducing another, for example replacing a class rewrite with a plugin but placing the plugin at the wrong intercept point. Items reward the change that moves the implementation closer to Commerce's design model with the smallest blast radius.

– Testing frameworks and coding standards

Adobe expects an architect to know where each type of test belongs in the Commerce workflow and what it proves. Unit, integration, and functional tests have distinct scopes, and the exam tests whether you can assign the right framework to the right problem. Coding standards items are less about syntax and more about enforcement: knowing which tools Adobe mandates for a Commerce project, what they catch, and at what stage in the workflow they should run. Items reward answers that place quality gates at the point in the workflow where they are most effective, not just at the end. Candidates who treat testing as a single undifferentiated activity tend to mis-assign frameworks and lose marks on what should be straightforward questions.

– Performance, scalability, and root-cause troubleshooting

Performance items in the Review domain are diagnostic rather than prescriptive. You are not designing a caching strategy from scratch; you are looking at an existing setup and identifying what is limiting throughput or response time. Scalability questions extend this to architectural decisions: which customisations or configurations will become bottlenecks as catalogue size or traffic grows, and which design changes address the constraint at its source. Root-cause troubleshooting ties the domain together. These items describe a production symptom and ask you to work backwards through the stack to the underlying cause. Items reward a systematic diagnostic approach rather than a list of possible causes. Candidates who jump to the most dramatic explanation without ruling out simpler ones consistently lose marks here.

How Review is tested

Review items are predominantly analytical. You will be given a description of an existing implementation, a test suite, a performance profile, or a code structure, and asked to evaluate it. The exam does not ask you to recall definitions; it asks you to apply architect-level judgment to something already in place.

The weight of this domain means you cannot afford to treat it as secondary. Candidates who focus only on Design preparation and skim Review often find the diagnostic and refactoring items harder than expected, because the skill of critiquing a design is genuinely different from building one.

The main mark-loss pattern is selecting the answer that addresses the symptom rather than the cause. Items reward identifying the architectural or structural decision that produced the problem, not the quickest surface-level fix. A second pattern: candidates over-scope refactoring answers, recommending a full rewrite when a targeted change at the correct extension point would resolve the issue. Items reward proportionate, targeted interventions.

After Design and Review, Configure and Deploy is where architecture meets operations. The domain is narrower in scope but unforgiving in detail: Commerce Cloud environments, deployment pipelines, and infrastructure configuration each have their own set of decisions that an architect is expected to own. At 22%, it is the smallest domain, but candidates who dismiss it as purely operational often drop marks on questions that require knowing exactly which configuration layer takes precedence or which deployment step is the right place to resolve a specific class of problem.

– Commerce and Commerce Cloud configuration

Configuration in Commerce operates across multiple layers: environment variables, config.php, env.php, the admin panel, and cloud-specific YAML files. The exam tests whether you know which settings belong at which layer and, critically, which layer wins when values conflict. Commerce Cloud adds its own configuration surface through .magento.app.yaml, services.yaml, and routes.yaml, and an architect is expected to know what each file controls and what the consequences are of misconfiguring it. Items reward selecting the configuration location that is both correct for the setting type and appropriate for the target environment. Candidates who treat all configuration as equivalent regardless of layer consistently mis-answer these items.

– Deployment process and infrastructure troubleshooting

Deployment on Commerce Cloud follows a defined pipeline with distinct phases, and each phase has constraints on what can and cannot be changed. The exam tests whether you can identify the right phase for a given action and whether you can improve a deployment process that has a specific flaw. Troubleshooting items in this domain describe an infrastructure or deployment failure and ask you to locate its origin. Items reward tracing the failure to the specific configuration file, pipeline phase, or infrastructure component responsible, rather than offering a general category of fix. A common trap is recommending a deployment-time change for a problem that is actually a build-time misconfiguration, or vice versa. Knowing the boundary between those phases precisely is what separates architect-level answers from administrator-level ones.

How Configure and Deploy is tested

Items in this domain are precise. They tend to present a specific configuration state or deployment scenario and ask you to identify what is wrong or what should be done next. Vague answers about general best practice do not score; the exam expects you to name the correct file, phase, or setting.

The domain's weight means you cannot afford to ignore it, but you also cannot let it consume preparation time that belongs to Design. The return on investment is in knowing Commerce Cloud's configuration hierarchy cold and understanding the deployment pipeline phases well enough to reason about failure modes without memorising every error message.

Candidates lose marks most often by conflating configuration concerns with deployment concerns, and by selecting fixes that would work in an on-premises Commerce environment but are incorrect for the Cloud-managed infrastructure. Items reward answers that respect the constraints Cloud imposes on what an architect can directly control versus what is managed by the platform.