DEV Community: Szymon Paluch

60 Claude Certified Architect Exam Questions & Answers (CCAR-F)

Szymon Paluch — Fri, 16 Oct 2026 07:30:05 +0000

Which exam are you preparing for?

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.

What exactly you get

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.

What the real exam covers

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:

Domain	Weight	Questions in my mock
D1 · Agentic Architecture & Orchestration	27%	16
D2 · Tool Design & MCP Integration	18%	11
D3 · Claude Code Configuration & Workflows	20%	12
D4 · Prompt Engineering & Structured Output	20%	12
D5 · Context Management & Reliability	15%	9

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.

Three questions to try

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.

QUESTION 3 · D1 · AGENTIC ARCHITECTURE

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?

A. Add a PreToolUse hook on process_refund that blocks any call above $500 and redirects the flow to human escalation.
B. Add a system-prompt line instructing the agent to always escalate refunds above $500.
C. Remove process_refund from the agent's toolset so every refund is handled by a human.
D. Fine-tune the model on historical tickets so it learns the $500 threshold.

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.

QUESTION 55 · D4 · STRUCTURED OUTPUT

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?

A. Add a required confidence float to every field and discard low values downstream.
B. Switch tool_choice to "auto" so the model can skip extraction when the number is missing.
C. Add a few-shot example with a correctly formatted purchase-order number.
D. Allow null in the po_number field and instruct the model to return null when the value is not present in the source.

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.

QUESTION 20 · D5 · CONTEXT MANAGEMENT

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?

A. Start a brand-new session with no prior context and re-describe the task.
B. Fork the session to branch off a divergent line of work.
C. Request a larger context window and continue as-is.
D. Run /compact to condense the accumulated history into a summary and continue the same task.

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.

All 60 questions with answers

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.

Question 1 · D1 · Agentic Architecture & Orchestration

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?

A. Terminate only when stop_reason is end_turn; whenever stop_reason is tool_use, execute the requested tool, append the tool_result to the message list, and continue the loop.
B. Expand the regex allowlist of closing phrases so it recognizes every polite sign-off the model might emit before stopping.
C. Add a max-iteration cap and stop the loop once the assistant produces two consecutive text-only responses.
D. Run a lightweight intent classifier on each assistant message to decide whether the turn represents a genuine completion.

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.

Question 2 · D1 · Agentic Architecture & Orchestration

Scenario: Customer Support Resolution Agent

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?

A. Attach the full untrimmed transcript of the conversation so the human has complete information.
B. Enable extended thinking on the escalation turn so the model reasons longer before handing off.
C. Escalate earlier in ambiguous cases so humans receive tickets before much conversation has accumulated.
D. Produce a structured handoff summary — the customer's issue, verified identifiers, tool results and account state gathered, actions already attempted, and the specific recommended next step.

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.

Question 3 · D1 · Agentic Architecture & Orchestration

Scenario: Customer Support Resolution Agent

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?

A. Add a PreToolUse interception hook on process_refund that blocks any call with an amount over $500 and redirects the flow to escalate_to_human.
B. Add a line to the system prompt instructing the agent to always escalate refunds over $500 instead of processing them.
C. Remove process_refund from the agent's toolset entirely so every refund is handled by a human.
D. Fine-tune the model on historical tickets so it learns the $500 threshold from past manager approvals.

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

Question 4 · D1 · Agentic Architecture & Orchestration

Scenario: Customer Support Resolution Agent

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?

A. Instruct the model in the system prompt to normalize all dates and currency values before reasoning about them.
B. Add a PostToolUse hook that normalizes each tool's raw output into one canonical schema before it is appended to the context.
C. Increase the context window so the model has more room to keep the varied formats straight.
D. Spin up a dedicated formatting subagent that the coordinator calls after every backend lookup.

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.

Question 5 · D1 · Agentic Architecture & Orchestration

Scenario: Customer Support Resolution Agent

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?

A. Enlarge the shared context window so the subagents can see the coordinator's earlier turns.
B. Store the confirmed customer record in a global variable that the SDK automatically injects into every subagent.
C. Instruct each subagent to call get_customer itself at the start so it independently establishes the account.
D. Include the coordinator's already-verified findings — the confirmed customer record and identifiers — explicitly in each subagent's Task prompt, since subagents do not inherit the coordinator's conversation context.

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.

Question 6 · D2 · Tool Design & MCP Integration

Scenario: Customer Support Resolution Agent

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?

A. Raise the agent's context window so the entire refund policy document fits alongside the conversation.
B. Split process_refund into two tools, process_full_refund and process_partial_credit, each with a distinct description and explicit boundary on when to use it.
C. Add three few-shot examples of partial-credit conversations to the system prompt while keeping the single tool.
D. Set tool_choice to "any" so the model is compelled to select a tool on every refund turn.

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.

Question 7 · D2 · Tool Design & MCP Integration

Scenario: Customer Support Resolution Agent

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?

A. Automatically retry get_customer in a tight loop until the database responds, however long that takes.
B. Increase the get_customer connection timeout so slow database responses are no longer cut off.
C. A structured error with an errorCategory (e.g. transient) and isRetryable metadata that lets the agent distinguish an access failure from a valid empty result and respond accordingly.
D. Treat every non-successful get_customer response as an escalation trigger and route all of them to escalate_to_human.

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.

Question 8 · D2 · Tool Design & MCP Integration

Scenario: Customer Support Resolution Agent

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?

A. Have the agent retry with exponential backoff, since repeated attempts eventually succeed for most declined refunds.
B. Raise the agent's refund authority limit above $640 so the call no longer fails.
C. Instruct the agent in the system prompt to never retry a refund more than once.
D. Return a structured error with errorCategory "business" and isRetryable set to false, so the agent stops retrying and routes the request to escalate_to_human.

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.

Question 9 · D5 · Context Management & Reliability

Scenario: Customer Support Resolution Agent

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?

A. Maintain a persistent 'case facts' block (order id, amount, dates, customer expectation) stored outside the summarized history and re-injected verbatim each turn.
B. Switch to a model with a larger context window so no summarization is needed.
C. Call get_customer and lookup_order again on every turn to refetch the numbers.
D. Enable extended thinking so the model reasons more carefully before quoting figures.

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.

Question 10 · D5 · Context Management & Reliability

Scenario: Customer Support Resolution Agent

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?

A. Continue with the most recently active of the three accounts, since it is the most likely current customer.
B. Pick the match with the highest fuzzy name-similarity score and proceed.
C. Escalate every multiple-match case straight to a human agent.
D. Ask the customer for an additional identifier (order number, email, or ZIP) to disambiguate before taking any account action.

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.

Question 11 · D3 · Claude Code Configuration & Workflows

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?

A. Add an @import to the repo-root CLAUDE.md pointing at ~/.claude/CLAUDE.md so the personal file is pulled in for everyone
B. Have each engineer run /memory after cloning to force-reload the user-scoped memory files
C. Move the conventions into the project-scoped .claude/CLAUDE.md (or repo root) so they are committed to version control and load for every clone
D. Convert the conventions into a skill under .claude/skills/ so they activate on demand for all users

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.

Question 12 · D3 · Claude Code Configuration & Workflows

Scenario: Code Generation with Claude Code

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?

A. Add a step to CLAUDE.md instructing Claude to summarize the skill's output before continuing
B. Set context:fork in the skill's SKILL.md frontmatter so its verbose exploration runs in an isolated context and only the result returns to the main session
C. Increase the context window so the accumulated exploration output no longer causes degradation
D. Restrict the skill with an allowed-tools list so it reads fewer files during exploration

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.

Question 13 · D3 · Claude Code Configuration & Workflows

Scenario: Code Generation with Claude Code

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?

A. Call /compact automatically at the end of the skill so the audit output is condensed before work continues
B. Set disable-model-invocation: true in the skill's SKILL.md frontmatter so the skill runs only when a user explicitly invokes /dep-audit
C. Delete the skill's description frontmatter so Claude can no longer match it to conversation topics
D. Move the audit instructions into CLAUDE.md so they load once at startup instead of triggering mid-session

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.

Question 14 · D3 · Claude Code Configuration & Workflows

Scenario: Code Generation with Claude Code

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?

A. Add a stronger system-prompt instruction forbidding edits to any file outside docs/
B. Require the skill to run in plan mode every time so a human approves each action
C. Declare allowed-tools in the skill's SKILL.md frontmatter, restricting it to Read/Glob/Write so the harness blocks Edit and Bash entirely
D. Add a global PreToolUse hook that inspects every Edit across all sessions and rejects ones outside docs/

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.

Question 15 · D3 · Claude Code Configuration & Workflows

Scenario: Code Generation with Claude Code

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?

A. Add an argument-hint field to the skill's SKILL.md frontmatter so the expected argument and format are shown at the invocation prompt
B. Document the correct usage in the project CLAUDE.md so it is always loaded into context
C. Rename the skill to /scaffold-component-with-name so the required input is implied by the name
D. Have the skill body instruct Claude to ask the user for the name whenever it is missing

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.

Question 16 · D3 · Claude Code Configuration & Workflows

Scenario: Code Generation with Claude Code

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?

A. Run each of the three changes in its own fresh session so they stay cleanly isolated
B. Enable plan mode and approve the three changes one at a time in sequence
C. Keep them sequential but ask Claude to re-read the enum before each message
D. Batch the three interacting changes into a single message so Claude edits the enum and all dependent switch sites together with full mutual context

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.

Question 17 · D4 · Prompt Engineering & Structured Output

Scenario: Code Generation with Claude Code

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?

A. Expand the request into a longer, more detailed prose description of what "robust" and "idiomatic" mean
B. Provide 2-3 concrete input-to-output examples showing the exact validation style and library you want
C. Fine-tune a model on the team's existing validation code so it internalizes the house style
D. Add a standing CLAUDE.md rule stating that validation should always be robust and idiomatic

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.

Question 18 · D5 · Context Management & Reliability

Scenario: Code Generation with Claude Code

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?

A. Switch to a larger-context model so the whole file list stays in the window
B. Run /compact frequently to keep the history short
C. Maintain a scratchpad manifest file that records migrated vs pending files and update it after each file, so progress survives context growth
D. Do the entire migration in a single large message to avoid state loss between turns

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.

Question 19 · D5 · Context Management & Reliability

Scenario: Code Generation with Claude Code

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?

A. Delegate the discovery to an Explore subagent that searches the monorepo and returns only a summary of call sites, keeping the main context focused on the edits
B. Read every candidate file into the main session first so all call sites are visible before editing
C. Run /compact after each search so the accumulated output is repeatedly condensed
D. Move to a larger-context model so the exploration output no longer competes with the edits

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.

Question 20 · D5 · Context Management & Reliability

Scenario: Code Generation with Claude Code

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?

A. Start a brand-new session with no prior context and re-describe the task
B. Fork the session to branch off a divergent line of work
C. Request a larger context window and continue as-is
D. Run /compact to condense the accumulated history into a summary while continuing the same task

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

Question 21 · D5 · Context Management & Reliability

Scenario: Code Generation with Claude Code

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?

A. Switch to a larger-context model so all the test output fits comfortably
B. Trim each test run's output to the relevant failing-test lines before it accumulates, and keep the key constraints in a summary placed at the top of the context
C. Enable extended thinking so Claude reasons harder over the full accumulated output
D. Instruct Claude to re-read the entire session history at the start of every turn

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.