Claude Certified Architect (Foundations): Exam Map and Study Method
The Claude Certified Architect (Foundations) examination assesses the ability to design, build, and operate production systems built on Claude — agentic loops, multi-agent orchestration, tool and MCP design, Claude Code configuration, prompt engineering, and context management. The notes below synthesise the full five-domain curriculum. The reference material is an independent community study guide and is not affiliated with or endorsed by Anthropic; where it states product specifics (SDK version numbers, command flags), those are presented as the guide presents them, and current behaviour should be verified against the official documentation at docs.claude.com and code.claude.com.
How the exam is structured
The exam is organised into five weighted domains and thirty task statements. The weightings indicate roughly how many questions each domain contributes, and they should drive study time allocation: Domain 1 alone is more than a quarter of the exam.
| Domain | Topic | Weight | Task statements |
|---|---|---|---|
| 1 | Agentic Architecture & Orchestration | 27% | 7 |
| 2 | Tool Design & MCP Integration | 18% | 5 |
| 3 | Claude Code Configuration & Workflows | 20% | 6 |
| 4 | Prompt Engineering & Structured Output | 20% | 6 |
| 5 | Context Management & Reliability | 15% | 6 |
The published pass mark is 720 out of 1,000 points. Experienced Claude developers are advised to budget roughly 15–20 hours of preparation; newcomers 30–40 hours.
The recurring "meta-patterns" the exam rewards
Across all five domains, the same diagnostic instincts are tested repeatedly. Internalising these makes individual questions easier because the right answer usually expresses one of them.
- Determinism beats probability for high-stakes rules. When a single failure causes money loss, a security breach, or a compliance violation, the answer is a code-level mechanism (hook, gate, settings file), never a stronger prompt.
- Trace failures to their origin. In multi-agent systems, a bad output usually comes from the input a component received (the coordinator's decomposition or context passing), not from the component that produced the visible result.
- Prefer low-effort, high-leverage fixes first. Better tool descriptions before routing classifiers; scoped access before full access; community MCP servers before custom builds; examples before more prose.
- Structural problems need structural fixes. Attention dilution, context degradation, and lost-in-the-middle are not solved by bigger models or larger context windows.
- Self-reported confidence and sentiment are poorly calibrated and should never directly drive automated decisions without calibration.
Many questions present a tempting but wrong distractor: "add stronger instructions," "use a bigger context window," "increase the iteration cap," "average the conflicting values," "escalate on negative sentiment." Recognising the distractor family is often faster than reasoning each option from scratch.
