Most people walk into the Claude Certified Architect (Foundations) exam expecting documentation trivia. It's not that. The exam tests whether you can build production systems with Claude, and the questions are almost entirely scenario-based. You'll get a situation, four plausible answers, and have to pick the one that actually works.
Here's what we've learned from pulling apart the exam structure: where candidates lose marks, which domains deserve the most prep time, and how to study without wasting hours on content that won't show up.
What the exam covers
Five domains, each weighted differently. The weighting matters more than most people realise:
| Domain | Weight | What it tests |
|---|---|---|
| Agentic Architecture & Orchestration | 27% | Agentic loops, orchestration patterns, guardrails, the Agent SDK |
| Claude Code Configuration & Workflows | 20% | Settings, CLAUDE.md, hooks, permissions, CI/CD |
| Prompt Engineering & Structured Output | 20% | System prompts, few-shot patterns, output validation |
| Tool Design & MCP Integration | 18% | Tool schemas, MCP servers and clients, tool routing |
| Context Management & Reliability | 15% | Context windows, caching, long conversations, production reliability |
Domain 1 is over a quarter of the exam on its own. If you've only got a few hours to study, that's where they go.
Domain 1: Agentic Architecture (27%)
This domain has the most weight and the most traps. Get the agentic loop lifecycle wrong and you'll bleed marks across multiple questions.
The core loop itself isn't complicated: send a request to Claude via the Messages API, check the stop_reason field, run any tools Claude asked for, append results to the conversation history, loop again. When stop_reason comes back as end_turn, you're done.
Simple enough on paper. The exam, though, is testing whether you know the wrong ways to do it.
The traps
Three anti-patterns come up again and again:
- Parsing natural language to detect completion. Checking whether Claude said "I'm done" is unreliable.
stop_reasonis the only signal you should trust. - Hardcoding iteration caps as your primary exit. A cap of 10 iterations either kills a task that needed 12 or wastes cycles when the model finished at 3.
- Checking
response.content[0].type == 'text'to decide you're finished. Claude can return text alongsidetool_useblocks. Text showing up doesn't mean the loop is over.
You'll also need to know orchestration patterns (sequential, parallel, routing, orchestrator-worker), guardrails, and the Claude Agent SDK. But the loop lifecycle is where most questions live.
Domain 2: Tool Design & MCP (18%)
Here's what catches people out: Claude picks which tool to call based primarily on the tool's description, not its name or parameter schema. Write a vague description like "Retrieves customer information" and Claude will misroute calls to it constantly. The exam knows this, and the tool interface design questions test it directly.
For MCP, you need to understand how servers expose resources, tools, and prompts over a standardised protocol, and how clients connect to them.
One pattern runs through the entire domain: the exam favours the simplest fix that works. When a question describes tool misrouting, the answer is almost always "write better tool descriptions." Not "add a routing classifier." Not "consolidate tools into one." Just describe them properly.
Domain 3: Claude Code Configuration (20%)
The most hands-on domain. It covers configuration settings at three tiers (project, user, enterprise), CLAUDE.md files and how they scope instructions to specific directories, hooks for pre/post tool execution, and permissions.
Where people trip up: the settings hierarchy. Enterprise overrides user, user overrides project. Straightforward. But CLAUDE.md files at the working directory level are always included regardless. That distinction shows up on the exam.
Domain 4: Prompt Engineering (20%)
This one's about whether you can write prompts that hold up at production scale, not just in a playground. The exam focuses on:
- System prompts with specific, measurable criteria (telling Claude to "be conservative" doesn't count)
- Structured output using JSON schemas and validation
- Few-shot examples, including when they're the wrong fix (they add token overhead and don't solve every problem)
- Output validation pipelines that catch bad responses before users see them
The trap that gets the most people: there's a difference between advice that sounds right and a fix that solves the stated problem. Few-shot examples won't fix misrouting caused by poor tool descriptions. Telling Claude to "be conservative" won't reduce false positives. Explicit categorical criteria will.
Domain 5: Context Management (15%)
The lowest-weighted domain, but it has one concept the exam loves: the progressive summarisation trap. When you summarise conversation history to save tokens, specific values ($247.83, order #8891) get compressed into vague references ("a recent order"). The model then gives wrong answers with full confidence. It's a nasty failure mode and the exam tests it from multiple angles.
Beyond that, know prompt caching (stick static content in the system prompt so it caches), long conversation management, and production reliability patterns.
Study strategy
Week 1: Foundations (Domains 1 and 3)
These two domains are 47% of the exam. Nearly half. Start with Domain 1 and work through every task statement, especially the agentic loop lifecycle and orchestration patterns. Then move to Domain 3 and nail the settings hierarchy and CLAUDE.md scoping rules.
Week 2: Applied skills (Domains 4 and 2)
Prompt engineering and tool design are where the exam tests your judgement, not your memory. The practice scenarios mirror real exam questions closely, so do them. Watch for that recurring "simplest fix that works" pattern across both domains.
Week 3: Context and practice exams
Finish Domain 5, then take the diagnostic exam to find your weak spots. Go back and review anything where you scored below 70%. When you feel solid, take the full practice exam.
Resources that actually matter
- Practice questions - 150+ questions across all 5 domains, matching the exam format
- Diagnostic exam - a shorter test that pinpoints your weak domains
- Build exercises - hands-on projects that make the concepts stick
- Quick reference sheets - one-page summaries per domain for last-minute review
- Glossary - precise definitions for every term the exam uses
For primary sources, read the Claude documentation, the MCP specification, and the Claude Code documentation. Everything else is supplementary.
Common mistakes
- Treating all domains the same. Domain 1 is worth nearly double what Domain 5 is. Study proportionally.
- Memorising API parameter names. The exam doesn't care if you know the exact method signature. It cares whether you know what
stop_reasonvalues mean and when to check them. - Skipping practice questions. Four options, all plausible, only one correct. If you haven't practised picking the best answer from several good-looking ones, you'll lose marks you didn't need to lose.
- Only studying the right way to do things. The exam asks "what's wrong with this approach" just as often as "what's the right approach." Know the anti-patterns cold.
What to do next
Starting from zero? Go to the Domain 1 lessons. Already have some background? Take the diagnostic exam to find your gaps. And when you're ready for a full dry run, the practice exam matches the real format.