CCAR-F practice questions, answered and explained

A team moves to goal-oriented delegation and finds that subagents reach conclusions the coordinator cannot audit. What restores visibility without giving up adaptability?

• A Have the coordinator re-run each subagent's investigation for itself

Re-running each investigation in the coordinator discards the delegation entirely.

• B Return to procedural instructions, so that the path is known in advance

Reverting to procedure gives up the adaptability the team moved to goal-oriented delegation to gain.

• C Require each conclusion to come back with its evidence and its method

Correct. Goal-oriented delegation controls the destination rather than the route, so control is reasserted through the output contract.

• D Reduce each subagent's tool access, so that fewer paths are possible

Narrowing tools limits where the subagent can look without making its reasoning visible.

Goal-oriented delegation controls the destination, not the route — so control is reasserted through the output contract. Requiring evidence and method with every conclusion keeps the coordinator able to audit the reasoning while the subagent stays free to adapt its path.

You are prompting a verification subagent to test one claimed bug. What does its prompt need in order to complete without a round trip?

• A The claim, its exact location, the code itself, and the bar for refuting it

Correct. Verification needs the specific assertion, where to look, the material to look at, and a defined bar for refutation.

• B The claim, together with an instruction telling the verifier to be skeptical

Skepticism without evidence produces an opinion rather than a verdict.

• C The coordinator's own system prompt, so the verifier shares its standards

The coordinator's system prompt conveys standing behavior, not the claim under test.

• D The full list of all findings, so this one can be ranked against the others

The other findings are irrelevant to whether this one is real.

Verification needs the specific assertion, where to look, the material to look at, and a defined bar for refutation. Skepticism without evidence produces an opinion; the other findings are irrelevant to whether this one is real.

A server exposes an internal design-system specification that agents consult constantly, and an operation that files a ticket. How should each be exposed?

• A The specification as a resource, and filing a ticket as a tool

Correct. Stable reference content read repeatedly belongs in resources, while an action with a side effect must be a tool.

• B Both of them as resources, so that neither costs a tool call

An action with a side effect must be invoked deliberately, which resources do not do.

• C The specification as a tool, and filing a ticket as a resource

This has both backwards: the specification is content and the ticket is an action.

• D Both of them as tools, so the model decides when it needs each

Filing a ticket is not content and cannot be a resource, so exposing both as tools misses the saving on the specification.

Stable reference content that is read repeatedly belongs in resources, where it can be attached without a discovery call. An action with a side effect must be a tool, because it has to be invoked deliberately by the model. Filing a ticket is not content and cannot be a resource.

A shared MCP server configuration must carry an API token. What is the correct way to express it?

• A Store the literal token in the committed config and restrict repository access

Literal tokens leak the moment the repository is cloned or mirrored, whatever the access controls.

• B Pass the token as a command-line argument within the server's start command

Command-line arguments are visible in process listings.

• C Have each developer edit the committed config locally and not commit it back

Uncommitted local edits to a committed file get committed by accident.

• D Reference it by environment variable expansion, so each user supplies a value

Correct. Expansion is what lets one committed configuration serve everyone without containing a secret.

Environment variable expansion is what lets one committed configuration serve everyone without containing a secret. Literal tokens leak the moment the repository is cloned or mirrored, command-line arguments are visible in process listings, and uncommitted local edits get committed by accident.

Invoice dates arrive across six vendor formats and the extracted values are inconsistent. What is the most effective fix?

• A Specify a target format, with few-shot examples covering the variants

Correct. Naming the normalized target and showing the transformation on the variants that actually appear is what carries the rule.

• B Extract the date as free text and then normalize it in code afterwards

Normalizing in code afterwards still requires the same format knowledge, with less context to apply it.

• C Send each vendor's documents to a separately fine-tuned model instance

Separate models per vendor multiply maintenance without addressing the instruction gap.

• D Raise max_tokens so the model can reason carefully about each date

Token room is not the constraint on formatting a date.

Format inconsistency is corrected by naming the normalized target and showing the transformation on the variants that actually appear. Few-shot examples of the awkward formats are what carry the rule. Post-hoc normalization in code is a fallback that still requires the same format knowledge, and neither token limits nor separate models address the instruction gap.

A contract schema has a boolean auto_renews. Many contracts are silent on renewal. What should the schema do?

• A Remove the field and infer renewal downstream from the term length

Inferring from term length substitutes a guess for the field and loses the distinction entirely.

• B Keep the boolean and default it to true, as auto-renewal is the norm

Defaulting to true records a different claim the document never made, and industry norms are not evidence about this contract.

• C Keep the boolean and default it to false when renewal is not mentioned

Defaulting to false records a claim the document never made.

• D Make the field nullable, so silence is recorded distinctly from a no

Correct. A two-valued field cannot represent yes, no, and not stated, and nullability preserves the difference between absence and negation.

A two-valued field cannot represent three states: yes, no, and not stated. Defaulting either way records a claim the document never made, and that claim is indistinguishable from a real one downstream. Nullability preserves the difference between absence and negation.

Midway through exploring a large codebase, context is filling with file contents and the agent is starting to lose earlier findings. What is the correct response?

• A Start an entirely fresh session and begin the exploration again

Restarting discards the findings already established and repeats the work.

• B Write findings to a scratchpad and push exploration into subagents

Correct. A scratchpad preserves findings outside the window, and subagent isolation means further reading costs the main context only a conclusion.

• C Ask the model to summarize the conversation and continue in context

A summary in the same context is lossy and still leaves the bulk material present.

• D Increase max_tokens on all of the requests that follow this point

The output cap governs response length rather than context pressure.

Sustained exploration relies on keeping the durable output outside the context window and keeping bulk reading out of it. A scratchpad preserves findings across the session, and subagent isolation means dozens of file reads cost the main context only a conclusion. max_tokens governs output length, not context pressure.

A single recorded interview must be transcribed, then translated, then summarized. Which structure is correct?

• A A parallel fan-out, with one worker assigned to each of the stages

Parallelism has nothing independent to overlap, since each stage waits on the one before it.

• B A sequential pipeline, since each stage consumes the previous output

Correct. There is one item and a genuine chain of dependencies — nothing can be translated before it is transcribed.

• C A single agent doing all three of the steps with no structure at all

The stages are genuinely dependent, and leaving the structure implicit makes failures harder to locate.

• D A coordinator-worker structure with three workers and a synthesis step

A synthesis step has nothing to reconcile; there is a single item passing through three stages.

There is one item and a genuine chain of dependencies — nothing can be translated before it is transcribed. That is the case sequential pipelines exist for. Parallelism has nothing independent to overlap here, and a synthesis step has nothing to reconcile.

An agent is asked to write and run a migration script against a production database. Which review architecture is appropriate?

• A Direct execution, followed by a review of what the migration did

Reviewing afterwards inspects damage that has already occurred.

• B A multi-phase workflow verifying the SQL adversarially, in production

Verifying the SQL adversarially while running it in production still executes the change before anyone approves it.

• C Direct execution, since a migration is a fairly routine operation

A production migration is among the least routine operations there is, and it is hard to undo.

• D Plan mode, so the approach, tables, and rollback path are approved

Correct. Irreversible production changes sit at the top of the risk scale, and plan mode puts approval before execution — the only ordering that helps.

Risk level drives the choice, and irreversible production changes sit at the top of that scale. Plan mode puts approval before execution, which is the only ordering that helps when the action cannot be undone. Reviewing afterwards inspects damage that has already occurred.

Review findings must be posted as inline comments on the changed lines of a pull request. What must the output contain?

• A A suggested replacement for every one of the flagged lines

A suggested replacement helps the author but is not what positions the comment.

• B The file path and the line number each finding refers to

Correct. An inline comment has to be anchored, and the anchor is a path plus a line.

• C The commit hash that the review was actually run against

The commit hash identifies the revision rather than the location within it.

• D A severity ranking attached to each individual finding

Severity helps triage but does not tell the system where to attach the comment.

An inline comment has to be anchored, and the anchor is a path plus a line. Severity helps triage and suggestions help the author, but neither tells the system where to attach the comment.

What does forking a command cost?

• A A separate context to populate and its own tokens to spend

Correct. The separate context has to be populated and its own tokens spent, which is wasteful when the command reads almost nothing.

• B Nothing at all, since the isolation it provides is free

A fork is a subagent, and subagents are not free: it loads its own system prompt and instructions and pays for its own tool calls.

• C Access to the project's configured tools while it is running

Forked commands retain access to the project's tools.

• D The ability to write files to disk during the command's run

Forked commands retain file access; the filesystem is shared.

A forked command runs in a subagent, and subagents are not free: it spends its own tokens on its system prompt, CLAUDE.md, the skill content and its own tool calls. That price is worth paying when it saves the session from a flood of intermediate material, and not worth paying for a command that reads two lines. Forked commands retain file access and tools.

Two servers are connected: one exposes search over the issue tracker, the other search over the wiki. The agent picks wrongly about half the time. What is the fix?

• A Have the user name the source system in every single request

Pushing disambiguation onto the user is not a fix to the server.

• B Service-prefixed names, and descriptions that name each corpus

Correct. Service prefixes separate the names, and naming each corpus in the description tells the model which one to pick.

• C Disconnect one of the two servers so only one search remains

Disconnecting a server removes a capability to avoid a naming and description problem.

• D Rename the two tools search_a and search_b so they are distinct

Opaque suffixes make the names distinct without telling the model which corpus each one searches.

Identical names with unstated domains give the model nothing to choose on. Prefixing each tool with its service, as the MCP spec recommends for clients aggregating servers, separates the names, and descriptions that name the corpus, ideally pointing at the sibling, resolve the choice at selection time. Opaque suffixes add no meaning, disconnecting a server removes a capability, and pushing the disambiguation onto the user is not a fix to the server.

You need to know who last changed a function and why. Which tool is correct?

• A Read, opening the file and inspecting its comments

The file's current contents carry no record of who changed what.

• B Bash, used to query the version control history

Correct. History lives in the version control system and is reached by running a command, which is Bash's role.

• C Grep, searching the tree for the author's name

Author names are not recorded in the source, so searching for them finds nothing useful.

• D Glob, used to locate the relevant file first

Locating the file is a step that does not answer the question.

History lives in the version control system and is reached by running a command, which is Bash's role. The file's current contents carry no record of who changed what, and locating the file is a step that does not answer the question.

A CI step runs an agent to check a policy and must fail the build when the policy is violated. What is the cleanest mechanism?

• A Have the step exit non-zero, derived from the structured result

Correct. CI systems act on exit status, so the decision has to reach the pipeline through it, parsed from a structured result.

• B Have the pipeline always succeed and rely on humans reading logs

A step that never fails is not a gate at all.

• C Have the agent open a pull request describing the violation

Opening a pull request reports the violation without failing the build.

• D Have the agent print FAILED and grep the log for that string

Log-scraping breaks the first time the wording shifts.

CI systems act on exit status, so the decision has to reach the pipeline through it — parsed from a structured result rather than guessed from prose. Log-scraping breaks the first time the wording shifts, and a step that never fails is not a gate.

A prompt asks Claude to analyze a contract in prose, then give a one-line risk verdict that a script extracts. Exact schema compliance is not needed. What is a sound lightweight method?

• A Ask for the verdict in the first sentence, before any of the reasoning is written out

Putting the verdict first means it is written before the reasoning that should inform it.

• B Ask for the verdict as the last sentence and have the script split the whole reply on periods

Periods appear in amounts, abbreviations and section numbers, so splitting on them is fragile.

• C Ask for the verdict in bold text and have the script look for the first bold phrase

Bold text is used for emphasis throughout prose, so the first bold phrase may not be the verdict.

• D Ask for the verdict inside a named XML tag and have the script read that tag's contents

Correct. A named tag gives the script an unambiguous delimiter without a full schema.

When a response mixes free reasoning with one extractable part and strict compliance is unnecessary, asking for that part inside a named XML tag is a documented, simple method: the tag is easy to find and does not depend on sentence boundaries or markup. Splitting on periods breaks on abbreviations and decimals, the first bold phrase may be something else, and demanding the verdict first removes the reasoning it was meant to rest on.

To cut costs, a team moved a JSON extraction to a smaller Claude model whose maximum output is lower. Documents that extracted cleanly before now end with stop_reason "max_tokens" even at that model's maximum output. The team wants the smaller model for every document. What is the durable fix?

• A Revert to the original model, since truncation shows the smaller one is not capable of the task

The failure is an output ceiling, not evidence the smaller model cannot extract.

• B Instruct the smaller model to be more concise so that its output fits beneath the lower ceiling

Compressing the output degrades the extraction and still depends on document size.

• C Retry truncated requests on the smaller model until one of the attempts completes within its limit

The same input produces output of roughly the same size, so retries meet the same cap.

• D Split each document so that per-request output fits well within the smaller model's output limit

Correct. Bounded per-request output makes the job portable across models with different limits.

Maximum output differs by model, so a job sized to one model's ceiling breaks on another. Sizing each request's output well below the limit makes the extraction independent of which model runs it. Conciseness instructions trade away fidelity, retries hit the same ceiling on the same input, and reverting contradicts the requirement and mistakes an output-limit problem for a capability problem.

A repository commits enableAllProjectMcpServers: true in .claude/settings.json so newcomers skip approval. On a fresh clone, before the folder is trusted, its servers still wait for approval. Why?

• A Committed settings are read only after the first git pull that follows a clone

Nothing about loading settings depends on a pull after cloning.

• B Project settings are read in claude -p runs, not in interactive sessions

Interactive sessions read project settings; that is where the approval prompt appears.

• C That key is valid only in user settings and is ignored in every project file

The key is honored in project settings once the workspace is trusted; the issue is trust, not location.

• D Trust is the user's decision; a repository cannot switch on its own servers

Correct. Letting a repository approve its own servers would let untrusted code grant itself tools.

Approving an MCP server is a trust decision that belongs to the user, not to the code being trusted. Claude Code ignores approvals committed in a project's own settings until the workspace itself is trusted, so a hostile repository cannot switch on its own servers. Approvals from the user's own settings or managed settings still apply. The key is valid in project settings once the folder is trusted, and project settings are read in interactive sessions too.

A team plans three nightly batches — summaries, classifications and translations — each with its own system prompt and model, believing a batch must be uniform. What is accurate?

• A Separate batches are needed, since a batch is billed at the rate of its costliest model

Billing is per request at that request's model, discounted by half.

• B One batch can hold all three, since each request carries its own independent parameters

Correct. Batched requests are independent and each carries its own params.

• C One batch works only if all requests share a system prompt, which is cached for the batch

No shared system prompt is required; each request supplies its own.

• D Separate batches are needed, since every request in one batch must use the same model

Model is a per-request parameter, so one batch can mix models.

Each batched request has its own custom_id and its own full Messages params, including model and system prompt, and requests are processed independently, so different request types can be mixed in one batch. Splitting by type is an organizational choice, not a requirement. No shared-system-prompt rule or costliest-model billing exists; each request is billed at 50% of its own model's price.

A knowledge-base search tool returns the full text of the top 10 articles, often 40,000 tokens per call, and most of it is irrelevant. How should the tool be redesigned?

• A Return the full text of only the top-ranked article, since ranking puts the answer first

The best answer is not reliably in the top-ranked result, so this hides relevant material.

• B Keep the full texts but strip whitespace and markup so each result takes fewer tokens

Compressing formatting leaves the bulk of ten irrelevant articles in context.

• C Return titles, IDs and snippets, plus a separate tool that fetches one article in full

Correct. Snippets let the agent choose, and full text is loaded only for articles it needs.

• D Return all 10 full texts in one call and tell the agent to ignore irrelevant passages

Ignored text still occupies the window and competes for attention.

Returning lightweight results and letting the agent fetch only what it chooses keeps each search cheap while leaving full detail one call away. Trusting rank alone hides the answer when it sits in the second or fifth article. Stripping markup trims tokens slightly but still loads ten articles, and an instruction to ignore text does not remove it from context.

A team triggers summarization only when a request fails with a 'prompt is too long' error. What is wrong with that design?

• A The client cannot detect that error, so the summarization trigger would never actually fire

The prompt-too-long error is a normal 400 response the client can handle.

• B Nothing, since waiting for the limit postpones the cost of summarizing for as long as possible

Waiting costs quality in the turns before the limit and leaves no room to summarize.

• C Summarizing needs headroom of its own, and quality degrades before the limit is ever reached

Correct. Trigger early enough to have room and before context rot sets in.

• D Summarizing on every turn from the start is required to keep context size perfectly constant

Constant-size context is not the goal, and per-turn summarization is wasteful.

At the limit there is no room left for the summarization request, and accuracy and recall have already been degrading as the context grew. Triggering at a threshold comfortably below the window leaves headroom and keeps quality up. The error is an ordinary 400 the client can see, and summarizing every turn is needless cost and churn.