The Claude Certified Architect exam: every domain, every task statement, scored by difficulty
A definitive, opinionated walk-through of all five exam domains and 30 task statements, with our internal difficulty rating and the concepts that catch most people out.
By Solomon Udoh · AI Architect & Certification Lead
The Claude Certified Architect Foundations exam is structured around five domains, thirty task statements, and six scenario-based question groups. Anthropic publishes the headline structure but stops short of telling you which task statements quietly carry most of the marks. After running several thousand learner sessions through the question bank, we have a clear view of where the difficulty actually sits, and it is not where the official guide hints.
Domain 1 (Agentic Architecture) and Domain 4 (Prompt Engineering and Structured Output) are where most candidates lose points. The agentic loop, stop_reason handling and subagent isolation alone account for roughly a quarter of the questions in our bank, and they are also the concepts learners most consistently misjudge their own mastery on. If you are prioritising study time, treat these two domains as the load-bearing wall of the exam.
Below we go domain by domain, task statement by task statement, with our difficulty rating (1 to 5), the concept that most learners trip on, and the kind of scenario you can expect. Use this as a planning document before you start, and again as a checklist in the final week before you sit.
How we score difficulty
Our ratings run from 1 (most candidates get this right first time) to 5 (the task statement where our learners lose the most marks relative to how confident they felt going in). They come from grading several thousand practice exam attempts against the knowledge graph that drives the adaptive engine, so a 5 does not mean the concept is intellectually hard. It means the exam has a trap laid for it, and the trap works.
Read the difficulty column together with the trap column. A task statement is dangerous when the wrong answer looks like good engineering: a routing classifier where a better description was the fix, a system prompt where a hook was the fix, a retry loop where the information was never in the document to begin with. The exam rewards the proportionate, deterministic, root-cause answer, and it punishes optimism. Keep that reflex in mind for every table below.
Domain 1: Agentic Architecture and Orchestration (27%)
The heaviest domain, and the one that decides most pass or fail outcomes. Seven task statements, and the difficulty is front-loaded onto the ones about control flow and enforcement.
| Task statement | Difficulty | What trips people up |
|---|---|---|
| 1.1 Agentic loops | 4/5 | Three anti-patterns: parsing natural language to decide termination, arbitrary iteration caps as the primary stop, and treating any assistant text as 'done'. The loop terminates on stop_reason, nothing else. |
| 1.2 Multi-agent orchestration | 4/5 | Assuming subagents inherit the coordinator's memory. They do not. When coverage is incomplete, the root cause is almost always the coordinator's decomposition, not a subagent. |
| 1.3 Subagent invocation and context passing | 3/5 | Forgetting that Task must be in the coordinator's allowed tools, and passing findings without structured source metadata, so attribution dies at synthesis. |
| 1.4 Workflow enforcement and handoff | 5/5 | Picking a stronger system prompt for a financial or security-critical step. High stakes demand a programmatic gate or hook, not politer instructions. |
| 1.5 Agent SDK hooks | 3/5 | Not seeing that hooks are the deterministic tool: PostToolUse to normalise messy tool output, interception to block a refund over a threshold. |
| 1.6 Task decomposition | 3/5 | Attention dilution: one giant pass over fourteen files gives inconsistent depth. Split into per-file passes plus a cross-file integration pass. |
| 1.7 Session state and resumption | 2/5 | Resuming a long session on stale tool results after files changed. A fresh start with an injected summary is often more reliable than --resume. |
The two hardest items are 1.1 and 1.4. If you can inspect stop_reason to drive the loop and reach for a prerequisite gate the moment money or security enters the scenario, you have most of the domain's marks. Everything else here is a variation on those two instincts.
Domain 2: Tool Design and MCP Integration (18%)
Lighter weighting, and mostly a domain of low-effort, high-leverage fixes. The exam wants you to reach for the cheapest fix that addresses the root cause first.
| Task statement | Difficulty | What trips people up |
|---|---|---|
| 2.1 Tool interface design | 3/5 | Not internalising that the tool description is the primary selection mechanism. When two tools misroute, the fix is better descriptions, not few-shot examples, a routing classifier, or consolidation. |
| 2.2 Structured error responses | 4/5 | Confusing an access failure (retry may help) with a valid empty result (the answer is 'no matches', do not retry). The four error categories, transient, validation, business, and permission, decide recovery. |
| 2.3 Tool distribution and tool_choice | 3/5 | Giving one agent eighteen tools and wondering why selection degrades. Scope to 4 or 5 per role, and know auto versus any versus forced selection cold. |
| 2.4 MCP server integration | 2/5 | Building a custom server when a community one exists, and putting shared config in user-level rather than project-level .mcp.json. |
| 2.5 Built-in tools | 2/5 | Grep searches file contents, Glob matches file paths. Pick the wrong one and you either waste turns or miss the file entirely. |
The sleeper here is 2.2. The exam loves a scenario where an agent retries three times and escalates, when the tool actually returned a legitimate empty result and the account simply does not exist. If you cannot tell 'could not reach the source' apart from 'reached it, found nothing', your recovery logic is broken, and the exam knows it.
Domain 3: Claude Code Configuration and Workflows (20%)
The most configuration-heavy domain. Reasoning will not save you here: you either know where the files live and what the flags do, or you guess. Hands-on Claude Code time is the only real preparation.
| Task statement | Difficulty | What trips people up |
|---|---|---|
| 3.1 CLAUDE.md hierarchy | 3/5 | The classic trap: a new teammate gets inconsistent behaviour because the instructions live in user-level config, which is not version-controlled and not shared. Team standards belong at project level. |
| 3.2 Slash commands and skills | 3/5 | Blurring skills (on-demand, task-specific) with CLAUDE.md (always loaded, universal). Knowing that context: fork isolates noisy output into a subagent. |
| 3.3 Path-specific rules | 4/5 | The sleeper concept. A glob like **/*.test.tsx in .claude/rules/ applies across the whole codebase; a directory-level CLAUDE.md cannot, because it is bound to one directory. |
| 3.4 Plan mode vs direct execution | 2/5 | Overthinking it. Plan mode for multi-file migrations and architecture; direct execution for a single-file fix with clear scope. |
| 3.5 Iterative refinement | 3/5 | Reaching for more prose when the model is inconsistent. Two or three concrete input and output examples beat any description. |
| 3.6 CI/CD integration | 3/5 | Forgetting the -p flag, so a pipeline hangs waiting for interactive input, and using the same session to review the code it just wrote. |
Drill 3.3 hardest. Path-specific rules are barely mentioned in casual Claude Code use, so most candidates have never touched them, yet the exam treats them as the correct answer whenever a convention must span many directories. It is the highest-difficulty item in a domain that otherwise rewards muscle memory.
Domain 4: Prompt Engineering and Structured Output (20%)
This is where the exam gets sneaky. Wrong answers here sound like good engineering. The whole domain turns on two words: be explicit.
| Task statement | Difficulty | What trips people up |
|---|---|---|
| 4.1 Explicit criteria | 4/5 | Believing 'be conservative' or 'only report high-confidence findings' improves precision. It does nothing. Define exactly which cases to report versus skip, with code examples per severity. |
| 4.2 Few-shot prompting | 3/5 | Adding more instructions when the fix is 2 to 4 targeted examples that show the reasoning for choosing one action over a plausible alternative. |
| 4.3 Structured output with tool_use | 4/5 | Thinking a JSON schema prevents fabrication. It kills syntax errors, not semantic ones. Nullable fields are what stop the model inventing values it does not have. |
| 4.4 Validation and retry loops | 4/5 | Retrying forever on information that was never in the source. Retry fixes format and placement errors, not genuinely absent data. |
| 4.5 Batch processing | 3/5 | Batching everything. The Message Batches API is 50% cheaper with a 24-hour window and no multi-turn tool calling: right for overnight reports, wrong for blocking pre-merge checks. |
| 4.6 Multi-instance review | 3/5 | Letting one session review its own output. It retains the reasoning that made it confident. An independent instance catches more. |
The two hardest, 4.3 and 4.4, are a matched pair, and the exam sets them as a trap. Both are about the limits of a mechanism. A schema guarantees valid JSON but not truthful JSON; a retry loop repairs a malformed field but cannot conjure a value the document never contained. Candidates who treat either as a silver bullet walk straight into the distractor.
Domain 5: Context Management and Reliability (15%)
The smallest weighting, and the one people under-prepare, which is a mistake because its failures cascade into every other domain. A broken context strategy takes your multi-agent system and your extraction pipeline down with it.
| Task statement | Difficulty | What trips people up |
|---|---|---|
| 5.1 Context preservation | 4/5 | Progressive summarisation quietly compresses '$247.83 for order #8891' into 'a recent refund'. Keep a persistent case-facts block, never summarised, and put key findings first to beat the lost-in-the-middle effect. |
| 5.2 Escalation and ambiguity | 4/5 | Escalating on sentiment or the model's self-reported confidence. Both are unreliable. The valid triggers are: the customer asks for a human, a policy gap, or no meaningful progress. |
| 5.3 Error propagation | 3/5 | The two anti-patterns: silently suppressing an error as an empty success, or killing the whole workflow on one failure. Propagate structured context and partial results instead. |
| 5.4 Codebase exploration | 2/5 | Letting a long session drift onto 'typical patterns' instead of the specific classes it found earlier. Scratchpad files, subagents, and /compact are the fixes. |
| 5.5 Human review and confidence calibration | 3/5 | Trusting a 97% aggregate that hides a 40% error rate on one document type. Validate by segment, and calibrate confidence thresholds on labelled data. |
| 5.6 Information provenance | 3/5 | Losing claim-to-source attribution through synthesis, and arbitrarily picking one number when two credible sources disagree. Annotate both, with dates. |
Do not let the 15% fool you into skipping it. Because Domain 5 shows up in nearly every scenario, a weak spot here quietly bleeds marks across Domains 1, 2, and 4 as well. It is the reliability layer under everything else on the exam.
Turning this into a study plan
The honest way to use this page is as a weighting map, not a reading list. Spend your hours where the marks and the difficulty both concentrate. That means Domain 1 first (27% of the exam, and home to the two hardest task statements in 1.1 and 1.4), then the two 20% domains, then Domain 2 and Domain 5.
Within each domain, drill the high-difficulty task statements as scenarios, not flashcards, because every one of them is a trap the exam springs through a plausible wrong answer. Reading that a hook beats a prompt is not the same as recognising, under time pressure, the scenario that is begging for one. That gap between recognition and recall is exactly what our adaptive study sessions target: the engine retires a concept only when your mastery probability clears 0.90, so the task statements you privately dread are the ones it keeps bringing back.
If you want the wider decision context, whether the credential is worth your working week at all, our numbers-first verdict on the exam covers cost, signal, and who should skip it. This page is for the people who have already decided to sit it and now want to know where the difficulty actually lives.
Where to go next
Pair this breakdown with two things. First, Anthropic's official Certification Exam Guide, which defines the five domains and thirty task statements in their own words, so you can check our difficulty read against the source. Second, a diagnostic: the fastest way to find your weakest domain is not to guess from these tables but to sit a short practice exam and let the results point you at it.
From there, the two deep dives worth reading next on this blog are our walk through why system prompts sit at the top of the prompt hierarchy, a concept the exam leans on hard, and the agentic reference architecture that maps the whole stack onto the exam domains. Study the weights, drill the traps, and sit it when the scenarios read as war stories rather than trivia.
About the author
AI Architect & Certification Lead
Solomon Udoh is an AI Architect who designs and ships production agent systems on the Claude API and Claude Code. He built AI Skill Certs' adaptive engine and authored its 174-concept knowledge graph, mapping every Claude Certified Architect - Foundations objective to hands-on, exam-aligned practice.
- Designs production multi-agent systems on the Claude API and Agent SDK
- Author of the AI Skill Certs knowledge graph (174 mapped exam concepts)
- Builds with MCP, Claude Code, structured outputs, and agentic loops daily
- Reviews every concept page against the official Anthropic exam guide
You might also like
Ready to put it into practice?
Study every exam concept with an adaptive tutor.