This article summarises the Claude Certified Architect Foundations (CCAR-F) exam guide published by Anthropic: what the certification validates, the exam format, what the domain weights mean, the task statements under each domain, and the scenarios the exam uses.
What CCAR-F validates
Anthropic's exam guide states that the certification "validates that practitioners can make informed decisions about tradeoffs when implementing real-world solutions with Claude."
The exam is intended for solution architects who design and implement production applications with Claude. The guide states that the candidate "typically has 6+ months of practical experience building with Claude APIs, Agent SDK, Claude Code, and MCP." It lists recommended experience in:
- Building agentic applications with the Claude Agent SDK, including multi-agent orchestration, subagent delegation, tool integration and lifecycle hooks
- Configuring Claude Code for team workflows with CLAUDE.md files, Agent Skills, MCP server integrations and plan mode
- Designing MCP tool and resource interfaces for backend system integration
- Engineering prompts that produce reliable structured output
- Managing context windows across long documents, multi-turn conversations and multi-agent handoffs
- Integrating Claude into CI/CD pipelines for code review, test generation and pull request feedback
- Making escalation and reliability decisions, including error handling and human-in-the-loop workflows
Exam format
| Item | Detail |
|---|---|
| Exam code | CCAR-F |
| Questions | 60 |
| Question types | Multiple choice and multiple response. Each question states how many answers to select. |
| Structure | 4 scenarios, picked at random from a bank of 6 |
| Time | 120 minutes |
| Delivery | Proctored, online or at a test centre |
| Passing score | Scaled score of 720 on a scale of 100 to 1,000 |
| Result | Pass or fail, scaled score, and percent correct by domain |
| Exam fee | US$125 |
| Validity | 12 months from the award date |
A scaled score of 720 does not mean 72% of questions answered correctly.
What domain weights mean
The exam guide divides the exam content into five domains and gives each domain a weight. The guide explains the weights as follows:
"Weights reflect the relative importance of each domain to competent performance as determined through the job task analysis. The percentages indicate the approximate proportion of scored items drawn from each domain."
In practice, a domain weight tells you roughly what share of the scored questions come from that domain. Multiplying the weight by 60 gives an estimate of the number of questions. The actual number on your exam can differ.
| Domain | Domain weight | Estimated questions |
|---|---|---|
| Agentic Architecture & Orchestration | 27% | 16 |
| Claude Code Configuration & Workflows | 20% | 12 |
| Prompt Engineering & Structured Output | 20% | 12 |
| Tool Design & MCP Integration | 18% | 11 |
| Context Management & Reliability | 15% | 9 |
Your result shows percent correct for each domain, so you can see which domains to study again if you need to retake the exam.
Task statements in each domain
The guide lists task statements under each domain. Each task statement has knowledge and skills listed beneath it. The task statements do not have separate weights. The second column below gives examples of what the guide lists for each one.
Agentic Architecture & Orchestration (27%)
| Task statement | Examples from the guide |
|---|---|
| 1.1 Design and implement agentic loops for autonomous task execution | Checking stop_reason ("tool_use" or "end_turn"), adding tool results to the conversation history, not using iteration caps as the main way to stop |
| 1.2 Orchestrate multi-agent systems with coordinator-subagent patterns | A coordinator that routes all communication, subagents with isolated context, splitting research scope across subagents |
| 1.3 Configure subagent invocation, context passing, and spawning | The Task tool, allowedTools, AgentDefinition, passing earlier findings in the subagent prompt, parallel Task calls |
| 1.4 Implement multi-step workflows with enforcement and handoff patterns | Programmatic prerequisites instead of prompt instructions, structured handoff summaries for human agents |
| 1.5 Apply Agent SDK hooks for tool call interception and data normalization | PostToolUse hooks, blocking tool calls that break a policy, choosing hooks when compliance must be guaranteed |
| 1.6 Design task decomposition strategies for complex workflows | Prompt chaining or dynamic decomposition, per-file review passes plus a cross-file pass |
| 1.7 Manage session state, resumption, and forking | --resume with session names, fork_session, starting a new session with a summary when tool results are stale |
Tool Design & MCP Integration (18%)
| Task statement | Examples from the guide |
|---|---|
| 2.1 Design effective tool interfaces with clear descriptions and boundaries | Tool descriptions as the main input to tool selection, removing overlap between tools, splitting generic tools |
| 2.2 Implement structured error responses for MCP tools | The isError flag, transient, validation, business and permission errors, retryable and non-retryable errors |
| 2.3 Distribute tools appropriately across agents and configure tool choice | Giving each agent only the tools its role needs, tool_choice "auto", "any" and forced selection |
| 2.4 Integrate MCP servers into Claude Code and agent workflows | Project-level .mcp.json and user-level ~/.claude.json, environment variable expansion, MCP resources |
| 2.5 Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively | Grep for file contents, Glob for file paths, Read and Write when Edit cannot find a unique match |
Claude Code Configuration & Workflows (20%)
| Task statement | Examples from the guide |
|---|---|
| 3.1 Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization | User, project and directory levels, @import, the .claude/rules/ directory, the /memory command |
| 3.2 Create and configure custom slash commands and skills | .claude/commands/, .claude/skills/ with SKILL.md, the context: fork, allowed-tools and argument-hint options |
| 3.3 Apply path-specific rules for conditional convention loading | Rules files with a paths field and glob patterns, so rules load only for matching files |
| 3.4 Determine when to use plan mode vs direct execution | Plan mode for multi-file and architectural changes, direct execution for well-scoped fixes, the Explore subagent |
| 3.5 Apply iterative refinement techniques for progressive improvement | Input and output examples, writing tests first, the interview pattern |
| 3.6 Integrate Claude Code into CI/CD pipelines | The -p flag, --output-format json and --json-schema, an independent instance to review generated code |
Prompt Engineering & Structured Output (20%)
| Task statement | Examples from the guide |
|---|---|
| 4.1 Design prompts with explicit criteria to improve precision and reduce false positives | Specific criteria instead of "be conservative", severity levels defined with code examples |
| 4.2 Apply few-shot prompting to improve output consistency and quality | 2 to 4 examples for ambiguous cases, examples for documents with different formats |
| 4.3 Enforce structured output using tool use and JSON schemas | Tool use with JSON schemas, tool_choice settings, optional (nullable) fields, "other" plus detail fields |
| 4.4 Implement validation, retry, and feedback loops for extraction quality | Retrying with the validation error included, knowing when a retry cannot help, detected_pattern fields |
| 4.5 Design efficient batch processing strategies | Message Batches API (50% cost savings, up to 24-hour processing, no latency SLA), custom_id, resubmitting only failed items |
| 4.6 Design multi-instance and multi-pass review architectures | Independent review instances, per-file passes plus cross-file integration passes |
Context Management & Reliability (15%)
| Task statement | Examples from the guide |
|---|---|
| 5.1 Manage conversation context to preserve critical information across long interactions | A persistent "case facts" block, the "lost in the middle" effect, trimming tool output to relevant fields |
| 5.2 Design effective escalation and ambiguity resolution patterns | When to escalate, honouring a request for a human, asking for more identifiers when several records match |
| 5.3 Implement error propagation strategies across multi-agent systems | Structured error context, telling access failures apart from valid empty results |
| 5.4 Manage context effectively in large codebase exploration | Scratchpad files, subagent delegation, state manifests for crash recovery, /compact |
| 5.5 Design human review workflows and confidence calibration | Stratified sampling, accuracy by document type and field, confidence thresholds set with labelled data |
| 5.6 Preserve information provenance and handle uncertainty in multi-source synthesis | Claim-source mappings, keeping conflicting figures with their sources, publication dates |
Exam scenarios
The guide states that the exam uses scenario-based questions. Each scenario describes a production context and frames a set of questions. Four scenarios are picked at random from these six:
| Scenario | Primary domains |
|---|---|
| Customer Support Resolution Agent | Agentic Architecture & Orchestration; Tool Design & MCP Integration; Context Management & Reliability |
| Code Generation with Claude Code | Claude Code Configuration & Workflows; Context Management & Reliability |
| Multi-Agent Research System | Agentic Architecture & Orchestration; Tool Design & MCP Integration; Context Management & Reliability |
| Developer Productivity with Claude | Tool Design & MCP Integration; Claude Code Configuration & Workflows; Agentic Architecture & Orchestration |
| Claude Code for Continuous Integration | Claude Code Configuration & Workflows; Prompt Engineering & Structured Output |
| Structured Data Extraction | Prompt Engineering & Structured Output; Context Management & Reliability |
Because you do not know which four scenarios you will get, prepare for all six.
Example question
This is an original Timo practice question on task statement 1.5, in the style of the Customer Support Resolution Agent scenario. It is not an official exam question.
A support agent built with the Claude Agent SDK can close customer accounts through a close_account tool. Accounts with an unpaid balance must never be closed by the agent. Those cases must go to the billing team. The rule must hold every time.
Which approach should the team use?
A. State the rule in the system prompt and add three examples of accounts that must not be closed.
B. Add a hook that checks the balance before each close_account call, blocks the call when the balance is unpaid, and routes the case to billing.
C. Have the agent state its confidence before each closure, and send low-confidence cases to the billing team.
D. Have billing staff review a random sample of closed accounts each week, and reopen any that had an unpaid balance.
Answer: B. A hook runs in code on every close_account call, so the rule holds every time.
- A relies on prompt instructions. The guide notes that prompt instructions alone have a non-zero failure rate when compliance must be deterministic.
- C relies on a confidence rating from the model. The guide describes self-reported confidence as an unreliable measure of case complexity.
- D finds the problem after the account is closed, so it does not meet the requirement that such accounts are never closed.
More questions in this format are in the free 20-question CCAR-F practice test, which explains every answer option and does not require sign-up. For the exam format and registration steps, see the CCAR-F exam guide on Timo Labs.
Top comments (0)