AD0-E137 Adobe Experience Manager Sites Developer Expert Exam Topics and Questions

Configurations is where the exam tests your ability to make AEM behave correctly before a single line of custom code is written. Dispatcher rules, SAML and LDAP wiring, replication agents, multi-tenancy setup, and editable template models all live here. Get any one of them wrong in production and the site either breaks or ships insecure content. The exam knows this and will push you into realistic scenarios where the wrong configuration choice has a plausible-looking justification.

– Dispatcher and replication

Dispatcher rules are the most scenario-heavy part of this topic. You will be given a caching or access-control situation and asked to identify which rule type applies: filter rules, cache invalidation, header handling, or something else. The trap is that multiple rule types can appear relevant, but only one fits the described behaviour precisely. Work backwards from the outcome the scenario describes, not forwards from the rule you remember best.

Replication agents connect your author and publish tiers. The exam tests whether you know how to set up agent transport, flush agents, and reverse replication, and which settings govern each. Mistakes here usually come from confusing the direction of replication or misidentifying which agent type handles a given content flow.

– Identity, access and multi-tenancy

SAML and LDAP integration questions ask you to work through the OOTB configuration steps in order. Both are out-of-the-box features, so the exam is checking whether you know the specific OSGi service configurations, the keystore requirements for SAML, and the bind credentials and search base settings for LDAP. Candidates lose marks by confusing SAML handler properties with generic authentication handler settings.

Multi-tenancy configuration tests your understanding of how AEM isolates content trees, permission sets, and configurations across tenants. The exam will give you a business scenario and ask you to determine which steps are required. The common error is treating multi-tenancy as purely a permissions question when it also involves run-mode-scoped configurations and separate site roots.

– Templates and content fragment models

Editable templates and content fragment models are grouped here because both involve a structured authoring setup that must be configured before authors can work. For editable templates, the exam focuses on the steps to enable a template type, set policies, and control which components are allowed. Candidates who only know page templates from a development angle often miss the policy-inheritance chain.

Content fragment models are tested on their configuration path, their field types, and how they relate to GraphQL endpoints in a headless delivery scenario. Know where models live in the repository and how enabling the feature flag differs from creating an individual model. The exam rewards precision on these steps, not general awareness that the feature exists.

How Configurations is tested

At 24% of the exam, Configurations produces a significant portion of your items. Nearly all of them are scenario-based: you are given a described environment, a stated requirement, and asked to select the correct sequence of steps or the correct rule type. This format punishes candidates who have read about a feature but never configured it, because the distractors are written to match partial knowledge.

The most common place candidates drop marks is in the ordering of steps. Dispatcher filter rules, SAML setup, and replication agent configuration all have a specific sequence where doing step three before step two produces a broken result. Items reward knowing that sequence exactly, not just knowing that all the steps exist.

A second pressure point is distinguishing OOTB behaviour from custom development. Several sub-topics involve features that work out of the box given the right configuration. Items reward recognising when you should configure an existing capability rather than build a new one. Reaching for custom code when an OOTB setting exists is a consistent wrong-turn in this topic.

AEM Development carries the heaviest weight on the exam, and it earns that weight by covering the widest technical ground. Where Configurations tests your knowledge of settings and sequences, this topic tests your ability to reason through code-level decisions: which Sling model annotation, which servlet registration property, which JCR query syntax. The scenarios here are closer to code review than to checklist recall, and the distractors are often syntactically plausible but semantically wrong.

– SPA, Sling models and component structure

SPA development questions test the relationship between the SPA framework structure, Sling Model Exporter, and the JSON output that drives a client-side application. You need to know how @Model and @Exporter annotations work together, what the Sling Model Exporter delegates to, and where the component's HTL fits when the SPA editor is involved. The trap is assuming SPA components work like classic AEM components in every respect: the JSON contract and the editing layer introduce constraints that classic development does not have.

Custom component creation is tested end to end: HTL expressions, Use-API versus Sling Model, and the OSGi service layer beneath it. Items reward knowing which layer to put logic in. Business logic in HTL and presentation logic in a service are both examined as wrong approaches, so the distinction must be clear before exam day.

– OSGi services, servlets and API integration

OSGi service questions turn on the details of component annotations, service ranking, and how the container resolves competing service registrations. The exam gives you a requirement and asks you to identify the correct approach: whether to use an OSGi service, a Sling servlet, or a specific servlet registration type. Candidates lose marks by selecting a servlet type that would work in isolation but conflicts with the described security or URL constraints.

Third-party API integration scenarios test whether you understand how to wire an external HTTP client inside AEM's OSGi container, handle authentication, and manage configuration through OSGi rather than hardcoding values. The exam does not ask you to write code, but it does ask you to identify which approach or which class is appropriate given a constraint. Knowing the AEM HTTP client bundles and when to use them over a raw Java approach is worth reviewing.

– Unit testing and JCR queries

Unit testing questions focus on the AEM Mocks framework. You are expected to know how to set up a mock context, load content from a JSON fixture, and adapt resources to Sling models for testing. The exam rewards knowing how mock data is structured and loaded, not just that mocking is possible. Candidates who have only used integration tests often underestimate how specific these questions get.

JCR query questions ask you to select the appropriate query language and syntax for a described retrieval scenario. SQL2 and XPath are both in scope. The exam tests whether you know when a query would traverse the repository versus use an index, and which query type suits a given content structure. Selecting an inefficient query that technically returns the right result is a trap the exam sets deliberately.

How AEM Development is tested

At 33%, this topic drives more of your final score than any other. Items are almost entirely scenario-based, and the scenarios are technical: a described component requirement, a failing unit test, a servlet that needs to match a specific URL pattern. You are not asked to recall definitions. You are asked to pick the approach that actually works given the constraints stated.

The distractors in this topic are carefully constructed. Wrong options often use real class names or annotation names in plausible combinations that would not compile or would not behave as described. Items reward knowing why a particular annotation or registration property is necessary, not just that it exists.

Candidates most often drop marks on OSGi service resolution and on JCR query selection. For services, the failure mode is ignoring the ranking or the interface being registered against. For queries, it is selecting a query that returns correct results without considering traversal cost. The exam treats performance-unaware queries as wrong answers even when they are functionally correct. Reviewing the difference between indexed and unindexed query patterns before sitting is time well spent.

Build and Deployment shifts the focus from writing and configuring AEM features to shipping them reliably. The skills tested here sit at the boundary between development and DevOps: Maven project structure, dependency management, run mode configurations, workflow setup, and Oak index management. Candidates who have always worked with a pre-built pipeline often find this topic harder than expected, because the exam asks about the mechanics of the build and deployment process rather than its outputs.

– Maven, archetypes and dependency management

Maven archetype questions are scenario-based: you are given a project requirement and asked to identify the correct archetype command and its key parameters. The AEM Project Archetype is the standard starting point, and the exam tests whether you know the parameters that control what gets generated, including the package group, the app ID, and the AEM version target. Getting the command right but the parameters wrong is a common source of lost marks.

Front-end and back-end dependency management are tested separately. For back-end, the exam focuses on how Maven reactor builds order modules and resolve inter-module dependencies. For front-end, the focus is on how the ui.frontend module integrates with the Maven build via the frontend-maven-plugin and what happens when the dependency graph is misconfigured. Candidates who treat the front-end build as separate from Maven often miss questions about where failures surface.

– Run mode configurations and workflows

Run mode configuration questions ask you to identify the correct folder naming convention and OSGi configuration file placement for a given environment. The exam gives you a scenario with multiple environments and asks which configuration will apply. The trap is that AEM supports compound run modes, and candidates who only know single run modes make wrong calls when the scenario stacks two of them.

Workflow configuration is tested at the setup level, not the implementation level. The exam wants you to know how to configure workflow launchers, models, and transient workflows, and which approach suits a described content-processing requirement. The distinction between a transient workflow and a persistent one is a recurring decision point. Choosing the wrong type for the described volume or durability requirement is where candidates drop marks.

– Oak indexes

Custom Oak index questions test both creation and lifecycle management. You need to know the index definition node structure, the difference between Lucene and property indexes, and the re-indexing process including its performance implications. The exam gives you a scenario involving a slow or failing query and asks you to determine the appropriate index type and configuration.

A common error is selecting a Lucene index for a case where a property index is sufficient, or vice versa. The exam rewards matching index type to query pattern rather than defaulting to the more powerful option. Re-indexing questions focus on when it is required and how to trigger it without taking the repository offline unnecessarily. Knowing the async indexing lanes and their configuration is worth specific attention before sitting.

How Build and Deployment is tested

At 25%, Build and Deployment is the second-heaviest topic by weight. Items here tend to be more procedural than the AEM Development items: the exam is checking whether you can identify the right step, the right command, or the right configuration file placement in a described situation.

The Maven and run mode questions reward precision on naming conventions and parameter values. Vague familiarity with the archetype or with run mode folders is not enough. The exam will give you options that are close but wrong in a specific character or folder level, and items reward catching that difference.

Oak index questions are where technically strong candidates sometimes underperform, because index management is often handled by a DBA or platform team in practice. The exam treats it as a developer responsibility. Items reward knowing the index type decision criteria and the re-indexing trigger process.

Workflow questions reward distinguishing configuration intent from implementation detail. The exam is not asking you to write a workflow step; it is asking you to select the correct launcher condition or model type for a described business process. Candidates who over-rotate toward implementation detail miss these.

Environment Maintenance closes the exam with the operational side of AEM: keeping environments consistent, managing releases, moving content and configurations between instances, and selecting the right tool when something needs fixing. After three topics that test what you build, this one tests what you do when the system is live. The scenarios here are closer to day-two operations than to initial development, and candidates who have only worked in development environments sometimes find the tool-selection questions unfamiliar.

– Environment configuration and release management

AEM environment configuration questions ask you to determine the correct steps for managing settings across author, publish, and dispatcher tiers in a described scenario. The exam is looking for decisions that account for environment-specific differences, not a one-size-fits-all configuration push. Candidates who treat all environments as identical lose marks on questions where the correct approach differs by tier.

Release management questions focus on the AEM release process: service packs, cumulative fix packs, and how they are applied. The exam tests whether you know the sequence and the preconditions, not just that patches exist. A common mistake is assuming a newer fix pack can be applied without the base service pack it requires. Know the dependency chain and the verification steps that follow an update.

– Package manager and maintenance tools

Package manager questions test your ability to use it as a synchronisation tool across AEM environments, not just as an installation mechanism. The exam gives you a scenario involving content or configuration drift between environments and asks you to identify the steps to resolve it using package manager. The detail that matters is filter path configuration and build order, because a poorly scoped package can overwrite content it was not meant to touch.

Maintenance tool questions present a described problem and ask you to identify which tool applies: the repository checker, the data store garbage collector, the workflow purge, the version purge, or another OOTB maintenance task. The trap is that several tools address overlapping symptoms. Items reward selecting the tool whose scope matches the described problem exactly, not the most powerful tool available. Knowing what each maintenance task actually touches in the repository is the deciding factor.

How Environment Maintenance is tested

At 18%, Environment Maintenance is the lightest topic by weight, but it is not a safe topic to under-prepare. The items here tend to be tool-selection and step-identification questions, and the distractors are drawn from tools and steps that are adjacent but wrong for the described scenario.

Package manager questions reward knowing the filter configuration in detail. Candidates who know that package manager can sync content but do not know how filter paths control scope will pick options that are directionally correct but practically dangerous.

Release management items reward knowing the dependency sequence for fix packs and service packs. The exam does not ask you to recite version numbers, but it does ask you to identify whether a described update sequence is valid.

Maintenance tool questions are the most scenario-driven in this topic. Items reward matching the tool to the specific symptom: a repository size problem points to different tools than a workflow backlog does. Candidates who default to the most powerful or most familiar tool without reading the scenario carefully are the ones this topic catches out.