That works out to roughly fifteen questions per scenario. You read a production context once, then answer a run of items against it, then move to the next context and do it again. Four times.
Why this changes how you sit the exam
On a conventional certification you get 60 unrelated questions, each carrying its own miniature world. Your working memory resets every item. Nothing you read in question 12 matters in question 13.
Here it does. The scenario briefing establishes a system — what it is built on, what tools it has, what it is trying to achieve, what constraint it is operating under — and the questions that follow assume you still have that in your head. Some items restate the detail they depend on. Others do not. Keeping the scenario's details straight is itself part of what is being tested, which is a fair thing to test in an architect, since holding a system's constraints in mind while making a series of decisions about it is the job.
The upside is real, though. Fifteen questions of context-switching cost paid four times is far cheaper than sixty questions of it paid sixty times, and the scenarios are published in advance. You can arrive already knowing which four worlds out of six you might be dropped into.
The six published scenarios
Four of these six appear on any given form. The exam guide publishes all six, which means every one of them is worth understanding as a system before you sit down — not memorising, but knowing well enough that the briefing confirms what you already expected rather than teaching you something new under time pressure.
1. Customer Support Resolution Agent
A support agent built on the Agent SDK that handles genuinely ambiguous requests — returns, billing disputes, account problems — through custom MCP tools for customer lookup, order lookup, refunds and human escalation, aiming at high first-contact resolution while knowing when to stop and hand over.
Domains that live here: Agentic architecture, tool design, and context management. The escalation boundary is the interesting part: this is the scenario where questions about when an agent should refuse to act on its own naturally live.
2. Code Generation with Claude Code
Claude Code used for generation, refactoring, debugging and documentation inside a real development workflow, configured with custom slash commands and CLAUDE.md, and choosing between plan mode and direct execution.
Domains that live here: Claude Code configuration, with context management alongside it. Expect questions about where configuration belongs and when a plan is worth the round trip.
3. Multi-Agent Research System
A coordinator agent delegating to specialised subagents — web search, document analysis, synthesis, report generation — to research a topic and produce a cited report.
Domains that live here: Agentic architecture, tool design, and context management. Coordinator and subagent patterns, what gets passed down, what comes back, and how citations survive the synthesis step.
4. Developer Productivity with Claude
Agent SDK tooling that helps engineers explore unfamiliar codebases, make sense of legacy systems, generate boilerplate and automate repetitive work, using the built-in tools alongside MCP servers.
Domains that live here: Tool design, Claude Code, and agentic architecture. This is where the built-in tool choices and large-codebase context strategy get exercised directly.
5. Claude Code for Continuous Integration
Claude Code wired into a CI/CD pipeline running automated review, generating test cases and leaving pull-request feedback, with prompts tuned for actionable output and few false positives.
Domains that live here: Claude Code configuration and prompt engineering. False-positive rate is the explicit design constraint, which makes this the natural home for explicit-criteria prompting questions.
6. Structured Data Extraction
An extraction system pulling fields out of unstructured documents, validating against JSON schemas, holding accuracy up through edge cases and feeding a downstream consumer.
Domains that live here: Prompt engineering and structured output, with context management. Schema enforcement, validation and retry loops, and what to do with the documents that do not fit.
What the domain spread implies
Notice that the domains are not evenly distributed across the six. Agentic architecture shows up in the support agent, the research system and the developer productivity scenario. Claude Code carries three of them. Structured output is concentrated in extraction and CI.
Since only four scenarios appear, the mix you personally get is not fixed — but the published domain weights are. The exam balances to 27/20/20/18/15 regardless of which four you draw, which tells you something useful: any four of these scenarios can carry the full blueprint. Every scenario is going to ask you things that are not obviously "about" it.
Tactics that actually help
- Read the whole briefing before the first question. The temptation under a clock is to skim the context and start answering, backfilling detail as you go. That is the wrong trade here. You are amortising one careful read across fifteen items; two extra minutes up front is eight seconds per question.
- Note the numbers and the constraints. Target resolution rates, tool inventories, what is explicitly ruled out. These are what decide between two answers that are both good engineering.
- Expect items that assume earlier detail. A question late in a run may refer to "the escalation tool" or "the coordinator" without reintroducing it. If a question seems underspecified, the missing specification is almost always back in the briefing rather than absent.
- Do not lose the thread when the subject changes. Within one scenario the questions will move from orchestration to a prompt-shape question to a context question. The system did not change; only the lens did. Candidates lose points by treating a topic shift as a scenario shift and answering generically.
- Flag within the scenario, not across it. If you want to revisit an item, revisit it before you leave that context. Coming back after you have loaded two other systems means re-reading the briefing.
The questions that actually decide it
Here is the thing worth internalising before anything else. The items that separate a pass from a fail are usually not the ones where you are missing a feature or have never heard of a parameter. Those are rare, and they are obvious when they happen.
The hard ones are the items where two options are both perfectly defensible engineering. Both would work. Both would survive a code review. A competent architect could ship either and justify it. Only one is credited.
What breaks the tie is that the exam rewards the approach matching Anthropic's documented patterns for the thing being described — the shape the platform is designed around, not merely a shape that functions. A subagent that returns distilled findings rather than raw material. A structured tool error the model can act on rather than an exception the caller swallows. Configuration that lives where the tooling looks for it rather than somewhere equally reasonable. Enforcement in structure rather than instruction.
Which means preparation is less about learning more features and more about absorbing why the documented pattern is the documented pattern. When you are stuck between two options that both work, the question to ask is not "which is better engineering" — you have already established both are. It is "which one is the way this is meant to be done." That question has an answer, and the answer is learnable.
It is also why practising against loose, shuffled questions underprepares you. The tie-breaking constraint usually lives in the scenario briefing, not in the stem. Practice that strips the scenario strips the thing being tested. Our free CCAR-F form is built in scenarios, the way the exam is →