The CCA-Foundations Exam, and How This Series Prepares You
What the Claude Certified Architect – Foundations exam (CCAR-F) actually measures — the five weighted domains, the scenario format, the 720-to-pass bar — and how this series maps to the blueprint, built and verified against the current Claude Agent SDK.
The Claude Certified Architect – Foundations exam (code CCAR-F) certifies that you can design and build production systems on Anthropic’s stack. That means agents with the Claude Agent SDK, tools and MCP servers, Claude Code workflows, structured output, and the context-management discipline that keeps all of it reliable. This series is a study guide for that exam, but it’s written the way the rest of this blog is written: against the actual SDK and tooling, with the code verified rather than recalled. If you pass because you memorized a blueprint, you learned the wrong thing; the aim here is that you pass because you can build the systems the blueprint describes.
This first post is orientation: what the exam is, how it’s scored, what it measures, and how the series is organized against it. No code yet — that starts in the next post.
What the exam is
The format matters, because it shapes how you should study.
- 60 items, multiple-choice and multiple-response — each item tells you how many answers to select, so a “select all that apply” won’t blindside you.
- Scenario-based. The exam draws 4 scenarios at random from a bank of 6 (below), and the questions hang off those scenarios. You’re not answering trivia; you’re reasoning about a described production system.
- 120 minutes.
- Passing score: 720 on a 100–1,000 scale. Your report is pass/fail plus a percent-correct by domain, so a weak domain shows up even if you pass.
- $125 USD, proctored (online or test center), credential valid 12 months.
The scenario format is the single most useful thing to internalize. This is not a “define MCP” exam; it’s a “you’re building a support agent with these four tools and an 80%-resolution target — what’s the right escalation design?” exam. Study the judgment, not the vocabulary.
The blueprint: five weighted domains
The exam is built from five content domains, weighted by how much they matter to competent performance. The percentages are the approximate share of scored items from each:
| # | Domain | Weight |
|---|---|---|
| 1 | Agentic Architecture & Orchestration | 27% |
| 2 | Tool Design & MCP Integration | 18% |
| 3 | Claude Code Configuration & Workflows | 20% |
| 4 | Prompt Engineering & Structured Output | 20% |
| 5 | Context Management & Reliability | 15% |
Domain 1 is the heaviest by a clear margin, over a quarter of the exam. It’s also the one most people underprepare. “Agentic loops” and “multi-agent orchestration” sound conceptual until you have to reason about what actually terminates a loop or what a subagent can see. Domains 3 and 4 tie for second at 20% each. Domain 5 is the lightest, but don’t skip it: it’s reinforced across nearly every scenario, so you’ll meet it in context whether you study it directly or not.
The six scenarios
Each exam presents four of these six. Reading them now tells you exactly what kind of system the questions assume:
- Customer Support Resolution Agent — a Claude Agent SDK agent handling returns, billing disputes, and account issues through MCP tools (
get_customer,lookup_order,process_refund,escalate_to_human), targeting 80%+ first-contact resolution while knowing when to escalate. (Domains 1, 2, 5) - Code Generation with Claude Code — Claude Code in a dev workflow: generation, refactoring, debugging, with custom slash commands, CLAUDE.md config, and plan-mode-vs-direct-execution judgment. (Domains 3, 5)
- Multi-Agent Research System — a coordinator delegating to specialized subagents (search, analyze, synthesize, report) to produce cited reports. (Domains 1, 2, 5)
- Developer Productivity with Claude — an agent exploring unfamiliar codebases with the built-in tools (Read, Write, Bash, Grep, Glob) plus MCP servers. (Domains 2, 3, 1)
- Claude Code for CI/CD — Claude Code in a CI/CD pipeline running automated reviews and test generation, designing prompts for actionable feedback with few false positives. (Domains 3, 4)
- Structured Data Extraction — extracting from unstructured documents, validating against JSON schemas, handling edge cases. (Domains 4, 5)
Notice the recurring cast: the Agent SDK, MCP tools, Claude Code, and the twin reliability concerns of escalation and structured validation. Master those and you’ve covered the surface the scenarios draw from.
How this series is organized
The series follows the blueprint, one arc per domain, sized so each post treats a coherent slice completely:
- Arc 1 — Agentic Architecture & Orchestration (the heaviest): the agentic loop and what really terminates it; coordinator–subagent orchestration and context isolation; workflows, hooks, and session state.
- Arc 2 — Tool Design & MCP Integration: designing tool interfaces and structured errors; distributing tools and wiring MCP servers; the built-in tools.
- Arc 3 — Claude Code Configuration & Workflows: CLAUDE.md hierarchy and path rules; slash commands and skills; plan mode and CI/CD.
- Arc 4 — Prompt Engineering & Structured Output: precision prompting and few-shot; structured output via tools and JSON schema; batch and multi-pass review.
- Arc 5 — Context Management & Reliability: context management; escalation and error propagation; human review, confidence, and provenance.
- A closing post works all six scenarios end to end, the way the exam frames them.
Each post names the exact task-statement objectives it covers, because the exam items are written against those objectives. So you’ll always know which blueprint line a section is preparing you for.
One thing this series does deliberately: it teaches the anti-patterns the blueprint explicitly flags as wrong, not just the right answers. Domain 1, for instance, calls out terminating a loop by parsing the model’s natural-language output, or using an arbitrary iteration cap as the primary stop condition. Those are exactly the plausible-but-wrong options an exam item will offer, so knowing why they’re wrong is worth as much as knowing the right design.
How the code is verified
This blog’s rule is that every technical claim is either run against a pinned version or flagged in the post as unrun. This series is honest about a split that’s specific to it.
The code is written against claude-agent-sdk 0.2.128 and anthropic 0.120.0 (Python 3.13), the current versions as of writing, with Claude Code checked against the live tool. Everything that can be verified without a live model call has been. The SDK’s real surface — query(), ClaudeSDKClient, AgentDefinition and its fields, the hook event types, the session functions (fork_session, resume, list_sessions), the tool and MCP APIs. Plus the anthropic Messages API’s stop_reason values and structured-output parameters, and the Claude Code configuration surface (CLAUDE.md scoping, commands vs. skills, plan mode). Those are structural facts, and they’re confirmed.
Running a live agent needs an Anthropic API key — an agentic loop actually calling Claude, say, or a structured-output extraction judged for quality. Unlike a model-agnostic framework, there’s no local substitute for Claude’s own behavior. Those examples were written against the verified API and then executed in a dedicated key-based pass against claude-haiku-4-5 (the model is a swappable slot; the same code runs on any Claude model). Where a claim is about the API or SDK contract — the loop terminating on end_turn, a PreToolUse hook firing and denying, tool_choice forcing a schema — the pass confirmed the exact runtime behavior. Each chapter notes what was observed. Where a claim is about model quality — does few-shot improve consistency, does tighter tool scoping improve selection — the pass confirmed the direction. Few-shot took format adherence from 0 of 4 to 4 of 4, and the magnitude stays model-dependent. An unverified claim wearing confident prose is the failure mode to avoid, so every runtime claim here was either run or is marked as model-dependent.
That’s a large amount of verifiable surface, and it’s now been run. The Agent SDK maps to the exam so directly that most of what you need to know is checkable by introspection, and that’s where we begin.
Setting up to follow along
The runnable examples in this series need just two packages. The quickest way to a working project is uv, scaffolding the project and pinning the exact versions used here:
uv init cca-dev && cd cca-dev
uv add anthropic==0.120.0 claude-agent-sdk==0.2.128
That’s the pair the series was verified against (Python 3.13); run any snippet with uv run python script.py.
Two things the code needs from outside itself:
- An API key, from the environment. The
anthropicclient and the Agent SDK both readANTHROPIC_API_KEYfrom the environment — a.envfile is not loaded automatically. Export it (export ANTHROPIC_API_KEY=sk-ant-…),sourcean env file, or load it in Python withpython-dotenvbefore the first call. With no key reachable, a call fails with an authentication error rather than hanging. - The
claudeCLI, for the Agent SDK.claude-agent-sdkdrives theclaudecommand-line tool under the hood. So thequery(), hooks, and sessions examples need the Claude Code CLI installed and on your PATH (npm install -g @anthropic-ai/claude-code, or the native installer from Anthropic’s docs). The plainanthropicexamples don’t need it.
Final thoughts
CCA-Foundations rewards understanding over recall: five weighted domains, a scenario format that asks for design judgment, and a 720 bar that a percent-by-domain report will hold you to. The heaviest domain — agentic architecture — is also the most underprepared, so it’s where this series starts and spends the most time. Study the systems, not the slides; the exam is built to catch people who did the reverse.
Next: the agentic loop — what actually drives an agent’s iterations, what terminates them, and the anti-patterns the blueprint wants you to recognize on sight.
Comments