About the Exam

Master-level certification for architects who design Adobe Commerce (Magento) solutions. It covers solution architecture, integration and data-migration strategy, extensibility, performance and scalability planning, and the trade-offs between customisation and out-of-the-box capability. Passing demonstrates the ability to lead the technical design of a large Adobe Commerce implementation.

Exam Topics

  • Catalog and Products22%
  • Promotions16%
  • Orders, Payments, Shipping, and Tax18%
  • Customers14%
  • Content, CMS, and Storefront16%
  • Store Operations and Admin14%

How to Use This Practice Exam

  1. Browse — Read each question, select your answer, and reveal the explanation.
  2. Exam Mode — Simulate real exam conditions with a timed session and score report.
  3. Learn Mode — Spaced repetition schedules questions you struggle with for long-term retention.

Download the Full Exam PDF

Get every question and answer in a clean, printable PDF built for offline study. Purchase once, keep permanent access, and re-download the latest version anytime.

Last updated April 3, 2025 at 5:55 PM

Topic filter
Retired questions
Question sort

QuestionQ1

Orders, Payments, Shipping, and Tax

A company plans to build an Adobe Commerce website to sell its products to customers in its country. Tax rules in that country are highly complex and require Adobe Commerce customization. An Architect intends to address this by creating a custom tax calculator that calculates taxes for every Adobe Commerce order.

How should the Architect add taxes to all orders?

  • A Write a before plugin to \Magento\Quote\Model\QuoteManagement::placeOrder() and add the custom tax to the quote
  • B Declare a new total collector in “etc/sales.xml” in a custom module
  • C Add a new observer to the event “sales_quote_collect_totals_before” and add the custom tax to the quote
Explanation

Adobe Commerce calculates amounts during quote total collection. Registering a custom total collector in etc/sales.xml incorporates the custom tax into quote and order totals consistently before checkout submits the order. Adobe Commerce documents custom quote totals as collectors declared in etc/sales.xml.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!

QuestionQ2

Content, CMS, and Storefront

An Architect on a headless Adobe Commerce project creates a new customer attribute named my_attribute. Based on the customer’s attribute value, a plugin modifies the results of GraphQL queries. The frontend application communicates with Adobe Commerce through Varnish by Fastly, which already caches the queries that will be modified. The Adobe Commerce Fastly extension is installed, and no other changes are made to the application.

Which steps should the Architect take to ensure that Varnish’s vcl_hash function also takes the newly created attribute into account?

  • A Create a new class inheriting from Magento\Framework\GraphQl\Query\Resolver\IdentityInterface and returning the value of my_attribute from the getIdentities function. Then specify a @cache(cacheIdentity: Path\To\IdentityClass) directive for each GraphQL query to include the newly created IdentityClass to each query that adds the cache tags for each customer.
  • B Create a new class inheriting from Magento\GraphQlCache\Model\CacheId\CacheIdFactorProviderInterface and returning the value of my_attribute from the getFactorValue function and my_attribute from getFactorName function. Then add this class through DI to the IdFactorProviders array of Magento\GraphQlCache\Model\CacheID\CacheIdCalculator.
  • C Create a new class inheriting from Magento\Customer\CustomerData\SectionSourceInterface and returning the value of my_attribute from the getSectionData function. Then add this class through DI to the sectionSourceMap array of Magento\Customer\CustomerData\SectionPoolInterface.
Explanation

Adobe Commerce calculates X-Magento-Cache-Id from registered cache-ID factors, and Fastly/Varnish uses that value to distinguish cached GraphQL responses for logged-in customers. Implementing CacheIdFactorProviderInterface to supply my_attribute as the factor name and its current customer value as the factor value, then registering it in CacheIdCalculator’s idFactorProviders DI argument, makes the cache identifier vary by that attribute. Cache identities control cache invalidation tags, while customer-data sections supply client-side private content and do not vary the Varnish GraphQL cache key.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!

QuestionQ3

Orders, Payments, Shipping, and Tax

An Adobe Commerce Architect is developing a new GraphQL API mutation to change how configurable products are added to the cart. The mutation accepts a configurable product ID. If the supplied product has only one variant, the mutation must add that variant to the cart and return a non-null Cart type. If the configurable product has multiple variants, the mutation must return a non-null ConfigurableProduct type.

The mutation declaration is as follows:

Question Image

How should the Adobe Commerce Architect declare this mutation’s output?

  • A
  • B
  • C
Explanation

A GraphQL union represents a result that can be one of several object types without requiring those types to share fields. AddToCartOutput must therefore be a union of ConfigurableProduct and Cart, with a type resolver that determines the concrete returned type. The mutation’s AddToCartOutput! return type ensures that one of those results is non-null.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!

QuestionQ4

Store Operations and Admin

An Adobe Commerce Architect must log the result of a ServiceClass::getData method execution after every plugin has run. The method is public, and several plugins are declared for it. These plugins include after and around types, and each has a specified sortOrder.

Which solution should be used to satisfy this requirement?

  • A Declare a new plugin with the sortOrder value higher than the highest declared plugin sortOrder and implement afterGetData method.
  • B Declare a new plugin with the sortOrder value lower than the lowest declared plugin sortOrder and implement aroundGetData method.
  • C Declare a new plugin with the sortOrder value higher than the highest declared plugin sortOrder and implement aroundGetData method.
Explanation

An around plugin with the lowest sortOrder wraps every higher-priority-numbered plugin execution. Logging after its $proceed() call returns occurs only after the observed method and all subsequent plugins—including their after methods and the post-proceed portions of their around methods—have completed. Adobe Commerce documents that around plugins affect the execution flow of all plugins that follow them and that plugin priority is determined by sortOrder.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!

QuestionQ5

Catalog and Products

A company operates an Adobe Commerce store. An attribute called “my_attribute” (type “text”) was created to store every product’s global ID, which is shared across multiple systems.

Several months after go-live, all “my_attribute” values are integers. This creates an issue for the other systems when they receive this data.

An Adobe Commerce Architect must recommend a solution to change “my_attribute” from type “text” to “int”.

Which two actions should the Architect take to accomplish this?

Choose two
  • A Migrate data from table “catalog_product_entity_text” to “catalog_product_entity_int” for the attribute_id
  • B Go to Admin > Stores > Attributes > Product, edit “my_attribute” and update type from “text” to "int"
  • C Write a plugin for \Magento\Eav\Model\Entity\Attribute\Backend\AbstractBackend::afterLoad() and load data from “catalog_product_entity_int”
  • D Create a Data Patch and update “my_attribute” type from “text” to “int”
  • E Run the command bin/magento indexer:reset catalog_product_attribute
Explanation

Product EAV values are persisted in backend tables determined by the attribute’s backend type; text values reside in the text backend table and integer values in the integer backend table. A Data Patch provides the version-controlled mechanism to update the attribute definition, while the existing rows for that attribute must be migrated from catalog_product_entity_text to catalog_product_entity_int so the values remain available after the backend type changes. Adobe’s documentation describes defining product attributes programmatically with a Data Patch and identifies catalog_product_entity_int as the integer attribute backend table.

Learn more

Community Discussion

No comments yet. Be the first to start the discussion!

That's the end of the preview

It's free

100% of the questions are free for all users.
No strings attached.

Topics covered
Catalog and ProductsPromotionsOrders, Payments, Shipping, and TaxCustomersContent, CMS, and StorefrontStore Operations and Admin
Know a question that should be here? Contribute to this exam
Back home