14% of the exam — about 9 of the 63 questions — across 5 sub-objectives.
Domain 6 is worth more than evaluation and gets skipped because it looks like soft skills. It is scored on structure rather than warmth.
The move underneath most of it is translation. Stakeholders speak in preferences and designs are built against constraints, so the work is converting one into the other while the conversation is still happening.
Conduct structured discovery and requirement gathering
A discovery call is elicitation with a shape: listen to the goal in plain language, translate it into requirements and assumptions, and write those down before the conversation moves on. Skip the third step and the design quietly inherits your assumptions rather than the stakeholder's constraints.
The exam's favorite object is a vague adjective. A stakeholder says the experience should feel seamless. Seamless is not a requirement. The useful next question is what would make it feel not seamless, and the answers turn into a latency target, an integration point, a handoff rule, and a defined behavior when something fails.
Watch for the assumption nobody stated. Scenarios often contain a constraint mentioned once in passing, such as a compliance review that adds two weeks or a system that only accepts batch input overnight, and the credited answer is the one that surfaces it rather than the one that designs past it.
From the free practice form
A VP of Customer Experience opens a kickoff call by saying, "We've decided we need an AI chatbot on our support site — how fast can you build it?" She has budget approved and a launch date already communicated internally. The architect has not yet seen any support metrics or spoken to the support team. What should the architect do FIRST?
Second question, same objective
During discovery for an AI document-processing system, the operations director insists the system must run fully automated end to end, while the compliance officer states that every output touching customer accounts must be human-reviewed. Both were interviewed separately and each believes their requirement is settled. The project sponsor asks the architect to "just write up the requirements." What should the architect do FIRST?
Communicate architectural decisions and trade-offs
Presenting a trade-off means giving the stakeholder enough to make the decision themselves. An option with its cost named, an alternative with its cost named, and a recommendation.
An approval obtained without the costs on the table is not an informed choice, and the exam treats it as a failure even when the chosen option was right. If a scenario has someone agreeing to a plan whose downside was never stated, the missing element is usually what the question is asking about.
Say what you gave up. A recommendation with no stated sacrifice reads as a sales pitch to anyone senior, and the credited answers name the thing being traded away alongside the thing being gained.
From the free practice form
An architect recommends a mid-tier model for a claims-triage workload after testing shows it meets quality targets. In the review meeting, the CTO pushes back: "If we're doing this, I want the most capable model available — I don't want us looking cheap." Which response best communicates the recommendation?
Second question, same objective
An architecture review board challenges an architect's decision to use a retrieval-based design instead of fine-tuning for a policy-lookup assistant. Two board members favor fine-tuning because a vendor demo impressed them, and the meeting is scheduled to end in a decision. Which TWO actions best serve the architect in communicating the decision?
Manage stakeholder feedback loops and expectation alignment (including SLAs)
A feedback loop and an observability stack are different things. Dashboards tell your team the system is healthy. A feedback loop decides which signals reach the stakeholder and what happens when one of them is bad.
An SLA names what you owe when something breaks. It has a number, a window, and a consequence, and a scenario that quotes one is constraining the architecture with it. Agreeing to a target nobody designed for is the failure this sub-objective tests.
Expectations drift silently between milestones. The structural answer is a regular point at which the current state is shown against what was agreed, rather than a conversation that happens when someone is already unhappy.
From the free practice form
During contract negotiation, an enterprise customer's procurement team demands an SLA of 2-second response time for an AI-assisted search feature. The architect's production telemetry shows median latency of 1.4 seconds but p99 latency of 6 seconds, driven by long-document queries. The sales lead urges the architect to accept the term to close the deal. What should the architect do FIRST?
Second question, same objective
An executive sponsor watches a polished demo of an AI contract-review assistant and tells the steering committee, "It caught every issue in the demo — I expect the same in production." The demo used ten hand-picked contracts, and no systematic evaluation has been run. The sponsor asks the architect to confirm an accuracy commitment for the rollout plan. Which response best manages the sponsor's expectations?
Document architectures and provide implementation guidance
Documentation on this exam is judged by whether it survives your absence. Three readers matter: the person implementing it, an auditor asking why, and you in six months.
The thing that goes missing is rationale. A diagram records what was built. It does not record which options were rejected and why, and that reasoning is what a successor needs before they undo a decision without knowing what it protected.
Implementation guidance means handing over enough to build without you, including the constraints that are not obvious from the diagram: which parts the guarantees depend on, what was deliberately left out, and what should trigger a redesign rather than a patch.
From the free practice form
Six months after launch, a new engineering team inherits an AI-powered routing system. The architecture documentation includes detailed component diagrams, API specifications, and data-flow charts, yet the team keeps asking questions like "Why is there a rules layer in front of the model?" and "Why was the vector store chosen over the existing search cluster?" What is the most important gap for the architect to close?
Second question, same objective
An architect hands a design for an AI intake-classification service to a delivery team, providing an architecture overview and a summary of the intended behavior. Three weeks in, the team has improvised its own prompt structures, retry behavior, and confidence thresholds, and early testing shows results diverging from what the design intended. What should the architect have provided to prevent this?
Support lifecycle phases (discovery, design, handoff, monitoring, iteration)
This is the phase-gate material, and the questions are recognisable: you are at a given stage and asked which activities belong there, before the next one.
The distractors are usually things that legitimately belong, only later. Building the eval suite belongs early, and so does surfacing constraints. Load testing and a rollback plan belong before handoff rather than during discovery. Knowing what happens when carries more weight here than knowing any single activity in depth.
Handoff is the gate people underestimate. What transfers is not only the system but the ability to operate it: the runbook, the alerting, the rationale, and a named owner.
The shape to recognize is a question that names a point in time and asks what belongs before it. Sitting the exam, these read as "before you do X, should you do Y", and the wrong answers are usually things you would genuinely do, only later. That is what makes them attractive: nothing in the option is incorrect except when it happens.
So the useful preparation is not memorising a phase list. It is being able to say, for any activity, what has to be true before it starts and what it unblocks once it finishes.
From the free practice form
An AI email-triage system goes live and hits its launch targets. The sponsor declares the project complete and reassigns the team, and the operations group receives a monitoring dashboard as the handoff artifact. The architect knows the incoming email mix shifts seasonally and that classification quality will likely degrade within months. What should the architect do before the engagement closes?