60 Fragen und Antworten zur Claude Certified Architect Prüfung CCAR-F

Posted on Oct 16 • Originally published at szymonpaluch.com

Architect Foundations (CCAR-F) Architect Professional (CCAR-P) Associate (CCAO-F) Developer (CCDV-F)

All 60 original questions from my free Claude Certified Architect Foundations (CCAR-F) practice set are on this page, each with its answer and explanation. I walk through three of them step by step: the right answers, the traps and where to study. The same questions also run as an online test with a study mode, a timed 120-minute attempt and results by domain.

Take the free practice exam → 60 questions · no account needed

Studying for Claude Certified Architect Foundations and stuck between two plausible answers? Remembering the letter will only get you so far. These three examples work through the requirement, the mechanism that meets it and the reason to reject each alternative.

I wrote these questions during preparation, using the public exam objectives. They do not come from the live exam. Each asks you to pick one of four options. The $500 threshold and 11% rate below are assumptions in the exercises, not measurements from my client projects.

I passed CCAR-F on July 15 with 833/1000. My account of taking the exam covers the preparation and the sitting itself. That score is personal experience, not evidence that the question set produces the same result for other people.

The official CCAR-F has 60 questions, a 120-minute limit and a passing score of 720 on a 100 to 1000 scale. It includes both single-answer and multiple-response items and selects four of six scenarios. My mock covers all six scenarios with single-answer questions only. This comparison follows Anthropic’s July 2026 exam guide, version 1.0, checked on September 29. Here are the domain weights and the question counts in my set:

On the exam, I found decisions with several plausible solutions the hardest. These exercises therefore start with a concrete constraint: who can approve a refund, how to represent a missing value, or when to condense a session. Your choice should follow from that constraint.

This set covers Foundations. The Architect Professional (CCAR-P) guide describes that separate scope and its own examples. A CCAR-F mock score does not assess readiness for Professional.

If Professional is your exam, take the 63-question CCAR-P practice exam instead. It follows the Professional guide and, like the real exam, includes multiple-response questions.

Associate and Developer have their own free full-length mocks too, each written from its own exam guide.

Pick an answer and write one sentence explaining your choice before reading the explanation. You can then check whether you understood the mechanism or merely recognized a familiar term. These are questions 3, 55 and 20 from the full set below, lightly edited for this walkthrough.

Company policy states that any refund above $500 must be approved by a manager. An audit shows the support agent has autonomously called process_refund for higher amounts several times. What is the best way to guarantee the policy holds?

Correct: A. A PreToolUse hook can deny a tool call before the refund executes. Here it checks the amount and routes larger refunds for approval. B and D influence model behaviour but do not enforce the limit. C also blocks permitted refunds up to $500. In production, enforce the rule in the refund service too, so other paths cannot bypass the check. See tool blocking with Agent SDK hooks.

To test the hook, prepare two calls: $500 and $501. The first should proceed; the second should wait for a person. Then explicitly ask the agent to ignore the limit and try again. Check that the code still stops the refund. You do not have to guess whether the model understood the request. If the amount is absent or cannot be parsed, stop the call and report an error too.

For documents that lack a purchase-order number, Claude invents a plausible-looking number about 11% of the time instead of signaling absence. Downstream systems treat the fabricated values as real. What is the best schema-level fix?

Correct: D. Allowing null gives the model a way to represent a missing number without supplying a string. Nullable and optional mean different things: a field can be required while its value may be null. A adds a confidence estimate, B changes tool selection, and C illustrates the format; none defines absence in the schema. This fix does not guarantee factual accuracy, so still test extraction on documents without a number. The structured outputs documentation lists supported types, including null.

Use a document with no purchase-order number and expect "po_number": null. Then supply a document with a number and check that the model copies it unchanged. Both cases need to pass. Valid JSON alone is insufficient: a fabricated number can fit the schema too. If the model still adds one, compare the result with the source and inspect the field’s instructions.

Midway through a coherent multi-hour refactor, the session approaches its context limit. The history is full of superseded intermediate diffs, but the task and the goal are unchanged and the latest file states are still valid. What should you do to keep going without losing the thread?

Correct: D. /compact summarizes the history and frees context for continued work. Tell it which goal and decisions to preserve, then check the summary: compression can omit details. A requires rebuilding context from scratch, B creates a branch, and C leaves the redundant history in place. The Claude Code context recommendations show how to give /compact a specific focus.

Before compaction, record what should work after the refactor and which tests demonstrate it. You can ask: /compact Preserve the refactor goal, changed files and errors we have not fixed yet. Read the resulting summary. If an important decision is missing, add it before the agent resumes editing. Then run the same tests. This exercise continues one existing task.

If you chose another option, identify the requirement it misses. D1 is about preventing an operation, D4 about representing missing data, and D5 about continuing the same task. That mistake tells you what to revisit in the documentation.

Here is the full set, in the same order as the online test and the PDF. Each question names its domain and scenario. The answer and its explanation stay folded under “Show the answer”, so choose your option first.

Keep count of your correct answers. The next section turns that count into the mock’s score. To match the real exam’s time limit, give yourself 120 minutes for all 60.

Scenario: Customer Support Resolution Agent

A customer support resolution agent built with the Claude Agent SDK reaches backend systems through custom MCP tools (get_customer, lookup_order, process_refund, escalate_to_human). The engineering team wrote a wrapper loop that ends the conversation whenever the assistant's text matches a closing phrase like "let me know if there's anything else." Production logs show that in 11% of sessions the loop terminates while a tool_use block is still pending, so the refund is never actually executed. What is the correct way to drive the agentic loop?

Show the answer Correct answer: A. The agentic loop must be driven by the API's stop_reason signal, not by parsing natural-language content. tool_use means the model wants a tool run, so you execute it, append the tool_result, and iterate; end_turn is the only correct termination signal. Matching closing phrases (B) is exactly the brittle text-parsing that caused the bug and will still misfire. An iteration cap plus consecutive text heuristic (C) can truncate legitimate multi-step work and still ignores stop_reason. A classifier (D) is over-engineering that reintroduces natural-language inference where a deterministic protocol field already gives the answer.

When the support agent invokes escalate_to_human, human agents report they must re-read the entire raw conversation to understand each case, and average handle time for escalated tickets has risen. What should the agent do at the moment of escalation to fix this?

Show the answer Correct answer: D. Effective human handoff requires a structured summary that front-loads exactly what the human needs: the problem, confirmed identifiers, what was tried, and a recommendation. That is what removes the re-reading burden and shortens handle time. Dumping the full transcript (A) is the current failure mode — it forces the human to reconstruct the case themselves. Extended thinking (B) improves the model's own reasoning but produces no artifact for the human. Escalating earlier (C) changes when tickets arrive, not the missing information problem, and would likely lower first-contact resolution.

Company policy states that any refund above $500 must be approved by a manager rather than auto-issued. The support agent, however, has autonomously called process_refund for amounts over $500 in several audited cases. What is the best way to guarantee the policy holds?

Show the answer Correct answer: A. A policy violation that must never occur calls for an interception (PreToolUse) hook that deterministically blocks the disallowed process_refund call and redirects to escalation. The hook enforces the threshold regardless of what the model decides. A prompt instruction (B) is advisory and is precisely what the audited violations bypassed. Removing the tool (C) throws away all legitimate sub-$500 automation and tanks first-contact resolution. Fine-tuning (D) is heavy, slow, and still probabilistic — it cannot promise the hard $500 boundary is never crossed. Worked through step by step above

get_customer and lookup_order call two different backend systems that return dates in different formats (ISO vs. US) and amounts with inconsistent currency notation. Logs show the model occasionally misreads these heterogeneous fields, e.g., treating a refund amount in the wrong units. What is the most robust remedy?

Show the answer Correct answer: B. A PostToolUse hook is the designed mechanism for normalizing heterogeneous tool output into a consistent schema before it ever reaches the model, eliminating the ambiguity deterministically. Asking the model to normalize in-prompt (A) leaves the same error-prone inference in place — the source of the current misreads. A larger context window (C) addresses volume, not format inconsistency, and does nothing for unit confusion. A separate formatting subagent (D) adds a full round-trip and orchestration overhead for a transformation a hook performs inline and reliably.

The coordinator has already run get_customer and confirmed the account, then spawns subagents to check order history and refund eligibility in parallel. Those subagents return results that contradict the confirmed account — some even re-run get_customer and pick a different customer match. What is the correct fix?

Show the answer Correct answer: D. Subagents run with their own fresh context and do not inherit the coordinator's conversation, so any prior findings they must use have to be passed explicitly in the Task prompt. Handing each subagent the confirmed customer record eliminates the contradictions and the redundant lookups. Enlarging a "shared" context window (A) misdescribes the architecture — there is no shared window to grow across the hub-and-spoke boundary. There is no SDK mechanism that auto-injects a global variable into subagents (B); it is a plausible-sounding non-feature. Having each subagent re-run get_customer (C) is exactly what produced the divergent matches and duplicates work.

process_refund handles both full order refunds and small partial goodwill credits. Logs show the agent issues full refunds when only a partial credit was warranted in 17% of cases because it cannot tell from the single tool which behavior it is invoking. What is the best fix?

Show the answer Correct answer: B. When one tool conflates two distinct behaviors, the reliable fix is to split it into separately named tools whose descriptions encode clear boundaries, making the choice explicit at selection time. Option A adds context but leaves the overloaded tool ambiguous, so the same misclassification persists. Option C helps at the margins but few-shot prompt examples cannot substitute for a tool interface that still exposes one undifferentiated action. Option D only guarantees that some tool is called, not that the correct refund behavior is chosen, and does nothing about the underlying overloading.

When the customer database is briefly unreachable, get_customer returns a plain empty result, and the agent tells the customer "I can't find any account with that information" and closes the case. Real accounts are being turned away during transient outages. What should the MCP tool return instead?

Show the answer Correct answer: C. The root cause is that an access failure is being conveyed as a valid empty result, so the agent draws the wrong conclusion; the tool must emit structured error metadata (errorCategory, isRetryable) that separates 'lookup failed' from 'no such customer.' Option A retries blindly with no bound and still lacks the semantics to tell the two conditions apart. Option B may reduce some timeouts but does not fix the core ambiguity when a failure does occur. Option D over-escalates by treating validation and business outcomes identically to infrastructure faults, defeating the resolution target and burying real transient errors.

For refunds above the agent's $500 authority, process_refund correctly declines, but it returns a generic isError response. Logs show the agent then retries the same $640 refund three times before eventually giving a confusing reply. How should the tool signal this condition?

Show the answer Correct answer: D. A policy-limit rejection is a business error that is deterministically non-retryable; encoding errorCategory "business" with isRetryable false tells the agent that retrying is pointless and that escalation is the correct next step. Option A applies retry logic meant for transient faults to a permanent business rule, wasting calls and never succeeding. Option B changes policy to dodge the control rather than handling the boundary the business intends to enforce. Option C is a prompt-only patch that leaves the error semantically indistinguishable from a retryable one, so behavior stays fragile compared with programmatic metadata the agent can act on reliably.

In longer billing-dispute conversations, the agent uses progressive summarization to keep the history compact. Testers find that after several turns it quotes the wrong refund amount and an incorrect order date, even though those values appeared earlier. What is the best remedy?

Show the answer Correct answer: A. Progressive summarization compresses away precise numbers, dates, and stated expectations, so the fix is to keep those exact values in a persistent case-facts block that lives outside the summarized transcript and is re-supplied unchanged. Option B only delays the same information loss once conversations grow, and does not protect the specific fields. Option C is wasteful and can still be re-summarized away, plus it re-incurs latency and error surface each turn. Option D improves reasoning but cannot recover facts that summarization has already discarded from context.

A customer gives only the name "Maria Garcia." get_customer returns three distinct matching accounts. Logs show the agent proceeds with the most recently active match, and in several cases it has processed refunds against the wrong customer's order. What is the correct behavior?

Show the answer Correct answer: D. When multiple customer records match, the agent must not guess; requesting an additional identifier resolves the ambiguity and prevents acting on the wrong account. Option A guesses on recency and is exactly the behavior producing misdirected refunds. Option B guesses on name similarity, which cannot distinguish two people with the same name. Option C needlessly hands off a case the agent can resolve itself with one clarifying question, undermining the first-contact-resolution target when disambiguation is straightforward.

Scenario: Code Generation with Claude Code

Your team standardized naming and error-handling conventions by adding them to ~/.claude/CLAUDE.md on the tech lead's machine. Everything works for the lead, but three newly onboarded engineers who cloned the repo report that Claude Code ignores the conventions entirely, even though git status shows a clean checkout. What is the most effective fix?

Show the answer Correct answer: C. The CLAUDE.md hierarchy loads user-scoped instructions from ~/.claude/CLAUDE.md, which is personal to a machine and is NOT shared through version control — the classic 'new teammate didn't get the instructions' symptom. Committing the conventions to the project-scoped.claude/CLAUDE.md (or repo root) makes them load for every clone, so C is correct. An @import to ~/.claude/CLAUDE.md (A) fails because that file doesn't exist on the teammates' machines. Running /memory (B) only inspects already-loaded memory files; it cannot pull in instructions that were never in a shared scope. A skill (D) is on-demand rather than always-loaded, so it wouldn't provide the persistent conventions the team wants.

Your team's /investigate-flaky skill greps the entire test suite, reads dozens of files, and prints verbose exploration before it answers. Developers notice that after running it, the main session is cluttered with raw output and Claude's subsequent answers in that session degrade in quality. What is the best fix?

Show the answer Correct answer: B. Skills support context:fork in their SKILL.md frontmatter precisely to isolate verbose, exploratory work in a separate context and return only the distilled result, keeping the main session clean — so B is correct. A CLAUDE.md instruction to summarize (A) is a prompt-only measure that runs after the pollution already occurred and is unreliable. A larger context window (C) does not fix attention dilution from irrelevant accumulated output; it just delays it. An allowed-tools list (D) restricts which tools the skill may use but does not stop verbose output from landing in the main context, and it would also cripple the investigation the skill exists to perform.

A team's.claude/skills/dep-audit/ skill is meant to be run manually before releases, but Claude keeps auto-invoking it mid-session whenever dependency files come up, dumping roughly 4,000 lines of resolution output into unrelated refactoring sessions. The team still wants engineers to be able to run /dep-audit explicitly. What is the most effective fix?

Show the answer Correct answer: B. disable-model-invocation: true is the frontmatter switch designed for exactly this: it removes the skill from Claude's automatic invocation while keeping explicit /dep-audit slash invocation available, so release engineers keep the workflow and refactoring sessions stay clean. /compact (A) reacts only after the 4,000 lines have already polluted and degraded the session, and compaction can discard needed detail. Deleting the description (C) is a hack — the description also documents the skill for humans and tooling, and gutting metadata to suppress triggering is not the supported mechanism. Moving the instructions into CLAUDE.md (D) changes where guidance loads but makes the verbose audit part of every session's baseline context, worsening rather than fixing the problem.

A shared generate-docs skill is supposed to read source and write Markdown into docs/, but twice it has run Edit and shell rm and overwritten source files. Adding the reminder "only write to docs/, never edit source" to the skill body has not reliably stopped it. What is the best way to guarantee the skill cannot touch source?

Show the answer Correct answer: C. When deterministic tool restriction is required, prompt text is insufficient because the model can still choose a forbidden tool; the allowed-tools frontmatter enforces the restriction at the harness level, scoped exactly to this skill. Stronger prose (option A) is still an instruction the model may ignore, which is the observed failure. Plan mode (option B) adds friction to every run and relies on the human catching the bad action rather than preventing it. A global PreToolUse hook (option D) is the right idea at the wrong scope — it would police every session's edits when the problem is confined to one skill, and allowed-tools is the purpose-built, skill-scoped mechanism.

A shared /scaffold-component skill expects a component-name argument, but telemetry shows teammates invoke it with no argument or a malformed one about a third of the time, producing empty or misnamed scaffolds. What is the most effective way to reduce these malformed invocations?

Show the answer Correct answer: A. argument-hint is the frontmatter field designed precisely to surface the expected argument and format at the moment of invocation, guiding the caller before a malformed run happens. Documenting usage in CLAUDE.md (option B) helps the model but does not present the hint to the human at invocation time, where the mistake occurs. Renaming (option C) is a cosmetic nudge that neither shows the format nor prevents empty calls. A body instruction to ask when missing (option D) is a runtime fallback that adds a round-trip and still does not communicate the expected format up front — the direct, purpose-built fix is argument-hint.

A developer needs three changes that all touch the shared PaymentStatus enum and the several functions that switch on it. They sent each change as a separate sequential message; after the third message the project no longer compiles because the earlier edits did not anticipate the later ones. What is the best way to structure the request?

Show the answer Correct answer: D. Fixes that interact — here all three touch one enum and its dependent switches — should be batched into a single message so the model reasons about them jointly and keeps the code internally consistent; only independent changes benefit from being sequenced separately. Separate fresh sessions (option A) make the interaction worse by discarding shared context each time. Plan mode approvals (option B) still process the edits one at a time, reproducing the same ordering problem. Re-reading the enum each message (option C) treats a coordination problem as a memory problem; the real fix is to let the model see all three interacting edits at once.

Asking Claude to "make the input validation more robust and idiomatic" yields inconsistent output across runs: sometimes it adds zod, sometimes hand-written checks, sometimes nothing meaningful. The team wants the validation style to come out consistent. What is the most effective refinement?

Show the answer Correct answer: B. For ambiguous, style-sensitive tasks, concrete input/output examples communicate the target far more reliably than prose and generalize across cases — a few examples pin down the exact pattern the vague adjectives left open. More detailed prose (option A) still leaves "robust" and "idiomatic" open to interpretation, which is the source of the variance. Fine-tuning (option C) is heavy over-engineering for what a few examples in the prompt solve. A CLAUDE.md rule (option D) restates the same vague adjectives as an always-loaded instruction without demonstrating the concrete format, so the inconsistency persists.

During a 200-file framework migration carried out in one long session, logs show Claude re-migrating files it already converted and skipping others as the conversation grows. What technique best keeps the migration on track?

Show the answer Correct answer: C. For large, long-running tasks the durable pattern is an external scratchpad or manifest that tracks state on disk, so progress is authoritative regardless of what falls out of the conversation window. A larger window (option A) still degrades over a 200-file span and does not give a reliable record of what is done. /compact (option B) shrinks history but can summarize away exactly the per-file progress you need, and it does not create a checkable record. A single massive message (option D) is impractical at this scale and still offers no crash-safe record of completed work — the manifest provides both tracking and recovery.

To rename a widely-used internal API, Claude must first locate every call site across a large monorepo. Doing this discovery inline reads dozens of files and floods the main session with search output before any edits begin, and the later edits then start to wander. What is the best approach?

Show the answer Correct answer: A. Verbose discovery over a large codebase should be delegated to a subagent so the exploration happens in an isolated context and only a distilled summary of call sites returns — the main session stays focused on performing the rename. Reading every file into the main session (option B) is exactly the flooding behavior causing the edits to wander. Repeated /compact (option C) is a lossy patch applied after the noise already accumulated and interrupts the flow. A bigger window (option D) still suffers attention dilution from the raw search output; isolating the discovery is what preserves the working context.

Midway through a coherent multi-hour refactor, the session approaches its context limit. The history is full of superseded intermediate diffs, but the current task and goal are unchanged and the latest file states are still valid. What should the developer do to keep going without losing the thread?

Show the answer Correct answer: D. When the task is a single coherent thread and only the accumulated intermediate history is bloating the context, /compact condenses that history into a summary so work can continue seamlessly on the same task. Starting fresh (option A) is the move when prior tool results are stale or the task changes — neither applies here, and it discards still-valid state. Forking (option B) is for pursuing a divergent branch, not for continuing one coherent line. A larger window (option C) postpones the limit without addressing the superseded-diff clutter; compaction removes the dead weight while preserving the goal. Worked through step by step above

In a long debugging session Claude repeatedly runs the full test suite; each run dumps roughly 2,000 lines of passing-test noise into the context. Over time Claude starts overlooking the failing-test details and the constraints stated at the start of the session. What is the best fix?

Show the answer Correct answer: B. The failure is context degradation from unbounded verbose tool output plus lost-in-the-middle placement of the key constraints; the fix is to trim tool outputs to the relevant fields before they accumulate and to keep the critical summary up front where attention is strongest. A larger window (option A) still lets 2,000 lines per run bury the failing details and dilute attention — capacity is not the problem, signal-to-noise is. Extended thinking (option C) makes the model reason harder over the same noisy context without removing the noise. Re-reading the whole history each turn (option D) amplifies the very clutter that is drowning the failing-test details.

The synthesis subagent's reports read as generic overviews: in 30% of runs they omit the specific figures and named sources the web-search subagent surfaced. Tracing shows the Task prompt sent to the synthesis subagent contains only the report topic and formatting instructions. What is the best fix?

Show the answer Correct answer: B. Subagents do not inherit the coordinator's conversation context; in a hub-and-spoke topology the coordinator must pass prior findings explicitly in the Task prompt, so embedding the web-search and document-analysis results verbatim is the fix. A larger context window (A) does not cross the process boundary into a freshly spawned subagent. Instructing it to 'recall' earlier research (C) fails because the subagent starts with no prior turns to recall. Giving it its own search tool (D) is wrong scope and over-engineering — it duplicates work and diverges from the evidence already gathered.

The coordinator dispatches three independent regional web-search subagents (EU, US, APAC), but issues each Task call only after the previous subagent returns. End-to-end research latency is about 3x the slowest single search. What change most reduces latency?

Show the answer Correct answer: A. Parallel subagents are launched by issuing multiple Task calls in one assistant response; because the three regional searches are independent, doing so collapses their latency to roughly the slowest single search. Merging into one looping subagent (B) removes the parallelism and the per-region differentiation. An iteration cap (C) does not address latency and risks dropping regions entirely. tool_choice 'any' (D) governs which tool the model picks, not whether subagents run concurrently.

A newly configured coordinator answers research questions directly from its own knowledge instead of delegating; its attempts to invoke subagents never appear in the trace. The subagent definitions exist and work when tested standalone. What is the root cause?

Show the answer Correct answer: C. To spawn subagents the coordinator's allowedTools must include 'Task'; when it is absent the coordinator has no delegation mechanism and silently answers on its own, exactly as observed. Scope mismatch (A) is not the gating mechanism for spawning and the subagents work standalone. Model size (B) does not explain a total absence of delegation attempts — the capability is simply not exposed. A forced tool_choice (D) would produce visible forced tool calls, not silent non-delegation.

For open-ended briefs like 'assess the competitive landscape for X', the coordinator runs a fixed three-step chain (search then summarize then format). Reviewers note the reports consistently miss emerging subtopics that only surface mid-investigation. What orchestration change best fits this workload?

Show the answer Correct answer: D. Open-ended investigation calls for dynamic decomposition, where the coordinator spawns follow-up subtasks in response to what earlier findings reveal; a fixed chain suits only predictable, well-defined multi-aspect work and structurally cannot chase subtopics it did not pre-plan. Few-shot formatting examples (A) and a second formatting pass (C) improve presentation, not investigative coverage. Raising temperature (B) adds randomness, not the adaptive depth that surfaces emerging subtopics.

After the shared search and document-analysis phase completes, stakeholders want two report variants from the same evidence — a one-page executive brief and a technical deep-dive — without re-running the costly searches. What is the best way to produce both?

Show the answer Correct answer: B. fork_session creates divergent branches that share all prior state, so forking after the research phase lets each branch produce one variant from the same gathered evidence without re-searching. Continuing one session (A) entangles both outputs in a single history and biases the deep-dive on the already-generated brief. Two fresh sessions (C) wastefully re-run the expensive searches. A bigger context window (D) is unrelated to branching divergent outputs.

Logs show the document-analysis subagent attempting to invoke the web-search subagent directly to fill gaps, producing routing errors and duplicated searches. How should the topology be corrected?

Show the answer Correct answer: A. The correct topology is hub-and-spoke: subagents report findings and gaps back to the coordinator, which dispatches any follow-up work — peer-to-peer subagent calls are the defect. Adding a lock (B) legitimizes and entrenches the wrong topology. Merging the two subagents (C) collapses the intended specialization and differentiation. Giving every subagent the full tool set (D) over-provisions tools, degrades tool selection, and still bypasses the coordinator's orchestration.

A weekly market report is produced by --resume of a named coordinator session. This week the report cites last week's prices as current, because the resumed session replays cached web-search tool results. What is the best fix?

Show the answer Correct answer: D. When prior tool results are stale, the right move is to start fresh with an injected summary of the earlier conclusions and re-run the searches, so the report is grounded in current data rather than replayed cached results. Forking (A) copies the stale tool outputs into the new branch, preserving the problem. Prompt-based suppression under --resume (B) is unreliable and the outdated results still occupy context. A larger window (C) keeps the stale data resident, compounding the confusion.

The coordinator's agentic loop sometimes stops before the report subagent has run: it ends whenever the latest assistant text contains the phrase 'research complete'. Intermittently the synthesis subagent uses that phrase mid-analysis, halting the workflow. How should loop termination be driven?

Show the answer Correct answer: C. The agentic loop must be driven by the API's stop_reason — continue and append the tool result while stop_reason is tool_use, and terminate only on end_turn — never by parsing the model's natural-language text. A minimum iteration count (A) masks the bug with an arbitrary floor. A stricter regex (B) still parses assistant text and remains brittle. A classifier (D) is over-engineering for a deterministic termination signal the API already provides.

The synthesis subagent is initialized with the full registry of 18 tools shared across the system (web_search, fetch_url, parse_pdf, extract_tables, generate_chart, render_report, and others). Traces show that in 22% of runs it issues a fresh web_search or parse_pdf call instead of combining the findings the coordinator already passed in its prompt, adding 6-9 s of latency per run. What is the most effective fix?

Show the answer Correct answer: A. Over-provisioning tools degrades selection: a role with 18 tools available will occasionally pick search or parse tools it should not touch. Scoping the synthesis subagent to only the tools its role needs removes the wrong options entirely and is the governing fix. A larger context window (B) is irrelevant — the findings already fit; the model is choosing to re-fetch, not overflowing. A prompt prohibition (C) is non-deterministic (the 22% proves prompt-only guardrails leak). Forcing tool_choice "any" (D) makes it worse by mandating a tool call every turn when synthesis often needs none.

The document-analysis subagent must call classify_document before running any field extraction, because the extraction schema depends on the detected type. Relying on a prompt instruction, it skips classification in 9% of runs and extracts against the wrong schema. The coordinator invokes it once per document, and the required first step is always the same. What is the best fix?

Show the answer Correct answer: B. When a specific tool must run first deterministically, forcing tool_choice to that named tool on the opening turn is the direct API mechanism and guarantees classify_document executes before any extraction. Setting tool_choice "any" (A) forces a tool but not which one, so the model could still call an extraction tool. A stronger prompt (C) is exactly the non-deterministic approach that already failed 9% of the time. An interception hook (D) would work but is heavier cross-tool policy machinery for a single fixed first-step ordering that the forced tool_choice already guarantees at the API level.

The document-analysis subagent handles mixed inputs: some are PDFs requiring parse_pdf, and some are already plain-text snippets that need no tool at all. It is currently configured with tool_choice "any". Logs show it calling parse_pdf on plain-text inputs — returning garbage — in 18% of cases. What is the best fix?

Show the answer Correct answer: C. tool_choice "any" forces at least one tool call on every input, so plain-text snippets get needlessly routed through parse_pdf. "auto" lets the model choose to use no tool when none applies, which is exactly the flexibility this mixed-input role needs. Forcing parse_pdf (A) makes the wrong behavior mandatory. A preprocessing stage (B) addresses the symptom at the wrong layer and adds a component when a one-line config change suffices. Few-shot examples (D) cannot override the hard constraint that "any" mandates a tool call regardless.

The web-search subagent is equipped with two tools, search_web and search_academic, each carrying a one-line description ("search the web" / "search academic sources"). It routes queries to the wrong tool in 31% of cases — for example, sending peer-reviewed-literature queries to search_web. What is the best first step?

Show the answer Correct answer: D. Tool descriptions are the primary tool-selection mechanism, so the first move is to enrich them: state input formats, give example queries, spell out source coverage, and draw explicit boundaries between the two. Consolidating (A) destroys the useful distinction the two tools provide — here differentiating is the fix, not merging. A dedicated router model (B) over-engineers a problem that a description edit resolves. A static forced tool_choice (C) cannot work when the correct tool legitimately varies per query.

The synthesis subagent merges findings from the web-search and document-analysis subagents into a unified narrative but drops the record of which source each claim came from. The report-generation subagent can then no longer attach citations, and 40% of the report's sentences ship uncited. What is the best fix?

Show the answer Correct answer: C. Provenance must be preserved through synthesis, not reconstructed afterward: each synthesized claim should carry its originating source(s) forward so report generation can cite the actual origin. Re-running web_search (A) invents new sources that may not be what the claim was actually based on. A guessing post-processor (B) fabricates provenance. Placeholder markers (D) defer the problem to humans and leave the report uncited by default. Carrying claim-source mappings end to end is the governing principle.

Two sources report different market-size figures for the same market — $4.2B (2021 data) versus $6.8B (2023 data). The synthesis subagent silently picks $6.8B and presents it as the single authoritative fact. Reviewers, seeing the discarded figure elsewhere, flag the report as unreliable. What is the best fix?

Show the answer Correct answer: D. These figures are not actually contradictory — they are different years — so the fix is to annotate both with their source and date, which requires the pipeline to preserve publication/collection dates precisely so temporal change is not mistaken for conflict. Silently keeping one figure, even the more recent one (A), or averaging them (B) destroys provenance and can be flatly wrong. Human routing (C) is unnecessary overhead when the discrepancy is fully explained by date; escalation should be reserved for genuinely ambiguous conflicts, not every differing number.

The coordinator passes each subagent's output forward verbatim: the web-search subagent's full scraped page bodies — roughly 38k tokens — flow straight into the synthesis subagent's prompt. Synthesis quality has dropped and it now misses findings buried in the middle of the passed-in content (lost-in-the-middle). What is the best fix?

Show the answer Correct answer: A. Downstream context should be budgeted: trim verbose tool outputs to the relevant extracted fields before they accumulate, and counter lost-in-the-middle by placing the key summary first under clear section headers. A larger-context model (B) does not fix attention dilution — lost-in-the-middle persists at any window size when the prompt is full of low-signal bulk. A "focus on important parts" instruction (C) does not reduce the noise the model must still attend to. Re-fetching (D) duplicates work and re-introduces the same raw volume the trimming was meant to remove.

Scenario: Developer Productivity with Claude

A coordinator agent is asked to produce a migration plan for a 400,000-line legacy billing monolith. The engineer hard-codes an upfront decomposition into five subagent tasks (billing, invoicing, tax, reporting, auth). Production runs show the final plan omits an entire 'dunning' subsystem and a currency-conversion layer that no subagent was ever assigned. What is the most effective decomposition strategy?

Show the answer Correct answer: B. For unfamiliar or legacy code you cannot know the true structure in advance, so any static decomposition guarantees blind spots — exactly the omitted 'dunning' and currency layers. The governing pattern is mapping-then-adaptive decomposition: discover the real module structure first, then decompose against what actually exists, which is why B is correct. A is wrong because more iterations do not change the coverage of a fixed assignment list. C is still a static decomposition bounded by incomplete prior knowledge — the missing subsystems were unknown, so listing more names from memory does not surface them. D confuses context size with decomposition; the failure is missed coverage, not insufficient window.

The coordinator spawns a subagent with a single Task call to trace how a payment webhook propagates through the orders module. Logs show the subagent re-runs Grep to rediscover the entrypoint the coordinator had already located two turns earlier, and reaches a conclusion that contradicts the coordinator's established finding. What is the root cause?

Show the answer Correct answer: C. In a hub-and-spoke design each subagent starts with a clean context and sees only what the coordinator writes into its Task prompt, so unless prior findings are passed in, the subagent rediscovers and can contradict them — making C correct. A is wrong because the Task tool governs spawning further subagents, not inheriting context. B is irrelevant: interactive delegation does not run through the Batches API. D is wrong because tool_choice controls which tool is invoked, not whether earlier conclusions are carried over.

An engineer runs --resume on a named exploration session from three days ago to continue a refactor. Since then a teammate moved several files and renamed a package. The resumed agent replays cached Read and Grep results from the old history and proposes edits against paths that no longer exist. What is the best way to continue the work?

Show the answer Correct answer: D. When prior tool results are stale, replaying them drives edits against a state of the world that no longer holds; the fix is to keep the conclusions but re-ground on the current tree — start fresh with an injected summary, so D is correct. A is wrong because retaining more stale history is the problem, not a lack of window. B still carries the stale Read/Grep results into the fork. C compacts (summarizes) the stale outputs rather than replacing them with fresh reads of the moved files, so the wrong paths persist.

A security scan flags that the team's committed.mcp.json contains a hardcoded GitHub personal-access token used by an MCP server. The team wants the server config to stay shared and version-controlled, but each engineer (and CI) must supply their own credential without leaking it. What should they do?

Show the answer Correct answer: B. MCP configuration supports ${ENV_VAR} expansion precisely so secrets stay out of version control while the config itself remains shared: writing ${GITHUB_TOKEN} lets each machine and CI job inject its own value at load time (B). Committing an encrypted blob (A) still ships a secret in the repo and adds key-management burden. Moving to user scope (C) sacrifices the requirement that the config stay shared and version-controlled. Putting the token in CLAUDE.md (D) commits the plaintext secret into VCS — the same leak, in a different file.

The agent connects to a database MCP server to help engineers query a legacy schema. Traces show that before every real query it fires 6-10 exploratory tool calls (list_tables, describe_table, sample_rows) to rediscover what exists, adding seconds of latency and thousands of tokens per session. The schema changes rarely. What is the best way to reduce this overhead?

Show the answer Correct answer: D. MCP resources exist to expose content catalogs (schemas, indexes, file listings) that the agent can read directly, eliminating the exploratory tool calls used just to discover what is available (D). Because the schema is stable, a resource is read once and reused. tool_choice "any" (A) forces a tool but does nothing to remove the discovery calls. A larger window (B) accommodates the bloat rather than preventing it. A cache (C) speeds up the redundant probes but still incurs the round trips and token cost — the discovery pattern itself is the problem.

The team added a code-intelligence MCP server that does semantic, cross-file symbol search over an indexed monorepo. In practice the agent almost always reaches for the built-in Grep tool instead, so it misses semantically related call sites that don't share literal text. The MCP tool's description currently reads only "Search the code index." What is the most effective first step?

Show the answer Correct answer: A. Tool descriptions are the primary tool-selection mechanism, so a thin description ("Search the code index") loses to a well-understood built-in like Grep; enriching it with example queries and an explicit boundary (semantic vs literal matching) makes the agent prefer it where appropriate (A). Removing Grep entirely (B) is over-scoped — literal search is still the right tool for many tasks. A CLAUDE.md prohibition (C) fights good behavior with a blanket rule instead of clarifying when each tool wins. Forcing tool_choice every turn (D) breaks legitimate Grep and Read use and does not teach correct selection.

The agent is asked to rename a shared constant throughout a generated client file. Its Edit call fails with a non-unique-match error because the target string appears on many lines that must all be updated consistently, and no single surrounding context makes one occurrence unique. What is the correct way to complete the change?

Show the answer Correct answer: D. Edit performs a targeted replacement on a unique match; when the anchor is inherently non-unique and the change spans many identical occurrences, the correct fallback is to Read the full file and Write it back with the edits applied (D). A sed substitution (A) sidesteps the built-in file tools and forfeits the reviewability and safety of Read/Write. Forcing tool_choice (B) does not resolve the ambiguity — Edit still cannot pick which occurrence to change. Regenerating the file (C) risks discarding unrelated hand-made changes and is far more destructive than needed.

An engineer asks the tool to determine which of 30 services emits a particular Kafka event. Answering requires grepping and reading across dozens of files, producing thousands of lines of intermediate tool output. Done inline, this verbose discovery floods the main session's context and later steps degrade from lost-in-the-middle effects. What is the best approach?

Show the answer Correct answer: B. Verbose, exploratory discovery belongs in an isolated Explore subagent that reports back only the concise answer, so the main context stays clean and free of attention dilution — making B correct. A is wrong because a larger window still accumulates and dilutes attention rather than preventing the flood. C plans the searches but does not reduce the volume of intermediate output they generate. D is slower and still pours every file's contents into the main context, worsening the problem.

A senior engineer added the team's coding-convention instructions to ~/.claude/CLAUDE.md, and the tool follows them perfectly on her machine. A newly onboarded teammate clones the same repository, but the tool ignores those conventions for him. What is the correct fix?

Show the answer Correct answer: A. ~/.claude/CLAUDE.md is user-scoped memory that never travels with the repository, which is exactly why a fresh clone does not pick it up; project-level CLAUDE.md is shared through VCS, so A is correct. B misuses MCP config, which defines tool servers rather than conventions and is itself personal. C makes the always-on conventions on-demand and still requires committing something to be shared. D references a.claude/config.json commands array that does not exist.

Scenario: Claude Code for Continuous Integration

A CI pipeline calls Claude Code to review each pull request, and a shell gate script greps stdout for the word "CRITICAL" to fail the build. The gate is flaky because Claude phrases severe findings differently each run — "severe issue," "major bug," "critical defect." What is the most effective fix?

Show the answer Correct answer: B. CI consumers must read structured, machine-parseable output rather than parsing free-form natural language. Running with --output-format json and a --json-schema forces findings into typed fields (severity, file, line) the gate can evaluate deterministically, so key B is correct. A builds a brittle synonym-normalization layer that will always lag new phrasings and is unneeded once output is structured. C is a prompt-only instruction that offers no deterministic guarantee — the model can still deviate. D misunderstands temperature: even at 0 the output is prose, not a stable schema, and the gate remains fragile.

In the pipeline, the same Claude Code session that generates an implementation also performs the automated review step. It consistently rates its own output clean, yet human reviewers keep finding real bugs it missed. What is the most effective change?

Show the answer Correct answer: A. A session that produced code carries the same assumptions that caused its defects, so self-review systematically misses them. An independent instance with no shared context reviews the diff fresh and catches issues the author blind spots hid, so key A is correct. B adds reasoning depth but keeps the identical context and biases, so the blind spots persist. C is a prompt nudge that cannot overcome the structural problem of reviewing one's own reasoning. D changes sensitivity, not perspective — the same session still fails to see the bugs it never flagged.

Locally, the author's Claude generates tests that follow team conventions (naming, arrange-act-assert structure). In CI on a clean checkout, the generated tests ignore those conventions. The conventions are documented only in the author's ~/.claude/CLAUDE.md. What is the best fix?

Show the answer Correct answer: D. User-level ~/.claude/CLAUDE.md is personal and not shared through VCS, which is exactly why it is absent on a clean CI checkout. Moving the conventions into the project's committed.claude/CLAUDE.md makes them load for every clone, in CI and for every teammate, so key D is correct. A wires the guidance into a fragile command flag that lives outside the repo and drifts. B stashes instructions on one build server, still unversioned and invisible to teammates. C is disproportionate and does not address the real cause — the instructions simply are not in the shared project scope.

The project's always-loaded CLAUDE.md has grown to embed a long, detailed code-review rubric. That rubric is needed only by the review job, but it is now injected into every CI job — test generation, doc updates — inflating token cost and diluting the model's focus on those tasks. What is the best fix?

Show the answer Correct answer: D. CLAUDE.md is always loaded, so anything job-specific placed there taxes every unrelated run. A Skill loads on demand only when its job invokes it, so moving the rubric into.claude/skills keeps it available to the review job while leaving CLAUDE.md lean for the rest — key D is correct. A loses versioned reuse and bloats the command definition. B is a fragile symlink hack that duplicates and desynchronizes the guidance. C changes formatting but the commented text is still loaded into context for every job, so the cost and dilution remain.

The CI reviewer posts naming-convention and style comments, but developers report that roughly 60% of these particular comments are wrong or trivial. They have started ignoring the bot entirely — including its genuine security findings. What is the most effective response?

Show the answer Correct answer: B. A single high-false-positive category erodes trust in the entire reviewer, so the governing principle is to remove the offending category from production and fix its prompt rather than paper over it. Temporarily disabling naming-convention comments stops the trust bleed immediately, and rewriting the category with explicit categorical criteria addresses the root cause before re-enabling it.

A global confidence threshold (A) is the wrong instrument — self-reported confidence is poorly calibrated and would also suppress good findings from healthy categories. A human moderation queue (C) defeats the point of automation and does not fix the noisy prompt. A sentiment classifier (D) is heavy over-engineering that treats symptoms (developer annoyance) rather than the miscalibrated category definition.

The CI reviewer handles clear-cut defects well but is inconsistent on genuinely ambiguous cases — for example, whether a bare except: is acceptable in a one-off script versus a shared library. Enumerating every possible scenario in the prompt is impractical. What is the best approach?

Show the answer Correct answer: A. Few-shot examples are the right tool for ambiguous judgment because a small set of well-chosen cases with their reasoning lets the model generalize the underlying principle rather than memorize a lookup table. Two to four exemplars covering the representative ambiguous patterns teaches the script-versus-library distinction without enumerating everything. An exhaustive list (B) is the enumeration approach the stem already rejects as impractical and it still will not cover unseen cases. Fine-tuning (C) is disproportionate engineering for a prompt-level problem and is slow to iterate. Flagging every borderline case to humans (D) abandons the goal of useful automated feedback and floods reviewers with noise.

In the pipeline, Claude Code generates test cases and then, within the same session, reviews those tests for quality. The review almost never finds problems, yet audits show 20% of the generated tests have weak or tautological assertions. What explains this and what is the fix?

Show the answer Correct answer: D. A session evaluating work it just produced is anchored to its own reasoning and tends to confirm rather than challenge it, which is why the self-review misses weak assertions the audit catches. An independent instance with no stake in the original generation reviews far more critically, so routing the tests to a fresh reviewer is the correct fix. Extended thinking (A) makes the same biased session think longer about the same conclusion; it does not remove the conflict of interest. Voting across three passes of the same session (B) compounds the shared bias instead of countering it. More detailed criteria (C) help at the margin but cannot overcome a reviewer predisposed to approve its own output.

Production logs show that 8% of extraction responses fail the downstream JSON.parse() step because Claude wraps its output in markdown code fences or prepends a sentence like "Here is the extracted data:". Prompt tweaks reduced but did not eliminate the failures. What is the most reliable fix?

Show the answer Correct answer: B. The governing principle is that tool_use with a JSON schema is the most reliable way to obtain structured output because the model returns a validated JSON object in the tool_use block, eliminating syntax and formatting errors entirely. Forcing the tool guarantees the structured path is taken. Prompt instructions plus temperature 0 (A) still rely on the model formatting free text and leave residual failures. Regex stripping (C) is a brittle patch that breaks on unexpected wrappers and does not address the root cause. Capping max_tokens (D) can truncate valid JSON and does not stop fence-wrapping.

After migrating to tool_use with a strict JSON schema, JSON parse failures dropped to zero. However, reconciliation shows 6% of extracted invoices have line-item amounts that do not sum to the stated invoice total. What does this reveal about schema-based structured output?

Show the answer Correct answer: C. The principle is that a JSON schema guarantees structural and type validity but cannot enforce semantic correctness such as line items summing to a total. The correct response is a downstream business-rule validation step that recomputes the sum and flags or retries mismatches. Option A confuses a structural constraint (additionalProperties) with an arithmetic invariant it cannot express. Option B misuses tool_choice, which controls tool selection, not numeric correctness. Option D misattributes a semantic discrepancy to a token limit; truncation would cause parse or completeness failures, not silent miscalculation.

For documents that lack a purchase-order number, audit logs show Claude inventing plausible-looking PO numbers about 11% of the time instead of signaling absence. Downstream systems then treat the fabricated values as real. What is the best schema-level fix?

Show the answer Correct answer: D. The principle is that making the field nullable gives the model a sanctioned way to represent absence, so it returns null instead of fabricating a value to satisfy a required field. The key can stay required while its value may be null; an optional field would also stop the fabrication, but the key would then be omitted rather than set to null.

Pairing this with an explicit instruction to emit null when the data is absent directly addresses the hallucination. A confidence score (A) is poorly calibrated and does not stop the fabrication, only tries to filter it afterward. Setting tool_choice to "auto" (B) risks skipping extraction entirely for otherwise-complete documents.

A few-shot example of a valid PO (C) reinforces the format but gives no path for the missing case, which is the actual problem. Worked through step by step above

The extraction schema uses an enum with six known values for document_type. A new vendor begins sending "credit memo" documents, which are not in the enum, and the model force-fits them to "invoice", corrupting downstream routing. What is the best design change?

Show the answer Correct answer: A. The principle is designing enums for extensibility with an "other" (or "unclear") escape value plus a free-text detail field, so unanticipated categories are surfaced rather than silently forced into a wrong bucket. This keeps the controlled vocabulary intact while capturing novel cases for review. Dropping the enum (B) sacrifices the validation and normalization that make the field useful downstream. A fine-tuned classifier (C) is heavy over-engineering when a schema change solves the problem. Enumerating every possible type (D) is impossible to complete and still breaks on the next truly novel document.

Extractions pass the JSON schema but sometimes violate a business rule (invoice_date later than due_date). The current recovery discards the result and re-runs the identical prompt from scratch; 40% of retries still fail the rule. What is the most effective retry strategy?

Show the answer Correct answer: B. The validation-retry principle is to feed the model its own failed output plus the exact validation errors, so it can correct the specific fields rather than re-deriving everything blindly. This targeted feedback is far more likely to resolve a rule violation than repetition. Re-running the same prompt (A, C) provides no new information and mostly reproduces the same error. The Batch API (D) is for high-volume latency-tolerant work, not a corrective loop, and it does nothing to give the model the failure context it needs to fix the fields.

For scanned documents where the tax ID is physically cut off at the page edge and simply absent from the source text, the validation-retry loop retries five times and still fails, burning tokens on every attempt. What is the correct understanding of this situation?

Show the answer Correct answer: C. The principle is that a validation-retry loop repairs formatting and structural mistakes but cannot conjure information that is not present in the source document. Recognizing absence, returning null, and escalating to a human is the correct terminal behavior, and it stops the wasteful token spend. Increasing retries (A) cannot recover data that was never in the input. Extended thinking (B) improves reasoning over available evidence but cannot invent an absent value without fabricating it. Changing tool_choice (D) alters which tool runs, not what text exists on the truncated page.

A 50,000-document extraction batch completes and 300 requests returned errors. The team needs to reprocess only the failures and reliably match every result back to its source document. What is the correct approach?

Show the answer Correct answer: A. The principle is that each Batch API request carries a caller-supplied custom_id, which is the correlation key for matching results back to sources and for selectively resubmitting only the failed items. Reprocessing the 300 failed custom_ids in a fresh batch is both cheap and precise. Resubmitting all 50,000 (B) wastes cost and time; batches are not atomic in that sense. Result ordering is not guaranteed (C), which is exactly why custom_id exists. Timestamp matching (D) is fragile and unnecessary when a deterministic custom_id mapping is available.

The pipeline handles six document types, each with its own extraction tool. Even when the type is already known from the intake folder that routed the document, the caller still sends all six tools with tool_choice "auto", and in 9% of cases the model invokes the wrong extractor. What is the best fix?

Show the answer Correct answer: B. The principle is that when the correct tool is already determined by upstream logic, you should force it with tool_choice {"type":"tool","name":...} instead of asking the model to re-decide, which removes the selection error entirely. "auto" (A) reintroduces the very choice that is failing, and sentiment analysis is irrelevant over-engineering. "any" (C) still lets the model pick the wrong extractor among the six. Merging into one mega-tool (D) creates a bloated schema and does not use the routing information you already have, likely degrading extraction quality.

The mock reports a score from 100 to 1000, the same range as the official exam, but it uses my own formula: 100 + 900 × the fraction answered correctly. With 60 questions, each correct answer adds 15 points. The threshold is 720, which takes 42 correct answers. It is a reference within this tool. It is neither Anthropic’s scoring formula nor a validated prediction of passing the official exam.

For a timed run, open the free 60-question CCAR-F practice exam. Study mode shows the explanation after “Check answer” and pauses the timer while you read. Exam mode gives you 120 minutes, with flagging and answer changes until submission. The tool’s questions are in English.

Results show your correct-answer count, the score from the table above and a breakdown across five domains.

Progress saves locally in this browser, so you can close the tab and resume later. The test page also explains how to practise in chat through MCP. You do not need an account or an email address to answer the questions.

If you would rather work on paper, the same 60 questions are in a free PDF with the answer key at the end. The key explains every option, as the online test does. You can download it without an email address.

On your next attempt, focus on what you can explain without the answer key:

If you struggle with the responsibilities of an agent and its tools, read my 12 rules for building agents. I wrote them while preparing for the same exam; they expand on topics from D1 and D2.

Check booking eligibility separately from your mock score. I cover the current account requirements and exam access without a partner employer in a separate article. A high practice score does not change the organizer’s requirements.

Have you identified a weak area? The Foundations study plan maps each domain to resources and exercises. Return to the questions after doing an exercise and check whether you can reject the wrong options without looking at the key.

Free, in the browser, no signup. Progress is saved locally.

Take the practice exam → Download the PDF Code on GitHub

No. I wrote all 60 questions myself from Anthropic’s public exam guide, and none is taken from the exam. Each has one correct answer, while the official exam also has multiple-response items. The set is not affiliated with or endorsed by Anthropic.

Yes. The same 60 questions are in a free PDF with the answer key at the end, and the key explains every option. The download link is on this page, and you do not need an email address.

The official exam’s passing score is 720 on a 100 to 1000 scale. This mock uses 720 as its reference too, which takes 42 of 60 correct answers, but the formula is mine, not Anthropic’s, so no mock score predicts your result. Before booking, make sure you can explain why each wrong option is wrong in your two weakest domains.

Important disclaimer. This is unofficial study material. It is not affiliated with, authorized or endorsed by Anthropic. I wrote all 60 questions myself, modeled solely on the publicly available exam guide. Claude and Claude Certified Architect are names owned by Anthropic.

No partner employer? Anthropic admits to its exams only people from Claude Partner Network organizations. Join our collective of AI consultants and sit all four exams through our partner organization. See the program → · Free practice exam →

Originally published at szymonpaluch.com.