CCAR-F Practice Exam
The seven Claude courses in this book teach the material. This page tells you whether you can use it under a clock, which is a different question and the only one that predicts your result.
The real exam gives you 60 items in 120 minutes, framed inside four production scenarios drawn from a bank of six. Questions do not ask what a feature is. They hand you a system that is already running and already misbehaving, quantify the symptom, and offer four changes that all sound reasonable. You are being scored on whether you can tell a fix from a plausible-sounding neighbour.
This exam covers all six scenarios rather than four, so nothing you draw on the day is unfamiliar. It is otherwise built to match: same item count, same weighting, same style, including the multiple-response items that the single-select quizzes inside the courses cannot express.
Sit It Here
The timer runs for 120 minutes and submits for you when it reaches zero. Your answers are kept in this browser, so a refresh will not lose an attempt. At the end you get a total, a percentage correct in each of the five domains, and every question back with your answer beside the right one, why the right one addresses the cause, and why each plausible alternative does not.
Open it in its own tab if you want the full window, which is closer to how you will sit the real thing.
The same sixty items are written out below, if you would rather work on paper and mark yourself against the answer key.
Before You Start
Sit it properly or the number means nothing.
- 120 minutes. Set a timer. Two minutes per item is the actual pressure, and it is most of the difficulty.
- Nothing open. No notes, no documentation, no agent. The real exam is proctored with a cleared workspace.
- Answer every item. There is no penalty for a wrong answer.
- Do not scroll to the answer key. It is at the bottom of this page. Reading an explanation before you have committed to an answer converts a diagnostic into a summary you will forget.
- Six items ask for two answers and say so. Score them all-or-nothing.
Write your answers on paper as you go, then mark them in one pass at the end.
Scenario 1: Customer Support Resolution Agent
You are building a customer support resolution agent with the Claude Agent SDK. It handles returns, billing disputes, and account issues. It reaches your backend through MCP tools named get_customer, lookup_order, process_refund, and escalate_to_human. The target is 80 percent first-contact resolution, with sound judgment about when to hand off.
Items 1 to 11.
1. Your agent resolves 61 percent of contacts without escalation against an 80 percent target. Reading transcripts, you find it escalates cases where the policy is unambiguous and it has every tool it needs, while it improvises on cases that turn on an exception nobody wrote down. What is the most effective first change?
- A. Have the agent emit a confidence score before each response and escalate anything below a threshold.
- B. Add explicit escalation criteria to the system prompt with few-shot examples showing a resolved case and an escalated case side by side.
- C. Train a classifier on historical tickets to predict escalation need before the agent runs.
- D. Widen the agent's tool access so fewer cases require a handoff.
2. Production logs show the agent calling get_customer when a user asks about an order, instead of lookup_order. Both tool descriptions are one line long and both accept a similar-looking identifier. What is the most effective first step?
- A. Expand each tool description to state what it accepts, what it returns, and when to use it rather than the other one.
- B. Add five to eight few-shot examples showing order-related phrasing routed to
lookup_order. - C. Add a routing layer that inspects the user's message and pre-selects the tool before each turn.
- D. Merge both into a single
lookup_entitytool that accepts any identifier and decides internally.
3. In roughly one call in eight, the agent skips get_customer and calls process_refund using only the name the customer typed. Twice this month that produced a refund on the wrong account. What change most reliably prevents it?
- A. Rewrite the system prompt to state that customer verification is mandatory before any refund.
- B. Add few-shot examples that always show
get_customerbeing called first. - C. Reorder the tool definitions so
get_customerappears first in the list. - D. Add a hook that blocks
process_refunduntilget_customerhas returned a verified customer ID in this session.
4. Your finance team sets a rule: refunds above 500 dollars need a human. Which implementation gives the strongest guarantee?
- A. A sentence in the system prompt stating the limit and instructing the agent to escalate above it.
- B. A few-shot example showing a 600 dollar request being escalated.
- C. A
PreToolUsehook that inspects the refund amount and redirects to escalation when it exceeds the limit. - D. A note in the
process_refundtool description stating the limit.
5. A customer writes one message containing three separate problems: a damaged item, a duplicate charge, and a request to change their address. The agent addresses the damaged item and ignores the rest. What is the right fix?
- A. Cap each conversation at one issue and ask the customer to open separate tickets.
- B. Increase
max_tokensso the reply has room for all three answers. - C. Escalate any message that appears to contain more than one issue.
- D. Instruct the agent to decompose multi-part requests, investigate each part, then synthesize one reply covering all of them.
6. lookup_order sometimes fails. Which return shape best enables the agent to recover on its own? Select two.
- A. A stack trace from the backend service.
- B. A generic "service unavailable" string for every failure type.
- C. An error category distinguishing a transient failure from a business-rule rejection from a permission problem.
- D. An immediate escalation to a human on any failure.
- E. A boolean indicating whether retrying could plausibly succeed.
7. Your agent calls process_refund, the tool succeeds, and the model then tells the customer the refund failed. Inspecting the request, the tool result was appended as a user message but the assistant turn containing the tool_use block was left out of the history. What happens?
- A. The call succeeds and the model reasons correctly, because
tool_use_idis sufficient to correlate them. - B. The model silently ignores the result and answers from prior context.
- C. The API rejects the request, because a tool result refers to a
tool_usethat is not present in the conversation. - D. The model requests the same tool again on the next turn.
8. Which stop reason means your loop must execute something and send another request?
- A.
end_turn - B.
max_tokens - C.
tool_use - D.
stop_sequence
9. A teammate proposes ending the loop when the assistant's text contains a closing phrase such as "let me know if you need anything else." Why is this the wrong termination condition?
- A. It is slower than checking a field.
- B. It parses natural language to make a control-flow decision, when
stop_reasonalready reports termination unambiguously. - C. Closing phrases vary by language and would need translation.
- D. It works, but only if temperature is set to zero.
10. After a long multi-turn conversation, the agent begins repeating questions the customer already answered. Which change most directly addresses the cause?
- A. Raise
max_tokensso more of the conversation fits in each reply. - B. Switch to a model with a larger context window.
- C. Maintain a running structured summary of established facts and keep it near the top of the context.
- D. Restart the session whenever the conversation exceeds twenty turns.
11. When the agent escalates, human agents complain they have to re-read the whole transcript. What should the handoff include? Select two.
- A. A structured summary naming the customer, the root cause as diagnosed, and the recommended action.
- B. The full untrimmed conversation transcript.
- C. What the agent already attempted and what the result was.
- D. The agent's confidence score.
- E. A list of every tool available to the agent.
Scenario 2: Code Generation with Claude Code
Your team uses Claude Code for generation, refactoring, debugging, and documentation across a shared repository. You are standardizing how it is configured so that every developer gets the same behaviour from a fresh clone.
Items 12 to 21.
12. You want a /review slash command running your team's checklist to be available to every developer as soon as they clone the repository. Where does the command file belong?
- A. In the project's
.claude/commands/directory. - B. In
~/.claude/commands/on each developer's machine. - C. In a
commandsarray inside.claude/config.json. - D. In a section of the root
CLAUDE.md.
13. Your repository has React components using hooks, API handlers with a specific error-handling style, and test files scattered next to the code they cover. You want the right conventions applied automatically based on which file is being edited. What is the most maintainable approach?
- A. Put every convention in the root
CLAUDE.mdunder per-area headings and let Claude infer which applies. - B. Create a skill per code type in
.claude/skills/containing the relevant conventions. - C. Create rule files in
.claude/rules/with frontmatter glob patterns scoping each set of conventions to matching paths. - D. Place a separate
CLAUDE.mdin each subdirectory containing that area's conventions.
14. You have been asked to restructure a monolith into services. It touches dozens of files and the service boundaries are genuinely open questions. Which approach fits?
- A. Plan mode, to explore dependencies and settle an approach before editing.
- B. Direct execution with detailed upfront instructions specifying each service.
- C. Direct execution, letting the boundaries emerge as the work proceeds.
- D. Direct execution, switching to plan mode only if unexpected complexity appears.
15. A colleague reports that plan mode "does not really do anything" because their read-only commands still executed. What is actually true?
- A. Plan mode blocks every tool, so their observation indicates a misconfiguration.
- B. Plan mode only applies to subagents, not the main session.
- C. Plan mode is advisory and the model may ignore it at will.
- D. Plan mode prevents changes to your system while read-only inspection proceeds normally.
16. You want a project skill to do a large analysis without its intermediate output filling the main conversation. Which frontmatter setting achieves this?
- A.
context: fork - B.
allowed-tools - C.
argument-hint - D.
model
17. A skill's frontmatter lists allowed-tools: Read, Grep. A reviewer assumes this prevents the skill from writing files. Are they right?
- A. Yes. The field is an allowlist and anything absent is blocked.
- B. Yes, but only when the skill runs with
context: fork. - C. No. The field pre-approves those tools so they run without a prompt; it does not restrict what else can be used.
- D. No, because the field applies to slash commands rather than skills.
18. A personal skill and a project skill share a name. Which one takes effect?
- A. The project skill, because project configuration is closest to the work.
- B. Whichever loaded first in the session.
- C. The personal skill, because personal configuration overrides project configuration.
- D. Neither; the collision raises an error at startup.
19. Your team needs a shared MCP server for the internal ticket system, and you personally want an experimental server nobody else should get. What configuration achieves both?
- A. Both in the project's
.mcp.json, with the experimental one commented out for others. - B. Both in your user-level configuration, since project files should not contain server definitions.
- C. The shared one in the project's
.mcp.json, the personal one in your user-level configuration; both are available to you at once. - D. Only one may be active at a time, so alternate as needed.
20. A long exploration session has filled with verbose file listings and search output, and the agent has started answering from general patterns rather than the code it read earlier. Which two moves most directly address this? Select two.
- A. Delegate the verbose exploration to a subagent so its output never enters the main thread.
- B. Write key findings to a scratchpad file and re-read it as needed.
- C. Raise the temperature so the model considers more possibilities.
- D. Re-paste the original request at the end of every turn.
- E. Ask the model to be more careful.
21. You resume a session from yesterday. Several files it examined have since changed on disk. What is the risk?
- A. The stored tool results are now stale, and the model will reason from them with full confidence unless something re-reads the files.
- B. Resumption fails, because the session hash no longer matches.
- C. Claude Code re-reads every file automatically on resume.
- D. The session resumes with the file contents omitted entirely.
Scenario 3: Multi-Agent Research System
A coordinator agent delegates to specialized subagents: one searches the web, one analyzes documents, one synthesizes findings, one drafts reports. The system produces cited reports on topics you supply.
Items 22 to 32.
22. You run the system on "the impact of AI on creative industries." Every subagent completes successfully and the synthesis reads well, but the report covers only visual arts, omitting music, writing, and film. The coordinator's log shows it split the topic into digital art, graphic design, and photography. Where is the fault?
- A. The web search subagent's queries were too narrow.
- B. The document analysis subagent filtered out non-visual sources.
- C. The synthesis subagent failed to notice the coverage gap.
- D. The coordinator's decomposition was too narrow, so the subagents covered their assignments correctly and the assignments were wrong.
23. Your coordinator will not spawn subagents at all. Which configuration is most likely missing?
- A. The subagents lack system prompts.
- B.
Taskis absent from the coordinator'sallowedTools. - C.
max_tokensis set too low. - D. The subagents were not registered with the MCP server.
24. The synthesis subagent produces summaries missing key findings the search subagent clearly discovered. What is the most likely cause?
- A. The synthesis subagent's context window is too small.
- B. The findings were not passed explicitly in the synthesis subagent's prompt, and subagents do not inherit the coordinator's history.
- C. The search subagent returned results in the wrong order.
- D. The coordinator invoked the subagents in the wrong sequence.
25. You want the search and document-analysis subagents to run at the same time. How?
- A. Invoke them in consecutive turns as quickly as possible.
- B. Emit multiple
Tasktool calls in a single coordinator response. - C. Set a concurrency option in the coordinator's configuration.
- D. Run two coordinators in parallel.
26. The search subagent times out mid-task. Which return to the coordinator best enables intelligent recovery?
- A. Retry with exponential backoff inside the subagent, returning "search unavailable" only after exhausting attempts.
- B. Return structured error context: the failure type, the query attempted, any partial results, and possible alternatives.
- C. Catch the timeout and return an empty result set marked successful.
- D. Propagate the exception to a top-level handler that ends the run.
27. Testing shows the synthesis agent frequently needs small factual checks, currently handled by returning to the coordinator, which invokes search, then re-invokes synthesis. This adds round trips and 40 percent latency. Your evaluation finds 85 percent of these checks are simple lookups such as dates and figures; 15 percent need real investigation. What is the most effective change?
- A. Give synthesis a scoped
verify_facttool for simple lookups, leaving complex verification to delegate through the coordinator as it does now. - B. Batch all verification needs and send them to search at the end of the synthesis pass.
- C. Give synthesis full access to every web search tool so it never round-trips.
- D. Have search proactively cache extra context around each source in anticipation.
28. Reports read fluently but citations have drifted: claims appear without the source they came from. Where does attribution most commonly get lost?
- A. During summarization steps, when findings are compressed without carrying claim-source mappings through.
- B. During the search subagent's retrieval step.
- C. During report formatting.
- D. During the coordinator's initial decomposition.
29. Two credible sources give different figures for the same market size. What should the synthesis output do?
- A. Select the value from the more recent source and discard the other.
- B. Select the value from the more authoritative source and note that others exist.
- C. Average the two values.
- D. Preserve both values with their attributions and annotate the disagreement explicitly.
30. Your pipeline keeps flagging conflicts between sources that turn out, on inspection, to be reporting different years. What schema change most directly fixes this?
- A. Require a publication or collection date on every extracted claim, so a difference across time is distinguishable from a contradiction.
- B. Raise the threshold at which two values count as conflicting.
- C. Restrict the pipeline to a single source per topic.
- D. Have the model judge which value is most plausible.
31. The coordinator receives synthesis output covering only part of the research goal. Which pattern handles this?
- A. Return the partial report and note the limitation.
- B. Re-run the entire pipeline from the start.
- C. Increase the number of subagents so more ground is covered initially.
- D. Have the coordinator evaluate synthesis output for gaps, re-delegate targeted queries for what is missing, and re-invoke synthesis until coverage is sufficient.
32. A four-hour run crashes at hour three. What design limits the loss? Select two.
- A. Each agent exports its state to a known location as it works.
- B. The whole pipeline runs inside a single long-lived session.
- C. Every agent writes to one shared log file.
- D. The coordinator loads a manifest on resume and injects recovered state into agent prompts.
- E. The run is retried automatically from the beginning on failure.
Scenario 4: Developer Productivity with Claude
You are building developer productivity tooling on the Claude Agent SDK. It helps engineers explore unfamiliar codebases, understand legacy systems, generate boilerplate, and automate repetitive work. It uses the built-in tools and integrates MCP servers.
Items 33 to 41.
33. An engineer asks which files define a particular interface across a large repository, and they do not know the filenames. Which built-in tool fits first?
- A.
Read, iterating over the tree. - B.
Glob, matching a filename pattern. - C.
Bash, running a custom script. - D.
Grep, searching file contents for the interface name.
34. Your tool needs data from the company's internal service catalog, which has a REST API and no filesystem presence. What is the right integration?
- A. A
Bashtool call issuing curl requests. - B. Pasting catalog contents into the system prompt.
- C. A
Readtool pointed at a cached export. - D. An MCP server exposing catalog lookups as tools.
35. Your MCP server should expose a browsable catalog of internal documentation the agent can pull in when relevant, plus an action that opens a ticket. How should these be modelled?
- A. The documentation catalog as resources, the ticket creation as a tool.
- B. Both as tools, since the agent invokes both.
- C. Both as resources, since both concern internal systems.
- D. The documentation catalog as a tool, the ticket creation as a resource.
36. An engineer asks a high-level question about a system they have never seen. Answering means reading many files, most of which will not matter. What keeps the main conversation usable?
- A. Read every file into the main context and let the model sort it out.
- B. Ask the engineer to narrow the question first.
- C. Delegate the exploration to a subagent, which returns conclusions while the main agent keeps the high-level thread.
- D. Increase
max_tokenson the main agent.
37. You want to explore two different refactoring approaches from the same analysis baseline without redoing the analysis. Which mechanism fits?
- A. Running two separate sessions from scratch.
- B. Forking the session so each branch inherits the shared analysis and diverges from there.
- C. Compacting between the two explorations.
- D. Writing the analysis to a file and pasting it into a new session.
38. Your coordinator spawns a subagent to trace a dependency chain. The subagent returns a correct answer to a question the coordinator did not ask. What is the most likely cause?
- A. The subagent's model was too small.
- B. The subagent had too many tools available.
- C. The subagent's prompt stated a procedure rather than the goal and the quality bar, so it optimized for the wrong target.
- D. The coordinator's temperature was too high.
39. You want a reusable "generate a service scaffold" capability that takes an argument, runs in isolation, and is available to the whole team. Where does it belong?
- A. A section in the root
CLAUDE.md. - B. A personal skill in your user configuration.
- C. A project skill in
.claude/skills/withcontext: forkand an argument hint. - D. A shell script in the repository.
40. Your .mcp.json needs an API token that must not be committed. What is correct?
- A. Commit the token and rotate it frequently.
- B. Reference the credential through environment variable expansion in the configuration.
- C. Move the server to user scope so the file is not in the repository.
- D. Store the token in
CLAUDE.md, which is not code.
41. Two engineers get different behaviour from the same repository. One has personal instructions that contradict the project's. What resolves it?
- A. The project instruction wins, because it is in the repository.
- B. Both reach the model and nothing resolves the contradiction for you.
- C. The most recently edited file wins.
- D. Claude Code raises a conflict warning and halts.
Scenario 5: Claude Code for Continuous Integration
You are integrating Claude Code into a CI/CD pipeline. It runs automated code review, generates test cases, and comments on pull requests. Feedback must be actionable, and false positives must stay low enough that engineers keep reading it.
Items 42 to 50.
42. Your pipeline runs claude "Analyze this pull request for security issues" and the job hangs. Logs show it waiting for interactive input. What is correct?
- A. Set an environment variable to force headless operation.
- B. Redirect stdin from
/dev/null. - C. Add a
--batchflag. - D. Add the
-p(or--print) flag so it processes the prompt, prints the result, and exits.
43. Your pipeline must turn findings into inline comments programmatically. What should the invocation produce?
- A. Prose the pipeline parses with regular expressions.
- B. A markdown table.
- C. A file the pipeline reads afterwards.
- D. Structured JSON output the pipeline consumes directly.
44. A pull request modifies 14 files. Your single-pass review returns detailed feedback on some files, superficial comments on others, misses obvious bugs, and flags a pattern in one file while approving identical code in another. How should you restructure?
- A. Require developers to split large pull requests before review runs.
- B. Switch to a model with a larger context window so all 14 files fit comfortably.
- C. Split into focused passes: each file reviewed individually, then a separate pass for cross-file effects.
- D. Run three independent passes and report only findings appearing in at least two.
45. Engineers have started muting your review bot. Sampling shows roughly half of comments are matters of taste rather than defects. What is the most effective change?
- A. Reduce the number of comments by reporting only the top three findings.
- B. Define explicit criteria for what counts as a finding, so borderline style opinions are excluded by rule.
- C. Move the comments to a summary rather than inline.
- D. Run the review only on files with more than a threshold number of changed lines.
46. Your reviewer is inconsistent on a category of case that is genuinely ambiguous in your codebase. What most directly improves consistency?
- A. Lowering the temperature.
- B. Running the review twice and taking the union.
- C. Asking the model to be more consistent.
- D. Few-shot examples showing how that specific ambiguity should be resolved.
47. Your manager proposes moving two workflows to the Message Batches API for its cost saving: a blocking pre-merge check developers wait on, and an overnight technical-debt report. How do you evaluate this?
- A. Move the overnight report only; keep the pre-merge check real-time.
- B. Move both, polling for completion.
- C. Move neither, because batch results arrive out of order.
- D. Move both, with a fallback to real-time if a batch runs long.
48. You submit 100 files as a batch and nine fail. What lets you resubmit precisely those nine?
- A. The order of results in the response.
- B. Re-running the whole batch.
- C. A
custom_idon each request, correlating responses back to inputs. - D. Timestamps on each response.
49. A review task involves finding issues, assessing severity, and drafting remediation. Doing it in one prompt produces shallow results in all three. What is the pattern?
- A. Chain the steps: a focused pass per stage, each taking the previous output as input.
- B. Raise
max_tokensso the single response has room. - C. Ask for a longer answer.
- D. Run the same prompt several times and merge.
50. After tightening criteria, you want to know whether false positives actually fell. What measurement tells you? Select two.
- A. The total number of findings produced.
- B. The proportion of findings a maintainer would act on, sampled across recent merged pull requests.
- C. The average length of each finding.
- D. The change in that proportion before and after the criteria change, on the same pull requests.
- E. The runtime of the review job.
Scenario 6: Structured Data Extraction
You are building a system that extracts structured information from unstructured documents, validates it against JSON schemas, and passes it downstream. Accuracy must stay high and edge cases must be handled rather than hidden.
Items 51 to 60.
51. Some documents omit a field entirely. Your extractor currently returns a plausible-looking value anyway. What schema change addresses this?
- A. Add a description instructing the model not to guess.
- B. Mark the field required, forcing the model to look harder.
- C. Add a post-processing step that discards implausible values.
- D. Make the field nullable, so absence has a representation the model can return.
52. A category field has five known values, but real documents occasionally contain something outside them. What design handles this without corrupting the data?
- A. An enum of the five known values plus "other", paired with a detail string capturing what was actually found.
- B. Add a sixth enum value named "miscellaneous."
- C. Leave the field free-text.
- D. Reject documents containing unknown values.
53. You want the model's output to conform to your schema every time. Which mechanism gives the strongest guarantee?
- A. Requesting JSON in the system prompt and parsing the reply.
- B. Defining the schema as a tool and requiring the model to call it.
- C. Providing a few-shot example of the desired JSON.
- D. Post-processing the reply to repair malformed JSON.
54. After moving to schema-enforced output, a colleague says validation is now unnecessary. What have they missed?
- A. Schema enforcement removes syntax errors but not semantic ones: a value can be well-formed, correctly typed, and wrong.
- B. Nothing; conforming output is correct output.
- C. Schema enforcement applies only to nested objects.
- D. Validation is only needed for optional fields.
55. Your validation-retry loop retries every failure. Which failures are worth retrying?
- A. All of them, since retries are inexpensive.
- B. Format mismatches, where the information is present and rendered incorrectly, but not absences, where the information is not in the document.
- C. None; a failure means the document is unusable.
- D. Only failures on required fields.
56. Invoices sometimes state a total that does not match their own line items. Your schema cannot compute sums. How do you surface this?
- A. Ask the model to verify the arithmetic and report only if correct.
- B. Extract the stated total and the sum of line items as separate fields, and compare them in ordinary code.
- C. Reject invoices whose totals look unusual.
- D. Extract only the line items and always compute the total yourself.
57. You want to route uncertain extractions to human review. What is the most useful form of confidence?
- A. One confidence score per document.
- B. A per-field confidence score, with thresholds calibrated against a labelled validation set.
- C. The model's stated certainty in prose.
- D. A count of fields the model found.
58. You have automated everything above your confidence threshold. How do you keep learning about errors inside that automated set?
- A. Wait for downstream complaints.
- B. Lower the threshold periodically.
- C. Re-run high-confidence extractions with a second model and compare.
- D. Take a stratified random sample of high-confidence extractions and check them against ground truth on an ongoing basis.
59. Your pipeline reports 97 percent accuracy overall and stakeholders want to remove human review. What must you check first?
- A. Whether accuracy holds across every document type and field, since an aggregate can hide a segment performing far worse.
- B. Whether the sample was large enough for 97 percent to be stable.
- C. Whether the model version has changed recently.
- D. Whether 97 percent meets the contractual threshold.
60. Documents arrive in several layouts: some cite sources inline, some use a bibliography, some describe values in prose and others tabulate them. Extraction quality varies by layout. What most directly improves it? Select two.
- A. Requiring all documents be converted to one layout before extraction.
- B. Few-shot examples demonstrating extraction from each of the differing layouts.
- C. Measuring accuracy separately per layout so you know which ones actually need work.
- D. Increasing
max_tokens. - E. Lowering the confidence threshold for unusual layouts.
Answer Key
Stop here if you have not finished. Every explanation names why the correct option addresses the cause and why each distractor does not, because on this exam the distractors are the whole difficulty.
Each answer is tagged with the domain it tests, so you can total by domain in the scoring section below.
Scenario 1: Customer Support Resolution Agent
1. B (Domain 1). The symptom is a decision boundary the agent cannot see: it escalates the easy cases and improvises on the hard ones, which is what unclear criteria look like from the outside. Explicit criteria with contrasting examples is the proportionate first move. Self-reported confidence (A) fails because the agent is already confidently wrong on the hard cases, so the score it produces is the same broken judgment in a new format. A classifier (C) adds labelled data and training infrastructure before prompt work has been tried. Widening tool access (D) treats a judgment problem as a capability problem.
2. A (Domain 2). Tool descriptions are the primary signal the model uses to choose between tools, and yours are one line each for two tools that look alike. Fixing the description is the lowest-effort change that addresses the actual cause. Few-shot examples (B) add tokens on every request without repairing the underlying ambiguity. A routing layer (C) rebuilds in code the selection the model is designed to do. Consolidation (D) is a defensible architecture but a large change to propose as a first step when the immediate problem is that two descriptions are too thin to tell apart.
3. D (Domain 1). Money is involved and the required order is known in advance, so this calls for a deterministic guarantee rather than better odds. A hook that blocks the call until the prerequisite is satisfied cannot be talked out of it. A stronger instruction (A) and examples (B) both improve compliance from a probabilistic mechanism, which is what already failed one time in eight. Reordering definitions (C) has no defined effect on call order.
4. C (Domain 1). Same principle as item 3, stated as a policy limit. A PreToolUse hook inspects the actual argument and can redirect before the call executes. The prompt (A), the example (B), and the description note (D) are all instructions the model may follow, and a financial control that holds most of the time is not a control.
5. D (Domain 1). Decomposition, parallel investigation, and one synthesized answer is the named pattern for multi-concern requests. Forcing separate tickets (A) shifts the work to the customer. More tokens (B) gives room for an answer the agent never planned to write. Escalating anything multi-part (C) sends away the cases the agent could handle.
6. C and E (Domain 2). Recovery requires knowing what kind of failure occurred and whether another attempt could plausibly help. A stack trace (A) is operator detail the model cannot act on and will sometimes try to interpret. A uniform string (B) erases the distinction the agent needs. Escalating on any failure (D) throws away recoverable cases.
7. C (Domain 1). A tool_result must answer a tool_use that is present in the conversation, so omitting the assistant turn makes the request invalid and it is rejected. It does not degrade quietly: tool_use_id (A) identifies the call but does not substitute for the turn that made it. The silent-ignore (B) and re-request (D) options describe failure modes that do not occur here.
8. C (Domain 1). tool_use means Claude has asked for a tool and cannot proceed until you run it and return the result. end_turn (A) terminates the loop. max_tokens (B) means the response was truncated, which needs handling but not tool execution. stop_sequence (D) means a configured sequence was emitted.
9. B (Domain 1). Deciding control flow by reading prose is a named anti-pattern, and it is unnecessary because stop_reason reports termination as a field. Speed (A) is not the issue. Translation (C) is a symptom of the same mistake rather than the reason it is wrong. Temperature (D) does not make prose a reliable control signal.
10. C (Domain 5). Repeating answered questions means established facts have decayed out of effective attention. A maintained structured summary, kept where the model attends reliably, restores them at a fixed cost. More output tokens (A) does not affect what the model retains from input. A bigger window (B) misreads the problem: attention thins across long inputs whether or not they fit. Restarting (D) discards the facts entirely.
11. A and C (Domain 1). The human lacks the transcript, so the handoff must carry the identity, the diagnosis, the recommendation, and what has already been tried, so the human does not repeat it. The full transcript (B) is the thing they are complaining about. A confidence score (D) does not tell them what to do. The tool list (E) is irrelevant to a human.
Scenario 2: Code Generation with Claude Code
12. A (Domain 3). Project-scoped commands live in the repository's .claude/commands/, so they are version-controlled and arrive with a clone. The home directory (B) is personal scope and is not shared. The config array (C) describes a mechanism Claude Code does not have. CLAUDE.md (D) carries instructions and context, not command definitions.
13. C (Domain 3). Glob patterns in rule frontmatter attach conventions to paths, which is what "test files scattered next to the code" requires: the rule follows the file pattern regardless of directory. Inference from headings (A) is not deterministic. Skills (B) load when invoked or chosen, not automatically by path. Per-directory CLAUDE.md files (D) are directory-bound and cannot follow a pattern spread across the tree.
14. A (Domain 3). Plan mode earns its overhead when there are multiple valid approaches and the cost of discovering a constraint late is high, which describes service boundaries exactly. Detailed upfront instructions (B) assume you already know the answer. Emergent boundaries (C) risk rework. Switching only on surprise (D) ignores that the complexity is stated in the requirement rather than hypothetical.
15. D (Domain 3). Plan mode prevents changes to your system; read-only inspection continues, which is the entire point of exploring before committing. It is not a total tool block (A), it is not subagent-only (B), and it is enforced rather than advisory (C). Note that some documentation phrases this as "no execution of tools," which reads more absolutely than the behaviour warrants.
16. A (Domain 3). context: fork runs the skill in an isolated context so its intermediate work does not accumulate in the main conversation. allowed-tools (B) governs pre-approval, argument-hint (C) is input guidance for the caller, and model (D) selects the model.
17. C (Domain 3). This is the trap the field's name invites. allowed-tools pre-approves the listed tools so they run without an approval prompt; it is not a sandbox and does not block anything else. Answers A and B describe a restriction the field does not impose, and D misattributes the field.
18. C (Domain 3). Across levels, personal configuration overrides project configuration, and enterprise overrides personal. Proximity to the work (A) is a reasonable-sounding rule and the wrong one. Load order (B) and a startup error (D) describe behaviours that do not occur.
19. C (Domain 2). Project scope and user scope are separate and simultaneous: the shared server ships in the repository, your experimental one lives in your user configuration, and both are available in the same session. Commenting out (A) is not scoping. Moving the shared one to user scope (B) breaks it for everyone else. The one-at-a-time claim (D) is false.
20. A and B (Domain 5). Delegation keeps verbose output out of the main thread entirely, and a scratchpad file survives compaction in a way conversation history does not. Temperature (C) is unrelated to context degradation. Re-pasting the request (D) treats a symptom while continuing to grow the context. Asking for care (E) is not a mechanism.
21. A (Domain 5). Stored tool results are a snapshot from when they ran. On resume they are presented as fact, and the model has no way to know the files moved on. This is the reliability failure that reads as confident and wrong. Resumption does not fail (B), files are not automatically re-read (C), and contents are not dropped (D).
Scenario 3: Multi-Agent Research System
22. D (Domain 1). The log names the cause: the topic was split into three visual-arts subtasks, so every subagent succeeded at a task that was wrong to assign. The other options blame downstream agents that performed correctly within their scope, which is the most common misdiagnosis in coordinator systems: healthy components and a wrong answer.
23. B (Domain 1). A coordinator invokes subagents through the Task tool, so Task must be in its allowedTools. Missing system prompts (A) would degrade subagent quality rather than prevent spawning. A low max_tokens (C) truncates responses. Subagents are not registered with MCP servers (D); that describes a different mechanism.
24. B (Domain 1). Subagents start with the context you give them and do not inherit the coordinator's conversation history. Findings that were never placed in the synthesis prompt are simply absent. A small window (A) would truncate rather than omit specific findings. Result ordering (C) and invocation sequence (D) do not create missing content.
25. B (Domain 1). Parallelism comes from emitting several Task calls within one response. Consecutive turns (A) are sequential by construction. There is no concurrency setting of the kind described (C), and multiple coordinators (D) multiplies the orchestration problem rather than parallelizing within one.
26. B (Domain 2). Structured error context lets the coordinator decide: retry with a narrower query, try another route, or proceed with partial results and mark the gap. Internal retries returning a generic status (A) hide the information needed for that decision. An empty result marked successful (C) converts a failure into a silent wrong answer. Terminating the run (D) discards recoverable work.
27. A (Domain 2). The 85 to 15 split is the whole question. A scoped tool for the common, simple case removes most round trips while the existing coordination path still handles the cases that need it, which is least privilege applied to a measured distribution. Batching (B) creates blocking dependencies when later synthesis steps rely on earlier verified facts. Full tool access (C) over-provisions for 15 percent of cases. Speculative caching (D) cannot predict what synthesis will question.
28. A (Domain 5). Attribution is lost at compression: a summarization step that keeps the claim and drops the mapping produces text that reads well and cannot be traced. Retrieval (B) is where sources are gathered, formatting (C) is downstream of the loss, and decomposition (D) precedes any claims existing.
29. D (Domain 5). Two credible sources disagreeing is information, and the report should preserve both with attribution and mark the disagreement, distinguishing contested findings from settled ones. Choosing by recency (A) or authority (B) discards evidence on a rule the reader cannot see. Averaging (C) invents a number no source reported.
30. A (Domain 5). Without a date, the pipeline cannot tell a change over time from a contradiction, so every year-over-year difference registers as a conflict. Requiring publication or collection dates makes the comparison answerable. A higher threshold (B) hides real conflicts along with false ones. One source per topic (C) removes the cross-checking. Plausibility judgment (D) replaces evidence with a guess.
31. D (Domain 1). Iterative refinement is the named pattern: evaluate the synthesis for gaps, re-delegate specifically for what is missing, and re-synthesize until coverage holds. Reporting the gap (A) accepts an incomplete answer. A full re-run (B) repeats work that succeeded. More subagents (C) does not help when the problem is coverage assessment rather than capacity.
32. A and D (Domain 5). State exported to a known location plus a manifest the coordinator loads on resume turns a three-hour loss into one agent's work. A single long-lived session (B) is what makes the crash total. A shared log (C) records events without making state recoverable. Restarting from the beginning (E) is the loss the design is meant to prevent.
Scenario 4: Developer Productivity with Claude
33. D (Domain 2). The engineer knows the interface name, not the filenames, so the search is over contents: that is Grep. Read (A) requires knowing what to open. Glob (B) matches filename patterns, which is the information you do not have. Bash (C) reaches for a custom script when a built-in tool does exactly this.
34. D (Domain 2). A REST service with no filesystem presence is what MCP servers exist for: the catalog becomes tools with descriptions the model can select on. Curl through Bash (A) works and gives up description quality, error structure, and any hope of reliable selection. Pasting the catalog (B) spends context on data that may be stale. A cached export (C) trades freshness for convenience without being asked to.
35. A (Domain 2). Resources are for content the agent pulls in when relevant; tools are for actions with effects. A documentation catalog is browsable content, and opening a ticket changes the world. Making both tools (B) or both resources (C) collapses a distinction the protocol draws deliberately, and D inverts it.
36. C (Domain 5). Delegation keeps the verbose reading out of the main thread while the coordinator keeps the high-level question. Reading everything into main context (A) is the problem. Narrowing the question (B) shifts work to the engineer who asked precisely because they do not know the system. More output tokens (D) does not change what enters the input.
37. B (Domain 1). Forking gives both branches the shared analysis baseline and lets them diverge, which is the exact use case. Fresh sessions (A) repeat the analysis. Compacting (C) reduces context rather than branching it. Writing and pasting (D) reconstructs by hand what forking does natively.
38. C (Domain 1). Subagent prompts should state the goal and the quality bar rather than a procedure, so the agent can adapt when reality differs from the plan. A procedural prompt gets followed literally toward the wrong target. Model size (A), tool count (B), and temperature (D) do not explain a correct answer to a different question.
39. C (Domain 3). Reusable, argument-taking, isolated, and shared points at a project skill with context: fork and an argument hint. CLAUDE.md (A) holds context, not invocable capabilities. A personal skill (B) is not shared. A shell script (D) gives up the model entirely.
40. B (Domain 2). Environment variable expansion keeps the reference in the committed file and the secret out of it. Committing and rotating (A) commits a secret. Moving to user scope (C) breaks the shared server to solve a secrets problem. CLAUDE.md (D) is committed too.
41. B (Domain 3). Both instructions reach the model and nothing arbitrates between them, which is why contradictions across scopes are a configuration bug rather than something the system settles. Note this differs from name collisions between same-named items, where personal overrides project. Repository precedence (A), recency (C), and a halting warning (D) all describe arbitration that does not happen.
Scenario 5: Claude Code for Continuous Integration
42. D (Domain 3). The -p or --print flag is the documented non-interactive mode: it takes the prompt, writes the result to stdout, and exits. The environment variable (A) and --batch flag (C) name things that do not exist. Redirecting stdin (B) is a Unix workaround that does not address how the command is meant to run.
43. D (Domain 3). Structured JSON is what a pipeline can act on without guessing. Regex over prose (A) breaks the first time phrasing shifts. A markdown table (B) is prose with alignment. Writing to a file (C) moves the parsing problem rather than removing it.
44. C (Domain 4). The symptom set, uneven depth plus contradictory verdicts on identical code, is attention dilution across a large input. Focused passes give each file consistent depth, and a separate integration pass catches what only appears across files. Splitting the pull request (A) shifts the burden to developers without improving the system. A larger window (B) is the tempting wrong answer: fitting the input is not the same as attending to it evenly. Consensus across runs (D) suppresses genuine findings that surface intermittently.
45. B (Domain 4). Half the comments being taste means the definition of a finding is too loose, so tighten the rule rather than the volume. Reporting fewer findings (A) hides the problem and may drop real defects. Moving comments to a summary (C) changes placement, not signal. A line-count threshold (D) filters by an unrelated proxy.
46. D (Domain 4). Few-shot examples targeted at the specific ambiguity are the named technique for exactly this: showing how your codebase resolves a case the model cannot infer. Temperature (A) narrows variation without supplying the missing judgment. Taking the union of two runs (B) increases noise. Asking for consistency (C) is not a mechanism.
47. A (Domain 4). Batching halves the token price and can take up to 24 hours with no latency guarantee, which suits an overnight report and rules out anything a developer is blocked on. Moving both (B) makes people wait on a process with no deadline. The ordering claim (C) is false, since custom_id correlates responses. A timeout fallback (D) adds machinery to avoid making the distinction the question is asking for.
48. C (Domain 4). custom_id is the correlation key: it maps each response to the request that produced it, so you can resubmit exactly the failures. Result order (A) and timestamps (D) are not reliable identity. Re-running everything (B) pays for the 91 that succeeded.
49. A (Domain 4). Sequential decomposition gives each stage a focused prompt and feeds it the previous stage's output, which is why chained passes beat one prompt asked to do three jobs. More tokens (B) and a longer answer (C) address length rather than focus. Repeating and merging (D) repeats the same shallow pass.
50. B and D (Domain 4). The rate at which findings are actionable is the measure, and the before-and-after comparison on the same pull requests is what isolates your change from differences in the code. Total findings (A) can fall while precision worsens. Finding length (C) and job runtime (E) measure nothing about correctness.
Scenario 6: Structured Data Extraction
51. D (Domain 4). A model with no way to express absence will produce something, so give absence a representation: a nullable field makes "not present" a legal answer. An instruction (A) is a request rather than a structure. Marking it required (B) forces the fabrication it is meant to prevent. Discarding implausible values (C) catches only the guesses that look wrong.
52. A (Domain 4). The enum plus "other" plus a detail string keeps the closed set useful while preserving what was actually found, so unexpected values are recorded rather than forced into a neighbouring bucket. A "miscellaneous" member (B) records that something was unusual without saying what. Free text (C) discards the structure. Rejecting documents (D) throws away the cases most worth seeing.
53. B (Domain 4). Defining the schema as a tool and requiring the call is the mechanism that constrains the output shape, rather than asking for a shape and hoping. Prompt requests (A) and examples (C) improve the odds without enforcing. Repairing malformed JSON (D) treats the symptom after the fact.
54. A (Domain 4). Structured output eliminates the class of errors where JSON does not parse or types are wrong. It has nothing to say about whether the value is the right one: a correctly typed, schema-valid, entirely incorrect date passes. That distinction is a named objective. Options C and D describe limits the mechanism does not have.
55. B (Domain 4). Retrying is useful when the information is present and was rendered wrong, and useless when the information is not in the document, because no number of attempts will conjure it. Retrying everything (A) spends money on the impossible cases. Abandoning all failures (C) discards the recoverable ones. Field requiredness (D) is unrelated to whether a retry can succeed.
56. B (Domain 1). Extract the stated value and the evidence for it as separate fields, then compare them in ordinary code, which is deterministic and auditable in a way asking the model to check its own arithmetic is not. Reporting only when correct (A) hides the failures. Rejecting unusual totals (C) uses a heuristic where a comparison is available. Always computing yourself (D) discards the stated value, which is the thing you need to disagree with.
57. B (Domain 5). Per-field confidence lets you route the uncertain field rather than the whole document, and a threshold means something only when it was calibrated against labelled data. A document-level score (A) is too coarse to route on. Prose certainty (C) is not a number you can threshold. A field count (D) measures completeness, not reliability.
58. D (Domain 5). Stratified random sampling of the automated set is how you measure the error rate you have chosen not to look at, and how novel failure patterns surface before they become complaints. Waiting for complaints (A) is a detection strategy with an unbounded delay. Lowering the threshold (B) changes what is automated without measuring anything. A second model (C) tells you where two models disagree, which is not the same as ground truth.
59. A (Domain 5). An aggregate can be excellent while one document type runs far below it, and that segment is exactly where automation would do harm. Per-type and per-field breakdown before reducing review is the named requirement. Sample size (B) is a real concern and a smaller one than a hidden segment. Model version (C) and contractual thresholds (D) do not tell you whether the number is evenly earned.
60. B and C (Domain 4). Targeted few-shot examples teach the layouts that are failing, and per-layout measurement tells you which those are, so the two work together. Normalizing every document first (A) is a large upstream project that may not be possible. More tokens (D) does not address structural variety. Lowering the threshold for odd layouts (E) automates exactly the cases you have least reason to trust.
Scoring
Count one point per item. The six multiple-response items score all-or-nothing: both correct options, no extras.
What the number means
Be careful here, because this is where practice exams usually lie to you.
The real exam reports a scaled score from 100 to 1,000 with a cut score of 720, and the scaling comes from a formal standard-setting study that equates across exam forms of differing difficulty. That mapping is not published, so no practice test can tell you what raw score becomes 720, and any that claims to is inventing it. Treat your raw score as a raw score.
As a working target: 48 out of 60, and no single domain below 70 percent. That is a margin, not a threshold. It is chosen so that a bad draw of scenarios on the day does not decide your result.
Per-domain breakdown
Score each domain separately. The real exam reports percent-correct by domain on your score report, and an uneven profile is more useful than a total: a strong overall score hiding one weak domain is the profile most likely to fail on a different scenario draw.
| Domain | Items here | Blueprint weight | Your score |
|---|---|---|---|
| 1. Agentic Architecture and Orchestration | 16 | 27% | / 16 |
| 2. Tool Design and MCP Integration | 9 | 18% | / 9 |
| 3. Claude Code Configuration and Workflows | 11 | 20% | / 11 |
| 4. Prompt Engineering and Structured Output | 13 | 20% | / 13 |
| 5. Context Management and Reliability | 11 | 15% | / 11 |
| Total | 60 | 100% | / 60 |
The item counts approximate the published weights rather than matching them exactly. Domain 1 is exact; the others sit within two items. The gap is deliberate: an extra genuine question about context reliability is worth more than a padded one about tool configuration.
What to do with a weak domain
Do not re-read the whole course. Go to the specific project.
| Weak domain | Go build |
|---|---|
| 1. Agentic Architecture | Projects 1 and 2 in Build AI Agents with the Claude Agent SDK, and Project 1 in The Loop by Hand |
| 2. Tool Design and MCP | Project 1 in the Agent SDK course, plus the MCP configuration steps in Claude Code for Teams |
| 3. Claude Code Configuration | The full project in Claude Code for Teams |
| 4. Prompt Engineering and Structured Output | All four projects in Structured Extraction Pipelines, and Project 2 in Claude Code as a CI Worker |
| 5. Context Management and Reliability | Project 2 in the Agent SDK course, and Project 4 in Structured Extraction |
A weak domain is almost never a gap in reading. It is a gap in having built the thing and watched it fail.
Sources
Written against the Claude Certified Architect - Foundations Exam Guide, version 1.0, effective July 2026, which is the authoritative statement of what is tested. Items are written against the guide's task statements, in-scope topic list, and the style of its own sample questions. They are not reproduced from the exam, which is confidential, and no one writing this has seen it.
- Anthropic Partner Academy, where the current exam guide is published. Download it and read Section 6 in full: it is the definitive list, and it changes.
- Certifications and the FDE path, for how registration and the two-stage path work.
Where this page and a current exam guide disagree, the guide wins.