Adobe Commerce Architect Master common mistakes
Adobe Commerce Architect Master · Understand the traps and how to avoid them.
Placing all custom logic in a single module and putting controllers, models, and observers in a flat directory structure without separating business logic into service contracts and API interfaces.
Candidates coming from Magento 1 or from procedural habits treat modules as a place to dump code, and the exam's architecture questions reward understanding of service contracts, dependency inversion, and module boundaries rather than raw working code.
What to do instead
For each scenario, sketch the module boundary first: define the API interface (service contract) with data interfaces, implement it in a model, and wire it via di.xml preferences. Practise refactoring a fat controller into a service class plus a thin controller that only reads input and returns a result.
Answering database-design questions by adding a new EAV attribute for every new field, including fields used for reporting, filtering, or high-volume writes.
EAV is the default mental model for product and customer data, so candidates over-apply it, ignoring the join cost and the fact that the exam distinguishes EAV from flat and extension tables.
What to do instead
Classify each new field before answering: is it a first-class entity attribute needing store-scoped values (EAV), or a high-volume transactional or reporting field (dedicated extension table with a foreign key)? Be ready to justify the choice with query patterns and indexing.
Designing integrations that call the REST API synchronously inside a customer-facing request, or that poll the database directly instead of using the message queue and asynchronous consumers.
Synchronous code is easier to test locally, so candidates default to it and miss that the exam tests resilience, decoupling, and the role of message queues and webhooks in integration architecture.
What to do instead
For every integration scenario, state the sync/async decision explicitly: publish to the queue for non-blocking work, use consumers with retry and dead-letter handling, and reserve synchronous REST for cases where the caller needs an immediate response. Name the failure behaviour when the remote system is down.
Treating caching as a single switch, giving answers that say 'enable the cache' without distinguishing full-page cache, block cache, configuration cache, and the private-content/Varnish layer.
In day-to-day work the cache is usually just 'on', so candidates never internalise which layer handles which content type and how cache tags and TTLs interact.
What to do instead
Build a one-page map of cache layers: what each stores, what invalidates it (cache tags, TTL, config changes), and which layer serves personalised versus shared content. Practise tracing a product price change through each layer to see what gets purged.
Answering security questions with 'use ACLs' alone, without addressing input validation, output escaping, CSRF protection, or the distinction between authentication and authorisation.
ACLs are the most visible security feature, so candidates stop there and miss that the exam probes layered defence and the specific mechanisms (form keys, escaping contexts, admin versus frontend ACL resources).
What to do instead
For each security scenario, enumerate the layers: validate and sanitise input, escape output per context, enforce CSRF form keys on state-changing requests, and then apply ACL resources and roles. State where each control lives in the request lifecycle.
Describing deployment as 'run setup:upgrade and deploy static content' without sequencing, mode awareness, or a rollback path, and without separating build-time from deploy-time steps.
Local workflows collapse build and deploy into one command sequence, so candidates never learn which steps belong in CI, which require downtime, and how production mode changes what is safe to run.
What to do instead
Write the pipeline as ordered phases: build (composer install, DI compile, static content deploy) producing an immutable artifact, then deploy (maintenance mode, schema/data upgrade, cache flush, smoke test), then verify and roll back by redeploying the prior artifact. Note which steps differ between developer and production mode.
Configuring cloud environments by editing files directly on an environment or hardcoding credentials and service values into committed configuration, rather than using environment variables, the configuration management flow, and per-environment overrides.
It works in the moment and is faster than learning the configuration hierarchy, but the exam tests understanding of the file hierarchy, environment-specific overrides, and the build/deploy configuration flow.
What to do instead
Practise the hierarchy explicitly: base configuration, environment-specific overrides, and sensitive values supplied as environment variables or secrets. For any scenario, state where the value should live and how it flows from repository to running environment.
Designing storefront customisation that overrides core templates and layouts directly, or that relies on JavaScript that bypasses the Knockout/UI component and RequireJS layering.
Direct overrides are the quickest way to make a change visible, so candidates default to them and miss that the exam rewards extension via layout XML, theme inheritance, plugins, and the defined frontend component architecture.
What to do instead
For each frontend scenario, choose the least invasive extension point in order: layout XML and blocks, theme inheritance and fallback, then plugins or preferences only where necessary. For interactive components, describe the UI component configuration and RequireJS module rather than a script tag.
Ignoring the difference between the three deployment modes and the implications for generated code, DI compilation, and static files, then giving answers that would break in production mode.
Most candidates develop only in developer mode, so the constraints of production mode (no on-the-fly generation, no symlinks for static content, stricter error handling) are unfamiliar.
What to do instead
Learn the mode matrix: what each mode does with generated code, static files, and errors. For any deployment or troubleshooting answer, check it against production mode and adjust the steps accordingly.
Answering scalability questions with 'add more servers' or 'use a CDN' without identifying the bottleneck, the data-consistency implications, or the session and media storage strategy for multi-node setups.
Horizontal scaling is the intuitive answer, so candidates skip the analysis step and miss that the exam tests identification of the constraint (database, cache, session, media) and the trade-offs of each scaling approach.
What to do instead
Structure every scalability answer as: identify the bottleneck with evidence, choose the scaling mechanism, then state the consistency and operational consequences (shared session storage, shared media, cache invalidation across nodes, database read replicas and lag).