← Claude

Claude Certified Architect — Foundations (CCA-F)

Architect

Proctored exam on designing and shipping production-grade Claude applications: agentic architecture, Claude Code workflows, prompt engineering, MCP tool design, and context management.

Passing score
72%
Per attempt
30 questions
Question pool
86
Suggested time
120 min

Content last updated Aug 14, 2026

About this exam

Anthropic's proctored exam testing the ability to design and ship production-grade Claude applications at enterprise scale. Closed-book, no AI assistance, scenario-based (multiple-choice + multiple-response, each item stating how many responses to select). Five domains, compiled here from Anthropic's own official documentation (platform.claude.com, code.claude.com, and Anthropic engineering blog) rather than third-party prep material.

Exam details

Exam code
CCAR-F
Exam fee
$125 USD
Item format
Multiple-choice and multiple-response items; each item states how many responses to select
Prerequisites
6+ months of practical experience building with Claude APIs, Agent SDK, Claude Code, and MCP
Exam structure
4 scenarios drawn from a bank of 6, 60 items total
Delivery method
Proctored: online proctored and/or test center, per program policy
Target audience
Solution architect who designs and implements production applications with Claude
Result reporting
Pass/fail with scaled score (100–1,000), plus percent-correct by domain
Certification validity
12 months from the date awarded

Content domains

Expand a domain for what it covers and what you'll need to know.

Agentic Architecture & Orchestration 27% ▾

Orchestrator-worker pattern

  • A lead ("orchestrator") agent analyzes a query, develops a strategy, and spawns subagents for different aspects of the work. Subagents run with their own separate context window, work independently, and return findings to the orchestrator.
  • Effort scaling rules (embedded in the orchestrator's prompt) prevent over/under-investment: simple fact-finding uses 1 agent with 3–10 tool calls; direct comparisons use 2–4 subagents with 10–15 calls each; complex, open-ended research uses 10+ subagents with clearly divided responsibilities. Without explicit rules, early versions spawned excessive subagents (e.g. 50) even for trivial queries.
  • Subagents should receive explicit delegation: an objective, an expected output format, guidance on which tools to use, and clear task boundaries — vague task descriptions cause duplicate work across subagents.
  • Filesystem-based output handoff: subagents write full outputs to external storage and pass lightweight references back to the orchestrator, minimizing token overhead versus routing all data through the orchestrator directly.

Numeric findings from Anthropic's internal multi-agent research system

  • A multi-agent system (Opus-class lead + smaller-model subagents) outperformed a single agent by 90.2% on an internal research evaluation.
  • Token usage alone explained about 80% of performance variance in one evaluation; tool-call count and model choice explained the rest.
  • Agents consume roughly 4x more tokens than a normal chat interaction; multi-agent systems consume roughly 15x more tokens than a normal chat.
  • Enabling parallel tool calling (3+ simultaneous calls) cut research time by up to 90% for complex queries.

Reliability patterns for production agents

  • Agents are stateful across many tool calls, so errors compound without mitigation. Favor resumable execution from checkpoints over full restarts.
  • For long-horizon work, persist plans/state to external memory before the context window (e.g. 200K tokens) is exhausted, rather than relying on everything staying in-context.
  • Use "rainbow deployments" — gradually shifting traffic between old and new agent versions while both run simultaneously — to avoid breaking agents mid-execution during a deploy.
  • Evaluate with an LLM-as-judge rubric (factual accuracy, citation accuracy, completeness, source quality, tool efficiency) plus human review for the edge cases automated grading misses. For agents that mutate state, evaluate end-state correctness rather than turn-by-turn behavior.

Built-in Claude Code subagent types

  • Explore: read-only, delegated to when Claude needs to search/understand a codebase without making changes; invoked with a stated thoroughness level (quick / medium / very thorough); keeps exploration results out of the main conversation context.
  • Plan: used during plan mode to research the codebase before presenting an implementation plan; read-only tools only (Write/Edit denied); inherits the model of the main conversation.
  • General-purpose: full tool access, used for complex multi-step tasks needing both exploration and modification.
Claude Code Configuration & Workflows 20% ▾

Subagent definition

  • Subagents are Markdown files with YAML frontmatter: `name`, `description`, `tools` (which tools it may use), `model` (e.g. `sonnet`, `haiku`), followed by the system prompt as the file body.
  • Stored at `.claude/agents/` (project-scoped) or `~/.claude/agents/` (user-scoped, available across all projects on the machine). Project scope takes precedence for a name collision.
  • Each subagent runs in its own context window with independent permissions, which preserves the main conversation's context and lets you route cheap/routine tasks to faster, cheaper models (e.g. Haiku).

Hooks

  • Hooks are automated actions that fire at specific lifecycle events. Configured in `settings.json` at several scopes: `~/.claude/settings.json` (all projects, local only), `.claude/settings.json` (single project, committed/shareable), `.claude/settings.local.json` (single project, gitignored), managed policy settings (org-wide), or bundled in a plugin's `hooks/hooks.json`. Configurations merge across levels rather than replacing each other.
  • Key tool-call lifecycle events: `PreToolUse` (before a tool runs — can block it), `PostToolUse` (after a tool succeeds), `PostToolUseFailure` (after a tool fails). Also: `SessionStart`/`SessionEnd`, `UserPromptSubmit`, `Stop`, `SubagentStart`/`SubagentStop`, `PreCompact`/`PostCompact`.
  • Five handler types: `command` (runs a shell script/executable with JSON on stdin), `http` (POSTs JSON to an endpoint), `mcp_tool` (calls a tool on a connected MCP server), `prompt` (single-turn evaluation by a Claude model), `agent` (spawns a subagent to verify a condition; experimental).
  • Exit-code semantics for `command` hooks: exit `0` = success, no decision (proceeds); exit `2` = blocking error on blockable events like `PreToolUse`/`UserPromptSubmit` (prevents the action); any other exit code = non-blocking error (action proceeds, first line of stderr shown as a notice). A hook can also return JSON on stdout with `hookSpecificOutput.permissionDecision` set to `"allow"`, `"deny"`, or `"escalate"`.
  • `PostToolUse` and `PostToolUseFailure` cannot block — the tool has already run by the time they fire.
  • `disableAllHooks: true` in a settings file disables all hooks from that scope; managed-policy hooks can only be disabled by managed settings, not by user/project settings.
Prompt Engineering & Structured Output 20% ▾

Core prompting techniques (from Anthropic's official prompting best practices)

  • Be clear and direct — state exactly what's wanted rather than implying it.
  • Add context to improve performance — background/purpose helps Claude prioritize correctly.
  • Use examples (multishot prompting) effectively — one of the most reliable ways to steer output format, tone, and structure.
  • Structure prompts with XML tags — to separate instructions, context, and input data unambiguously.
  • Give Claude a role via the system prompt — shapes tone and framing for the whole conversation.
  • Long-context prompting techniques — for prompts with large documents/data.
  • Leverage extended thinking and interleaved thinking (thinking between tool calls) for complex, multi-step reasoning.
  • For agentic systems specifically: manage long-horizon reasoning and state tracking, balance autonomy vs. safety guardrails, guide subagent orchestration, chain complex prompts into smaller steps, and explicitly reduce "overeagerness" (doing more than asked) and hallucination in agentic coding tasks.

Structured outputs — how they actually work

  • Structured outputs are enforced via constrained decoding (grammar-based token sampling), not via prompting or `tool_choice` forcing alone. The output schema is compiled into a grammar that constrains which tokens the model can generate next, so invalid JSON or schema violations are architecturally impossible — no retries needed for validation failures.
  • Two related mechanisms: JSON outputs (`output_config.format`) makes Claude's text response itself conform to a schema, with no tool call involved; strict tool use (`strict: true` on a tool definition) guarantees a tool call's parameters conform to that tool's input schema. They can be combined in the same request (structured final answer + validated tool calls during the agentic loop).
  • Compiled grammars are cached for 24 hours; the first request using a new schema pays a compilation-latency cost, and changing the schema or tool definitions invalidates that cached grammar.
  • JSON Schema support has real limits: supported are basic types, arrays/objects, `enum`, `const`, `anyOf`/`allOf`/`$ref`, common string formats, and `minItems` of 0 or 1 only. Not supported: recursive schemas, numeric constraints like `minimum`/`maximum`, string length constraints, array constraints beyond `minItems`, `additionalProperties` other than `false`, or external `$ref` URLs.
Tool Design & MCP Integration 18% ▾

What MCP is for

  • The Model Context Protocol (MCP) is an open standard for connecting AI agents to external tools and data sources — issue trackers, databases, monitoring dashboards, design tools, etc. — so Claude can act on those systems directly instead of working from pasted context.
  • An MCP server can expose three capability types: Resources (file-like data clients can read), Tools (functions the model can call), and Prompts (pre-written templates for common tasks).

Transports

  • HTTP — the recommended transport for remote/cloud-based MCP servers; supports OAuth; added with `claude mcp add --transport http <name> <url>`. The MCP spec calls this transport `streamable-http`, accepted as an alias for `http` in JSON config.
  • SSE (Server-Sent Events) — deprecated remote transport; use HTTP instead where available. Added the same way with `--transport sse`.
  • stdio — local server run as a subprocess on the user's machine, ideal for tools needing direct filesystem/system access; added with `claude mcp add ... -- <command> [args...]`, where `--` separates Claude Code's own flags from the server's command/args. Stdio servers are not automatically reconnected if they disconnect (unlike HTTP/SSE, which retry with exponential backoff up to 5 attempts).
  • WebSocket — persistent bidirectional connection for servers that push unprompted events to Claude; configured via `claude mcp add-json` with `"type": "ws"`; does not support OAuth and isn't available via the `--transport` flag.

Configuration scopes

  • `local` (default): available only to the current user, in the current project.
  • `project`: shared with everyone on the project via a checked-in `.mcp.json` file — but a cloned repo can't auto-approve its own servers; a project-scoped server stays "pending approval" until the user runs `claude` interactively and accepts the workspace-trust dialog.
  • `user`: available to that user across all their projects.

Reliability details

  • MCP servers can send a `list_changed` notification so Claude Code refreshes available tools/prompts/resources without a reconnect; if a refresh request itself fails, Claude Code keeps the previously discovered capabilities rather than clearing them.
  • Tool definitions consume context window budget; when many MCP tools are configured, a "tool search" mechanism can withhold full tool definitions from context and load only the ones needed for a given turn.
Context Management & Reliability 15% ▾

Prompt caching

  • Minimum cacheable prompt length varies by model family — smaller/newer models have lower minimums (e.g. several hundred tokens) while some models require several thousand; prompts shorter than the minimum are simply not cached (no error).
  • Up to 4 explicit cache breakpoints per request; automatic caching (a single top-level `cache_control` field) lets the system move the breakpoint forward on its own across a growing multi-turn conversation.
  • Cache lookups check up to 20 content blocks backward from a breakpoint for a matching prior cache entry — if a breakpoint drifts more than 20 blocks past the last cache write, add a second breakpoint to avoid missing the cache.
  • Cache hierarchy is `tools` → `system` → `messages`: changing tool definitions invalidates every downstream cache; changing the system prompt invalidates system + message caches; changing only messages invalidates just the message cache.
  • Default cache TTL is 5 minutes (`"ephemeral"`); an extended 1-hour TTL option costs roughly 2x the normal cache-write price versus roughly 1.25x for the 5-minute write. Cache reads are much cheaper than normal input tokens (on the order of a 90% discount).
  • Best practice: place static/reusable content (system instructions, shared context, tool definitions) at the start of the prompt, and put the cache breakpoint at the end of the static prefix — never on content that changes every request, since that guarantees a cache miss.

Server-side context compaction

  • Compaction automatically summarizes older conversation turns once input tokens cross a configured threshold (a default around 150K tokens, with a documented minimum around 50K), replacing the need for custom client-side summarization logic.
  • When triggered, the response includes a `compaction` content block containing the summary; on the next request, the API automatically drops everything before that compaction block. The full response (compaction block included) must be appended back into the message history for the next turn.
  • An optional "pause after compaction" mode stops right after the summary is generated, letting the caller preserve specific recent messages verbatim or inject extra context before continuing — useful for enforcing a hard total-token budget across a long-running agent by counting how many compactions have occurred.
  • Custom summarization instructions can fully replace the default compaction prompt (not append to it) — e.g. to bias the summary toward preserving code snippets and technical decisions over conversational detail.
  • Compaction and prompt caching are meant to be combined: keeping the system prompt cached separately from the conversation body means only the new summary needs a fresh cache write after each compaction, not the whole system prompt again.
Start Practice

Official resources

Practice by SuperML.org is an independent study resource and is not affiliated with, endorsed by, or officially connected to Claude. Questions are AI-generated for practice purposes only.