AEM Sites Architect Master common mistakes
AEM Sites Architect Master · Understand the traps and how to avoid them.
Treating editable template policies as global by choosing 'All' or leaving policy mapping empty when the requirement says two site sections must allow different column layouts and component sets.
Candidates memorise that policies are 'attached to templates' and forget the Design Mode / policy mapping step that scopes a policy to a specific template, page, or section, so they answer as if one policy must serve everything.
What to do instead
When a scenario requires divergent authoring constraints, state explicitly that you create separate policies and map them per template or per page subtree in the template's policy configuration, then verify inheritance from the template root down.
Answering that content fragment variations change the underlying model fields, or that a variation can add fields the model does not define.
Confusion between the model (schema, defined by the data type and field set) and variations (named content permutations of that same schema) leads to answers that promise schema changes from the authoring UI.
What to do instead
Anchor on the rule: the model defines fields; variations only supply alternative values for the same fields. To change structure you version the model and, where needed, create a new model or migrate content.
Proposing to publish code or configuration by replicating packages from author to publish, or by editing files directly on a publish instance.
On-premise habits carry over; candidates describe manual replication or direct file edits instead of the Cloud Manager pipeline, and forget that publish instances are immutable in AEM as a Cloud Service.
What to do instead
Describe the deployment path as commit to the Cloud Manager git repository, pipeline build, and deployment of the code and content package; runtime configuration goes through OSGi config, Cloud Manager environment variables, or config pipelines, never manual publish edits.
Writing Dispatcher rules that allow caching of authenticated or personalised responses, or omitting the statfile invalidation step when content is activated.
Candidates focus on the /cache and /rules sections and treat flush as automatic, forgetting that the dispatcher.any statfile and the flush agent are what make invalidation happen.
What to do instead
State the full loop: author activation triggers the replication flush agent, which calls the Dispatcher flush endpoint to update the statfile; and add explicit rules to bypass cache for requests carrying session cookies, Authorization headers, or personalised selectors.
Granting permissions by adding users to the administrators group, or by assigning ACLs at the root /content node, to solve a small scoped access requirement.
Broad grants are the quickest way to make a test scenario 'work', and candidates under-use group-based ACLs at the narrowest node with rep:glob restrictions.
What to do instead
Model least privilege: create a project-specific group, apply allow ACLs at the narrowest content path, use rep:glob to exclude sensitive subtrees, and deny or omit read on /apps, /libs, and /conf where not needed.
Describing a headless delivery design that returns the full content fragment JSON to the browser without considering the GraphQL persisted query allow-list or the Content Delivery endpoints.
Candidates know GraphQL exists but not the Cloud Service controls around it, so they design direct arbitrary queries against the author instance or skip caching considerations entirely.
What to do instead
Specify persisted queries registered and allow-listed in the Cloud Service environment, executed against the publish-tier GraphQL endpoint, with Dispatcher/CDN caching and a client-side strategy that respects the query allow-list.
Assuming a component's HTL/Sling Model behaviour is identical between author and publish, or forgetting that client libraries must be built through the pipeline rather than uploaded as /etc/clientlibs packages.
Legacy workflows allowed uploading clientlib packages to /etc; on Cloud Service that path is not the supported deployment route, and candidates answer from older on-premise experience.
What to do instead
Place clientlibs in the codebase under /apps with the appropriate categories and embed/dependencies, build them with the front-end pipeline, and include the clientlib on pages via the template or component policy rather than manual package upload.
On a migration or upgrade scenario, proposing in-place upgrades of a legacy instance to the current release without an audit of deprecated APIs, removed features, and customisations.
Candidates underestimate the analysis phase and jump to a target-state architecture, skipping the content and code audit that determines feasibility.
What to do instead
Structure the answer as audit (deprecated APIs, custom overlays under /apps, workflows, replication agents), then remediation, then content migration via a tool such as the Content Transfer Tool or a package-based approach, then regression testing.
Diagnosing a slow page by recommending more JVM heap or a larger publish instance before checking Dispatcher cache hit ratio, query performance, and component-level request counts.
Troubleshooting answers default to infrastructure scaling because it is easy to name, while the exam expects a layered diagnosis from CDN/Dispatcher inward.
What to do instead
Work outward-in: CDN and Dispatcher hit ratio and cache rules, then number of component requests and clientlib weight, then JCR queries (explain, indexes), then JVM and thread dumps only after the request path is understood.
Choosing a multi-site architecture that duplicates templates and components per site instead of using shared editable templates with per-site policies and language copies or live copies.
Candidates equate site isolation with code duplication, missing that editable templates plus policy mapping and MSM provide isolation without forking the component library.
What to do instead
Propose one shared component and template set in the project, per-site policies for authoring differences, MSM live copies or language copies for content, and separate site roots under /content with their own conf folders only where branding truly diverges.