Independent guide
Start here · Step 1

Sign in with your partner-organisation email on the Skilljar site, not claude.ai

Create an Anthropic Academy (Skilljar) account, authenticate, and accept the EULAs — then every course and resource below unlocks.

Important: this is a separate account from claude.ai — not your Claude login. Sign up fresh with your partner-organisation email.

Sign in / sign up at the Anthropic Partner Academy ↗

An independent study guide · Claude Certified Architect - Foundations

Pass the
CCAR-F. (also written CCA-F)

Design agentic Claude systems that survive contact with production. The exact prep path, the exam blueprint, and a guide to all 5 domains.

  1. Sign in at Skilljar with your partner-organisation email — not claude.ai.
  2. Practice on personal gear only — never run Claude on employer devices, networks, or data.
  3. Follow the prep path below (7 official courses).
  4. Book the exam — 60 Qs · 120 minutes · closed-book · pass 720/1,000.
Sign in with your partner email ↗ See the prep path →
60questions
120minutes
720to pass /1,000
5domains
01

Your prep path

There’s no single dedicated course for this exam. This is the whole prep — the catalog courses that map to the blueprint, plus curated extras (marked ★) not on Anthropic’s own list. Each course opens on Skilljar — sign in first.

  1. 01 Course
    AI Fluency: Framework & Foundations
    — Start ↗
  2. 02 Course
    Building with the Claude API
    — Start ↗
  3. 03 Course
    Claude on Google Cloud
    — Start ↗
  4. 04 Course
    Claude Code in Action
    — Start ↗
  5. 05 Course
    Claude 101
    — Start ↗
  6. 06 Course
    Claude with Amazon Bedrock
    — Start ↗
  7. 07 Course
    Introduction to Model Context Protocol
    — Start ↗
  8. 08 Course
    Introduction to Subagents ★ curated not on Anthropic's list; maps to the 27% Agentic Architecture domain
    — Start ↗
  9. 09 Course
    Introduction to Agent Skills ★ curated not on Anthropic's list; Skills are central to agentic architecture
    — Start ↗

That’s the whole prep. Then practice hands-on (use the domain guides below as reference) and book the exam (sign in with your partner email first). 9 courses · no durations published

02

Exam blueprint

A proctored, closed-book exam: 60 scenario-based multiple-choice / multiple-response questions in 120 minutes, no AI assistance. Scored to 1,000 with a passing bar of 720. It is proctored online or at a Pearson VUE test center, and the credential is valid for 12 months from the date the credential is awarded. Exam structure: 4 scenarios drawn from a bank of 6.

CCAR-F
exam code
60
questions
$125
exam fee
120 minutes
time limit
720/1,000
passing score
12 months
validity
4 scenarios drawn from a bank of 6
exam structure

Domains & weights

Study time should follow the weights. Click a domain to jump to its guide.

01 Agentic Architecture & Orchestration 27%
02 Tool Design & MCP Integration 18%
03 Claude Code Configuration & Workflows 20%
04 Prompt Engineering & Structured Output 20%
05 Context Management & Reliability 15%
03

The five domains

Reference for each domain — the concepts to know, the official docs, and exam tips. The prep path above is what to take; this is what to know. Click a domain to expand it.

01

Agentic Architecture & Orchestration

27%

This is the heaviest domain on the CCAR-F and tests your ability to design multi-step Claude systems that take actions, not just generate text. You must master the core agentic loop (Claude reasons, calls tools, observes results, repeats until done), know when a single agent, a deterministic workflow, or an orchestrated multi-agent system is the right architecture, and be able to apply Anthropic's named patterns (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer) plus the guardrails, human-in-the-loop checkpoints, and observability needed to ship agents to production. Expect scenario questions that hand you a problem and ask you to pick the simplest architecture that works.

Key concepts to master
The agentic loop. Every agent runs the same cycle: Claude receives a prompt plus tools, evaluates state and either emits text or requests tool calls (stop_reason "tool_use"), your code executes the tools and returns tool_result blocks, and the loop repeats turn-by-turn until Claude responds with no tool calls (stop_reason "end_turn"). One "turn" is one round trip of model output plus tool execution; turns continue without yielding control back to your code until the task is done. Note: server-executed tools can also pause with stop_reason "pause_turn" mid-iteration, which you handle by re-sending the conversation to let the model continue.
Workflows vs. agents. Anthropic's defining distinction: workflows orchestrate LLMs and tools through predefined code paths (predictable, consistent, lower cost), while agents let the model dynamically direct its own process and tool use (flexible, handles open-ended tasks, higher latency/cost). The exam-critical rule is "start simple": use the least autonomous solution that solves the problem, and only reach for an agent when you genuinely cannot predict the steps.
The five composable patterns. Memorize all five: Prompt Chaining (sequential steps with checkpoints), Routing (classify input, dispatch to a specialized handler/model), Parallelization (sectioning independent subtasks, or voting for confidence), Orchestrator-Workers (a lead model dynamically decomposes a task and delegates to workers, then synthesizes — for when subtasks can't be predicted in advance), and Evaluator-Optimizer (one model generates, another critiques in a refinement loop, best when you have clear eval criteria).
Subagents and context isolation. A subagent is a separate agent instance with its OWN fresh context window; only its final message returns to the parent (verbatim, as the Agent tool result, though the parent may summarize it), keeping the orchestrator's context lean. Subagents enable parallelization, tool restriction (least privilege), and specialized system prompts. The only channel from parent to subagent is the Agent tool's prompt string, so all needed file paths/context must be passed in explicitly.
Claude Agent SDK. The official package (Python and TypeScript) that embeds Claude Code's agent loop in your app — it handles tool execution, context management, compaction, retries, sessions, and permissions so you consume a message stream (SystemMessage/AssistantMessage/UserMessage/ResultMessage, plus StreamEvent when partial messages are enabled). Subagents are configured via AgentDefinition (description, prompt, tools, model, effort, maxTurns, permissionMode, and more); Claude invokes them through the built-in Agent tool, which must be in allowedTools to auto-approve.
Guardrails, permissions, and human-in-the-loop. Control autonomy with stopping conditions (max_turns / max_budget_usd), permission modes (default, acceptEdits, plan, dontAsk, bypassPermissions, plus auto in the TypeScript SDK), allowed/disallowed tool rules, and hooks (PreToolUse, PostToolUse, Stop, etc.) that can validate, audit, or block tool calls before they run. Agents should pause for human approval at high-stakes checkpoints and run in sandboxed/isolated environments — reserve bypassPermissions for CI/containers.
Single vs. multi-agent economics. Anthropic's multi-agent research system (Opus 4 lead + Sonnet 4 subagents) beat single-agent Opus 4 by 90.2% on the internal research eval — but agents use ~4x the tokens of chat and multi-agent ~15x. The takeaway for the exam: multi-agent is justified only for high-value tasks with heavily parallelizable, independent subtasks that exceed one context window; it's a poor fit for tightly-coupled work needing shared context or tight real-time coordination.
Agent evaluation and observability. You can't ship agents you can't measure: start with a small set (~20) of representative queries, use LLM-as-judge scoring against a rubric (accuracy, completeness, citations, efficiency) plus human review for edge cases, and add production tracing, resumable execution (capture session_id), and gradual rollouts. Inspect the ResultMessage subtype (success, error_max_turns, error_max_budget_usd, error_during_execution, error_max_structured_output_retries) and stop_reason (end_turn, max_tokens, refusal) to detect refusals and limit hits.
Official documentation
Building Effective Agents (Anthropic engineering) ↗ How the agent loop works — Claude Agent SDK ↗ Subagents in the Claude Agent SDK ↗ How we built our multi-agent research system (Anthropic engineering) ↗
Exam pro tips
  • When a question asks for the "best" architecture, default to the SIMPLEST one that meets the requirements. Anthropic explicitly preaches starting simple and adding agentic complexity only when demonstrably needed — answers that reach for a multi-agent orchestrator when a single agent or a fixed workflow would do are usually the distractor.
  • Anchor on the workflows-vs-agents definition: 'predefined code paths' = workflow, 'model dynamically directs its own process' = agent. If the steps are knowable in advance, it's a workflow pattern; if the number/shape of steps depends on the input, it's orchestrator-workers or an autonomous agent.
  • Remember subagent context isolation cold: each subagent gets a FRESH context and the parent only sees its final message — so subagents are the right answer for token/context savings, parallel independent work, and tool least-privilege, but the WRONG answer when subtasks must share evolving state.
  • Use the model lineup correctly under pressure: a strong lead model (Opus 4.x) orchestrating cheaper workers (Sonnet 4.x / Haiku 4.5) is the canonical cost-aware multi-agent setup. Don't cite retired or fictional model IDs, and recall that multi-agent buys accuracy at a large (~15x) token premium that only pays off on high-value, parallelizable tasks.
  • Don't forget the Agent tool must be in allowedTools to auto-approve subagent invocations — otherwise Claude won't delegate (the call falls through to your permission callback, or is denied in dontAsk mode). The same applies to the Workflow tool for large-scale orchestration.
02

Tool Design & MCP Integration

18%

This domain tests whether you can give Claude reliable access to external systems: writing well-shaped tool definitions, driving the tool-use request/response loop, and integrating tools through the Model Context Protocol (MCP). You must understand both the Claude API tool surface (the `tools` parameter, `tool_use`/`tool_result` blocks, `tool_choice`, parallel calls, error handling) and the MCP architecture (hosts/clients/servers, the three server primitives, transports, and the JSON-RPC data layer). At 18% of the exam, expect scenario questions on diagnosing poor tool selection, designing schemas, choosing transports, and routing errors correctly.

Key concepts to master
Tool definition anatomy. A Claude tool definition has three core fields: `name` (must match the regex `^[a-zA-Z0-9_-]{1,64}$`), `description` (a detailed plaintext explanation), and `input_schema` (a JSON Schema object with `type`, `properties`, and `required`). Optional fields include `input_examples`, `strict`, `cache_control`, `defer_loading`, and `allowed_callers`.
Descriptions are the #1 performance lever. Tool-selection accuracy depends far more on the prose description than the schema; Anthropic calls it 'by far the most important factor in tool performance.' Aim for at least 3-4 sentences covering what the tool does, when (and when not) to use it, what each parameter means, and any caveats such as what the tool does NOT return; vague one-liners cause mis-selection.
The tool-use loop. Claude returns `stop_reason: "tool_use"` with one or more `tool_use` content blocks (each has `id`, `name`, `input`). Your code executes them and sends back a user message containing `tool_result` blocks that reference `tool_use_id` and carry `content`; the tool_result blocks must come first in that user message's content array. The loop repeats until Claude responds with text.
tool_choice and parallel calls. `tool_choice` has four modes: `auto` (default with tools), `any` (must use some tool), `tool` (forces a named tool), and `none` (default with no tools). `any`/`tool` prefill an assistant turn so no preamble text is emitted, and are incompatible with extended thinking (only `auto`/`none` work with extended thinking). Set `disable_parallel_tool_use: true` inside `tool_choice` to force at most one tool call per turn (exactly one when combined with `any`/`tool`).
Tool error handling (is_error). On the Claude API, you signal a failed execution by returning a `tool_result` block with `is_error: true` and an error message in `content`; Claude can then retry or adapt (it typically retries 2-3 times before apologizing). This is distinct from malformed-request errors (such as an invalid `input_examples`), which surface as normal 400 API errors.
Client tools vs server tools. Client tools (user-defined plus Anthropic-schema tools like bash/text_editor) execute in YOUR application and require you to run the loop. Server tools (e.g., web_search, code_execution, web_fetch) execute on Anthropic infrastructure and return results directly, use versioned `type` strings (e.g., `web_search_20260209`), and carry extra usage-based pricing.
MCP architecture: host, client, server. An MCP host (e.g., Claude Code, Claude Desktop) spins up one MCP client per connection, each maintaining a dedicated link to one MCP server. MCP is built on JSON-RPC 2.0 and split into a data layer (lifecycle, primitives, notifications) and a transport layer (connection establishment, message framing, authorization).
MCP primitives and transports. Servers expose three primitives: tools (model-invoked actions via `tools/call`), resources (context data, `resources/read`), and prompts (reusable templates). Clients can expose sampling (`sampling/createMessage`), elicitation (`elicitation/create`), and logging. Discovery uses `*/list` methods. Two transports: stdio (local process I/O) and Streamable HTTP (remote, HTTP POST + optional SSE, with bearer/API-key/custom-header auth, OAuth recommended).
Official documentation
Tool use with Claude - overview ↗ Define tools (schemas, descriptions, tool_choice) ↗ MCP architecture overview (modelcontextprotocol.io) ↗ MCP tools concept (definitions, tools/call, isError) ↗
Exam pro tips
  • Watch the API-vs-MCP naming trap: the Claude API uses snake_case (`input_schema`, `is_error`, `tool_use_id`) while MCP uses camelCase (`inputSchema`, `outputSchema`, `isError`, `structuredContent`). Scenario questions often hinge on picking the field name that matches the layer being described.
  • When a question says 'Claude isn't calling the right tool' or 'calls the wrong one,' the intended fix is almost always a better/more detailed tool description (or namespacing/consolidation), not forcing `tool_choice` or swapping models.
  • For transport questions, anchor on cardinality and locality: stdio = local, single client, no network; Streamable HTTP = remote, many clients, HTTP POST + optional SSE, with bearer/API-key/custom-header auth (OAuth recommended). The cert is current MCP, so prefer Streamable HTTP over the older HTTP+SSE transport.
  • Distinguish the two MCP error paths: unknown tool or bad arguments = JSON-RPC protocol error (numeric `code` like -32602); a tool that ran but failed (API down, rate limit) = a normal result with `isError: true` so the model can react. Mirror this with the Claude API's `is_error` on `tool_result`.
03

Claude Code Configuration & Workflows

20%

This domain covers the Claude Code CLI and its configuration ecosystem: how an architect customizes Claude Code per project, per user, and per organization through layered settings.json files, CLAUDE.md memory, slash commands/skills, lifecycle hooks, permission rules, subagents, and MCP server connections. The exam tests scenario-based decisions about WHERE configuration lives (file precedence/scope), HOW to enforce vs. merely guide behavior (hooks/permissions vs. CLAUDE.md), and HOW to run Claude Code safely and reproducibly in interactive and headless/CI contexts. Expect questions that hinge on precise mechanics: hook exit codes, permission modes, settings precedence, MCP scopes, and subagent isolation.

Key concepts to master
Settings file hierarchy and precedence. Highest to lowest: managed/enterprise policy (system dirs: /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux/WSL, C:\Program Files\ClaudeCode\ on Windows), then CLI flags, then .claude/settings.local.json (gitignored, personal/local), then .claude/settings.json (project, committed), then ~/.claude/settings.json (user). Higher scope wins, EXCEPT permission rules (allow/ask/deny), which MERGE across all scopes rather than override. Note: MCP local-scoped servers live in ~/.claude.json, distinct from settings.local.json.
CLAUDE.md memory vs. auto memory. CLAUDE.md files (load order broadest-to-most-specific: managed policy > user ~/.claude/CLAUDE.md > project ./CLAUDE.md or ./.claude/CLAUDE.md > local ./CLAUDE.local.md) are author-written instructions loaded in full every session and delivered as a user message after the system prompt, NOT enforced config. Auto memory is what Claude writes itself per-repo in ~/.claude/projects/<project>/memory/MEMORY.md (first 200 lines OR 25KB, whichever comes first, loaded each session; topic files load on demand). Imports use @path syntax (max depth 4 hops, relative to the importing file); the # shortcut adds entries and '/memory' manages/views them. Reads CLAUDE.md, not AGENTS.md (import or symlink AGENTS.md if needed).
Hooks and lifecycle events. Hooks are command/http/mcp_tool/prompt/agent commands configured in settings.json under 'hooks', keyed by event (PreToolUse, PostToolUse, UserPromptSubmit, Stop, SubagentStop, SessionStart/SessionEnd, PreCompact, Notification, and more) with a matcher (tool name, regex, or '*'). Exit code 0 = success (stdout parsed as JSON for structured control); exit code 2 = blocking error (stderr fed to Claude, JSON skipped); other non-zero = non-blocking error (continues). PreToolUse can return hookSpecificOutput.permissionDecision allow/deny/ask (also 'defer') and updatedInput to rewrite the call. Hooks are the only way to GUARANTEE an action happens or is blocked.
Permissions and permission modes. permissions.allow/deny/ask use rule syntax like Bash(git diff *), Read(./.env), with trailing-space prefix matching. Modes: default (reads only), acceptEdits (auto file edits + common FS commands mkdir/touch/rm/mv/cp/sed in-scope), plan (read-only research before editing, presents a plan to approve), auto (classifier-gated autonomy, research preview), dontAsk (only pre-approved allow rules + read-only commands run; everything else denied, for CI), bypassPermissions (skip all checks, isolated containers/VMs only). Cycle default->acceptEdits->plan with Shift+Tab; set defaultMode in settings. Deny and explicit ask rules apply even in bypassPermissions; protected paths (.git, .claude, .mcp.json, .claude.json, shell rc files like .zshrc/.bashrc) are never auto-approved except in bypassPermissions, and allow rules cannot pre-approve them.
Subagents. Specialized agents with their own context window, system prompt (the markdown body), tool set, and model; they return only a summary to the main conversation. Defined as markdown+YAML frontmatter; precedence (highest first): managed > --agents CLI flag (JSON, session-only) > .claude/agents/ (project) > ~/.claude/agents/ (user) > plugin. Required frontmatter: name and description (Claude delegates based on description); optional: tools, disallowedTools, model (sonnet/opus/haiku/fable, a full ID like claude-opus-4-8, or inherit; defaults to inherit), permissionMode, mcpServers, hooks, memory (user/project/local), effort, isolation: worktree. Built-ins: Explore (read-only, Haiku), Plan (read-only, inherits model), general-purpose (all tools, inherits model). Invoked via the Agent tool (renamed from Task in v2.1.63; Task still works as an alias).
MCP server configuration in Claude Code. Add with 'claude mcp add' (or add-json). Transports: stdio (local process, command/args after the -- separator), http/streamable-http (recommended remote, supports OAuth; 'streamable-http' is a JSON alias for 'http'), sse (deprecated), ws (WebSocket, header auth only, not via --transport flag). Three scopes: local (default, ~/.claude.json, private to you+current project), project (.mcp.json at repo root, committed, requires an approval prompt), user (~/.claude.json, all your projects). Precedence local > project > user > plugin > claude.ai connector; entries are NOT merged (whole highest-priority entry wins). Tools are namespaced mcp__<server>__<tool>; manage with claude mcp list/get/remove and /mcp.
Slash commands and skills. Custom commands have merged into skills: .claude/commands/deploy.md and .claude/skills/deploy/SKILL.md both create /deploy. Files support frontmatter (allowed-tools, disallowed-tools, argument-hint, arguments, description, model, effort, hooks, paths), $ARGUMENTS plus indexed args $ARGUMENTS[N] / $N (0-based: $0 = first arg, $1 = second), !`bash` for command output injection, @file references, and ${CLAUDE_SKILL_DIR}; subdirectories create namespaces. If a skill and a command share a name, the skill wins. Built-ins include /init, /memory, /agents, /mcp, /permissions, /hooks, /model, /context, /compact, /clear, /resume, /rewind, /plan, /config, /review, /doctor.
Headless / CI usage. Run non-interactively with claude -p "prompt". Control output via --output-format text|json|stream-json (json adds result, session_id, total_cost_usd and metadata; --json-schema gives validated output in the structured_output field). Pre-approve tools with --allowedTools/--disallowedTools (permission-rule syntax) or a locked-down --permission-mode dontAsk. Use --max-turns, --append-system-prompt, --continue (most recent) or --resume <session_id>. --bare skips auto-discovery (hooks, skills, plugins, MCP, auto memory, CLAUDE.md) for reproducible CI and faster startup; --dangerously-skip-permissions equals bypassPermissions.
Official documentation
Claude Code Settings reference ↗ Claude Code Memory (CLAUDE.md and auto memory) ↗ Claude Code Hooks reference ↗ Connect Claude Code to tools via MCP ↗ Claude Code Permission modes ↗ Claude Code Subagents ↗
Exam pro tips
  • When a question says an action must ALWAYS happen or NEVER be allowed (e.g., 'run lint before every commit', 'block writes to prod'), the answer is a hook or a permissions.deny rule — NOT CLAUDE.md. CLAUDE.md and memory are guidance Claude can ignore; only hooks and permission rules are enforced by the client.
  • Memorize the two precedence exceptions: settings normally OVERRIDE highest-to-lowest, but permission rules MERGE across all scopes; and MCP server scope precedence is local > project > user (then plugin, then claude.ai connector) with NO field merging (the whole highest-priority entry wins).
  • Hook exit codes are a favorite trap: exit 2 blocks (and stderr goes to Claude, JSON is skipped), exit 0 means stdout is parsed as JSON for structured control, and any other non-zero is a non-blocking error. Exit 1 does NOT block.
  • For CI/headless scenarios, the safest reproducible answer combines claude -p with --bare (skips local hooks/skills/plugins/MCP/auto memory/CLAUDE.md auto-discovery) and an explicit --allowedTools list or --permission-mode dontAsk; never reach for --dangerously-skip-permissions unless the scenario is an isolated container.
  • Watch the URL change: the Claude Code docs now live at code.claude.com/docs/en/... (the old docs.claude.com/en/docs/claude-code/... paths 301-redirect there). The Claude API/model docs live at platform.claude.com/docs and docs.claude.com; the MCP spec is at modelcontextprotocol.io.
04

Prompt Engineering & Structured Output

20%

This domain tests your ability to reliably steer Claude's behavior and output through prompt construction and to guarantee machine-parseable results. It spans the core prompting toolkit (clear/direct instructions, system-prompt roles, multishot examples, chain-of-thought/thinking, XML tagging, and long-context structuring) plus the modern reliability layer for structured data: the Structured Outputs feature, tool use with strict schemas, and prompt caching. A key exam-relevant shift: prefilling the assistant turn is no longer supported on Claude 4.6+ models, so Structured Outputs and tool use have replaced prefill as the way to force formats like JSON.

Key concepts to master
System prompts and role prompting. Set Claude's role, expertise, and tone in the top-level system parameter (separate from user messages). Even a single role sentence measurably focuses behavior; reserve system for stable instructions/persona and put task-specific input in user turns.
Multishot (few-shot) examples. 3-5 relevant, diverse examples wrapped in <example>/<examples> tags are one of the most reliable ways to lock in output format, tone, and edge-case handling. Diversity matters so Claude doesn't latch onto an unintended pattern; you can even ask Claude to critique or generate examples.
Chain-of-thought and adaptive thinking. Let Claude reason before answering to improve accuracy on multi-step tasks. Modern models (Opus/Sonnet 4.6) use adaptive thinking (thinking: {type: "adaptive"}) with an effort parameter (low/medium/high/xhigh/max) instead of the older extended-thinking budget_tokens; when thinking is off you can still elicit manual CoT with <thinking>/<answer> tags. Note Opus 4.5 with thinking off is sensitive to the word 'think' (prefer 'consider'/'evaluate').
XML tags for structure. Use descriptive, consistent XML tags (<instructions>, <context>, <document>, <example>) to unambiguously separate instruction types and inputs, and to designate output containers. XML tags double as a format-control lever ('write your answer in <answer> tags').
Structured Outputs feature. Constrains responses to a JSON Schema via constrained sampling so output is always valid/parseable. Configure with output_config.format (type: json_schema) for the final response, or strict: true on tool definitions for guaranteed tool inputs; SDK helpers accept Pydantic/Zod and return typed parsed_output. Supports enums, const, anyOf/allOf, $ref, and common string formats but NOT recursive schemas or numeric/length constraints (minimum/maxLength). Complexity limits include up to 20 strict tools per request.
Tool use to force structured / JSON output. Define a tool whose input_schema is your target object and use tool_choice to control invocation: auto (default, model decides), any (must call some tool), tool (force a specific named tool), none (no tools). Forcing any/tool guarantees a structured tool_use block; combine tool_choice:any with strict:true for both a guaranteed call and schema-valid inputs. Note any/tool are incompatible with extended thinking.
Migrating away from prefilling. Prefilling the last assistant turn (e.g., starting the reply with '{' to force JSON) returns a 400 error on Claude 4.6+ models. Replace prefill use-cases with Structured Outputs (formats/classification via enums), system-prompt instructions ('respond directly without preamble'), or tool calling.
Prompt caching. Mark stable prefixes with cache_control: {type: "ephemeral"} to cut cost (~0.1x base on reads, 1.25x write for 5m TTL, 2x write for 1h TTL) and latency; cache hits cost a fraction of base input. Up to 4 breakpoints, place them on content identical across requests (never on timestamps), default 5-minute TTL with optional ttl:"1h"; verify via cache_read_input_tokens / cache_creation_input_tokens. Changing tools invalidates everything; changing system invalidates system+messages.
Long-context prompting. For 20k+ token inputs, put longform documents near the TOP, above the query/instructions (can improve quality up to ~30%). Wrap each doc in <document> with <source> and <document_content> subtags, and ask Claude to extract relevant quotes into <quotes> tags before answering to ground the response.
Controlling output format. Tell Claude what TO do rather than what not to do ('write in flowing prose' beats 'no markdown'), use XML format indicators, and match your prompt's style to the desired output style. Newer models are terser and may skip post-tool summaries unless asked.
Official documentation
Prompting best practices (Claude prompt engineering reference) ↗ Structured Outputs (JSON schema + strict tool use) ↗ Define tools & forcing tool use (tool_choice) ↗ Prompt caching ↗
Exam pro tips
  • When a scenario needs guaranteed valid JSON, prefer Structured Outputs (output_config.format) or a forced tool (tool_choice + strict:true) over 'prompt it to return JSON' or prefill — prefill is a trap answer because it 400s on Claude 4.6+ models.
  • Watch the tool_choice + extended/adaptive thinking interaction: tool_choice 'any' and 'tool' are NOT compatible with thinking enabled (only 'auto' and 'none' are). Scenario questions love this conflict.
  • On caching questions, the highest-yield trap is putting cache_control on content that changes between requests (timestamps, per-user context) — the cache prefix must be byte-identical, so cache stable prefixes and place variable content after the breakpoint. Remember changing tools invalidates the entire cache.
  • For long-context scenarios, the correct answer usually moves the large documents to the top (before the question) and adds quote-extraction grounding — not 'increase max_tokens' or 'split into more calls'. Also recall that few-shot examples belong in XML tags and that telling Claude what TO do beats negative instructions.
05

Context Management & Reliability

15%

This domain covers how to keep Claude applications fast, cheap, and dependable as conversations and agentic loops grow. On the context side you must master the context window as finite "working memory" (and "context rot" — accuracy and recall degrade as it fills), plus the concrete levers Anthropic ships to manage it: prompt caching, server-side compaction, context editing (tool-result and thinking-block clearing), token counting, context awareness, and retrieval/RAG to keep only relevant content in context. On the reliability side you must know the API error taxonomy and which errors are retryable, exponential-backoff/retry-after handling, streaming via SSE, stop-reason handling, and cost/latency controls (caching, batch processing, model selection, structured logging and evals).

Key concepts to master
Context window & context rot. The context window is the model's finite working memory (all input plus the generated output). Claude Fable 5, Opus 5 and Sonnet 5 — the current models — all offer a 1M-token window on the Claude API, as do the legacy Opus 4.8/4.7/4.6 and Sonnet 4.6. Haiku 4.5 is 200k. More context is not automatically better — recall and accuracy degrade as the window fills ("context rot"), so curating what is in context matters as much as raw capacity.
Prompt caching (cache_control). Add cache_control: {type: "ephemeral"} breakpoints (up to 4) to reuse stable prefixes like system prompts, tool definitions, and long documents. Default TTL is 5 minutes (refreshed on hit), with an optional 1h TTL. Minimum cacheable length varies by model — 512 tokens for Opus 5 / Fable 5 / Mythos 5; 1,024 for Sonnet 5 / Opus 4.8 / Sonnet 4.6 / Sonnet 4.5; 2,048 for Opus 4.7 / Haiku 3.5; and 4,096 for Haiku 4.5 / Opus 4.6 / Opus 4.5. Cache writes cost ~1.25x base input for the 5m TTL (2x for the 1h TTL); cache reads cost ~0.1x (10%) of base input — the main lever for latency and cost on repeated context.
Server-side compaction. The recommended strategy for long-running conversations: the API automatically summarizes/condenses earlier turns server-side so the conversation can continue beyond the limit with minimal integration. Beta feature — pass the anthropic-beta header compact-2026-01-12 and add a {"type": "compact_20260112"} edit in context_management. Supported on the current Fable 5, Opus 5 and Sonnet 5, and on Mythos 5 / Mythos Preview and the legacy Opus 4.8/4.7/4.6 and Sonnet 4.6. Check the docs for the current list before relying on it.
Context editing (tool-result & thinking-block clearing). Beta header anthropic-beta: context-management-2025-06-27 with a context_management.edits array. clear_tool_uses_20250919 clears old tool results past a trigger (default 100k input tokens) with keep (default 3 tool uses), clear_at_least, exclude_tools, and clear_tool_inputs options. clear_thinking_20251015 trims old thinking blocks (keep takes thinking_turns or "all"). The response's context_management.applied_edits reports what was cleared.
Token counting & context awareness. Use the token counting endpoint (POST /v1/messages/count_tokens; client.messages.count_tokens) to estimate input_tokens before sending — and to compare tokenizer differences (Fable 5 / Mythos 5 use the Opus 4.7 tokenizer, ~30% more tokens than older models). Note token counting is an estimate and does not use caching. Separately, Sonnet 4.6/4.5 and Haiku 4.5 have built-in context awareness: the model receives its token budget (e.g. <budget:token_budget>1000000</budget:token_budget>) and post-tool-call updates on remaining capacity (<system_warning>Token usage: .../...</system_warning>), helping it pace long tasks.
Extended-thinking token handling. Thinking tokens count toward the window and are billed as output, and the API automatically strips previous thinking blocks from later turns to save capacity (you do not need to strip them yourself). Exception: during a tool-use cycle the entire unmodified thinking block (including its signature) that accompanies a tool call MUST be returned with the tool_result, or the API returns a 400 invalid_request_error — never edit, reorder, filter, or reconstruct thinking blocks (include both thinking and redacted_thinking).
Error taxonomy & retry strategy. Know the codes: 400 invalid_request_error, 401 authentication_error, 402 billing_error, 403 permission_error, 404 not_found_error, 413 request_too_large, 429 rate_limit_error, 500 api_error, 504 timeout_error, 529 overloaded_error. Retry the transient ones (429, 500, 529, 504) with exponential backoff and honor the Retry-After header on 429; 4xx like 400/401/403/404 are not retryable. Every response carries a request-id header (value like req_018Ee..., exposed as request_id in error JSON and on SDK response objects) for debugging and support.
Streaming, stop reasons & graceful degradation. Stream long requests over SSE (or use the Batch API for >10-minute / high-volume jobs) to avoid idle-connection timeouts. New event types may be added, so handle unknown event types gracefully and expect ping events; note that errors can arrive AFTER a 200 in a stream (e.g. an overloaded_error event). Always branch on stop_reason — end_turn, max_tokens, tool_use, stop_sequence, refusal, pause_turn, and model_context_window_exceeded (default on Sonnet 4.5+; earlier models opt in via the model-context-window-exceeded-2025-08-26 beta header) — and design fallbacks (retry, smaller model, truncated context) for graceful degradation.
Official documentation
Context windows - Claude Docs ↗ Prompt caching - Claude Docs ↗ Errors - Claude API Docs ↗ Streaming Messages - Claude Docs ↗ Context editing - Claude Docs ↗ Compaction - Claude Docs ↗
Exam pro tips
  • When a scenario asks how to cut cost/latency on a repeated long prompt, the answer is almost always prompt caching the stable prefix (system + tools + documents) — and remember reads are ~10% of base input while writes are ~25% more (5m TTL; 1h writes are 2x), so caching only pays off across multiple hits within the TTL.
  • Distinguish the three context-trimming tools the exam loves to contrast: compaction = automatic server-side summarization for long chats (compact-2026-01-12 beta); context editing = surgical clearing of old tool results / thinking blocks via the context-management-2025-06-27 beta header; RAG = retrieve-only-what's-relevant. Match the tool to the symptom in the question stem.
  • For reliability scenarios, retry 429/500/529/504 with exponential backoff (honor Retry-After) but never blindly retry 400/401/403/404 — fix the request instead. If a question mentions debugging a production failure, the expected artifact is the request-id (request_id).
  • Memorize the thinking-block rule: the API auto-strips prior thinking to save context, but during a tool-use turn you MUST return the original, unmodified thinking block (signature intact) with the tool_result or you get a 400 — a classic distractor on this exam.
  • Watch the per-model caching minimums: 512 for Opus 5 / Fable 5, 1,024 for Sonnet 5 / Opus 4.8 / Sonnet 4.6, but 4,096 for Haiku 4.5 — a distractor that often swaps Haiku 4.5 (4,096) with the Haiku 3.5 figure (2,048).
04

Lab & study setup

The CCAR-F is a hands-on architecture exam, so the only way to pass is to build with Claude, not just read about it. This setup covers what to subscribe to, what to install, and the exercises that map to the five exam domains.

⚠ Read this first: practice on personal gear only

Treat all exam practice as strictly personal. Do every bit of Claude and Claude Code work on your own device, your own network, your own Anthropic account, and your own payment method. Keep it fully separate from anything your employer manages. This is about respecting your employer's policies and keeping company assets out of your study lab, not following any specific quoted rule.

  • Use a personal device only. Do not install Claude or Claude Code on an employer-managed laptop, workstation, or any corporate-issued hardware.
  • Use a personal network. Practice off the corporate network and off the company VPN, on your own home or personal connection.
  • Never feed employer code, data, configs, customer information, or anything confidential into Claude. Build the labs with your own throwaway sample data.
  • Keep your study lab fully separate from work. When in doubt, leave it out and check your own employer's acceptable-use and AI-tool policies.
Subscriptions & access
Personal Claude Max 5x ($100/mo)The value pick for most serious candidates doing a few focused Claude Code sessions a day. Covers interactive Claude Code in terminal, desktop, and web. Verify current pricing at claude.com/pricing.
Personal Claude Max 20x ($200/mo)Only if you will grind many Claude Code hours every day for weeks. Anthropic's own estimate is roughly 240-480 Sonnet hours and 24-40 Opus hours per week; treat those as ranges, not guarantees.
Personal Anthropic API key (Console, pay-as-you-go)Required and separate from any subscription. You need this to practice the Claude API, MCP servers, and the Agent SDK, all heavily weighted on the exam. Metered by tokens; load roughly $20-50 of personal credits.
Claude Pro ($20/mo, optional)Fine only for light, intermittent practice. You will hit the rolling 5-hour and weekly caps on any real all-day project. Verify current pricing.
Your environment
  • Install Node.js and Python (with uv, the recommended MCP runner), plus git and a code editor such as VS Code, on your personal machine.
  • Install Claude Code globally, following the official setup docs (avoid sudo; fix your npm global prefix if you hit permission errors).
  • Add the official Anthropic SDK for raw API work, in TypeScript or Python.
  • Create a personal API key in the Anthropic Console — copy it once, as it can't be retrieved later.
  • Keep your API key in an environment variable or a git-ignored env file, and never commit keys to source control.
  • Set up a single lab repo and build every exercise into it; prototype prompts in the in-browser Workbench before you code.
Hands-on practice
  • Agentic Architecture (~27%): hand-write the agent loop with the raw API (watch for stop_reason tool_use, run the tool, append tool_result, repeat), then build a hub-and-spoke orchestrator that fans out concurrent subagents and merges results.
  • Claude Code config (~20%): build a CLAUDE.md hierarchy, add path-specific .claude/rules/, write a custom skill with context: fork and allowed-tools restrictions, and practice plan mode, sessions, memory, and slash commands.
  • Tool Design & MCP (~18%): build a minimal MCP server (FastMCP) with two tools, test it standalone in the MCP Inspector, then wire it into Claude Code with claude mcp add. Write descriptions for similar-sounding tools and confirm Claude routes correctly.
  • Prompt Engineering & Structured Output (~20%): emit schema-valid JSON two ways (output_config JSON Schema vs strict tool use), add a validation-retry loop with nullable fields, and run a job through the Message Batches API for cost.
  • Context Management & Reliability (~15%): run a deliberately long session, enable compaction, and verify the agent still recalls a fact stated 50 turns earlier; study why progressive summarization destroys transactional facts.
  • Cost-control reps: mark a long system prompt with cache_control ephemeral and read cache_creation vs cache_read tokens across calls; do MCP and Agent SDK exercises on Haiku or Sonnet to keep personal spend to a few dollars.
From people who passed
  • Build, do not just read. This is the single loudest recurring tip; every weekend project you ship raises your readiness more than any reading. People learned most by building and breaking things.
  • Know MCP and tool use at an implementation level, not conceptually. A widely-shared candidate write-up stressed designing tool schemas, handling tool-call errors, and chaining calls; lazy tool descriptions are the #1 self-reported mistake.
  • Study to internalize, not to look up. The exam is closed-book (60 questions, 120 min, 720/1000 to pass, no Claude or docs), so memorize the patterns; you cannot grep mid-test.
  • Treat it as system design, not prompt trivia. Every question is a broken-production scenario asking for the right architectural call; practice passing context explicitly to subagents.
  • Do not sit it too early. Anthropic recommends ~6 months hands-on; most plans run 4-6 weeks. Use the official Exam Guide as your curriculum and take the official practice exam, and know the Haiku/Sonnet/Opus tradeoffs cold.

Sources: Anthropic / Claude official pricing (consumer plans) · Anthropic official API pricing docs (per-MTok rates, caching, batch) · Claude Code setup · MCP server quickstart · Community write-up: the Architect exam — 5 domains, 6 scenarios (dev.to, unofficial) · Community write-up: preparing for the Architect exam — a technical roadmap (dev.to, unofficial)

05

Official resources

There is no single official “CCAR-F study guide” PDF. The real prep is the Anthropic Academy courses plus the official product docs — everything below is official.

  • Book the exam ↗

    The certification page where you schedule and sit the proctored exam. Sign in first — it's partner-gated, so the page only appears once you're signed in. — CCA-F certification page

  • Partner portal — exam access ↗

    Where you actually book the exam. Sign in with your partner-organisation account, request the Claude Certified Architect – Foundations exam, and reach Anthropic's internal training materials. — claude.com/partners

  • Anthropic Academy (Skilljar) ↗

    The official structured prep — free, self-paced courses. Sign in with your account and enroll (the prep path above lists exactly which ones). — anthropic-partners.skilljar.com

  • All Claude certifications ↗

    The index of all four Claude certifications, with links to every certification page and exam guide. — Partner Academy certifications page

  • Claude documentation ↗

    The source of truth for exam questions. Focus on the Claude API (tool use, structured outputs, prompt caching) and Claude Code (settings, hooks, MCP). — docs.claude.com · code.claude.com/docs

  • Model Context Protocol spec ↗

    The MCP specification — server/client architecture, transports, and tool schemas. Directly tested in the Tool Design & MCP domain. — modelcontextprotocol.io

  • Certification announcement ↗

    The official launch announcement for the Claude Partner Network and its certifications. — anthropic.com/news

⚠ A word of caution

Skip third-party “free CCAR-F practice test” and brain-dump sites that crowd search results. They are not affiliated with Anthropic, are frequently inaccurate, and dump sites can violate exam terms. Stick to Anthropic Academy and the official docs above.

06

Frequently asked questions

The essentials on eligibility, cost, format, and access — answered from verified facts.

What is the CCA-F certification?

CCAR-F stands for Claude Certified Architect – Foundations (older write-ups, and this site's former domain, call it CCA-F). It is one of four certifications in Anthropic's Claude Certification Program, and it validates the skills needed to build production applications with Claude. Its exam guide is Version 1.0, effective July 2026.

Who is the CCAR-F exam for?

It targets solution architects and developers who build production applications with Claude, not casual users. Its domains span agentic architecture, Claude Code, prompt engineering, tool design/MCP, and context management. Any specific prerequisite experience requirement is not publicly specified.

Who is eligible to take the exam?

The exam is gated to the Claude Partner Network, so eligibility depends on your organisation's partner status. If your employer is an Anthropic partner you're eligible — reach the exam through the partner portal at claude.com/partners.

How does a partner access the exam?

Sign in with your partner-organisation email, complete the prep-path courses, then book and sit the exam on the CCA-F certification page (anthropic-partners.skilljar.com/claude-certified-architect-foundations-certification). It's partner-gated, so that page only appears once you're signed in and through the prerequisites; if you don't see it, your organisation's partner admin can confirm your access.

Do I sign in with my claude.ai account?

No — Anthropic Academy (Skilljar) is a separate platform with its own account, and the exam is delivered there. Your claude.ai / Claude login will not work. Create a new account with your partner-organisation email, then authenticate and accept the EULAs to unlock the courses and exam.

What does the exam cost you?

Confirm the current price — and whether any partner waiver applies to you — through the partner portal. This guide doesn't have a figure it can stand behind, so don't assume it's free.

What is the exam format?

It is 60 scenario-based multiple-choice questions to be completed in 120 minutes. Scoring uses a scaled score out of a maximum of 1000, and the passing threshold is 720.

What topics does the exam cover, and how are they weighted?

Five domains: Agentic Architecture & Orchestration (27%), Claude Code Configuration & Workflows (20%), Prompt Engineering & Structured Output (20%), Tool Design & MCP Integration (18%), and Context Management & Reliability (15%).

Is the exam closed-book? Can I use AI assistance?

Yes, the exam is closed-book, and no AI assistance is allowed during the exam. You must answer the scenario-based questions on your own without external tools or documentation.

How should I prepare, and how much time should I budget?

Anthropic Academy offers 13 free self-paced courses on Skilljar (anthropic-partners.skilljar.com), open to all, including Claude 101, AI Fluency Framework & Foundations, Building Applications with the Claude API, Introduction to Model Context Protocol, Claude Code (in Action / Developer Training), and Introduction to Agent Skills. Follow the dedicated Partner Network Learning Path at anthropic-partners.skilljar.com/page/claude-partner-network-learning-path. A specific recommended prep time is not publicly specified - confirm via the partner portal.

What are the best authoritative sources to study from?

The source of truth is the official documentation: docs.anthropic.com / docs.claude.com for the Claude API and Claude Code, and modelcontextprotocol.io for the MCP specification. Pair these with the Anthropic Academy courses for structured learning.

How difficult is the exam and what level is it?

It is a Foundations-level certification aimed at solution architects and developers building production applications with Claude, covering five domains: agentic architecture, Claude Code, prompt engineering/structured output, tool design/MCP, and context management/reliability. The scaled passing bar is 720 out of 1000. Beyond these facts, the difficulty level is not publicly characterized further.

Does the certification expire, and what is the retake policy?

The exact expiration and retake policies aren't publicly specified — confirm those, and any cost, through the partner portal.

Is this guide official or affiliated with Anthropic?

No. It's an independent study guide — not affiliated with, endorsed by, or sponsored by Anthropic. Always confirm exam details (eligibility, cost, policies) through the official partner portal.

How long does the credential stay valid?

12 months from the date the credential is awarded. On-time renewal is a free, non-proctored assessment on the Anthropic Partner Academy; a lapsed credential requires retaking the full proctored exam at full fee.