CCAR Prep

Flashcards · 30 cards · free

Every Claude Certified Architect — Foundations objective, on one card each

One card for each of the 30 objectives the exam grades, in blueprint order. Each says what the objective covers and, more usefully, the distinction its questions turn on. Most items on this exam are a choice between two defensible answers, not a fact you either know or do not. Every card links to practice questions on that objective.

answers are shown, not hidden. This is a reference you read, not a self-test

D1Agentic Architecture and Orchestration

27% of the exam · 7 objectives

  • Objective 1.1 · Agentic Loops

    What does objective 1.1, agentic loops, cover on the CCAR-F exam?

    The loop has one natural stopping point: Claude keeps calling tools and feeding results back until it produces a response containing no tool calls. Anyone expecting a turn limit or a stop sequence to end it is describing a cap rather than the mechanism. A turn is a round trip and not a message, and max_turns counts only the turns that used a tool. The trap worth carrying in is ResultMessage. Its subtype says how the run ended, and the result field exists only when that subtype is success, so code reading it unconditionally breaks on exactly the caps it was meant to respect.

    8 practice questions →
  • Objective 1.2 · Multi-Agent Orchestration

    What does objective 1.2, multi-agent orchestration, cover on the CCAR-F exam?

    Five shapes, and most items describe one in the stem and ask you to name it. A single call, a fixed chain, parallel workers, an orchestrator deciding how many workers to spawn, an evaluator paired with an optimiser. The orchestrator is the reflex choice and earns its cost only when the number of subtasks is discovered during the run rather than known before it. Two ideas recur in the distractors: overlapping partitions pay twice for the same document and cover nothing extra, and only the coordinator holds every worker's findings, so only the coordinator can see that two of them disagree.

    8 practice questions →
  • Objective 1.3 · Subagent Invocation and Context Passing

    What does objective 1.3, subagent context, cover on the CCAR-F exam?

    A freshly spawned subagent begins with its own system prompt, the delegation message you wrote, and project-level instruction files. It does not begin with the parent's conversation, the files the parent opened, or the reasoning that narrowed the problem down, which is what makes the brief load-bearing rather than a formality. Two further facts turn up as keys. Where a tool is named in both the allowed and the denied list, the denial wins and the tool is removed. And the built-in exploration and planning agents skip instruction files deliberately, so a rule they must obey has to be restated in the prompt they are given.

    8 practice questions →
  • Objective 1.4 · Workflow Enforcement and Handoff

    What does objective 1.4, workflow enforcement, cover on the CCAR-F exam?

    Instruction files are context, not enforcement. They shape behaviour without guaranteeing it, so anything that has to hold every time needs a control the model cannot talk its way past: a PreToolUse hook inspecting the call before it executes, or a tool resolving the limit server-side from state the conversation cannot write. The same reasoning settles where an audit record belongs. A transcript captures what the agent announced, including changes whose tool call then failed; writing the record inside the tool at the moment the change commits captures what happened.

    8 practice questions →
  • Objective 1.5 · Agent SDK Hooks

    What does objective 1.5, agent sdk hooks, cover on the CCAR-F exam?

    Thirty-one hook events exist and perhaps eight are settled enough to examine, so the mechanics matter more than the roster. Exit status 2 is the only code that blocks on its own; every other non-zero status is a non-blocking error and the action goes ahead. PostToolUse cannot block anything, because the tool has already run, and anybody expecting it to veto a write has the lifecycle wrong. Tool events answer with permissionDecision, which takes three values and not two: allow, deny, escalate. Lifecycle events such as Stop use a different key entirely.

    8 practice questions →
  • Objective 1.6 · Task Decomposition Strategies

    What does objective 1.6, task decomposition, cover on the CCAR-F exam?

    These items hand you a workload and ask where the seams fall. Distinct input categories wanting distinct handling is a routing problem. Identical work over independent units partitions across concurrent workers. Stages that each consume the previous stage's output form a chain, and parallelising them leaves nothing to run at the same time. The instructive error is splitting a code review by file when the property under review lives between files, which leaves every worker blind to it; splitting by concern instead hands each worker the whole diff and a single lens.

    7 practice questions →
  • Objective 1.7 · Session State and Resumption

    What does objective 1.7, sessions and resumption, cover on the CCAR-F exam?

    Three operations, and the stem usually settles which is available to you. Continue picks up the most recent session in the working directory, resume takes a session id you kept hold of, and fork resumes and then branches, leaving the original id and history untouched. The caveat is the sharpest question here: forking branches the conversation and not the filesystem. A forked agent that edits files makes real edits, visible to any session working in that directory, so treating a fork as a sandbox is wrong in a way that costs work.

    7 practice questions →

D2Tool Design and MCP Integration

18% of the exam · 5 objectives

  • Objective 2.1 · Tool Interface Design

    What does objective 2.1, tool interface design, cover on the CCAR-F exam?

    The description is the model's only account of what a tool does, so vague descriptions produce exactly the symptoms these items describe: guessed parameter formats, tools picked for adjacent work they do not cover, and a tool abandoned after one failure. Two fixes recur as keys. Put a constraint in the schema as a fixed set of permitted values rather than describing it in prose, because a constraint the model sees as part of the shape stops wrong values being produced instead of translating them afterwards. And shape the result: a tool returning ninety fields spends context on all ninety whether the next decision needs them or not.

    8 practice questions →
  • Objective 2.2 · Structured Error Responses

    What does objective 2.2, structured errors, cover on the CCAR-F exam?

    One decision follows a failure, and it is whether trying again could work. That makes retryability the property a structured error has to state rather than leave the agent to infer from a message. A timeout may succeed unchanged; a malformed argument never will; a closed account is a business fact that will not move, so the useful output is a reason the user can be told. The other half of the objective is refusing to collapse distinct facts: nothing found and could not look are different, and a tool that returns an empty list for both leaves the agent reporting the only reading it has.

    7 practice questions →
  • Objective 2.3 · Tool Distribution and Tool Choice

    What does objective 2.3, tool distribution, cover on the CCAR-F exam?

    Four values, and their consequences are what get examined. Auto is the default once tools are supplied and lets Claude decide; any forces some tool; tool forces a named one; none forbids them. The consequence worth knowing is that any and tool prefill the assistant message, so the model emits no natural-language explanation before the tool_use block even when the prompt asks for one. A scenario wanting both a forced extraction and something to show the user therefore cannot use forcing. On the distribution side, an unset pair inherits everything, tools alone is a whitelist, and where both appear the denial wins.

    7 practice questions →
  • Objective 2.4 · MCP Server Integration

    What does objective 2.4, mcp integration, cover on the CCAR-F exam?

    The protocol settles an interface and nothing more: how a server describes its tools and resources, and how a client invokes them. Authentication, rate limiting, retries and caching stay the server's job, and dropping them because a protocol arrived is the misreading these items are built around. The shape it suits is many systems, many consumers and distributed ownership, where each team maintains one server that every application reuses. Two further points appear as keys: results carry a flag marking failure, so prose describing a problem inside a successful result is invisible, and stable reference material belongs in a resource rather than behind three tool calls.

    7 practice questions →
  • Objective 2.5 · Built-in Tools

    What does objective 2.5, built-in tools, cover on the CCAR-F exam?

    Glob finds files by name, Grep finds lines inside them, and the difference that decides an item is that Glob ignores .gitignore while Grep respects it, so only one of them turns up a build artefact. Grep is built on ripgrep rather than POSIX grep, which changes how metacharacters are escaped. On the writing side, an edit must pass three checks: the file has been read, the old string matches exactly, and it appears exactly once. When the anchor is not unique the fix is a longer anchor or replace_all. Falling back to rewriting the whole file discards concurrent changes.

    7 practice questions →

D3Claude Code Configuration and Workflows

20% of the exam · 6 objectives

  • Objective 3.1 · CLAUDE.md Hierarchy, Scoping, and Modular Organisation

    What does objective 3.1, claude.md hierarchy, cover on the CCAR-F exam?

    An instruction file loads in full at the start of every session, so a monthly release procedure kept there is paid for in every conversation that has nothing to do with releases. That is the cost side. The correctness side is that discovered files are concatenated rather than overriding one another, so contradictory rules at two levels both sit in context and the agent may follow either. Two further facts show up as keys: length itself reduces adherence, so the fix for a long file is subtraction rather than emphasis, and after compaction the project-root file is re-injected while files found in subdirectories are not.

    7 practice questions →
  • Objective 3.2 · Custom Slash Commands and Skills

    What does objective 3.2, commands and skills, cover on the CCAR-F exam?

    The title implies two mechanisms, and the documentation has merged them: a file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both produce /deploy and behave the same. The axis that still decides is when the body loads. A skill loads on invocation, an instruction file loads every session, which is why a long procedure belongs in the former. Precedence runs backwards from most config systems, with personal beating project. And two frontmatter fields are worth memorising: disable-model-invocation keeps a deploy out of Claude's hands, while allowed-tools grants permissions for the invoking turn only.

    7 practice questions →
  • Objective 3.3 · Path-Specific Rules for Conditional Convention Loading

    What does objective 3.3, path-specific rules, cover on the CCAR-F exam?

    A path-scoped rule is present only while the agent is working on files the pattern matches, so a Terraform edit never sees the front-end conventions at all. Three consequences are examined. A rule with no path declaration is unconditional and loads at launch with the same weight as the project file, which is backwards from what most authors assume. Loading triggers on reading a matching file rather than at launch or on every tool call, so a session that stayed in one area may never have loaded a rule and nothing is broken. And brace expansion has a budget; a pattern that exceeds it is used literally and matches nothing.

    7 practice questions →
  • Objective 3.4 · Plan Mode vs Direct Execution

    What does objective 3.4, plan mode, cover on the CCAR-F exam?

    The deciding line is short enough to memorise: if you could describe the diff in one sentence, skip the plan. Plan when the approach is uncertain, when several files change, or when the code is unfamiliar to you. The honest concession is that planning adds overhead, which is what stops the plan-everything answer being merely stupid. Two distinctions get examined. Plan mode addresses unknown scope, while effort addresses reasoning depth inside a single response, and they solve different problems. And plan mode is an approval gate, so an unattended pipeline with nobody to approve wants scoped permissions instead.

    7 practice questions →
  • Objective 3.5 · Iterative Refinement Techniques

    What does objective 3.5, iterative refinement, cover on the CCAR-F exam?

    Claude stops when the work looks done, and without something that returns pass or fail, looking done is the only signal available and you become the verification loop. So the answer is usually to give it a check it can run: a test suite, a build exit code, a script that diffs against a fixture. The mechanisms escalate from asking in the prompt, through a goal condition, to a Stop hook that blocks the turn from ending. Two counter-intuitive points: ask for evidence rather than an assertion of success, and after correcting the same issue twice, clear the context rather than correcting a third time.

    6 practice questions →
  • Objective 3.6 · CI/CD Integration

    What does objective 3.6, ci/cd integration, cover on the CCAR-F exam?

    Almost everything here is about the flags. The json output format puts the response text in a result field, and a schema supplied alongside it lands in structured_output instead; a format annotation such as email is accepted and never enforced, which is a fair trap because assuming otherwise is a real design error. Permissions matter more than anything else in an unattended run, and the rule syntax hides one: the space in Bash(git diff *) is what confines prefix matching, since without it the pattern also matches git diff-index. Bare mode skips CLAUDE.md, hooks and MCP discovery, which is what makes a run reproducible across machines.

    6 practice questions →

D4Prompt Engineering and Structured Output

20% of the exam · 6 objectives

  • Objective 4.1 · System Prompts with Explicit Criteria

    What does objective 4.1, system prompt criteria, cover on the CCAR-F exam?

    The recurring failure is a criterion the prompt never defines. Asking an agent to flag anything suspicious leaves it inventing a standard, and a slightly different one each run, so the fix is named categories with a stated rule each and a worked example anchoring the boundary. The other half is knowing when the prompt is the wrong instrument. Requirements phrased with never or without exception are guarantees, and a prompt raises the odds while leaving a tail; appending the text in code removes the model from the requirement. Length is examined too: a rule lost among thirty others is not fixed by adding a thirty-second.

    7 practice questions →
  • Objective 4.2 · Few-Shot Prompting

    What does objective 4.2, few-shot prompting, cover on the CCAR-F exam?

    Three to five examples, and what makes them work matters far more than the count. They should mirror the real case, sit inside example tags so the model can tell them from instructions, and vary enough that no accidental pattern is learned. That last property is the objective's best question. Examples too alike teach the accident rather than the rule, so if all of them happen to have two-word inputs then two-word inputs are what gets handled, and the fix is varying them rather than adding more or raising effort. Reach for an example when an instruction has repeatedly failed to land a format.

    7 practice questions →
  • Objective 4.3 · Structured Output with Tool Use

    What does objective 4.3, structured output, cover on the CCAR-F exam?

    Prose describing a shape leaves the model to produce it; a tool input schema makes the shape part of the request. Two things have to be settled and items often test both at once: what the structure is, which the schema fixes, and that a structured response is produced at all, which requiring the tool call fixes. A required field with no way to express absence is the trap worth carrying in, because the model then chooses between breaking the schema and inventing a value, and it invents. Prefilling the response was the older way to force a shape and is no longer where a new service should start.

    7 practice questions →
  • Objective 4.4 · Validation, Retry, and Feedback Loops

    What does objective 4.4, validation and retry, cover on the CCAR-F exam?

    Validation questions turn on which failures a check can actually catch. A syntax and type check passes a total that contradicts its own line items, so relationships between values need arithmetic the code can do without the model. Self-checking shares the failure it is meant to catch, since a value misread for a reason is confirmed for the same reason. On retries, the distinction is whether the failure is variable or systematic: resending an identical request is a fresh sample and fails about as often as it succeeds, feeding back what was produced and what was wrong turns it into a correction, and a schema that is wrong about the documents is not fixed by any number of attempts.

    7 practice questions →
  • Objective 4.5 · Batch Processing Strategies

    What does objective 4.5, batch processing, cover on the CCAR-F exam?

    The trade is latency for price, and the deciding constraint in these stems is nearly always whether somebody is waiting. A day of headroom is comfortably wider than batch turnaround; a feature with a person watching the spinner is the one case where the discount is unavailable. Partial recovery is the other half. A caller-chosen identifier on every item is what lets the failures be selected and resubmitted as a smaller batch, and the downstream effect has to be harmless when an item is processed twice, because a partial failure can leave the first half already applied.

    6 practice questions →
  • Objective 4.6 · Multi-Instance and Multi-Pass Review

    What does objective 4.6, multi-pass review, cover on the CCAR-F exam?

    A fresh context reviews better because it is not attached to the code it just wrote. The reviewer sees the diff and the criteria you hand it, not the reasoning that produced the change, so it judges the result on its own terms. That makes a fork the wrong instrument here: it inherits the parent conversation, which is precisely the context an independent review is trying to escape. Two more points are examined. Name the work, the plan it is checked against, and what counts as a finding. And a reviewer asked to find gaps will find some regardless, so scope it to correctness rather than to taste.

    6 practice questions →

D5Context Management and Reliability

15% of the exam · 6 objectives

  • Objective 5.1 · Context Window Management

    What does objective 5.1, context window, cover on the CCAR-F exam?

    Performance degrades as the window fills, and the first casualty is an early instruction that still binds a late turn. That is the fact these items are built on, and it rules out any strategy that drops the oldest content first, since the oldest content is often the commitment. Summarising keeps it in condensed form; better still, anything that must never be lost belongs outside the material being condensed, in a block present on every turn. Two details recur: named fields survive better than regenerated prose, because rewriting is where drift enters, and the effective place to trim a large tool result is before it arrives.

    5 practice questions →
  • Objective 5.2 · Escalation and Ambiguity Resolution

    What does objective 5.2, escalation and ambiguity, cover on the CCAR-F exam?

    Two questions decide nearly every item here. Has the user asked for a person, which is a first-class trigger and not the agent's judgement to override on the grounds that it could have coped. And is being wrong cheap to correct, which is what separates proceeding on a stated assumption from stopping to ask. The same ambiguity that justifies carrying on with a report justifies stopping before a deletion, because one is regenerated and the other is not. On the mechanics: batch the questions, since three asked separately cost three interruptions, and offer concrete options with a note on what turns on the answer.

    5 practice questions →
  • Objective 5.3 · Error Propagation in Multi-Agent Systems

    What does objective 5.3, error propagation, cover on the CCAR-F exam?

    A failure that stops looking like a failure is the defect these items are about. A worker that cannot reach a source and returns findings alone has converted a partial result into an apparently complete one, and everything downstream then reasons from a false premise while looking entirely plausible, because the later stages did their jobs correctly on bad input. Could not look and nothing there are the two facts that must never collapse into each other. Not everything travels upward, though: a timeout that succeeded on retry was recovered without loss, and reporting it is noise rather than propagation.

    5 practice questions →
  • Objective 5.4 · Codebase Exploration and Context Degradation

    What does objective 5.4, codebase exploration, cover on the CCAR-F exam?

    One constraint generates the rest: the window fills fast and performance falls as it does. Exploring a large codebase is the classic way to fill it, and the fix is delegating the exploration so only the findings come back, since the subagent reads in its own window and the main context grows by a summary rather than a transcript. Scoping the request is the other acceptable fix, so a well-formed stem says which constraint decides. Worth knowing about compaction: it replaces older messages with a summary, and the project-root instruction file is re-injected on every request while a nested one is not.

    5 practice questions →
  • Objective 5.5 · Human Review and Confidence Calibration

    What does objective 5.5, confidence calibration, cover on the CCAR-F exam?

    A confidence score is not a probability of being right until somebody has checked that it tracks correctness, and if it does not, no threshold placed on it separates anything. Measurement against known-correct labels is the only thing that finds a real boundary. The second idea is that an aggregate hides its own composition: 94% overall is consistent with near-perfect handling of the common case and a much worse rate on a rarer one, so automating on the headline figure automates the bad segment. And automation removes the measurement along with the labour, which is why a continuing sample matters afterwards.

    5 practice questions →
  • Objective 5.6 · Information Provenance and Multi-Source Synthesis

    What does objective 5.6, provenance and synthesis, cover on the CCAR-F exam?

    Citations from the API are parsed and extracted directly, so they are guaranteed to point at text that is actually in the documents you supplied. Asking for quotes in the prompt buys no such guarantee, and that contrast is the objective's central question. Enabling them is all or nothing across the documents in a request. One architectural constraint is worth carrying in: citations and structured outputs cannot be combined and the API returns a 400, so a scenario needing both grounded quotes and a strict schema has to run two passes. On the synthesis side, conflicting sources are annotated with both values and their attribution rather than quietly resolved.

    5 practice questions →

Cards tell you what is on the exam. A timed mock tells you whether you can answer it.

Sit a timed mock →