AEM Sites Business Practitioner Expert common mistakes
AEM Sites Business Practitioner Expert · Understand the traps and how to avoid them.
Treating the publish tier as if it renders pages live from authored content, and answering that template or component edits appear on the site immediately after saving.
In author the content is editable and reflects changes at once, so candidates generalize that behaviour to the public site and forget that content must be activated to the publish instance.
What to do instead
Separate the two tiers in your head: author is for creating and previewing, publish serves activated content. For any 'when does the visitor see it' question, check whether the change was activated (and whether replication succeeded).
Answering that deleting or moving a page in the Sites console automatically removes it from the published site.
Author-side operations feel destructive because the page disappears from the tree, but publish keeps its own copy until a deactivation or delete is replicated.
What to do instead
Learn the author/publish lifecycle for pages: activate, deactivate, delete (which requires deactivation first or a delete replication). Map each console action to its publish-side effect before choosing an answer.
Choosing 'edit the component dialog and save' when a page needs a layout or content variation that the component does not support, instead of using the editable template and policy-driven structure.
Candidates spend most time in the page editor and default to dialog edits, overlooking that structure, allowed components, and responsive layout are governed at the template and policy level.
What to do instead
For layout/structure questions, think template editor first: static vs editable templates, layout containers, and policies that lock or permit components. Only fall back to dialog edits for content within an already-allowed component.
Confusing the component dialog with the design/policy dialog and picking the wrong place to set a default value or restrict a component's options site-wide.
Both dialogs look similar and are opened from the same component, but one stores per-instance content and the other stores shared configuration.
What to do instead
Remember: dialog = content for this instance; policy/design = shared rules and defaults for all instances under a template or page. Read the question for words like 'all pages', 'default', or 'restrict' to pick the policy.
Assuming a moved or renamed asset breaks all references, or conversely assuming references update everywhere with no follow-up needed.
Asset references are stored in content, and behaviour differs between references that AEM can track and hard-coded paths in components or external links.
What to do instead
Know that AEM tracks references for managed assets and can update them on move/rename, but untracked or hard-coded links must be found and fixed manually. When a question mentions external or hard-coded paths, plan a manual reference check.
Picking 'copy the asset into every page' when the requirement is to reuse the same image or content in many places and keep it maintainable.
Candidates reach for the simplest visible action (upload again) rather than the reuse mechanisms available, so they miss the efficiency and consistency the exam is testing.
What to do instead
For any 'used in many places' or 'update once' requirement, prefer referencing the shared asset or using content fragments/experience fragments over duplicating. Duplication is the wrong answer when maintainability is stated.
Assuming a workflow runs automatically on every asset or page change without checking the launcher or trigger configuration.
Workflows are often demonstrated as already running, so candidates forget that a launcher (or manual start) is what actually triggers them and that conditions can limit when they fire.
What to do instead
For workflow questions, identify the trigger explicitly: manual start from the console, a launcher on a node event, or a scheduled/periodic process. If the scenario says 'only for certain paths or types', look for launcher conditions.
Treating a workflow step's participant assignment as automatic and ignoring that a step may require a specific group or user to complete it, causing 'stuck' items in real scenarios.
Candidates focus on the workflow model and forget that inbox tasks are assigned to people or groups, and that a misconfigured participant stalls progress.
What to do instead
When a scenario describes items not progressing, check the step's participant/assignee configuration and whether the assigned group has access. Map each workflow step to who must act on it.
Answering personalization questions by describing a separate page per audience instead of using targeting with segments and experiences on a single page.
Candidates think in terms of static site structure and miss that AEM targeting swaps experiences within one page based on segment membership.
What to do instead
For 'different content for different visitors on the same URL' requirements, choose targeting: define segments, add targeted experiences to the component or page, and confirm the activity is enabled and published.
Ignoring permissions and group membership when a user reports they cannot see a page, an asset, or a workflow task, and instead blaming publishing or caching.
Candidates jump to content and replication causes because those are the domains they studied most, while access control is often the actual cause of 'I can't see it' symptoms.
What to do instead
For visibility problems, first confirm the user's group membership and the ACLs on the relevant path (including whether they can read on author vs publish). Rule out permissions before investigating replication or cache.