CCAR-F: how the exam is dealt

The Claude Certified Architect – Foundations exam asks one kind of question over and over: given this production system, which design holds up? It is not a recall test about API parameters. Almost every item puts a working system in front of you, breaks something about it, and offers four plausible repairs.

The blueprint

Five domains, weighted. The weights are approximate proportions of scored items, and they are the single best guide to where your study hours belong.

Domain 1 is the largest single block and Domain 5 the smallest, but the spread is narrow — there is no domain you can afford to skip, and no domain that will carry you on its own.

What the scenario draw means for you

The domains do not distribute evenly across the scenarios either. Prompt engineering and structured output live mostly in the extraction and CI contexts; the multi-agent and support contexts carry orchestration and context management. So the draw moves your domain mix, which is why the practice papers here draw four scenarios apiece rather than dealing a fixed blend.

A study sequence that works

What the exam will not reward

Scenario 1: Customer Support Resolution Agent

You are building a customer support resolution agent using the Claude Agent SDK. The agent handles high-ambiguity requests like returns, billing disputes, and account issues. It has access to your backend systems through custom Model Context Protocol (MCP) tools (get_customer, lookup_order, process_refund, escalate_to_human). Your target is 80%+ first-contact resolution while knowing when to escalate.

Passage quoted verbatim from the official CCAR-F exam guide v1.0, section 5.

Primary domains

• Agentic Architecture & Orchestration
• Tool Design & MCP Integration
• Context Management & Reliability

What the exam asks inside this context

• Enforcement before money moves. Identity verification ahead of a refund is the canonical prerequisite-gate item, and the correct answer is programmatic every time. A refund above a threshold gets intercepted and rerouted to escalation, not talked out of.

• Tool descriptions with boundaries. The four named tools are deliberately close together, and questions turn on what a description fails to say — a threshold, an input format, an edge case.

• When to escalate. Three legitimate triggers: the customer asks for a human, policy is silent or has an exception, or the agent cannot make progress. Frustration is not one of them, and neither is a low self-reported confidence.

• Facts that survive a long conversation. Amounts, dates, order numbers and statuses belong in a persistent case-facts block outside the summarized history, because summarization is what eats them.

Scenario 2: Code Generation with Claude Code

You are using Claude Code to accelerate software development. Your team uses it for code generation, refactoring, debugging, and documentation. You need to integrate it into your development workflow with custom slash commands, CLAUDE.md configurations, and understand when to use plan mode vs direct execution.

Passage quoted verbatim from the official CCAR-F exam guide v1.0, section 5.

Primary domains

• Claude Code Configuration & Workflows
• Context Management & Reliability

What the exam asks inside this context

• Configuration scope. Which CLAUDE.md level reaches a teammate, which slash command directory is shared, and why a new joiner is missing instructions that work perfectly for everyone else.

• Plan mode against direct execution. Scope decides it. A single-file fix with a clear stack trace is executed; a migration across forty-five files is planned first.

• Skills and their frontmatter. context: fork for verbose or exploratory work, allowed-tools to keep a skill from doing damage, argument-hint for a missing parameter.

• Iterative refinement. Concrete input/output examples and failing tests, rather than more description. Interacting problems go in one message; independent ones are better fixed one at a time.

Scenario 3: Multi-Agent Research System

You are building a multi-agent research system using the Claude Agent SDK. A coordinator agent delegates to specialized subagents: one searches the web, one analyzes documents, one synthesizes findings, and one generates reports. The system researches topics and produces comprehensive, cited reports.

Passage quoted verbatim from the official CCAR-F exam guide v1.0, section 5.

Primary domains

• Agentic Architecture & Orchestration
• Tool Design & MCP Integration
• Context Management & Reliability

What the exam asks inside this context

• What a subagent inherits. Nothing. Not the parent conversation, not earlier findings, not memory between invocations — so the synthesis subagent gets the complete prior findings in its prompt or it does not have them.

• Decomposition that covers. Slice a topic too narrowly and every slice is complete while the cross-cutting question is owned by nobody. Partition scope, by subtopic or by source type, before the subagents start.

• Errors that a coordinator can act on. Failure type, what was attempted, partial results, alternatives. A generic 'search unavailable' is technically true and useless.

• Provenance through synthesis. Claim-source mappings with URLs, document names and excerpts, preserved and merged rather than compressed away — plus dates, so a year-old figure is not read as a contradiction.

Scenario 4: Developer Productivity with Claude

You are building developer productivity tools using the Claude Agent SDK. The agent helps engineers explore unfamiliar codebases, understand legacy systems, generate boilerplate code, and automate repetitive tasks. It uses the built-in tools (Read, Write, Bash, Grep, Glob) and integrates with Model Context Protocol (MCP) servers.

Passage quoted verbatim from the official CCAR-F exam guide v1.0, section 5.

Primary domains

• Tool Design & MCP Integration
• Claude Code Configuration & Workflows
• Agentic Architecture & Orchestration

What the exam asks inside this context

• Which built-in for which job. Grep searches contents, Glob matches paths, Edit needs a unique anchor and Read plus Write is the fallback when there is not one.

• Learning a codebase without reading it all. Grep to entry points, Read to follow imports and trace flows. Reading everything up front fills the context with files the task never touches.

• Scoped tool sets. An agent holding explore, edit and deploy together will eventually edit during an investigation. The fix is the tool list, not an instruction.

• MCP servers alongside the built-ins. Project versus user scope, environment variable expansion for tokens, and a description good enough that the agent does not fall back to Grep.

Scenario 5: Claude Code for Continuous Integration

You are integrating Claude Code into your Continuous Integration/Continuous Deployment (CI/CD) pipeline. The system runs automated code reviews, generates test cases, and provides feedback on pull requests. You need to design prompts that provide actionable feedback and minimize false positives.

Passage quoted verbatim from the official CCAR-F exam guide v1.0, section 5.

Primary domains

• Claude Code Configuration & Workflows
• Prompt Engineering & Structured Output

What the exam asks inside this context

• Running non-interactively. -p, or the job hangs. Then --output-format json with --json-schema, because inline PR comments need parseable findings rather than prose to scrape.

• Precision over emphasis. Explicit categorical criteria — report bugs and security, skip minor style — rather than asking for high-confidence findings only.

• Independent review. The session that generated the code is the worst reviewer of it, because it holds the reasoning that produced the mistake.

• Repeat runs. Prior findings go into context with an instruction to report only new or unaddressed issues, or every re-run posts the same comments again.

Scenario 6: Structured Data Extraction

You are building a structured data extraction system using Claude. The system extracts information from unstructured documents, validates the output using JavaScript Object Notation (JSON) schemas, and maintains high accuracy. It must handle edge cases gracefully and integrate with downstream systems.

Passage quoted verbatim from the official CCAR-F exam guide v1.0, section 5.

Primary domains

• Prompt Engineering & Structured Output
• Context Management & Reliability

What the exam asks inside this context

• Guaranteed shape. tool_use with a JSON schema, and tool_choice set so a tool is actually called — 'any' when the document type is unknown, forced when one extraction must run first.

• Schema design against fabrication. Optional and nullable fields where the source may be silent; an 'unclear' enum value and 'other' plus a detail string where the categories may not fit.

• Validation that catches meaning. Schemas remove syntax errors and leave semantic ones. calculated_total beside stated_total, and a conflict_detected boolean, put the check in the output shape.

• Retry, and knowing when not to. Retry with the specific validation errors attached. Do not retry when the information is simply absent from the document.

Domain 1: Agentic Architecture & Orchestration

Domain 1 is the biggest block on the exam, and nearly all of it reduces to one question: what is actually in control? The loop is controlled by stop_reason, not by reading the assistant's text. Ordering is controlled by a prerequisite gate, not by an instruction. A subagent's scope is controlled by the tools it was given, not by what it was told. Read every Domain 1 stem for the mechanism, and you will find that the distractors are almost always the version where a person is trusting the model to cooperate.

What the guide measures here

1. Design and implement agentic loops with proper termination conditions
2. Orchestrate multi-agent systems with coordinator-subagent patterns
3. Configure subagent invocation, context passing, and spawning
4. Implement multi-step workflows with enforcement and handoff patterns
5. Apply Agent SDK hooks for tool call interception and data normalization
6. Design task decomposition strategies for complex workflows
7. Manage session state, resumption, and forking

The order to learn them in

Domain 1 Project — build a support agent, then make it a team

One system, seven stages. You start with a single agent that can call two tools and finish with a coordinator delegating to subagents across resumable sessions. Every stage is one of Domain 1's seven task statements, so finishing the project is finishing the domain's practical half.

Domain 1 is 27% of the exam, the largest block, and nearly all of it reduces to one question: what is actually in control? You cannot answer that from reading. You answer it by writing the loop, watching it stop for the wrong reason, and fixing it.

What you will be able to do

• Write an agentic loop that terminates on stop_reason and explain why the other three termination strategies are wrong
• Enforce a business rule in code and say when a prompt instruction is not enough
• Build a coordinator that delegates to subagents and explain what each subagent does and does not inherit
• Choose between a fixed pipeline and adaptive decomposition, and justify the choice from the task rather than from preference
• Decide between resuming a session, forking it, and starting fresh with an injected summary

Before you start

Three commands and a smoke test. Do this before stage 1 — a setup problem discovered halfway through a loop looks exactly like a loop bug, and you will spend the difference debugging the wrong thing.

No key yet? Create one in the Anthropic Console. Every stage in this project costs a few cents at most; the loop you build sends short messages.

Now put this in agent.py and run python agent.py:

You should see end_turn ready. If you do, the install works, the key works, and you have already met the one field the whole of stage 1 turns on.

If instead you see an authentication error, the key is wrong or not exported in this shell. If the import fails, the virtualenv is not active — the source line above has to be re-run in every new terminal.

Build it in this order

The order is not the guide's. It is the order the system needs: enforcement has to have a loop to enforce, hooks intercept calls the loop is already making, and a coordinator is only worth having once there is decomposition to hand out.

Stage 1 in full

The four steps

Send the whole conversation. Read stop_reason. If it is tool_use, run the tools, append the results, and go again. If it is end_turn, you are done. The Messages API is stateless — everything the model knows on iteration four is something your loop put in the request.

Beyond the two values the guide names

The exam guide keys tool_use and end_turn — the two a basic loop branches on, and the two you will be graded on. The live API returns five more, and a loop that assumes anything other than end_turn means tool_use will mishandle all of them:

refusal arrives on a successful HTTP response, so a loop that only checks status codes treats it as ordinary output — and its stop_details identifies the policy category. The safe default is to treat anything other than end_turn as "not finished, find out why".

For the exam, know the two. For production, handle the seven.

Verified against the Messages API documentation on 2026-08-30: https://platform.claude.com/docs/en/build-with-claude/handling-stop-reasons

The three anti-patterns

Parsing natural language. Checking whether Claude said "I'm done". Ambiguous by construction — it may have finished the first file and be about to open the second.

An iteration cap as the primary stopping mechanism. It either cuts off work that needed twelve iterations or burns seven on a task that finished in three. A cap is a safety net; it is not a design.

Treating assistant text as completion. Claude routinely returns explanatory text alongside a tool_use block in the same response — "Let me look up your order" and the lookup arrive together. Text presence says nothing about whether the agent is finished.

Reference implementation

Work the stage first. This is what a finished stage 1 looks like, and the base every later stage modifies.

Three details worth reading twice. The refusal branch reads stop_details, which is populated for that value alone. The loop is a for over the cap rather than a while True with a counter, so the cap is structurally a bound — exactly what the anti-pattern says it should be. And the calculator walks a whitelisted syntax tree rather than calling eval: a tool is an execution surface the model decides to invoke, and a lab that ships eval teaches the opposite of what Domain 2 is about.

Prove stage 1 before moving on

• Break the append on purpose: stop adding the tool_result message and re-run. The agent should call the same tool again — the repeated-call symptom seen from the inside.
• Log stop_reason every iteration. A two-tool prompt should print tool_use, tool_use, end_turn.
• Confirm the safety cap never trips on a normal query. If it does, the loop is not terminating on stop_reason and stage 1 is not finished.

When you get stuck

Every stage above ends with a STUCK? line — the first thing worth checking, which is usually the thing actually wrong.

Past that, in the app: the Help button in this page's toolbar sends the tutor the section you are currently reading, together with the project's title, so you can ask "why does this not work" without pasting anything in. It knows which stage you are on.

• Print stop_reason before you branch on it. Most of stage 1's failures stop being mysterious the moment the value is on screen.
• Print the message list, not just the reply. Almost every bug in stages 1 to 3 is a message that was not appended, appended twice, or appended in the wrong role. The history is the state; look at the state.
• Change one thing. These stages compose, so a stage that breaks after you edited two of them gives you no information about either.

Where the depth lives

This page is for building. The reading is elsewhere, and repeating it here would put the same claims in three places to drift apart:

• The Domain 1 roadmap — what the domain is about, the order to learn it in, and where it catches people
• 7 flashcard decks, 48 cards — one card per published objective
• 66 Domain 1 questions — judgement under exam conditions, inside the six production scenarios

Sources

• CCAR-F Exam Guide v1.0, section 6 — Domain 1's seven task statements, which are this project's seven stages.
• CCAR-F Exam Guide v1.0, section 8 — Preparation Exercise 1 (Build a Multi-Tool Agent with Escalation Logic) and Exercise 4 (Design and Debug a Multi-Agent Research Pipeline). This project merges them: exercise 1 is the loop-and-enforcement half, exercise 4 the coordinator half.
• Anthropic Messages API reference — the stop_reason set, stop_details, the tool_result message shape, and the parallel-tool-use rule.

The tool-use round trip, from the API documentation

The exam guide describes the agentic loop in prose. This is the same loop as the API documents it: the exact message shapes, the exact field names, and the full set of values that decide whether your loop runs again.

One turn, in full

A client tool round trip is three messages. Your request defines the tool; Claude answers with a tool_use block; you run the tool and send a tool_result back.

1. You send messages plus a tools array. Each tool carries a name, a description, and an input_schema.
2. Claude replies with stop_reason: "tool_use" and one or more tool_use blocks. Each block has an id, a name, and an input object.
3. You append two messages — the assistant turn verbatim, then a user turn whose content is a tool_result block carrying tool_use_id and content. The tool_use_id must match the id from step 2.
4. You send again. Claude uses the result to answer.

Where the code runs

The documentation splits tools by where they execute, and it is worth holding because it decides whether you write a handler at all.

bash and text_editor are client tools with Anthropic-published schemas. web_search, web_fetch and code_execution are server tools.

Every stop_reason value

This is the set the loop branches on. The exam guide keys two of them; the API returns seven.

Two details the documentation is specific about: refusal returns HTTP 200, not an error, and the pause_turn iteration limit for server-side tool loops defaults to 10.

tool_choice

tool_choice constrains a single request. The default is {"type": "auto"}, which lets Claude decide whether to call a tool at all.

disable_parallel_tool_use: true limits a turn to at most one tool call.

Strict tool use

Adding strict: true to a custom tool definition makes Claude's calls match your schema exactly. That eliminates a class of shape error and does nothing about semantics — a schema-valid call can still put the right value in the wrong field.

Sources

• Tool use overview — https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview (retrieved 2026-08-30)
• Handling stop reasons — https://platform.claude.com/docs/en/build-with-claude/handling-stop-reasons (retrieved 2026-08-30)