How to pass Claude Certified Architect - Foundations (CCAR-F)

How this exam thinks

What each domain tests and how to study it

The CCAR-F blueprint is split across 5 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.

1. Agentic Architecture & Orchestration

   27% of exam

   What you must be able to do. Design an agentic loop that terminates on the protocol rather than on heuristics, decompose work across a coordinator and subagents with explicit context passing, and choose programmatic enforcement over prompt wording wherever the scenario demands a guarantee.

   In one sentenceThe largest domain: the loop lifecycle driven by stop_reason, hub-and-spoke coordination with isolated subagent context, and the line between guidance that shifts behaviour and enforcement that bounds it.

   Recall check: answer these from memory first

   • Walk the agentic loop in order, naming the stop_reason value that continues it and the one that ends it.
   • A subagent spawned with the Task tool needs a finding the coordinator discovered three turns ago. How does it get there, and why is nothing else sufficient?
   • Given a rule that must hold in every session, name the mechanism that enforces it and say why a CLAUDE.md line does not.
   • Say when you would resume a named session and when you would start fresh with an injected structured summary.

   What it tests. The mechanics of the agentic loop and everything built on top of it. You send a request, inspect stop_reason, execute the tools the model asked for, append the results to the conversation history, and iterate while stop_reason is tool_use, stopping on end_turn. It tests coordinator-subagent design with the Task tool, allowedTools and AgentDefinition, the fact that subagent context is explicit rather than inherited, multi-step workflows with prerequisite gates and structured handoff summaries, PostToolUse hooks for normalising heterogeneous tool output, fixed versus adaptive task decomposition, and session resumption and forking.

   How to study it. Write the loop out by hand before you study anything else, including the branch on stop_reason and the append of tool results, because half this domain is a corollary of it. Then drill the enforcement distinction until it is instant: a line in CLAUDE.md or a system prompt changes the probability of an ordering, a PreToolUse hook blocks the call. Build a two-level coordinator once, even a toy one, so that the isolation of subagent context is something you have hit rather than something you have read. For decomposition, practise saying out loud which of a fixed pipeline and an adaptive plan a given scenario needs, and why an overly narrow split produces coverage gaps rather than efficiency.

   Easy to confuse

   • Prompt-based guidance versus programmatic enforcement. Instructions in context shift sampling probability and cannot bound it, so compliance is statistical even when the instruction is fully present and well written. A hook runs outside the model and can deny the call before it reaches the tool. When the scenario quotes a residual failure rate or says a prerequisite must hold every time, the answer is the hook.
   • An iteration cap versus a protocol termination signal. Stopping the harness after N model calls is a cost bound, not a completion test, and it truncates exactly the long cases that needed the extra turns. Termination is stop_reason reaching end_turn. Parsing assistant text for a phrase that sounds final is the same error in a different costume.
   • Coordinator context versus subagent context. A subagent starts with what its prompt contains and nothing else: no coordinator history, no memory of a previous invocation. Any option that assumes the subagent already knows something the coordinator learned is wrong, and the fix is to put the finding in the Task prompt rather than to widen its tools.
   • PreToolUse versus PostToolUse hooks. PreToolUse sits in front of the call and can block or redirect it, which is what a policy threshold or a prerequisite gate needs. PostToolUse sits behind it and transforms the result before the model reads it, which is what normalising timestamps or status codes across several MCP servers needs. Match the hook to whether the scenario is preventing an action or reshaping data.
   • Fixed prompt chaining versus adaptive decomposition. A fixed sequential pipeline is right when the aspects to cover are known in advance, such as a multi-aspect review. Adaptive decomposition is right when subtasks only emerge from intermediate findings, such as an open-ended investigation. The tell is whether the scenario can list the steps before starting.

   Worked example from the CCAR-F bank

   lock_openFree sampleAgentic Architecture & Orchestrationhard

   The Resolution Desk team runs a Customer Support Resolution Agent on the Claude Agent SDK, calling the MCP tools get_customer, lookup_order, process_refund and escalate_to_human. To stop refunds being issued against unverified orders, they added a line to the project CLAUDE.md stating that process_refund must be called only after a successful lookup_order in the same session. Across the next 5,000 sessions, telemetry records 62 sessions in which process_refund was called with no preceding lookup_order call. Which statement best explains that residual failure rate?

   • ACLAUDE.md is prompt based guidance that shifts the probability of a behaviour rather than controlling it, so compliance is statistical; a prerequisite that must hold every time needs a PreToolUse hook that inspects the call and blocks it.check_circle Correct
   • BCLAUDE.md is loaded once at session start, so its text is evicted from the context window as the conversation grows and the constraint stops applying part way through longer disputes.
   • CTool call ordering is enforced by the MCP server that publishes the tools, so the 62 sessions indicate that the server lost its per session state and stopped rejecting the out of order calls.
   • DThe rule sits at the wrong level of the CLAUDE.md hierarchy, and moving it from the project file to a user level file would make the same wording binding on every session the team runs.

   Prompt based instructions shape behaviour probabilistically, so a prerequisite that must hold every time requires a programmatic gate such as a PreToolUse hook. Text in CLAUDE.md enters the model's context and biases sampling, which is why compliance is high but not total. A PreToolUse hook executes in the harness rather than in the model, receives the pending tool call and its arguments, and can refuse it, so the guarantee comes from code that runs regardless of what the model decided.

   Why A is correct: Correct: instructions in context influence sampling and cannot bound it, whereas a PreToolUse hook runs outside the model and can deny the call deterministically before it reaches the tool.

   Why B is wrong: Tempting because attention dilution over long conversations is a real effect, but the failure does not depend on eviction: the instruction is advisory even while fully present in context, so restoring it would not make the ordering binding.

   Why C is wrong: Tempting because MCP servers do hold connection state, but the protocol exposes independent tools with no cross tool ordering semantics, so there is no server side sequencing rule that could have lapsed.

   Why D is wrong: Tempting because the hierarchy is real and does change which sessions see a file, but scope is not enforcement: the same sentence read from any level remains guidance the model may decline to follow.

2. Tool Design & MCP Integration

   18% of exam

   What you must be able to do. Write tool interfaces the model can route correctly without guessing, return errors an agent can act on, scope tool access per agent, and wire MCP servers into a project at the right level.

   In one sentenceTools are an interface for a reader who only has the description: name them so they cannot overlap, fail in a way that says what to do next, and give each agent only the tools its role needs.

   Recall check: answer these from memory first

   • Two tools keep getting confused by the model. Name the four things you add to each description, and the one thing you add that is specifically about the other tool.
   • Distinguish a tool result that reports an access failure from one that reports a valid empty result, and say why the difference matters to the agent.
   • Say when a server belongs in project-scoped .mcp.json and when it belongs in user-scoped configuration.
   • Give the three values tool_choice can take and a scenario that needs each.

   What it tests. Tool interface design and the MCP surface around it. Descriptions are the primary signal for tool selection, so thin or overlapping descriptions cause misrouting between similar tools and the fix is a boundary statement against the nearest alternative, not more instruction in the system prompt. It tests structured error responses using the isError flag plus metadata such as an error category and a retryable flag, the difference between an access failure and a valid empty result, per-agent tool scoping and tool_choice set to auto, any or a named tool, project-scoped .mcp.json against user-scoped configuration with environment variable expansion for credentials, and effective use of the built-in Read, Write, Edit, Bash, Grep and Glob tools.

   How to study it. Take two tools you have written and rewrite their descriptions to include input formats, an example query, an edge case and one sentence saying when to use the other tool instead. That exercise is most of this domain. Then work the error taxonomy: transient, validation, business and permission, and what each one should make the caller do, because the exam tests whether a subagent recovers locally or propagates. Learn the built-in tools by their access pattern rather than their names: Grep finds content, Glob finds paths, Edit needs a unique anchor and falls back to Read plus Write when there is not one, and codebase understanding is built incrementally from entry points rather than by loading everything.

   Easy to confuse

   • A failed lookup versus a successful lookup with no matches. An empty result set is a successful query and should not be returned as an error, because the agent's correct next move is to ask for another identifier rather than to retry. Collapsing both into isError, or both into an empty array, destroys the information the agent needs to choose between retrying, clarifying and escalating.
   • Fixing a misrouted tool in the description versus in the system prompt. The description travels with the tool and is what the model reads when selecting, so it is where the boundary belongs. System prompt wording that names one tool by keyword can override a good description and is worth auditing, but adding more prompt text is treating the symptom on the wrong layer.
   • One generic tool with an operation argument versus several purpose-specific tools. A single tool taking an enum of operations pushes the routing decision into an argument the model has no description for, so selection accuracy falls as the enum grows. Splitting it gives each operation its own description, input contract and boundary. The exam plants the generic tool as the tidy-looking wrong answer.
   • Giving an agent more tools versus giving it the right ones. Selection reliability degrades as the tool count rises, and an agent holding tools outside its specialisation tends to misuse them. Scope each subagent to its role and add a narrow cross-role tool only for a high-frequency need. An option that solves a routing problem by granting more access is usually wrong.
   • Grep versus Glob. Grep searches inside files for a pattern such as a function name, an error string or an import. Glob matches file paths by name or extension. If the scenario knows what the text says, it is Grep; if it knows what the file is called, it is Glob.

   Worked example from the CCAR-F bank

   lock_openFree sampleTool Design & MCP Integrationmedium

   The Resolution Desk team adds a second MCP tool, find_account, alongside the existing get_customer on their Customer Support Resolution Agent. get_customer is described as retrieving a customer record by identifier, and find_account is described as retrieving an account record by identifier. Both take a single string argument. Across 800 sessions the agent calls find_account in roughly half of the identity checks the team intended to route to get_customer, with no pattern the team can predict from the transcripts. Which statement best explains that split?

   • AThe two tools return records of different shapes, so the agent deliberately alternates between them across sessions in order to compare the two results before it answers the customer's opening question.
   • BThe MCP server registers tools in the order they are listed in the project .mcp.json file, and the model is required to select the earlier registration whenever two tools accept an argument of the same type.
   • CIdentical input schemas make validation reject one of the two calls, after which the harness automatically retries the request against the sibling tool, which is what produces an even split of calls across the sessions.
   • DTool selection is driven by the tool name and the description text, so two descriptions stating the same capability in different words give the model no discriminating signal, and the choice then varies with the wording of each customer's message.check_circle Correct

   Tool descriptions are the routing surface, so two tools whose descriptions state the same capability produce unpredictable selection. The model picks a tool by matching the request against each tool's name, description and input schema. When two descriptions assert the same capability in different words, no text distinguishes them, so selection falls to incidental wording in the customer's message and looks random in aggregate. Disambiguating means rewriting the descriptions to state what each tool covers and what it does not, or collapsing the pair into one tool.

   Why A is wrong: Tempting because the tools genuinely do return different record shapes, but the agent has no comparison behaviour of that kind; it selects one tool per intent, and nothing in the loop asks it to sample alternatives.

   Why B is wrong: Registration order is real, but it carries no selection precedence of this sort, and a rule like this would produce a consistent bias rather than the unpredictable half-and-half split observed.

   Why C is wrong: Plausible if you assume schemas are compared across tools, but validation checks a call against its own tool's schema only, and there is no automatic retry that reroutes a call to a different tool.

   Why D is correct: Correct. The description is the routing surface, and two overlapping descriptions leave the selection to incidental phrasing, which is exactly the unpredictable split the team measured.

3. Claude Code Configuration & Workflows

   20% of exam

   What you must be able to do. Place a convention at the scope where the people who need it will actually load it, package repeatable work as a skill or slash command with the right isolation, and run Claude Code non-interactively inside a pipeline.

   In one sentenceConfiguration is a distribution problem: user, project and directory scopes decide who gets a rule, path globs decide when it loads, and skills and slash commands decide what is shared through version control.

   Recall check: answer these from memory first

   • A new team member does not get a convention that everyone else's Claude Code follows. Name the most likely cause and the fix.
   • Say when a convention belongs in a path-scoped rule file rather than a directory-level CLAUDE.md.
   • Name the two things you configure on a skill to restrict what it can do and to prompt for a missing parameter.
   • Give two reasons a continuous integration job runs Claude Code non-interactively with structured output.

   What it tests. How Claude Code is configured and driven. The CLAUDE.md hierarchy runs user-level, project-level and directory-level, and user-level instructions are never shared with teammates through version control, which is the root cause behind a whole family of items about behaviour one engineer sees and nobody else does. It tests import syntax and splitting a large memory file into topic-specific rules, project-scoped versus user-scoped slash commands, skill frontmatter including allowed-tools and argument-hint and running a skill in a forked context so verbose output stays out of the main conversation, path-scoped rules whose frontmatter carries glob patterns, plan mode against direct execution, iterative refinement techniques, and running Claude Code headlessly in continuous integration with structured output.

   How to study it. Reason about every configuration item by asking two questions: who can see this file, and when does it load. Those two answers resolve most of the domain. Set up a small repo with a root CLAUDE.md, a package-level one, a path-scoped rule file and one skill, then verify which memory files actually loaded, because the surprise is instructive. For continuous integration, focus on why the non-interactive flag matters, which is that a pipeline job must never block waiting for input, and on why an independent instance reviews generated code better than the session that wrote it. Practise the plan mode boundary on real changes: architectural or multi-file work earns a plan, a single validation check in a single function does not.

   Easy to confuse

   • User-scoped versus project-scoped configuration. User-level files live in a personal configuration directory and are never distributed through version control, so a rule that works for its author and for nobody else is nearly always a scope fault. Anything the team must share belongs in the checked-in project file.
   • A directory-level CLAUDE.md versus a path-scoped rule. A directory file applies to everything under one folder. A rule file with glob patterns in its frontmatter applies to a file type wherever it sits in the tree, which is the normal case for tests living beside the code they test. When the convention follows the file type rather than the folder, use globs.
   • An always-loaded CLAUDE.md standard versus an on-demand skill. Put in memory what must shape every response, and package as a skill what is a specific procedure invoked occasionally. Loading a long procedure on every turn spends context on something rarely needed, and the fork context option keeps a verbose skill's output out of the main conversation entirely.
   • Plan mode versus direct execution. Plan mode earns its cost when a change is large, spans several files, has more than one defensible approach or carries architectural consequences, because rework is the expensive outcome. A well-scoped single-function change does not need it. Investigation in plan mode followed by direct execution of the agreed change is a valid combination, not a contradiction.
   • The session that wrote the code reviewing it versus an independent instance. A session carries its own reasoning context from generation and is less likely to question decisions it just made, so self-review instructions and longer thinking do not close the gap. An independent instance without that context is what catches the subtle issue, which is why a pipeline review runs separately from the run that produced the change.

   Worked example from the CCAR-F bank

   lock_openFree sampleClaude Code Configuration & Workflowsmedium

   An engineer on the Meridian Platform team adds a rule about running the type checker before any proposed refactor to the CLAUDE.md in her own home Claude directory, and confirms it takes effect in every repository she opens. Two colleagues then report that Claude Code proposes refactors on the same service without running the type checker, and a search of the checkout shows the rule is in none of the committed files. What does the placement of that rule guarantee?

   • AIt applies to every project on her machine and is folded into the repository at her next commit, so colleagues pick the rule up as soon as they pull the branch she is working on.
   • BIt applies to whichever repository was open when the file was last edited, because user scope memory is keyed to the working directory in force at the time of the change.
   • CIt applies to every collaborator signed in to the same workspace, because user scope memory is synchronised through the account rather than through the repository checkout.
   • DIt applies across every project on her own machine and travels with her user account, but it is not part of the repository, so a colleague's session does not load it.check_circle Correct

   User scope memory covers every project on one developer's machine and reaches no colleague, so shared rules belong in the project file. The two scopes answer different questions. User scope memory encodes personal working preferences and is loaded for whatever project that developer opens, while project scope memory is committed alongside the code and is loaded for anyone who checks the repository out. A rule that the whole team must follow only becomes a team rule when it sits in the checked-in file, which is why her colleagues see no trace of it.

   Why A is wrong: Sharing a convention by committing it is the right instinct, which makes this plausible. It is wrong because a user scope file lives outside the checkout and no commit sweeps it in; the rule has to be written into the project file deliberately.

   Why B is wrong: Directory keyed behaviour genuinely exists for nested project memory, so borrowing it here feels consistent. It is wrong because the user scope file is not bound to a directory at all and is loaded whatever project is open.

   Why C is wrong: Account synchronised settings are common in team tooling, so this reads as reasonable. It is wrong because user scope memory is a local file on one machine and carries no mechanism for distributing itself to other people.

   Why D is correct: Correct. User scope memory is personal and machine local, so it reaches all of her own projects and none of anyone else's, which is precisely the split her colleagues are seeing.

4. Prompt Engineering & Structured Output

   20% of exam

   What you must be able to do. Replace vague quality instructions with explicit criteria, use few-shot examples to fix format and demonstrate judgement, guarantee schema compliance through tool use, and build validation and retry loops that know their own limits.

   In one sentencePrecision comes from stating which cases count and which do not, structure comes from a schema enforced by tool use, and neither one fixes a semantic error that only validation against the source can catch.

   Recall check: answer these from memory first

   • A reviewer is told to report only high-confidence findings and the false positive rate barely moves. Say why, and what replaces that instruction.
   • Name what a JSON schema enforced through tool use guarantees, and give two errors it does not prevent.
   • Describe what you send back on a retry after a validation failure, and name a failure retry cannot fix.
   • Give two workloads that suit the Message Batches API and one that does not, with the property that decides it.

   What it tests. Getting reliable, usable output out of the model. It tests explicit categorical criteria against confidence-based filtering as a way to cut false positives, few-shot prompting for consistent format and for demonstrating how an ambiguous case should be handled, tool use with a JSON schema as the way to remove syntax errors, and the sharp limit on that: a schema-valid extraction can still put a value in the wrong field or return line items that do not sum to the stated total. It covers required, optional and nullable fields, enum design including an unclear member and an other plus detail pattern, tool_choice forcing the extraction tool, retry with specific validation failures fed back alongside the original source, batch processing through the Message Batches API with custom_id correlation, and multi-pass and multi-instance review.

   How to study it. Take any prompt you have written that asks for good judgement and rewrite it as a list of what to report and what to skip, with a concrete code or document example per severity band. The gap between those two prompts is the whole of Task Statement 4.1. Then get the schema boundary exact by breaking it deliberately: build an extraction tool with a JSON schema, feed it a messy document, and watch it return perfectly valid JSON that is wrong. That failure teaches the semantic versus syntactic distinction better than any note. For batching, learn the shape of the tradeoff rather than any number: a long asynchronous window with a cost saving and no latency promise, which suits overnight and audit work and rules out anything that blocks a merge.

   Easy to confuse

   • Explicit criteria versus a confidence threshold. Telling the model to be conservative or to report only what it is confident about asks it to grade its own output on a scale it is not calibrated for. A categorical rule naming the issue classes to report, with an example each, changes what gets produced rather than filtering it afterwards, and that is what the exam counts as the precision fix.
   • Syntax errors versus semantic errors in structured output. Tool use with a schema removes malformed JSON, missing fields and wrong types. It cannot tell that a total does not match the sum of the line items or that a date landed in the wrong field. Semantic correctness needs a validation step that compares the extraction against the source, so any option claiming the schema solved accuracy is wrong.
   • A nullable field versus an omitted optional field. Marking a field nullable gives the model a way to say the value is absent, which is what stops it fabricating one. Simply making a field optional lets it disappear silently and leaves the consumer unable to distinguish absent from not looked for. When the scenario mentions invented values, the answer is the explicit null.
   • Few-shot examples versus more detailed instructions. Instructions are read inconsistently and describe the target in the abstract. Two to four examples show the format and, more importantly, show the reasoning for choosing one action over a plausible alternative in an ambiguous case, which is what lets the model generalise to a pattern nobody listed.
   • Per-file review passes versus one pass over everything. Loading a large change in one pass dilutes attention and produces inconsistent and contradictory findings. Focused per-file passes catch local issues and a separate integration pass catches cross-file data flow. The exam wants both passes named, because either one alone leaves a class of defect unfound.

   Worked example from the CCAR-F bank

   lock_openFree samplePrompt Engineering & Structured Outputmedium

   After a noisy week, the Merge Gate team adds a line to the repository CLAUDE.md instructing the CI review job to post a comment only where the finding meets the written blocker or major criteria. Comment volume across the next 200 pull requests falls by a third, and 11 of those pull requests still carry a minor style comment. The team drafts a compliance note stating that minor comments can no longer reach a pull request. Which statement correctly assesses that note?

   • AIt is sound, because CLAUDE.md is loaded at the start of every run, so the instruction is in context for each finding the job produces during that session.
   • BIt is unsound, because CLAUDE.md guidance shifts the model's behaviour probabilistically, and only a check that inspects each finding before it is posted can make the rule hold on every run.check_circle Correct
   • CIt is unsound only for large pull requests, where the instruction sits far enough from the diff in the assembled context that it carries less weight over the findings generated at the end.
   • DIt is sound once the 11 comments are traced to runs started before the change landed, since a repository-level instruction overrides anything the job's own prompt asks for.

   Written guidance changes the likelihood of compliance; a rule that must hold every time needs enforcement outside the model. Instructions in CLAUDE.md, the system prompt or the job prompt all reach the model the same way, as text it conditions on. That is enough to move a rate, which is why volume fell by a third, and never enough to bound a behaviour, which is why 11 breaches remain. A compliance note asserting that something cannot happen is a claim about a guarantee, and the only mechanisms that supply one here operate outside generation: validating each finding's band against the criteria before the comment is posted, or gating the posting step so anything below major is dropped. Guidance and enforcement are complementary, and the note is describing the first as though it were the second.

   Why A is wrong: The loading behaviour described is accurate, which is what makes this tempting, but presence in context is not compliance; the instruction was in context for all 200 pull requests including the 11 that breached it.

   Why B is correct: Correct. The 11 surviving comments are the direct evidence: instructions in context steer generation without bounding it, so a deterministic claim needs enforcement outside the model.

   Why C is wrong: Position in context can affect adherence, so this names a real effect, but it turns a general absence of guarantee into a narrow size-dependent exception the evidence does not support.

   Why D is wrong: The stem places all 200 pull requests after the change, and there is no precedence rule by which a CLAUDE.md line overrides a prompt; both are guidance the model weighs together.

5. Context Management & Reliability

   15% of exam

   What you must be able to do. Keep the facts a long-running system depends on outside anything that gets summarised, propagate failures with enough structure for a coordinator to recover, and calibrate human review against measured accuracy by segment rather than an aggregate.

   In one sentenceContext is a lossy channel: protect the facts that must survive compaction, position the important material where it is read reliably, and make every downstream consumer able to tell a supported finding from a contested one.

   Recall check: answer these from memory first

   • Name what progressive summarisation is most likely to destroy, and where those facts should live instead.
   • List the valid escalation triggers, and name two commonly proposed triggers that are unreliable proxies.
   • A subagent's search fails. Say what it returns to the coordinator, and name the two anti-patterns either side of that.
   • Explain why an aggregate accuracy figure is not enough to justify automating high-confidence extractions.

   What it tests. Reliability over long horizons and across agents. It tests what progressive summarisation destroys, which is numbers, percentages, dates and stated customer expectations, and the lost in the middle effect where long inputs are handled reliably at their start and end while material in the middle gets dropped. It covers persistent case-facts blocks held outside summarised history, trimming verbose tool output before it accumulates, valid escalation triggers against unreliable proxies such as sentiment and self-reported confidence, structured error context propagated between agents, scratchpad files and state manifests for long codebase exploration and crash recovery, confidence calibration against a labelled validation set with stratified sampling of automated output, and preserving claim-to-source attribution through synthesis.

   How to study it. Treat this domain as one question asked six ways: what information does this design lose, and where does it lose it. Answer it for compaction, for tool output accumulating in history, for a summarisation step between subagent and coordinator, and for a synthesis pass merging several sources. Then learn the escalation triggers as a closed list, because the exam repeatedly offers a plausible fifth trigger that is really a proxy. On calibration, get one idea solid: an aggregate accuracy figure can hide a segment failing badly, so accuracy is validated per document type and per field before anything is automated, and stratified sampling of the automated stream is what catches a novel pattern later.

   Easy to confuse

   • Summarising history versus holding facts outside it. Compaction is a context strategy, not a storage strategy, and each cycle summarises a summary so precision decays. Transactional facts such as a verified identifier, an order reference and a disputed amount belong in a persistent block re-injected every request, where no summarisation step can touch them.
   • Silently returning empty results versus propagating a failure. Suppressing an error and reporting success makes the coordinator treat a gap as a finding, which is the worse of the two failures because nothing downstream can tell. Propagate the failure type, the attempted query, any partial results and the alternatives, and annotate the final synthesis with what was and was not covered.
   • Propagating a failure versus aborting the workflow. One subagent failing is not a reason to terminate everything, and the exam plants that as the over-correction next to silent suppression. Recover locally where the error is transient, propagate with context where it is not, and let the coordinator decide whether the remaining coverage is sufficient.
   • An explicit request for a human versus a complex case. An explicit customer request for a human is honoured immediately, without investigating first. Complexity on its own is not a trigger: the policy-side trigger is an exception or a gap in policy, and the progress-side trigger is an inability to make meaningful progress. Frustration is acknowledged, not escalated, where the issue is in scope.
   • A contradiction between sources versus a difference in date. Two credible figures that disagree get annotated with their attribution rather than silently resolved to one value, and publication or collection dates must travel in the structured output. Without the date, a legitimate change over time reads as a conflict, and the synthesis reports a dispute that does not exist.

   Worked example from the CCAR-F bank

   lock_openFree sampleContext Management & Reliabilitymedium

   The Resolution Desk team runs their Customer Support Resolution Agent with automatic context compaction: once a session passes 30 turns, the earlier turns are replaced by a model written summary and the raw turns are discarded. In one billing dispute the customer stated a disputed amount of 149.00 in turn 6, the summary written at turn 31 recorded only that a billing amount was in dispute, and at turn 44 the agent called process_refund for the full order value of 320.00. Which statement best explains this outcome?

   • AThe compaction step ran because the request had already exceeded the context window, so the turns holding the disputed amount were truncated before the summary could be written from them.
   • BThe process_refund input schema accepted 320.00 because that value sits under its maximum of 500, and that acceptance is what allowed a figure the customer never asked for to be paid out.
   • CThe session ran against a smaller context window than a 44 turn dispute requires, and moving the same workload to a model configured with a larger window would have retained the turn that held the figure.
   • DSummarisation is lossy, so a detail omitted from the summary is simply absent from the context afterwards, and once the raw turns were discarded the session held no remaining source from which the agent could recover the 149.00 figure.check_circle Correct

   Compaction is lossy and irreversible within a session, so any fact not carried into the summary cannot be recovered from the transcript. Automatic compaction rewrites earlier turns into a summary and discards the originals, which means the summary becomes the only representation of that stretch of the session. A value the summariser omits has no surviving source inside the conversation, so the agent cannot rediscover it by reasoning harder or by re-reading, and it falls back to whatever comparable number remains in context.

   Why A is wrong: Tempting because both overflow and compaction remove earlier turns, and an architect who has seen truncation errors will reach for that first. It is wrong because compaction runs to keep a session inside the window rather than as a consequence of breaching it, and turn 6 was available to the summariser, which simply did not carry the figure forward.

   Why B is wrong: Tempting because the schema genuinely did accept the call and a tighter bound feels like the missing control. It is wrong because schema validation checks the shape and range of an argument rather than whether the value is the correct one, so it explains nothing about where the 320.00 came from.

   Why C is wrong: Tempting because a larger window does postpone the point at which compaction fires. It is wrong here because the loss happened inside the summarisation step rather than at the window boundary, so a bigger window changes when the same lossy compression occurs rather than whether it drops the amount.

   Why D is correct: Correct. Compaction replaces turns with a compressed rendering of them, and anything the summariser drops is gone from the session state. The agent then reasoned from the only figure still present, the order value, because the disputed amount had no surviving representation anywhere in its input.

A study plan that works

1. Read the exam guide and inventory the six scenarios

   Day 1

   Read the CCAR-F exam guide end to end, then write the six published scenarios on one page: support agent, Claude Code codegen, multi-agent research, developer productivity, continuous integration, and structured data extraction. Four appear on any given form. For each, note the constraints it naturally carries, such as latency for a live support agent and a build-time budget for a pipeline job, because those constraints are what the items turn on.

2. Build a working agentic loop from scratch

   Week 1

   Implement the loop on the Claude Agent SDK yourself: send, branch on stop_reason, execute tools, append results, iterate to end_turn. Add one PreToolUse hook that blocks a call and one PostToolUse hook that reshapes a result. Two hours here makes Domain 1 mechanical instead of memorised, and it is the largest domain on the exam.

3. Design and break a set of tools

   Week 2

   Write three MCP tools with deliberately overlapping descriptions, watch the model misroute, then repair them with input formats, example queries, edge cases and an explicit boundary against the nearest alternative. Return a structured error with a category and a retryable flag, and separate an access failure from a valid empty result. Cover Task Statements 2.1 through 2.5 by hand rather than by reading.

4. Configure Claude Code properly on a real repository

   Week 2

   Set up a project CLAUDE.md, a package-level one, a path-scoped rule file with glob frontmatter, one skill with allowed-tools and argument-hint, and one project-scoped slash command. Verify which memory files actually load. Then run a headless review in a pipeline job with structured output. The scope questions on this exam are easy once you have watched a user-level rule fail to reach a teammate.

5. Drill structured output and its limits

   Week 3

   Build an extraction tool with a JSON schema, force it with tool_choice, and feed it documents messy enough to produce schema-valid nonsense. Add nullable fields and an unclear enum member, then write the validation step that compares a calculated total against a stated one and the retry that feeds the specific failure back. Finish by rewriting one vague quality prompt as explicit categorical criteria with an example per severity band.

6. Practise scenario questions and read every rationale

   Week 3-4

   Move to full scenario sets and read the explanation on every item, including the ones you answered correctly. The distractors on this exam are competent engineering choices that answer a different requirement, so the marks live in understanding why a good option is the wrong option here. Track which distractor family catches you: probabilistic where a guarantee was needed, assumed context, or a lossy signal.

7. Close weak domains, then sit a timed mock

   Week 4-5

   Use per-domain accuracy to pick the two domains dragging you down and drill those rather than re-reading what you already know. Then sit at least one full timed run to rehearse pacing across long scenario stems, and note that multiple-response items state how many answers to select, so read that line before evaluating options.

Know when you're ready

Exam-day tips

• Find the guarantee in the stem before you read the options. Words such as must, every time, before any, or a quoted residual failure rate mean a deterministic mechanism is required, and every probabilistic option is a distractor no matter how well written.
• Read the last sentence of the stem first. The scenarios are long and the requirement is usually in the final line, so knowing it before you read the setup turns a wall of context into a search.
• Check how many responses the item asks for. Multiple-response items state the number, and selecting the wrong count is a self-inflicted loss on questions you actually knew.
• When two options both look right, prefer the one that keeps information recoverable: structured error metadata over a generic status, attributed conflicting figures over a merged number, an explicit null over a silently missing field.
• Ask what the agent can actually see at that point. A large share of wrong options assume a subagent inherited context, that a compacted session still holds a figure, or that a session can objectively review its own output.
• Distrust both extremes around failure. Swallowing an error as success and aborting the whole workflow on one subagent failure are the two traps that flank the correct answer of local recovery plus structured propagation.
• Flag and move on. The stems are long enough that one stubborn item can cost you three easier ones, and every item is worth the same.

Frequently asked questions

Related certifications

Other Ai certifications with a study guide.

• AWS Certified AI Practitioner (AIF-C01) study guideAmazon Web Services
• NVIDIA-Certified Associate: Generative AI LLMs (NCA-GENL) study guideNVIDIA
• NVIDIA-Certified Associate: AI Infrastructure and Operations (NCA-AIIO) study guideNVIDIA
• NVIDIA-Certified Associate: Generative AI Multimodal (NCA-GENM) study guideNVIDIA
• NVIDIA-Certified Associate: Accelerated Data Science (NCA-ADS) study guideNVIDIA
• AI Governance Professional (AIGP) study guideIAPP
• Claude Certified Developer - Foundations (CCDV-F) study guideAnthropic
• Google Cloud Professional Machine Learning Engineer (PMLE) study guideGoogle Cloud
• GitHub Copilot (GH-300) study guideGitHub
• Microsoft 365 Certified: Copilot and Agent Administration Fundamentals (AB-900) study guideMicrosoft
• Microsoft Certified: Azure AI Fundamentals (AI-901) study guideMicrosoft