CCAR-F Learning Guide · Cheat sheet
CCAR-F exam cheat sheet
The whole Foundations guide on three printed pages or fewer: the decision rules, the facts worth memorising and the distractors the exam keeps offering, domain by domain. Read it the day before the exam.
Numbers like 1.1 open the lesson behind each point.
60items
120minutes
720to pass, of 1000
- D1 Agentic Architecture & Orchestration 27%
- D2 Tool Design & MCP Integration 18%
- D3 Claude Code Configuration & Workflows 20%
- D4 Prompt Engineering & Structured Output 20%
- D5 Context Management & Reliability 15%
How to read a CCAR-F question
Most items describe a production system with one flaw and ask for the best fix. Five habits pick the right option:
- "Must always" or "must never" means code. A hook, a gate or a permission, never a louder prompt.
- Fix the layer that failed. Missing subtopics are a coordinator decomposition problem, not a search problem.
- Prefer the targeted fix. A bigger model, a larger context window or temperature 0 is almost never the answer.
- Never hide a failure. An error is not an empty result, and a timeout is not "no data".
- Ask instead of guessing. Two matching customers means ask for an identifier.
Domain 1 · 27%Agentic Architecture & Orchestration
| stop_reason | What the loop does |
|---|---|
tool_use | Run every requested tool, append the results, call Claude again |
end_turn | Stop; the last response is the answer |
max_tokens | Incomplete: continue or raise the limit, never present it as done |
stop_sequence | Treat as end of turn unless that sequence means something to you |
- The loop ends on
stop_reason, not on text content, "I'm done" phrases or an iteration cap. A cap is a safety net only. Tool results are never fed back automatically: your code appends them. 1.1 - The coordinator is the only hub. It decomposes, picks only the subagents a query needs, routes every message and loops back when the synthesis has gaps. Subagents never talk to each other. 1.2
- Subagents start with no memory. Everything they need goes in their prompt: complete findings, paths, constraints, with structured metadata so citations survive. Spawn them in parallel in one turn. Give goals and quality criteria, not step-by-step scripts. 1.3
- A coordinator that never delegates is missing the Task tool in
allowedTools. The guide says Task; current SDK releases call it Agent. Answer with Task. 1.3 - Multi-issue messages: decompose and resolve each item. Several issues is not a reason to escalate. 1.4
- Handoff summary: customer and how verified, the issue in one line, root cause, amounts and orders, actions already taken, why escalated, recommended action. 1.4
| Hook | Runs | Use it to |
|---|---|---|
| PreToolUse | After Claude requests a tool, before it runs | Block, redirect or rewrite a call (refund limit, identity first) |
| PostToolUse | After the tool runs, before Claude sees the result | Normalise formats, trim fields, add context |
- "CRITICAL" in a tool description and temperature 0 are not guarantees. 1.5
- Decomposition: steps known in advance means a fixed chain; open-ended work means an adaptive plan; a many-file review means per-file passes plus an integration pass. 1.6
- Sessions: resume by name (
--resume) when the context is still true and say what changed; fork to try two approaches from one analysis; start fresh with a structured summary when most files have changed. 1.7
Domain 2 · 18%Tool Design & MCP Integration
- A tool description states what it does, its inputs and their format, what it returns, when to use it, when not to (name the neighbour) and edge cases. Fix misrouting in descriptions, names or a split, not with system-prompt examples, and not by merging tools behind a mode flag. 2.1
| Error category | Example | Right response |
|---|---|---|
| Transient | Timeout, service down | Retry, perhaps after a wait |
| Validation | Wrong order-number format | Fix the input or ask the user |
| Business | Outside the 45-day window | Do not retry; explain the policy |
| Permission | Agent may not see payroll | Do not retry; escalate or explain |
- Return failures with the
isErrorflag, a category, aretryableflag and a plain description. A failed search and an empty search are different results. 2.2
| tool_choice | Effect | Use when |
|---|---|---|
auto | May call a tool or reply in text | Conversational default |
any | Must call a tool, chooses which | Structured output, several possible schemas |
{"type": "tool", "name": ...} | Must call that tool | One step must run first |
- Tools follow the role: the smallest set per agent, one narrow cross-role tool for a frequent need, constrained tools instead of open-ended ones. 2.3
- MCP scope: shared servers in the project's
.mcp.json(committed), personal ones in~/.claude.json, secrets as${VAR}, never a literal token. If Claude prefers Grep over a capable MCP tool, improve the MCP tool's description; do not disable Grep. Expose catalogues as resources. 2.4 - Built-in tools: Grep searches file contents, Glob matches file paths (
**/*.test.tsx), Edit changes text by a unique match (fall back to Read plus Write), Bash runs commands. Grep first, then read selectively. 2.5
Domain 3 · 20%Claude Code Configuration & Workflows
| CLAUDE.md level | Location | Shared? |
|---|---|---|
| User | ~/.claude/CLAUDE.md | No, you only |
| Project | CLAUDE.md or .claude/CLAUDE.md at the repo root | Yes, via version control |
| Directory | CLAUDE.md in a subdirectory | Yes, if committed |
- Team standards go in the project file or
.claude/rules/; split big files with@import; check what loaded with/memory. One-off context stays in the conversation. Hard rules go in hooks or permissions. 3.1 - Commands and skills: shared in
.claude/commands/and.claude/skills/<name>/SKILL.md; personal in the same paths under~/.claude/. Frontmatter:context: forkruns it in an isolated sub-agent (for noisy output),allowed-toolslimits its tools,argument-hintprompts for a parameter. Skills load on demand; CLAUDE.md loads always. 3.2 - Path rules: a file in
.claude/rules/withpaths: ["**/*.test.ts"]loads only for matching files. Use it for conventions that follow a file type across the tree, not one CLAUDE.md per folder. 3.3 - Plan mode for wide, unclear or architectural work (migrations, 45+ files, several valid approaches); direct execution for a clear, narrow fix. Send verbose discovery to the Explore subagent. 3.4
- Refinement: concrete input and output examples for inconsistent transformations, tests for edge cases, let Claude interview you in an unfamiliar domain, interacting bugs in one message, independent ones one at a time. 3.5
- CI:
-p(--print) for non-interactive runs (a hanging job needs-p, not a timeout);--output-format jsonwith--json-schemafor parseable findings; context in CLAUDE.md; pass prior findings to stop duplicate comments and existing tests to stop duplicate tests; review with a separate instance. 3.6
Domain 4 · 20%Prompt Engineering & Structured Output
- Precision comes from categories, not confidence. Say what to report and what to skip, and define each severity with an example. "Be conservative" does nothing measurable. Switch off a noisy category while you fix it. 4.1
- Few-shot: two to four examples aimed at the ambiguous cases, each with its reason and the exact output format, matching the real input type. 4.2
- Structured output: define a tool whose input schema is your JSON schema, require it with
tool_choice, read thetool_useblock. Make absent fields nullable (required fields invite invention); use enums with an "other" or "unclear" value. The schema guarantees structure, not truth. 4.3 - Validation and retry: check meaning (line items sum to the total, fields in the right place). Retry with the document, the failed output and the exact errors. If the information is not in the document, stop retrying. 4.4
| Messages API | Message Batches API | |
|---|---|---|
| Cost | Standard | About 50% less |
| Results | Seconds | Within 24 hours, no latency SLA |
| Tools mid-request | Yes | No |
- Batch only what nobody waits for (overnight reports, backlogs), never a pre-merge check. Match results by
custom_idand resubmit only the failures. 4.5 - Review with an independent instance. Same-session self-review rarely catches its own bug, even with more thinking. Have findings carry confidence for routing. 4.6
Domain 5 · 15%Context Management & Reliability
- Long conversations: keep amounts, dates, IDs and promises in a persistent case-facts block, not in summarised prose. Trim verbose tool results. Put key findings first, since the middle of long input gets less attention. A bigger window is not the fix. 5.1
| Escalate | Do not escalate for |
|---|---|
| The customer asks for a human (escalate immediately) | Negative sentiment alone |
| Policy is silent or ambiguous (such as competitor price matching) | A self-reported confidence score |
| No meaningful progress is possible | Several issues in one message |
- Several matching records: ask for an identifier; never pick the most likely. 5.2
- Error propagation: retry transient errors locally; report the rest with failure type, what was attempted, partial results and alternatives. Never return an empty success, and never abort the whole run for one failure. 5.3
- Long explorations: a scratchpad file for findings, subagents for noisy questions, summaries between phases,
/compact, and state exports with a manifest for crash recovery. 5.4 - Human review: an overall accuracy figure hides weak segments. Check accuracy by document type and field, keep sampling high-confidence output, calibrate confidence on labelled data, and route reviewers to likely errors. 5.5
- Provenance: every claim keeps its source and date through every step. Show conflicting figures side by side with both sources; do not pick the newer one. Tables for financial data, prose for news, lists for technical findings. 5.6
Distractors the exam keeps offering
| Tempting option | Why it is wrong |
|---|---|
| Stronger wording: CAPITALS, "CRITICAL", repetition | Lowers the failure rate; does not remove it |
| Temperature 0, a bigger model, a larger context window | Does not fix the layer that failed |
| Every tool for every agent "so nobody is blocked" | Worse tool selection and misuse |
| Retry every error; return empty on failure | Wasted calls; silent data loss |
| Same-session self-review, even with extended thinking | Shares the generator's assumptions |
| Regular expressions over prose findings | Breaks; ask for JSON with a schema |
| Iteration cap or "done" text as the stop signal | stop_reason is the signal |
| Escalate on sentiment; pick the likeliest customer | Escalate on triggers; ask for an ID |
On exam day
- 60 items in 120 minutes is two minutes each. Flag anything slow and come back to it.
- Each item says how many responses to select. Read that line before the options.
- Find the constraint in the stem ("must always", "under 3 seconds", "teammates cannot see"); it usually rules out two options.
- The score is scaled to 1,000 with 720 to pass, so a raw percentage does not convert directly. Aim for 80% or more in the practice tests.
Unsure about a point? Open its lesson from the number beside it. Ready to check yourself? Take the CCAR-F practice tests.