AD0-E725 Adobe Commerce Developer Expert Exam Topics and Questions

Architecture is the heaviest topic on this exam by a wide margin, and it rewards breadth as much as depth. You need to hold the whole platform model in your head at once: how requests move through the system, what intercepts them, what speeds them up, and what breaks when you change one thing without understanding its dependencies. Gaps here tend to cascade into wrong answers on Customizations too, so time spent here pays twice.

– Caching, indexing and the CRON scheduler

Cache management in Adobe Commerce is not just about enabling or flushing: you need to know which cache types exist, what each one stores, and when invalidation is triggered automatically versus manually. The exam tests whether you can reason about stale data and pick the right cache type for a given scenario.

Indexers control how data is projected into flat or search-optimised tables. The key distinction is between Update on Save and Update by Schedule modes. Choosing the wrong mode under load has real consequences, and the exam will put you in a scenario where that choice matters.

CRON is the engine behind scheduled tasks, reindexing, and queue consumers. You need to know how groups are configured in crontab.xml, how to add a custom job, and what happens when jobs overlap or fall behind. The exam probes whether you understand the scheduling mechanics, not just that CRON exists.

– Extensibility model: plugins, preferences and observers

The Adobe Commerce extensibility model gives you several interception points, and the exam tests whether you pick the right one. Plugins (interceptors) let you run code before, after, or around a public method without rewriting it. Preferences replace a class entirely via di.xml. Observers react to dispatched events but cannot modify return values. Each mechanism has constraints: plugins cannot intercept final or non-public methods, preferences create tight coupling, and observers run asynchronously in some contexts.

Knowing which tool fits which requirement is the core competency here. The exam frequently presents a scenario and asks you to choose between these mechanisms. The trap is reaching for a preference when a plugin is sufficient, or using an observer where you actually need to alter data before it is returned. Sort codes from the framework's own conventions in your mind before exam day.

– Multi-site configuration and security

Running multiple websites, stores, and store views on a single Adobe Commerce instance involves scope-aware configuration. Each level of the hierarchy can override settings from the level above, and the exam tests whether you understand where a given configuration value is resolved and what happens when values conflict. Performance and cache isolation between sites on one instance is also fair game.

On security, the exam covers a specific set of mechanisms: Content Security Policy headers and how violations are reported or enforced, output escaping and the correct escaping method for each context (HTML, URL, JavaScript), form keys as CSRF protection, input sanitisation and validation, and reCAPTCHA integration. Knowing that these features exist is not enough. You need to know where each one is applied in the framework and what a misconfiguration looks like.

Git patches and Composer file-level modifications round out this group. The exam tests when a patch is appropriate versus a module override, and how patches are applied and maintained.

How Architecture is tested

At 38% of the exam, this topic will account for well over a third of your score. Items are scenario-based: you are given a business or technical requirement and asked which architectural mechanism satisfies it, or you are shown a configuration and asked what its effect will be.

The most common trap is confusing mechanisms that look similar. Plugins and preferences both modify behaviour, but the exam rewards choosing the one that fits the constraint in the scenario. Similarly, cache and index questions reward knowing the specific type or mode involved, not just the general concept.

Security questions reward knowing which framework utility to call in which context. Picking the wrong escaping method for the context, or misidentifying where CSP is enforced, costs marks. CRON questions reward knowing configuration structure rather than command-line usage. Expect multi-step reasoning: a scenario may introduce a constraint (a method is final, a site has a separate cache backend) that rules out the obvious answer and requires you to apply a less familiar mechanism.

Where Architecture stays largely inside the platform, External Integrations pulls you outward: into Adobe's SaaS ecosystem, into serverless compute, and into event-driven messaging between services. The concepts are newer than the core framework, and many candidates underestimate them. At 14%, a weak performance here will not sink you alone, but combined with gaps elsewhere it adds up. The technology moves fast, so focus on how the pieces connect rather than memorising API signatures.

How External Integrations is tested

Items in this topic test your ability to reason about data flow and integration architecture, not your ability to recall method names. A typical item presents a business requirement (pushing product data to a SaaS service, reacting to an external event, extending Commerce logic without modifying the core codebase) and asks which tool or approach fits.

For SaaS data flow customisation, the exam rewards knowing where in the pipeline you can intercept and transform data, and what the limits of that interception are. For App Builder, items reward understanding its role as an out-of-process extension layer and when it is the right choice over an in-process module.

Adobe I/O Events and Webhooks questions reward knowing the directional difference: events push notifications out of Commerce, webhooks allow external systems to trigger Commerce logic. Confusing the direction or the registration mechanism is the most common way to lose marks here. Expect scenario questions that describe a real integration need and require you to select the correct mechanism and its configuration approach.

Customizations is the second-largest topic and the one most directly tied to day-to-day Commerce development work. The difference from Architecture is the level of specificity: where Architecture tests your understanding of mechanisms, this topic tests whether you can apply them to real features. Catalog, checkout, the admin panel, APIs, entity types, message queues, and integration testing each have their own conventions, and the exam rewards candidates who know those conventions rather than those who can only reason from first principles.

– Catalog and checkout customisation

Catalog customisation covers product types, attributes, and the extension attributes system. The exam tests whether you know how to add an attribute to an entity correctly (via InstallData or a data patch), how extension attributes differ from custom attributes, and how product type logic is structured. Shortcuts that work in development but break indexing or caching in production are a common trap.

Checkout customisation is one of the more complex areas in Commerce development. The checkout is built on Knockout.js components wired through layout XML and RequireJS, and modifying it means understanding how those layers interact. The exam tests order-of-operations knowledge: where to inject a step, how to add a payment method, and what the sales operations pipeline looks like from quote to order. Candidates who know the checkout only from the frontend often miss the backend order processing side, which is equally examinable.

– Entity types and admin panel

Manipulating entity types programmatically means working with the EAV system, flat tables, and the repository and search criteria patterns. The exam tests whether you can add, retrieve, and persist data through the service layer rather than direct database calls. Knowing when an entity uses EAV versus a flat table, and what that means for queries and performance, is the kind of distinction that separates a correct answer from a plausible-sounding wrong one.

Admin panel customisation covers UI components, grids, forms, and ACL. UI components are configured in XML and backed by data providers, and the exam tests the relationship between those pieces. ACL questions reward knowing how to declare a resource and check permissions programmatically. The most common gap here is candidates who can build a grid but have not worked through the full permission model.

– APIs, message queues and integration testing

API customisation covers REST and GraphQL: how to expose a new endpoint, how to extend an existing one, and how web API configuration (webapi.xml, schema.graphqls) controls access and structure. The exam tests the declaration layer as much as the implementation layer.

Message queues in Commerce use AMQP or the database as a broker. The exam tests how to declare a topic and queue in configuration XML, how a consumer is registered, and how to leverage existing queues rather than always creating new ones. Knowing the difference between a synchronous and asynchronous queue consumer matters for scenario questions.

Integration tests are the final sub-topic and they are often under-prepared. The exam tests the structure of an integration test in Commerce: how the test database is managed, how fixtures are loaded, and what the ObjectManager does in a test context. Candidates who only write unit tests will find this unfamiliar.

How Customizations is tested

At 32%, this topic generates roughly a third of the exam. Items are almost always scenario-based, and many of them describe a specific requirement and ask for the correct implementation approach.

The catalog and checkout items reward procedural knowledge: the right class, the right XML node, the right sequence of steps. Guessing from general principles works less reliably here than in Architecture, because Commerce has strong conventions and the exam tests those conventions specifically.

Entity and admin items reward knowing the service layer patterns. Candidates who reach for direct database calls or skip the repository layer will find those answers are present but not rewarded.

API and queue items reward configuration knowledge. Knowing that something should go in webapi.xml is not enough if you do not know the structure of that declaration. Integration test items reward knowing what makes a Commerce integration test different from a unit test. The trap is applying PHPUnit knowledge without accounting for the Commerce test framework on top of it. Across all sub-topics, watch for distractors that describe valid PHP but violate Commerce conventions.

After working through the platform's internal mechanics and customisation patterns, the Cloud topic shifts your frame to the infrastructure and tooling that Adobe Commerce Cloud wraps around the application. At 16%, it carries more weight than External Integrations, and candidates who have only worked on on-premises or Magento Open Source installations often find it the least familiar part of the exam. The questions are operational rather than architectural: what do you configure, where, and with which tool.

How Cloud is tested

Cloud items test your ability to reason about the Adobe Commerce Cloud environment as a managed platform with its own configuration layer. The exam rewards knowing how the Cloud architecture differs from a self-hosted installation: the role of the build and deploy hooks, how environment variables are scoped, how services are declared in configuration files, and how environments relate to each other in the project hierarchy.

Setup and configuration questions reward knowing which file controls which aspect of the environment. Candidates who treat Cloud configuration as an afterthought and rely on the UI alone tend to miss questions about file-level configuration that the CLI or YAML files expose.

CLI tool questions reward operational knowledge: the commands used to manage environments, pull down data, run deployments, and inspect logs. The trap is knowing that a command exists but misidentifying its scope or its required flags. Expect scenario questions that describe a deployment or environment problem and ask which CLI command or configuration change resolves it. Precision matters: plausible-sounding commands that do not exist or do the wrong thing are common distractors.