AD0-E906 Adobe Workfront for Experience Manager Enhanced Connector Expert Exam Topics and Questions

Technical Requirements sets the technical floor for the whole exam. Before the connector can do anything useful, the plumbing has to be correct: forms, document handling, code promotion, and server-side troubleshooting all have to work together. This topic tests whether you can operate at the boundary between Workfront and AEM, not just describe it. Expect scenarios where a small misconfiguration produces a non-obvious symptom, and where knowing the data flow is the only way to isolate the fault.

– Custom forms and how values move through them

Workfront Custom Forms sit at the centre of most integration scenarios. The exam does not ask you to recite field types. It asks what happens when a value needs to travel from a custom form into AEM metadata, or back again. You need to know which field types carry values reliably across the connector, what triggers a sync, and what silently drops data when the mapping is wrong.

Identifying how values are passed means tracing the path: form field to object, object to event, event to connector, connector to AEM property. A gap anywhere in that chain produces metadata that looks correct in Workfront but arrives empty or mismatched in AEM. The exam presents those gaps as scenarios and expects you to name the cause.

– Document management, code promotion, and troubleshooting

Document management in this context means understanding which operations on a Workfront document trigger connector activity: linking, uploading, versioning, and deletion each behave differently. Scenarios will give you a state in one system and ask what the other system should reflect.

Promoting code across environments is a practical discipline. The exam tests whether you know what must be migrated alongside code: OSGi configurations, connector settings, and environment-specific credentials all travel separately from the code itself, and forgetting one is a common failure point in real deployments.

Troubleshooting server-side code rewards candidates who can read a symptom and work backwards to a cause. The exam will not ask you to write code, but it will ask you to identify whether a failure is a configuration fault, a permissions problem, or a code defect, and to know which log or diagnostic tells you which.

How Technical Requirements is tested

At 25% of the exam, this topic places a meaningful number of items in front of you, and most of them are scenario-based. You are given a state: a form field that is not syncing, a document that appears in Workfront but not in AEM, a value that is arriving blank. You have to identify the cause from a set of plausible options that all sound reasonable on the surface.

The trap in this topic is confusing symptoms with causes. A blank metadata field could be a mapping error, a missing trigger, a permissions gap, or a server-side fault. Items reward candidates who can distinguish those causes rather than pick the most familiar one. Troubleshooting questions in particular punish candidates who jump to configuration as the default explanation without ruling out code or permissions first.

Code promotion items tend to catch candidates who think only about the code itself and forget the environment-specific artefacts that travel alongside it. Knowing what moves automatically and what does not is the examinable point.

Where Technical Requirements asks you to diagnose, Configuration asks you to decide. This is the highest-weighted topic on the exam, and it lives in the space where AEM administration meets the connector: user management policies, asset workflow modifications, metadata schema design, and the deployment of OSGi bundles, tagging structures, and permissions. Getting these decisions right in the exam means understanding the order of operations and the consequences of each choice, not just the mechanics of each tool.

– User management and metadata schema decisions

User management best practices in this context are about the connector's security model, not general AEM administration. The exam tests whether you know how user accounts and group memberships in AEM need to align with Workfront roles, and what breaks when they do not. A mismatch at the user level can suppress connector activity silently, which makes it a favourite trap.

Metadata schema customisation asks you to make decisions, not just describe options. Different asset types carry different metadata requirements, and the exam presents scenarios where a single schema applied universally produces the wrong outcome for one asset class. You need to know when to create a separate schema, when to extend an existing one, and what downstream effects each choice has on the connector's ability to read and write metadata correctly.

– Workflows, OSGi bundles, tagging, and permissions

Modifying existing AEM asset workflows is tested procedurally. The exam does not ask you to build a workflow from scratch. It asks what you change in an existing workflow to accommodate connector behaviour: which steps to add, which to reorder, and which launcher configurations to adjust so that connector-initiated operations do not trigger redundant or conflicting processing.

Deploying OSGi bundles, assets, metadata schema, tagging, and permissions is the most operationally dense part of this topic. Each element has its own deployment mechanism and its own dependency order. The exam rewards candidates who know that permissions must be in place before the connector attempts to write assets, that tagging structures must exist before metadata schema reference them, and that bundle deployment order matters when one bundle depends on another. Candidates who treat these as independent steps rather than a sequenced operation tend to lose marks here.

How Configuration is tested

Configuration carries the largest weight on the exam. Items in this topic are predominantly procedural: you are told what needs to be achieved and asked to identify the correct sequence of steps, the right setting to change, or the appropriate schema design for the asset type described.

The dominant trap is selecting an option that is technically valid in isolation but wrong for the specific scenario. OSGi deployment questions, for example, often include an option that would work in a greenfield environment but fails when an existing bundle is already present. Metadata schema questions present options that differ only in where a field is placed or how it is inherited, and the distinction matters for the connector.

Items reward candidates who think about side effects: what else changes when this setting is applied, and does that conflict with anything already in place. Candidates who memorise individual configuration steps without understanding the dependencies between them will find the scenario-based items in this topic particularly difficult. The weight means you cannot afford to treat it as a secondary concern.

After two technically dense topics, Business Practices shifts the frame. The question is no longer how the system works but whether it is being used in a way that serves the business. Approval workflows, proofing, campaign deliverable tracking, and change management all appear here, and the exam tests your judgement about what a client actually needs, not just what the product can do. Candidates with a purely technical background often underestimate this topic and lose marks they should have kept.

– Workflow strategy, approvals, and proofing

Interpreting client needs to recommend workflow strategies is a judgement call, and the exam frames it as one. You are given a client situation and asked to identify the approach that fits it. The distinguishing factor between options is usually the balance between control and speed: a heavily gated approval process serves some clients and creates bottlenecks for others. Knowing which signals in the scenario point toward which design is what the exam is testing.

Workfront approval and proofing workflows are tested at the setup level. The exam expects you to know how automated approval routing works, how proof roles and stages interact, and what happens when a proof is not configured to match the review process the client described. The proofing viewer questions go further: settings, markup tools, and viewer behaviour all appear, and the trap is selecting an option that sounds like best practice in general but does not fit the specific use case in the scenario.

– Campaign management and change management

Tracking deliverables as part of campaign management tests whether you understand how Workfront structures work: tasks, milestones, and status fields as signals of campaign progress rather than as administrative overhead. The exam will present a campaign scenario and ask which tracking approach gives the stakeholders the visibility they need. Options that add complexity without adding signal tend to be wrong.

Change management for a Workfront implementation is the most people-facing sub-topic in the exam. The key considerations the exam tests are about sequencing and stakeholder impact: what to communicate before a configuration change goes live, how to manage adoption when workflows change, and which risks to surface before implementation rather than after. Candidates who treat change management as a soft topic and skim it tend to drop marks on items that turn on a specific consideration rather than a general principle.

How Business Practices is tested

Business Practices items are scenario-heavy and reward reading carefully. The scenario establishes a client context: an industry, a team structure, a pain point, or a constraint. The options are all plausible, but one fits the context and the others fit a different context or introduce a problem the scenario did not mention.

Approval and proofing items tend to trip candidates who know the feature set but have not thought about when each configuration is appropriate. The exam presents situations where the technically correct configuration is wrong for the client's process, and items reward matching the tool to the need rather than applying a default setup.

Change management questions are often the ones candidates skip in revision and then regret in the exam. They reward a specific kind of thinking: identifying the right moment to act and the right stakeholder to involve, rather than describing change management in general terms. At 21%, this topic is not a minor one, and the marks are genuinely available to candidates who treat the scenario details as the deciding factor rather than background noise.

The final topic carries the exam's largest individual weight, and it is narrower in scope than Configuration. The focus is on the connector itself: what must be true in AEM before installation can succeed, and which connector features to select given a specific customer use case. These two questions sound simple, but the exam tests them at a level of specificity that catches candidates who have general familiarity with the connector but have not worked through the details of its prerequisite chain and feature set.

How Installation and Configuration of Connector is tested

At 28%, this is the topic that decides the exam for most candidates. Items split between prerequisite validation and feature selection, and both types are scenario-driven.

Prerequisite validation items give you an AEM environment in a described state and ask whether it is ready for connector installation, or what must change before it is. The trap is assuming that a running AEM instance is a ready one. Specific package versions, service user configurations, and replication settings all appear as prerequisites, and missing any one of them produces a connector that installs but does not function correctly. Items reward candidates who know the full prerequisite list, not just the most obvious items on it.

Feature selection items give you a customer use case and ask which connector capabilities to enable. The options often include features that are relevant to the use case in a general sense but wrong for the specific requirement described. Items reward matching the feature to the stated need precisely. Candidates who enable every available feature as a default strategy will find those options consistently less strong than the targeted ones.