Official Sample Questions (12 total, with reasoning)

Tagged by scenario and domain. Use these to calibrate difficulty — the real exam will have 60 in this style.

Q1 — Scenario 1 (Customer Support) — Domain 1.4

Production data shows the agent skips get_customer 12% of the time and calls lookup_order on name alone, causing misidentified accounts/wrong refunds. Best fix?

A) Programmatic prerequisite blocking lookup_order/process_refund until get_customer returns a verified ID
B) System prompt states verification is mandatory
C) Few-shot examples showing get_customer called first
D) Routing classifier enabling only the tool subset per request type

Answer: A — Deterministic guarantee needed for financial-consequence errors; B/C are probabilistic; D solves tool availability, not ordering.

Q2 — Scenario 1 — Domain 2.1

Agent frequently calls get_customer for order questions instead of lookup_order. Both tools have minimal, similar descriptions. Best first step?

A) Few-shot examples (5-8) showing correct routing
B) Expand each tool's description: input formats, example queries, edge cases, boundaries
C) Pre-turn routing layer parsing input for keywords
D) Consolidate into one lookup_entity tool

Answer: B — Root cause is inadequate descriptions (the primary tool-selection signal); lowest-effort, highest-leverage fix. A adds tokens without fixing root cause; C is over-engineered; D is a bigger architectural change than a "first step" warrants.

Q3 — Scenario 1 — Domain 5.2

55% first-contact resolution vs 80% target. Agent escalates easy cases (damage replacement w/ photo evidence) but tries to handle complex policy-exception cases itself. Best fix?

A) Explicit escalation criteria + few-shot examples in system prompt
B) Self-reported confidence score (1-10) routing below threshold to human
C) Separate classifier trained on historical tickets
D) Sentiment analysis auto-escalates on negative sentiment

Answer: A — Root cause: unclear decision boundaries. B fails — the agent's confidence is already miscalibrated on hard cases. C is over-engineered without trying prompt fixes first. D solves the wrong problem — sentiment ≠ complexity.

Q4 — Scenario 2 (Code Gen) — Domain 3.2

Want a /review slash command available to every dev on clone/pull. Where to put the file?

A) .claude/commands/ in the project repo
B) ~/.claude/commands/ per-developer
C) In root CLAUDE.md
D) .claude/config.json with a commands array

Answer: A — Project-scoped commands are version-controlled and shared. B is personal-only. C is for context/instructions, not commands. D doesn't exist.

Q5 — Scenario 2 — Domain 3.4

Assigned to restructure a monolith into microservices — dozens of files, service-boundary decisions. Approach?

A) Enter plan mode: explore, understand dependencies, design before changing
B) Direct execution, incremental, let boundaries emerge
C) Direct execution with comprehensive upfront instructions
D) Direct execution first, switch to plan mode only if complexity surprises you

Answer: A — Textbook plan-mode trigger: large-scale, multi-file, architectural decisions. B risks late-discovered rework. C assumes you already know the right structure. D ignores that complexity is already known upfront.

Q6 — Scenario 2 — Domain 3.3

Distinct conventions per code area (React hooks, API async/await, DB repository pattern); test files (*.test.tsx) scattered everywhere but must follow uniform conventions. Most maintainable way to auto-apply correct conventions?

A) .claude/rules/ files with YAML frontmatter glob patterns
B) Consolidate all conventions into root CLAUDE.md under headers, rely on inference
C) Skills in .claude/skills/ per code type
D) Separate CLAUDE.md per subdirectory

Answer: A — Glob patterns (**/*.test.tsx) apply by file type regardless of location — exactly what scattered test files need. B relies on unreliable inference. C requires manual/optional invocation, not automatic. D is directory-bound, can't handle scattered files.

Q7 — Scenario 3 (Multi-Agent Research) — Domain 1.2

Topic "impact of AI on creative industries" → coordinator decomposed into "AI in digital art," "AI in graphic design," "AI in photography" — all visual arts, missing music/writing/film. Each subagent executed correctly. Root cause?

A) Synthesis agent lacks gap-detection instructions
B) Coordinator's decomposition is too narrow, missing relevant domains
C) Web search agent's queries aren't comprehensive
D) Document analysis agent over-filters non-visual sources

Answer: B — Logs directly show the coordinator's decomposition is the problem; A/C/D wrongly blame correctly-functioning downstream agents.

Q8 — Scenario 3 — Domain 5.3

Web search subagent times out. Best error propagation design for intelligent coordinator recovery?

A) Structured error context: failure type, attempted query, partial results, alternative approaches
B) Auto-retry w/ backoff in subagent, return generic "search unavailable" after exhausting retries
C) Catch timeout, return empty result set marked successful
D) Propagate exception to a top-level handler that kills the whole workflow

Answer: A — Gives the coordinator what it needs to make an informed recovery decision. B hides context behind a generic status. C is silent failure-suppression (an anti-pattern). D is an overreaction — unnecessary total termination.

Q9 — Scenario 3 — Domain 2.3

Synthesis agent needs frequent fact verification; currently round-trips through coordinator → web search agent → back (2-3 round trips, +40% latency). 85% of verifications are simple fact-checks, 15% need deep investigation. Best approach?

A) Give synthesis agent a scoped verify_fact tool for simple lookups; complex cases still go through coordinator/web search
B) Batch all verification needs, send at end of synthesis pass
C) Give synthesis agent full web search tool access
D) Have web search agent proactively cache extra context anticipating verification needs

Answer: A — Least-privilege scoped tool for the common case, preserves existing pattern for the rare complex case. B creates blocking dependencies (synthesis may need earlier verified facts before continuing). C over-provisions, breaking separation of concerns. D relies on unreliable speculative caching.

Q10 — Scenario 5 (CI/CD) — Domain 3.6

claude "Analyze this pull request for security issues" hangs — waiting on interactive input in CI. Correct fix?

A) Add -p flag
B) Set CLAUDE_HEADLESS=true env var
C) Redirect stdin from /dev/null
D) Add a --batch flag

Answer: A — -p/--print is the documented non-interactive mode. B and D reference features that don't exist; C is a workaround, not the intended mechanism.

Q11 — Scenario 5 — Domain 4.5

Manager proposes switching both (1) blocking pre-merge checks and (2) overnight technical-debt reports to the Message Batches API for 50% savings. Evaluation?

A) Batch only the overnight reports; keep real-time for pre-merge checks
B) Batch both with status polling
C) Keep real-time for both to avoid batch ordering issues
D) Batch both with a real-time timeout fallback

Answer: A — Batches API has up to 24h processing, no SLA — unsuitable for blocking workflows, ideal for overnight jobs. B is unacceptable ("often faster" isn't a guarantee for blocking work). C misunderstands custom_id correlation (solves ordering already). D adds needless complexity vs. simply matching API to workflow.

Q12 — Scenario 5 — Domain 4.6 / 1.6

PR touches 14 files in the stock-tracking module. Single-pass review is inconsistent: detailed on some files, superficial on others, missed bugs, contradictory feedback (flags a pattern in one file, approves the same pattern elsewhere). Fix?

A) Split into focused passes: per-file local analysis + separate cross-file integration pass
B) Require devs to split PRs into 3-4 file chunks before review runs
C) Switch to a higher-tier/larger-context model
D) Run 3 independent passes, flag only issues appearing in ≥2 runs

Answer: A — Directly fixes attention dilution; per-file consistency + a dedicated cross-file pass for data-flow issues. B shifts the burden to developers. C misdiagnoses the issue as context-window size, not attention quality. D would suppress real bugs caught inconsistently by chance.

Pattern Summary Across All 12