AEM Business Practitioner common mistakes
AEM Business Practitioner · Understand the traps and how to avoid them.
Treating the publish instance as if it were the author instance and expecting to create or edit pages there, or looking for authoring tools on the publish tier.
Candidates conflate the two environments because both look similar in the UI, and they forget that authoring capabilities are stripped from publish.
What to do instead
Memorize the author/publish split: content is created and edited on author, then replicated to publish. When a scenario asks 'where do I do X', first ask whether X is an authoring action or a delivery action.
Confusing a page's template with its components, or expecting a template to be edited directly on a live page.
Templates, components, and page properties all appear in the same editing context, so candidates mix up what controls layout versus what controls content.
What to do instead
Separate the layers: templates/editable templates define allowed structure and policies, components provide the building blocks, and page properties hold page-level metadata. Map each question to the layer it is really about.
Assuming deleting an asset from the Assets UI also deletes every published or referenced copy, or assuming it stays referenced safely.
Candidates underestimate how references and replication interact with deletion, and they answer from a single-instance mental model.
What to do instead
Learn the delete-versus-unpublish distinction and the role of reference checking before deletion. For each asset question, ask: is this about the repository, the publish tier, or a referencing page?
Treating a workflow as a single approval step and missing that a workflow model is a multi-step process with participants, steps, and transitions.
The approval UI looks simple, so candidates answer as if approval is one click rather than an orchestrated model.
What to do instead
Describe workflows in terms of model, steps, participants, and payload. When a scenario mentions routing, multi-stage review, or notifications, think workflow model rather than a single publish action.
Confusing personalization (targeted content for known/segmented audiences) with Experience Fragments (reusable content variations exported to other channels).
Both involve variations and reuse, so the terms blur under time pressure.
What to do instead
Anchor each concept by purpose: personalization selects what a visitor sees based on audience data; Experience Fragments package content for reuse across channels. Match the scenario's goal to the purpose, not the vocabulary.
Granting permissions at the wrong level, such as giving a user broad access instead of adding them to an appropriate group with the right privileges on the right path.
The permission UI invites direct assignment, and candidates forget that group-based, path-scoped privileges are the intended model.
What to do instead
Default to group membership plus path-scoped privileges, and check whether the scenario needs read, write, replicate, or delete on a specific node. Verify least-privilege before choosing an answer.
Expecting real-time reporting data to be immediately complete, or treating analytics and campaign data as if they update instantly.
Candidates assume dashboards are live, forgetting that reporting and analytics often depend on processed or aggregated data.
What to do instead
Distinguish operational data available immediately from analytics and campaign reporting that depends on collection and processing. When a question asks about timing or completeness, consider the data pipeline.
Publishing a page and assuming all referenced assets and child pages go live automatically.
The publish action feels global, but replication scope depends on what is selected and configured.
What to do instead
Check replication scope explicitly: page versus tree, referenced assets, and any related dependencies. For each publishing scenario, list what is actually included before answering.
Editing a live page's structure by changing the underlying template or component policy and expecting existing pages to update without republishing.
Candidates treat template/policy changes as instantly reflected everywhere, ignoring how existing content and published pages behave.
What to do instead
Trace the change path: template or policy change, effect on author content, then replication to publish. Ask whether the change affects new pages only or existing pages, and whether republishing is required.
Answering navigation questions by describing menus or links without connecting them to the site structure and page hierarchy that generate them.
Navigation appears as a UI widget, so candidates forget it is derived from page structure and configuration.
What to do instead
For navigation and site-structure questions, start from the page tree and hierarchy, then consider the navigation component's configuration. Explain how the structure produces the menu before selecting an answer.