AD0-E716 Adobe Commerce Developer with Cloud Add-on Exam Topics and Questions

This is the largest section of the exam and the one that will define your result. It spans the full width of Adobe Commerce's extension model: caching, dependency injection, routing, plugins, observers, preferences, configuration layers, Page Builder, CLI commands, integration testing, security controls, and CRON. The breadth is deliberate. Adobe wants evidence that you can make the right architectural call, not just recall a definition.

– Caching, configuration, and the request lifecycle

Cache management in Adobe Commerce is examined at the level of cache types, invalidation strategy, and when to use full-page cache versus block cache versus custom cache. Knowing that a cache type exists is not enough: you need to know when flushing one type affects another and what the programmatic API looks like.

The configuration layer sits beneath almost every other sub-topic here. System XML, config XML, and the scope hierarchy (global, website, store view) determine how settings are read and overridden. Items in this area test whether you can trace a config value through the scope chain under a multi-site setup.

Routes follow the front-controller pattern through router matching, controller dispatch, and result objects. Knowing the order in which routers are checked, and how to register a custom router, is the kind of detail that separates a correct answer from a plausible-sounding distractor.

– Plugins, preferences, observers, and dependency injection

The interception layer is one of the most heavily tested areas in this topic. Plugins (interceptors) come in three types, and sort order controls which fires first when multiple plugins target the same method. Preferences replace a class entirely; observers respond to events asynchronously. The exam tests your ability to choose the right mechanism for a given scenario, and it penalises candidates who reach for a preference when a plugin would preserve composability.

Dependency injection in Adobe Commerce uses the di.xml configuration and the ObjectManager under the hood. The constraints matter as much as the capabilities: you cannot inject session-dependent objects into singleton-scoped classes without side effects, and the exam surfaces exactly that kind of constraint. Understanding virtual types, type preferences, and constructor argument overrides at the XML level is necessary to answer these items correctly.

– Extension attributes, custom fields, and Page Builder

Extension attributes are the sanctioned way to add data to existing entities without altering core tables. The exam tests the full lifecycle: declaring the attribute in extension_attributes.xml, generating the extension interface, persisting the value, and loading it back. Candidates who know the declaration but have never traced the persistence path tend to miss the implementation-detail questions.

Store settings fields (system.xml fields, source models, backend models) are tested at the configuration level. You need to know how a field's type, scope, and backend class affect what gets saved and how it is read.

Page Builder customization is a narrower but distinct skill: adding a custom content type, its template, its form, and its preview. Items here reward knowing the content type configuration file structure over general familiarity with the drag-and-drop interface.

– CLI, testing, patches, security, CRON, and app emulation

Custom CLI commands are registered via di.xml and must implement a specific interface. The exam tests the structure of a command class: configure(), execute(), and how arguments and options are declared.

Integration tests in Adobe Commerce run against a real database fixture. Items test what makes an integration test different from a unit test and what the bootstrap process sets up. Knowing the annotation-based fixture loading mechanism is the detail that moves candidates from guessing to knowing.

Git patches and Composer file-level modifications are examined in terms of when each is appropriate. A patch applied via the Composer patches plugin has a different maintenance profile than a direct file override, and the exam surfaces that trade-off.

Security controls (CSP headers, form keys, output escaping, input sanitization, reCAPTCHA) are tested as implementation decisions, not as a checklist. CRON scheduling is tested through group configuration and the relationship between cron_groups.xml and the schedule. App emulation comes up in contexts where code must execute outside its normal store scope, such as in a CRON job that sends store-specific transactional email.

How Adobe Commerce Architecture and Customization Techniques is tested

At 36% of the exam, this topic will appear across a large share of the items you sit. The items are scenario-based: a requirement is described and you select the implementation approach. The trap in plugin and observer questions is that multiple mechanisms look applicable; items reward the option that preserves upgrade safety and composability. Preference questions often include a distractor that uses a plugin where a preference is genuinely needed, or vice versa.

DI constraint questions are among the most missed. Candidates who have only used DI in straightforward cases do not recognise the proxy or factory patterns as the answer when a non-injectable type is involved.

Caching questions test invalidation logic, not just cache type names. Security items test which control applies to which attack vector. CRON items test configuration structure. In every case, items reward precision over general familiarity. A candidate who can recite what a plugin does but cannot predict the outcome of two conflicting sort orders will lose marks here.

After the broad architecture coverage, the exam narrows to Adobe Commerce's data layer. This topic is about how the platform stores and modifies structured data: the Entity-Attribute-Value model, schema extension, data migration, and controlled database modification through patches. The questions here are implementation-level. Knowing that EAV exists is not sufficient; you need to know how to manipulate it programmatically and how to version schema changes safely.

– EAV attributes and schema extension

EAV is Adobe Commerce's mechanism for storing entity data across flat and EAV tables depending on attribute scope and type. The exam tests programmatic attribute creation and modification: using setup scripts or data patches to add an attribute, assign it to an attribute set, and configure its frontend and backend types. Candidates who only know the Admin UI path for adding attributes will miss the questions that ask about the programmatic API.

Extending the database schema is tested through the declarative schema approach introduced in recent versions of Magento/Adobe Commerce. You need to know how db_schema.xml is structured, how foreign keys and indexes are declared, and how the schema diff mechanism determines what SQL to generate. The older InstallSchema/UpgradeSchema scripts still appear as distractors, and the exam rewards knowing when the declarative approach supersedes them.

– Data import/export and database patches

Import and export in Adobe Commerce is tested at the programmatic level: the import model, import behaviors (add/update, replace, delete), and how validation errors are handled. Questions tend to present a data migration scenario and ask which import behavior or which entity type applies.

Patches are the recommended way to modify database state in a versioned, repeatable manner. The exam distinguishes between data patches (implement DataPatchInterface) and schema patches (implement SchemaPatchInterface), and tests the dependency declaration between patches. Recurring setups, which re-run on every deploy, are a distinct concept and the exam expects you to know the interface that enables that behavior. Candidates who conflate one-time patches with recurring setups lose marks on the questions that hinge on that difference.

How Working with Databases and EAV is tested

Items in this topic present a concrete data-layer requirement and ask for the correct implementation path. The most common trap is conflating the old upgrade script approach with the current declarative schema and patch system. Items reward the candidate who can identify which interface to implement and what method signature is required, not just the candidate who knows that patches exist.

EAV questions often describe an attribute that needs a specific scope or a non-standard backend model and ask what configuration achieves that. The distractor options are usually plausible but apply the wrong method or the wrong attribute property.

Import questions tend to hinge on behavior mode: the difference between add/update and replace has downstream consequences that the exam surfaces. Schema extension questions reward knowing the declarative syntax over the procedural one. Overall, this topic tests precision at the API and configuration level, so vague familiarity with the concepts will not be enough to score well here.

The Admin panel has its own development model, separate from the frontend. This topic covers the UI components that power Admin grids and forms, the ACL system that controls who sees what, and the modifier classes that adjust UI component behavior dynamically. At 6%, it is a focused area, but the questions are precise: the Admin UI component system has enough moving parts that a shallow reading of the docs will leave gaps.

How Developing with Admin is tested

Items here present an Admin customization requirement and ask for the correct component or configuration. Grid questions test the listing component structure: columns, data sources, filters, and how actions are extended or overridden. The trap is reaching for a block-based approach when the UI component approach is what the platform expects.

ACL questions test the resource tree declaration in acl.xml and how permissions are checked in controllers and UI components. Items reward knowing that ACL restriction must be applied at multiple layers, not just the menu. Candidates who apply it only at the controller level will select the incomplete answer.

Modifier classes adjust the UI component meta at runtime. Items test the interface they implement and where they are declared. These are among the more detail-sensitive questions in this topic: the method signature and the di.xml declaration both matter. Overall, this topic rewards candidates who have built Admin grids and forms from scratch rather than those who have only modified existing ones.

Catalog customization sits at the intersection of the EAV model, the indexing system, and the pricing engine. This topic shares a weight with Developing with Admin, but the subject matter is more varied: product types, catalog entities, indexes, price output, and multi-source inventory each have their own rules. The questions test whether you know where the platform's extension points are, not just what the catalog does.

How Customizing the Catalog is tested

Product type questions present a scenario where an existing type is insufficient and ask how to extend or replace it. Items reward knowing the product type registration in product_types.xml and the class hierarchy, not just the Admin-visible product type names.

Indexing questions test the difference between full reindex and partial reindex, how custom indexers are declared, and what triggers invalidation. The trap is assuming that saving an entity always triggers the right index update automatically.

Price output customization is tested through the price rendering architecture. Candidates need to know where custom price models are declared and how the price box and amount renderers are structured.

Multi-source inventory questions focus on the program-level impact: how MSI decouples stock from source, what the salability check involves, and how custom stock algorithms are introduced. Items here reward understanding the MSI module boundaries rather than the Admin UI for managing sources and stocks.

Sales operations customization covers the parts of the checkout and order pipeline that developers most often need to extend: payment methods, shipping methods, totals, and the broader sales workflow. The questions are scenario-driven and test implementation depth. Knowing the names of the interfaces is a starting point; knowing the method contracts and where each extension point sits in the pipeline is what the exam actually tests.

How Customizing Sales Operations is tested

Payment method questions ask about the interface hierarchy and what a custom payment method must implement to participate in the checkout flow. The exam distinguishes between offline and online payment methods and tests the authorize, capture, and void method contracts. Items reward the candidate who knows which methods are required versus optional.

Shipping method questions follow a similar pattern: the carrier interface, the collectRates method, and how rate results are constructed. Distractors often show a method that looks right but returns the wrong type.

Totals customization is tested through the totals collector: how a custom total is declared in sales.xml, what its collect and fetch methods do, and how sort order affects the calculation sequence. This is a detail that candidates who have only configured totals in the Admin will not know.

Broader sales operation customization, such as order state and status transitions, is tested at the model level. Items reward knowing the state machine rather than the Admin status grid.

APIs and Services is the smallest weighted topic in the exam, but the two sub-topics it covers are distinct enough that you need to prepare both. The REST and GraphQL API extension model and the message queue system do not overlap much in practice, and a candidate who is strong on one can be caught out by the other. Four percent is a narrow margin, but it is still marks on the table.

How APIs and Services is tested

API extension questions test the webapi.xml declaration: how a route is registered, how authentication is configured, and how an existing API endpoint is extended with new functionality. Items reward knowing the interface-based contract model that Adobe Commerce uses for its web API layer. Candidates who approach this as REST configuration without understanding the service contract underneath tend to pick the incomplete option.

Message queue questions test the topology: how a publisher, a topic, and a consumer are declared in queue_topology.xml, queue_publisher.xml, and queue_consumer.xml. The exam tests what happens when a message cannot be processed and how retry and rejection are configured. Items reward knowing the relationship between the queue configuration files rather than just knowing that RabbitMQ is supported.

Both sub-topics appear in scenario form. The scenarios are specific enough that general awareness of the features will not be sufficient. Precision at the configuration and interface level is what separates the scoring options.

At 16%, Cloud architecture is the second-largest topic in the exam. It shifts the focus from application code to the platform that runs it: environment topology, deployment pipeline, ECE-Tools, Fastly, and the service layer managed through YAML configuration. Many developers know Commerce well but have only surface-level Cloud exposure. This topic is where that gap shows up.

– Environment structure, files, and permissions

Adobe Commerce Cloud organises work across integration, staging, and production environments, each with a defined relationship to the Git branch model. The exam tests how the environment hierarchy works, what files belong to the project repository versus what is generated at build or deploy time, and what permission levels exist for project users.

The project file structure includes .magento.env.yaml, .magento.app.yaml, .magento/routes.yaml, and .magento/services.yaml. Each file has a specific scope and a specific set of allowable values. Items test which file controls which aspect of the environment, and the trap is attributing a setting to the wrong file. Knowing that these files exist is not enough; you need to know what each one governs and what it cannot do.

– Application services and multi-domain configuration

Services such as MariaDB, Redis, RabbitMQ, and Elasticsearch are declared in services.yaml and wired to the application in .magento.app.yaml. The exam tests how services are defined, versioned, and connected, and what constraints apply to service configuration on Cloud versus on-premises.

Multi-domain store setup on Cloud combines application-level configuration with routes.yaml entries. Items test the developer's share of this work: how routes are declared for multiple domains, how store codes are mapped, and where the boundary is between developer configuration and infrastructure support. Candidates who have only done single-domain Cloud deployments will find multi-domain questions harder than they expect.

– ECE-Tools, patches, deployment, and logs

ECE-Tools drives the build and deploy pipeline. The exam tests the main phases of deployment (build, deploy, post-deploy), what happens in each phase, and what ECE-Tools does at each step. Items reward knowing the phase boundaries: for example, that the filesystem is read-only during the deploy phase in ways that affect where certain operations must run.

ECE patches are applied through ECE-Tools and are distinct from Composer-level patches. The exam tests their purpose, particularly security breach patches, and how ECE-Tools is maintained and upgraded.

Log access on Cloud is tested practically: which logs exist, where they live, and which tool or command surfaces them. Items reward knowing the difference between deploy logs, application logs, and service logs, and how to access each type in a Cloud environment.

– Fastly and support boundaries

Fastly is the CDN and WAF layer in front of Adobe Commerce Cloud production environments. The exam tests out-of-the-box Fastly features: VCL snippets, image optimisation, and how Fastly is installed and configured through the Admin module. Items reward knowing the configuration steps and the feature set at a practical level, not deep VCL programming.

Knowing when to contact Adobe support versus handling something yourself is a distinct skill the exam tests explicitly. The YAML configuration files have documented limitations, and some changes require a support ticket rather than a self-service edit. Items reward knowing that boundary. Candidates who assume everything is self-service will select options that are technically coherent but operationally incorrect on the Cloud platform.

How Adobe Commerce Cloud architecture is tested

Items in this topic are scenario-based and often describe a deployment or configuration problem. The exam rewards candidates who can trace a setting through the correct YAML file to the correct environment scope. The most common trap is knowing the concept but misattributing it to the wrong file or the wrong deployment phase.

ECE-Tools questions test phase awareness: what can run in build versus deploy versus post-deploy. Fastly questions test the feature set and the installation path, not VCL syntax. Log questions test access method, not log content.

Multi-domain and service configuration questions reward precision at the file level. Support-boundary questions reward knowing the documented limitations of self-service YAML edits. Overall, this topic penalises candidates who have read about Cloud architecture without having worked through a deployment. Hands-on exposure to the YAML files and the deployment pipeline makes the difference on the scenario items.

Where the previous topic covered architecture and the deployment pipeline, this one focuses on the UI-driven side of Cloud management: the Project Web UI, variable configuration, environment management, branching, user onboarding, and plan capabilities. The distinction matters for the exam. Questions here expect you to know the UI workflows, the variable precedence hierarchy, and where the Web UI's limits are.

– Variables, configuration precedence, and troubleshooting

Cloud variables can be set at the project level, the environment level, or through the application configuration files. The exam tests the precedence hierarchy: which level overrides which, and what the practical consequences are when the same variable is set in two places. Items reward knowing the order of precedence, not just knowing that multiple levels exist.

Basic Cloud troubleshooting through the UI involves reading environment status, identifying failed deployments, and understanding what the variable hierarchy means for a misconfigured environment. The exam presents a misconfiguration scenario and rewards the candidate who can identify the source of the conflict within the precedence model rather than the one who suggests a blanket redeploy.

– User management, branching, environment management, and plan capabilities

Cloud user management covers roles, permissions, and the onboarding flow through the Project Web UI. The exam tests what each role can and cannot do, which matters for questions about restricting access or delegating environment management.

Branching through the UI creates child environments from parent branches. Items test the relationship between branch hierarchy and environment inheritance: a child environment inherits variables and services from its parent unless explicitly overridden. Candidates who treat branching as a pure Git operation without understanding the Cloud environment model will miss the inheritance-related questions.

Environment management through the UI includes syncing, merging, and resetting environments. Plan capabilities are tested at the level of what each plan tier provides in terms of environment count, storage, and available services. Items reward knowing the boundaries of a plan, not the marketing names for the tiers.

How Setup/Configuring Adobe Commerce Cloud is tested

Items here are grounded in the Project Web UI and the variable system. The most common trap is confusing environment-level variable configuration with project-level configuration, or misapplying the precedence order. Items reward the candidate who can predict the outcome of a specific variable configuration, not just describe the system in general terms.

User management questions test role boundaries. Branching questions test environment inheritance. Plan capability questions test what is possible within a given plan tier rather than what is possible on the platform generally.

Troubleshooting questions present a symptom visible in the UI and reward the candidate who traces it to the correct configuration layer. The distractor options in these questions are usually plausible actions that would help in a different scenario. Knowing the variable hierarchy cold is the single most effective preparation for this topic.

The CLI is where Cloud management becomes precise. Some operations are only available through the magento-cloud CLI: activating emails, rebasing environments, taking snapshots, dumping databases, and setting up a local environment. This topic tests those CLI-exclusive workflows alongside the variable and branching operations that are also available in the UI. Candidates who have only used the UI will find several of these questions have no familiar frame of reference.

How Commerce Cloud CLI tool (Managing part) is tested

Items in this topic describe a task and ask for the CLI approach. The exam distinguishes between operations that exist in both the UI and the CLI versus those that are CLI-exclusive. Items reward knowing which category a command falls into, because selecting a UI-based answer for a CLI-exclusive task is a trap the exam sets deliberately.

Variable management via CLI is tested alongside the UI approach from the previous topic. The exam expects you to know that the CLI and the UI ultimately write to the same configuration, but that certain flags and options are only accessible through the CLI.

Troubleshooting cloud services through the CLI covers MySQL, Redis, and the tunnel:info command. Items test what information each command surfaces and what you would do with it. Branching via CLI is tested for the commands and flags involved, not just the conceptual model. Snapshot and database dump questions test the command structure and the appropriate use case for each operation.