AD0-E134 Adobe Experience Manager Sites Developer Exam Topics and Questions

AEM developer environments are deceptively easy to get running and surprisingly easy to misconfigure. This topic covers the operational layer that every other topic depends on: getting an instance up, locking it down, wiring up replication, tuning the Dispatcher, and keeping the platform current with service packs and hotfixes. Get any of those wrong and the code you write in later topics either misbehaves in ways that are hard to trace, or it works locally and breaks in staging.

– Standing up the instance and controlling access

Installing an AEM developer instance involves more than running a JAR. The exam tests whether you know the correct runmodes, the expected directory structure, and the sequence of steps that produce a stable starting state. From there, access control becomes the immediate concern. Users and groups in AEM sit on top of the JCR repository, and ACL permissions are applied at the node level. The examinable detail is the order of operations: create the group structure first, apply permissions to paths, then assign users to groups. Reversing that order or assigning permissions directly to users rather than groups is the kind of shortcut the exam treats as wrong.

– Replication, Dispatcher, and keeping the platform current

Replication agents connect author to publish, and the exam focuses on how you configure, enable, and test them rather than on their internal mechanics. Knowing the difference between a default replication agent and a reverse replication agent, and when each is appropriate, is the kind of distinction that changes an answer. Dispatcher configuration is tested procedurally: given an existing setup, what do you change and where? The exam does not ask you to build a Dispatcher from scratch but to apply changes to an existing one correctly. Service pack and hotfix installation follows a defined sequence, and the exam rewards knowing that sequence, including the steps you must take before and after applying a patch to avoid corrupting a running environment.

How Installation and Configuration of AEM is tested

At 9%, this topic produces a small but focused set of items. They tend to be procedural: you are given a scenario describing an environment state and asked what to do next, or what went wrong. Items on ACL setup reward candidates who know that permissions are evaluated from the most specific path upward and that deny rules take precedence over allow rules at the same level. Replication agent items reward knowing which fields matter for connectivity and where to look when a replication queue stalls. Dispatcher items are typically scenario-based: a caching rule is behaving unexpectedly and you need to identify the cause in the configuration. The most common place candidates lose marks here is on service pack sequencing, either skipping prerequisite steps or misidentifying which console to use to verify a successful installation. Vague answers about 'applying the patch' do not score; the exam wants the specific sequence.

At 35%, this is the largest topic on the exam by a significant margin, and it maps directly to the daily work of an AEM Sites developer. The breadth is real: custom components, Touch UI dialogs, clientlibs, Core Component extension, editable templates, FileVault export, and workflow steps all appear here. Depth varies by sub-topic, but the exam consistently tests whether you can make the right architectural choice, not just whether you know the syntax.

– Building and wiring custom components

Custom component creation in AEM involves both the Sling resource type hierarchy and the Touch UI dialog structure. The exam tests whether you know how to construct a dialog correctly in Granite UI, including the node types, the property names that bind dialog fields to the content repository, and the difference between design dialogs and edit dialogs. Getting a field to persist to the right JCR property is a common item type. Clientlibs are tested alongside components because they are how CSS and JavaScript reach the page. The examinable details are the categories system, the embed and dependencies properties, and the correct folder structure under /apps. Candidates who treat clientlibs as a simple file-drop location lose marks on items that require understanding how the library is loaded and in what order.

– Extending Core Components and using AEM APIs

Extending out-of-the-box components and Core Components is tested as a design decision, not just a coding task. The exam asks which extension mechanism is appropriate in a given scenario: Sling Models delegation, HTL use-class, or a full overlay. Each has a context where it is the right answer and contexts where it introduces unnecessary complexity or breaks upgrade paths. AEM's out-of-the-box APIs, particularly the PageManager, ResourceResolver, and Tag Manager interfaces, appear in items where you must identify which API call produces a specific result. The exam rewards knowing the return types and the failure modes, not just the method names.

– Templates, FileVault, and workflow

Editable templates are tested with an emphasis on the policy and structure layers: what is locked at the template level, what is configurable per page, and where those settings live in the repository. Static templates still appear in exam scenarios involving legacy codebases. FileVault (vlt) commands are tested procedurally: the exam gives you a goal, such as exporting a component to the local filesystem or checking in changes, and asks for the correct command or sequence. Workflow is the narrowest sub-topic here. Items focus on implementing custom workflow steps and process steps as OSGi services, and on understanding where a process step's logic executes relative to the workflow engine.

How Templates and Components is tested

The weight means you will spend a large portion of the exam in this territory, and the items span a wide range of granularity. Some test a single property name in a dialog node; others present a multi-step scenario and ask which approach is architecturally sound. The trap that costs candidates most is conflating the overlay mechanism with the inheritance mechanism. Overlaying a component under /apps mirrors its structure but does not inherit updates from the original; extending via Sling Models delegation does. Items in this topic reward knowing when each approach is correct, not just that both exist. Clientlib items reward precision about loading order and category resolution. Template items reward knowing the distinction between what a template author controls and what only a developer can change. Workflow items are typically the least-weighted within the topic, but they appear, and candidates who skip them entirely pay for it.

Moving from the component layer into the service layer, OSGi is where AEM's runtime modularity lives. At 17%, this topic carries real weight, and it tests a kind of knowledge that is harder to guess your way through: the wiring of services, the lifecycle of bundles, and the configuration model are all precise, and the exam exploits that precision. If your OSGi knowledge comes from copying annotations without understanding what they do, this topic will expose that.

How OSGi Services is tested

With three sub-topics, the items here are concentrated rather than scattered. Custom OSGi service creation is tested at the annotation level: @Component, @Service, @Reference, and @Activate all carry specific semantics, and the exam distinguishes between them. Items reward knowing the difference between a component and a service in OSGi terms, and what happens when a required reference is unsatisfied. Configuration items test both the code path, using @Designate and a configuration interface, and the Felix console path: where configurations are stored, how factory configurations differ from singleton ones, and what a configuration PID is. Bundle management items are procedural: installing, starting, stopping, and resolving dependency issues. The most common loss of marks is on bundle states. Candidates who can only identify 'Active' and 'Installed' miss items that turn on recognising why a bundle is stuck in 'Resolved' or 'Installed' rather than transitioning to 'Active', and what the dependency graph looks like when that happens.

After the service layer comes delivery: getting your code and content into AEM reliably and repeatably. At 22%, this topic is more focused than its weight might suggest. It covers two things: building content packages with Maven and deploying them, either through Maven or through the Package Manager manually. The narrowness is deliberate. The exam tests whether you can execute the full build-and-deploy cycle correctly, not whether you understand every Maven plugin in existence.

How Packaging and Deploying AEM projects is tested

With only two sub-topics, the items go deep rather than wide. Maven-based package creation is tested through the filevault-package-maven-plugin and the content-package-maven-plugin, and the exam distinguishes between them. Items reward knowing which plugin produces which output, how the filter.xml controls what goes into a package, and what happens when the filter is too broad or too narrow. Deployment items test both the manual path through the Package Manager UI and the Maven deployment path using the autoInstallPackage profile. The exam rewards knowing the sequence for manual installation, including the order in which dependent packages must be installed, and the Maven properties that control where a package is deployed. The trap here is assuming that any Maven command that compiles the project also deploys it. Items reward candidates who know which goal or profile triggers deployment separately from the build. Candidates who have only ever used an IDE plugin without understanding the underlying Maven lifecycle tend to lose marks on the sequencing items.

The final topic shifts from building to diagnosing. At 17%, it carries the same weight as OSGi Services, and it is the topic that most closely mirrors what separates a developer who can build features from one who can own them in production. Logging, remote debugging, system console analysis, browser-side tools, and Dispatcher cache debugging all appear here. The exam tests whether you can navigate a broken environment systematically, not whether you can recite error codes.

– Logging and remote debugging

Custom log configuration in AEM is done through the Apache Sling Logging Logger Configuration OSGi factory. The exam tests the specific fields: the log level, the log file path, and the logger name, which maps to a Java package. Getting the logger name wrong means the custom log captures nothing, and the exam has items built around that failure mode. Changing log levels for existing loggers, including the root logger, is also tested. Remote debugging requires configuring the JVM debug port at startup and connecting an IDE to it. The exam tests the correct JVM argument syntax and where it is applied in an AEM installation. Items reward knowing that remote debugging must be enabled before the JVM starts, not patched in afterward.

– OSGi bundle issues and system consoles

Troubleshooting OSGi bundles at runtime means reading the Felix Web Console accurately. The exam presents bundle states and dependency graphs and asks you to identify the root cause of a failure. A bundle stuck in 'Installed' state means its dependencies are not met; a bundle in 'Resolved' state means it is wired but not yet started. Items reward knowing the difference and knowing where to look for the missing dependency. The system consoles tested extend beyond Felix: the Sling request resolver console, the query performance console, and the repository browser all appear in scenario-based items. The exam rewards knowing which console to open for a given class of problem, not a general familiarity with the console URL list.

– Page rendering, log file analysis, and Dispatcher cache

Browser-side troubleshooting covers the developer tools most relevant to AEM page rendering: network tab analysis for clientlib loading order, the DOM inspector for component markup, and the console for JavaScript errors tied to clientlib categories. The exam gives you a symptom and asks which tool and which view within that tool surfaces the cause. Log file analysis is scenario-based: given a log snippet or a description of what the log contains, identify the correct method to access it and what the relevant entries mean. Dispatcher cache troubleshooting is the most nuanced sub-topic in this group. Items turn on understanding which requests are cached, which headers invalidate cache entries, and how the /cache and /rules sections interact. A cached page that should have been invalidated and a request that should have been cached but was not are both common item scenarios.

How Troubleshooting AEM projects is tested

The items in this topic are almost entirely scenario-based. You are given a broken or misbehaving system and asked to identify the cause, the tool, or the next step. That format rewards candidates who have actually diagnosed AEM problems, not just read about the tools. The most common place marks are lost is on Dispatcher cache items, where candidates apply general HTTP caching knowledge instead of Dispatcher-specific rules. AEM's Dispatcher has its own invalidation model, and the exam exploits the gap between generic caching intuition and that specific model. Log analysis items reward knowing the log file locations and the correct Felix console path to change a log level at runtime, not just the OSGi configuration file approach. Remote debugging items reward precision on JVM argument syntax. Candidates who know the concept but not the exact form of the argument lose marks on items where the distinction between similar-looking options is the only thing being tested.