AD0-E117 Adobe Experience Manager Architect Master Exam Topics and Questions

Discovery sets the foundation for everything else on this exam. Where other topics ask you to design or build, this one asks you to listen, read between the lines, and translate what a business actually needs into something an architecture can address. The penalty for getting this wrong is not a failed test case; it is a solution that solves the wrong problem. Eighteen percent of the exam lives here, so gaps in this skill show up on your score sheet.

How Discovery is tested

Items in this topic present a business scenario, often with competing priorities or an existing AEM environment, and ask you to determine what the architecture must satisfy before any design work begins. The demand is translation: from a stakeholder's language to a technical constraint, or from an observed system state to an architectural gap.

The trap is jumping to a solution. Candidates who read a scenario and immediately think about which AEM feature to apply will miss items that reward stepping back to identify what the requirement actually is first. A second common loss is conflating functional and non-functional requirements. Knowing which category a constraint belongs to changes the design lever you reach for, and the exam tests that distinction directly.

Scenarios involving assessment of a current-state architecture reward candidates who can identify what is missing or misaligned, not just what is present. Expect to weigh a stated business goal against an architectural reality and name the gap precisely.

Once requirements are clear, Solution Design is where the exam puts most of its weight: 44 percent. This topic is where architectural decisions get made, and every sub-topic represents a category of decision that can go wrong in a different way. Security, integrations, performance, scalability, resilience, and migration are not loosely related ideas here; they are all angles from which the exam will probe whether you can produce a defensible architecture given a specific set of constraints.

– Architecture, security, and integration

Designing detailed architecture from business requirements means more than drawing component boxes. The exam rewards knowing which AEM deployment topology fits a given scenario and why alternatives fall short. Decisions about author-publish separation, dispatcher configuration, and cloud versus on-premise placement all carry consequences that show up in later topics, so the design rationale matters as much as the outcome.

Security design questions ask you to match a threat or compliance requirement to a specific control. Generic answers about authentication or encryption score poorly; the exam rewards selecting the control that fits the scenario's constraints, whether that means SSO integration, permission scheme design, or network-layer controls.

Integration requirements introduce procedural thinking: what sequence of decisions leads from a stated integration need to a workable AEM solution design? Items here often present a third-party system and ask you to determine the appropriate pattern, such as event-driven versus request-response, and the architectural implications that follow.

– Performance, scalability, resilience, and migration

Performance and testing requirements must be identified before architecture is finalised, not after. Items in this area reward candidates who can read a scenario and determine which performance characteristics are load-related, which are latency-related, and which require specific testing approaches such as soak testing or failover simulation. Naming a test type without connecting it to the scenario's constraint is a common way to lose marks.

Scalable and resilient architecture in AEM involves decisions about clustering, replication, and failure domain isolation. The exam presents scenarios where one design choice creates a single point of failure or a scaling bottleneck, and rewards the option that eliminates it while staying within the scenario's stated constraints.

Migration strategy questions are scenario-driven. The right strategy depends on factors such as content volume, downtime tolerance, and the source system's structure. Items reward matching the migration approach to those factors rather than defaulting to a preferred pattern regardless of context.

How Solution Design is tested

At 44 percent, this topic will determine your result more than any other. Items are almost always scenario-based: you are given a set of requirements, constraints, or an existing architecture, and asked to select or justify a design decision.

The primary demand is specificity. Candidates who know AEM concepts in the abstract but cannot apply them to a constrained scenario will find the options all look plausible. The exam rewards the option that fits the scenario's stated constraints exactly, not the option that describes best practice in general.

The most common loss pattern is over-engineering: selecting a more complex solution when the scenario's constraints do not require it. A second pattern is under-specifying security or integration, treating them as add-ons rather than first-class architectural concerns.

Migration items catch candidates who apply a single preferred strategy regardless of context. Scalability and resilience items catch candidates who identify a problem correctly but select a fix that introduces a different architectural weakness. Read every constraint in the scenario before committing to an option.

Solution Design produces the plan; Implementation is where the plan meets reality. At 22 percent, this topic tests a different skill set from its predecessor: you are no longer choosing between architectural options in the abstract but diagnosing what happens when a design is actually built. The scenarios shift from forward-looking to reactive, and the candidate who can only think in blueprints will find this topic uncomfortable.

How Implementation is tested

Items in this topic present situations that arise during an active AEM implementation: a design assumption that breaks when code meets infrastructure, a requirement that turns out to be ambiguous once development starts, or a defect that needs to be traced back to an architectural decision.

The exam rewards candidates who can distinguish between a symptom and a root cause. Selecting a fix that addresses the observable problem without identifying its architectural origin is a frequent way to lose marks. Items that ask for recommended implementation approaches reward matching the approach to the scenario's specific requirements rather than applying a default methodology.

Prototyping and proof-of-concept questions test whether you know which method produces useful evidence for a given uncertainty. The trap is selecting a method that is thorough but misaligned with what the scenario needs to prove.

Diagnosis items often include details that are irrelevant to the actual issue. Candidates who chase every symptom rather than reasoning from the architecture lose time and often select a plausible but incorrect resolution. Focus on what the scenario's constraints make structurally inevitable.

After implementation comes the long operational phase, and Maintenance tests whether your architectural thinking extends into production. At 16 percent, this topic is smaller than the others but not forgiving: the scenarios involve live environments where the cost of a wrong decision is immediate. The skills here are distinct from design and build; you are optimising, upgrading, and diagnosing systems that real users are already depending on.

How Maintenance is tested

Maintenance items are scenario-driven and operationally specific. A production environment has a problem, or an upgrade is being planned, or a non-functional requirement such as response time or availability is no longer being met. The exam rewards candidates who can identify the correct lever to pull without destabilising what is working.

Diagnosis items in a production context are harder than implementation-stage diagnosis because the scenario constrains what interventions are acceptable. Candidates who recommend changes that would require downtime when the scenario specifies high availability, or who propose architectural changes when a configuration change would suffice, will find the options do not reward them.

Upgrade and new-feature planning questions test procedural thinking: what must happen before, during, and after an AEM upgrade to keep the solution stable. The trap is selecting steps that are correct in isolation but out of sequence.

Optimisation for non-functional requirements rewards candidates who can map a measured shortfall, such as cache hit rate or replication latency, to a specific architectural adjustment rather than a general tuning recommendation.