Practice & Mock Questions

Domain 1: Agentic Architecture & Orchestration

Q1. A coordinator spawns a document-analysis subagent and a web-search subagent via two Task tool calls — one in turn 3, the other in turn 5 after the first result returned. Team wants true parallelism. What's wrong?

A) Nothing — subagents always run in parallel regardless of turn
B) The two Task calls must be emitted in the same assistant turn to run concurrently
C) Parallel subagents require a parallel: true flag on AgentDefinition
D) Subagents can never run in parallel

Answer: B — The two Task calls must be emitted in the same assistant turn to run concurrently.

Q2. Coordinator's system prompt says "delegate to the summarizer by referencing findings gathered earlier in this conversation." Summarizer keeps producing empty/generic output. Root cause?

A) Summarizer's model too small
B) The coordinator relies on implicit context inheritance that doesn't exist — findings were never placed in the subagent's prompt text
C) Task tool has a token limit truncating findings
D) Summarizer needs a PostToolUse hook to fetch findings itself

Answer: B — The coordinator relies on implicit context inheritance that doesn't exist — findings were never placed in the subagent's prompt text.

Q3. A finance-ops agent must never call transfer_funds unless verify_identity succeeded in the same session — zero tolerance for exceptions. Correct implementation?

A) Detailed system prompt + 3 few-shot examples
B) Programmatic prerequisite gate blocking transfer_funds until verify_identity returns success
C) Tool description reminding the model to double-check
D) Confidence threshold — only transfer when model is "highly confident" identity was verified

Answer: B — Programmatic prerequisite gate blocking transfer_funds until verify_identity returns success.

Q4. Open-ended task: "add comprehensive tests where coverage is weakest" on an unfamiliar legacy codebase. Best decomposition approach?

A) Fixed prompt chaining, alphabetical file order
B) Dynamic/adaptive: map structure → identify high-impact low-coverage areas → prioritized adaptive plan
C) One subagent per file, all in parallel, each told "add tests"
D) Single agent call, whole codebase, large context window

Answer: B — Dynamic/adaptive: map structure → identify high-impact low-coverage areas → prioritized adaptive plan.

Q5. Developer fixes a bug in payment_service.py that the agent analyzed 20 turns ago in the same session. Developer wants targeted re-analysis of just that file, without losing the rest of the session's context. Best approach?

A) New session, full re-exploration
B) fork_session to branch a new exploration path
C) Stay in the current session; explicitly tell the agent the file changed and needs targeted re-analysis
D) --resume with a brand-new session name

Answer: C — Stay in the current session; explicitly tell the agent the file changed and needs targeted re-analysis.

Common trap: confusing fork_session (branch to explore a divergent alternative from a shared baseline) with "same session, inject an update" (incremental correction — no divergence intended). Fork when you want two different paths to compare; stay-and-inform when you just need the existing path corrected.

Domain 2: Tool Design & MCP Integration

Q1. An MCP tool search_docs times out due to a downstream service outage. Another call to the same tool with a valid but very specific query returns zero matching documents. How should these two situations be represented differently?

A) Both isError: true with the same generic message
B) Timeout = isError: true + errorCategory + isRetryable: true; zero-match = successful response with an empty result set
C) Both treated as successful since the tool executed without crashing
D) Timeout = empty result set; zero-match = isError: true

Answer: B — Timeout = isError: true + errorCategory + isRetryable: true; zero-match = successful response with an empty result set.

Q2. One MCP tool manage_ticket handles create/update/close/reassign via an action parameter. Agents frequently pass the wrong action or omit required fields. Best fix?

A) Longer top-level description covering all four actions in one paragraph
B) Split into four distinct tools (create_ticket, update_ticket, close_ticket, reassign_ticket), each with its own schema/required fields
C) Forced tool_choice so manage_ticket is always called first
D) Reduce number of connected MCP servers

Answer: B — Split into four distinct tools (create_ticket, update_ticket, close_ticket, reassign_ticket), each with its own schema/required fields.

Q3. A synthesis subagent is given all 12 system-wide tools "just in case." Likely consequence?

A) No consequence — more tools always help
B) Faster execution — more options
C) Degraded tool-selection reliability + higher chance of misusing tools outside its specialization
D) MCP servers reject connections above a tool count

Answer: C — Degraded tool-selection reliability + higher chance of misusing tools outside its specialization.

Q4. Guarantee extract_metadata always runs as the very first step, regardless of document content. Correct tool_choice config?

A) "auto"
B) "any"
C) {"type": "tool", "name": "extract_metadata"} on the first call, then switch back to auto/any for follow-up turns
D) No tool_choice can guarantee this — needs a hook instead

Answer: C — {"type": "tool", "name": "extract_metadata"} on the first call, then switch back to auto/any for follow-up turns. D is a trap: forced tool_choice is sufficient for "first call" ordering; hooks are for open-ended multi-turn constraints

Q5. Company-wide Slack MCP server, auto-available to every engineer on clone, token from an env var not hardcoded. Where/how?

A) ~/.claude.json, token hardcoded
B) Project's .mcp.json, using ${SLACK_BOT_TOKEN} expansion
C) CLAUDE.md as a text instruction
D) .claude/skills/slack.md with context: fork

Answer: B — Project's .mcp.json, using ${SLACK_BOT_TOKEN} expansion.

Q6. System prompt: "When a user asks anything about their account, immediately use the lookup tool." Two tools: lookup_account_balance, lookup_account_security_settings. Password-reset questions keep routing to the balance tool. Root cause?

A) Model can never distinguish similarly-named tools
B) Generic word "lookup" in the system prompt + vague tool naming creates an unintended keyword association, overriding proper intent-matching
C) Tool listed first in the array always wins ties
D) MCP server misconfigured, exposing only one tool

Answer: B — Generic word "lookup" in the system prompt + vague tool naming creates an unintended keyword association, overriding proper intent-matching.

Q7. A subagent's MCP call to a flaky internal API times out. What should happen first?

A) Immediately propagate a generic failure to the coordinator
B) Attempt local recovery (e.g., one retry) for the transient failure; only propagate to the coordinator if that fails, including partial results + what was attempted
C) Silently return an empty success result
D) Terminate itself and have the coordinator restart the entire workflow

Answer: B — Attempt local recovery (e.g., one retry) for the transient failure; only propagate to the coordinator if that fails, including partial results + what was attempted.

Common traps: (1) reaching for a hook when forced tool_choice already solves a single-call ordering guarantee; (2) missing that generic wording in a system prompt — not just the tool description — can bias tool selection via keyword overlap.

Q8. A jira MCP server exposes a reusable prompt template named create_issue that takes a title and a priority. How does a user invoke it from Claude Code, supplying "Bug in login flow" as title and "high" as priority?

A) @jira:prompt://create_issue?title=Bug in login flow&priority=high
B) /mcp__jira__create_issue "Bug in login flow" high
C) By asking Claude in natural language to "use the create_issue tool" — prompts cannot be invoked directly
D) jira.create_issue({title: "Bug in login flow", priority: "high"})

Answer: B — MCP prompts surface as slash commands in the form /mcp__servername__promptname, with arguments passed space-separated after the command. Server and prompt names are normalized (spaces → underscores). The @ syntax is for resources, not prompts.

Q9. A developer references @docs:file://database/user-model in a prompt. What actually happens, per Claude Code's documented behavior for MCP resources?

A) Claude Code silently ignores it since resources require a preceding tool call to unlock
B) The resource is automatically fetched via the MCP server's resources/read and included as an attachment in the prompt — no explicit tool call is required from the user
C) It triggers the docs server's create_issue prompt with user-model as an argument
D) It only works if the developer first runs /mcp__docs__list_resources

Answer: B — Resources referenced with the @ syntax are automatically fetched and included as attachments. Claude Code also automatically provides underlying list/read tools when a server supports resources, but the user doesn't need to invoke those manually to get this behavior.

Q10. A prompt exposed by an MCP server is named Create Issue (with a space) on a server registered as My Jira. How will Claude Code most likely expose this as a slash command?

A) /mcp__My Jira__Create Issue, preserving spaces exactly
B) It cannot be exposed as a slash command since names contain spaces
C) Server and prompt names are normalized (spaces converted to underscores), so it would appear roughly as /mcp__My_Jira__Create_Issue
D) Claude Code renames it to a random UUID-based command for safety

Answer: C — Server and prompt names are normalized for the slash-command surface, spaces converted to underscores, fitting the /mcp__servername__promptname pattern.

Q11. A project has a GitHub MCP server and a Postgres MCP server configured in project-scoped .mcp.json, plus a personal experimental Slack MCP server in the developer's ~/.claude.json. When Claude Code starts a new session in this project, how does it connect to these servers?

A) It analyzes the first user message and only connects to the server(s) relevant to that specific request
B) It connects to all three automatically at session start — combining .mcp.json and ~/.claude.json — and their tools/resources/prompts become simultaneously available regardless of the current task
C) It connects only to the project-scoped servers in .mcp.json; the personal ~/.claude.json server requires a separate flag to activate
D) It prompts the developer at startup to choose which servers to activate for the session

Answer: B — Claude Code connects to every configured MCP server at session start, combining project-scoped (.mcp.json) and user-scoped (~/.claude.json) servers, with no task-based selective connection. All discovered tools, resources, and prompts become available simultaneously; the model then reasons about which specific one to use for a given request, but the connection step itself isn't selective.

Domain 3: Claude Code Configuration & Workflows

Q1. A senior engineer's testing conventions live in ~/.claude/CLAUDE.md. New hires never see them. Root cause and fix?

A) Conventions too detailed — simplify
B) User-level scope isn't shared via VCS; move to project-level .claude/CLAUDE.md or root CLAUDE.md
C) New hires need /memory reload
D) Must use .claude/rules/ instead of CLAUDE.md for team-wide conventions

Answer: B — User-level scope isn't shared via VCS; move to project-level .claude/CLAUDE.md or root CLAUDE.md.

Q2. A skill runs a large, verbose codebase audit; you don't want raw exploration output cluttering the main conversation. Which frontmatter option?

A) argument-hint
B) allowed-tools
C) context: fork
D) paths

Answer: C — context: fork.

Q3. terraform/** files need specific formatting/tagging conventions that apply nowhere else. Most maintainable scoping?

A) Root CLAUDE.md with a Terraform section
B) .claude/rules/terraform.md with paths: ["terraform/**/*"]
C) A manually-invoked skill
D) Directory-level CLAUDE.md in every subdirectory under terraform/

Answer: B — .claude/rules/terraform.md with paths: ["terraform/**/*"].

Q4. "Fix the typo in the error message on line 42 of utils.py." Best approach?

A) Plan mode first
B) Direct execution — simple, well-scoped, single-file
C) Explore subagent to map the codebase first
D) fork_session to try two fixes in parallel

Answer: B — Direct execution — simple, well-scoped, single-file.

Q5. CI script needs to auto-parse Claude Code's review output and post inline PR comments. Which flags matter most?

A) -p alone, parse plain text with regex
B) --output-format json + --json-schema, alongside -p for non-interactive execution
C) --batch
D) CLAUDE_CI_MODE=true

Answer: B — --output-format json + --json-schema, alongside -p for non-interactive execution.

Q6. Same session that generated a bug fix also reviews that fix, "since it already has full context." Concern?

A) No concern — more context is always better
B) The generating session retains its own reasoning and is less likely to challenge its own decisions — a weaker reviewer than an independent instance
C) Same session can't access --output-format json
D) CI blocks session reuse for security

Answer: B — The generating session retains its own reasoning and is less likely to challenge its own decisions — a weaker reviewer than an independent instance.

Q7. Fixing a migration script with three interacting edge cases (nulls, duplicate keys, out-of-order timestamps — handling one affects the others). Best way to communicate the fix?

A) Three separate messages, one edge case at a time
B) One detailed message covering all three together with example I/O for each, since interacting issues should be addressed together
C) Ask Claude to guess reasonable defaults with no further input
D) Interview pattern — Claude asks about each edge case one at a time across separate turns

Answer: B — One detailed message covering all three together with example I/O for each, since interacting issues should be addressed together. D is a trap: interview pattern is for surfacing unanticipated considerations; these three are already known and interacting — bundling is correct, not sequential discovery

Common traps: (1) confusing the interview pattern (surfacing unknown considerations before implementing) with bundling known interacting issues into one message; (2) assuming any team-wide convention needs .claude/rules/ when project-level CLAUDE.md is simpler and correct for universal (not path-conditional) standards.

Domain 4: Prompt Engineering & Structured Output

Q1. Review prompt says "Only flag issues you're highly confident about, and be conservative." FP rate stays high. Fix?

A) Lower temperature
B) Replace vague confidence language with explicit categorical criteria for report vs. skip
C) Add stronger emphasis wording to the same instruction
D) Remove FP-prone categories permanently

Answer: B — Replace vague confidence language with explicit categorical criteria for report vs. skip.

Q2. Few-shot examples for ambiguous tool selection — what makes an example generalize to novel ambiguous cases?

A) Correct tool call only, no explanation
B) Showing the reasoning for why one tool was chosen over the plausible alternative
C) 20+ examples covering literal cases
D) Only unambiguous examples

Answer: B — Showing the reasoning for why one tool was chosen over the plausible alternative.

Q3. Invoice extraction via tool_use + strict schema is syntactically perfect but line items sum to $940 vs. stated total $1000. What does this reveal?

A) Schema is broken
B) tool_use eliminates syntax errors, not semantic errors — schema compliance ≠ correctness
C) Set tool_choice: "any" to fix it
D) Impossible by design

Answer: B — tool_use eliminates syntax errors, not semantic errors — schema compliance ≠ correctness.

Q4. contract_end_date missing because the source PDF genuinely has no end date (open-ended contract). What should happen?

A) Retry with the same prompt
B) Retry with more specific error feedback
C) Recognize retry-is-futile (info absent from source); make the field nullable/optional so the model returns null instead of fabricating
D) Increase max_tokens

Answer: C — Recognize retry-is-futile (info absent from source); make the field nullable/optional so the model returns null instead of fabricating.

Q5. Overnight technical-debt reports + blocking pre-merge security check. Manager wants both on Batches API for 50% savings.

A) Batch both uniformly
B) Batch the overnight reports only; keep pre-merge synchronous — batch has no SLA, unsuitable for blocking work
C) Batch only the pre-merge check
D) Batch neither

Answer: B — Batch the overnight reports only; keep pre-merge synchronous — batch has no SLA, unsuitable for blocking work.

Q6. 500-document batch job, 12 fail from exceeding context limits. Correct remediation?

A) Resubmit all 500
B) Discard and restart with smaller batch size
C) Resubmit only the 12 failed docs (via custom_id), chunked to fit context limits
D) Move those 12 permanently to the synchronous API

Answer: C — Resubmit only the 12 failed docs (via custom_id), chunked to fit context limits.

Q7. Same CI session both generates a security fix and reviews it, "since it has full context." Weakness + fix?

A) No weakness
B) Generating session is anchored to its own reasoning, less likely to challenge itself; fix = independent instance with no prior reasoning context
C) Weakness is token cost, not quality
D) Only applies to Claude Code, not the Agent SDK

Answer: B — Generating session is anchored to its own reasoning, less likely to challenge itself; fix = independent instance with no prior reasoning context.

Q8. 20-file PR review is inconsistent in depth and produces contradictory findings across files. Fix and why?

A) Bigger context window — it's a capacity issue
B) Per-file local passes + separate cross-file integration pass — fixes attention dilution and keeps depth/consistency uniform while still catching cross-file issues
C) Split into 20 permanently separate single-file PRs, no integration pass ever
D) Run 5 times and average

Answer: B — Per-file local passes + separate cross-file integration pass — fixes attention dilution and keeps depth/consistency uniform while still catching cross-file issues.

No traps missed on first pass through this domain — 8/8. Key reinforced distinctions: syntax vs. semantic error scope of tool_use; retry-futile (info absent) vs. retry-helps (format/structural); batch fit is entirely about latency tolerance, not raw cost savings.

Domain 5: Context Management & Reliability

Q1. A 30-turn support session needs to recall a $127.50 refund amount from turn 4, but the conversation has since been progressively summarized. Best design?

A) Summarize more frequently
B) Extract transactional facts into a persistent "case facts" block included in every prompt, outside the summarized narrative
C) Ask the customer to repeat it
D) Rely on long-context recall

Answer: B — Extract transactional facts into a persistent "case facts" block included in every prompt, outside the summarized narrative.

Q2. Customer says "just get me a real person" while describing a simple, easily-resolvable issue. Correct response?

A) Resolve first, escalate only if they insist again
B) Escalate immediately — honor the explicit request without first attempting to resolve it
C) Run sentiment analysis to confirm frustration level first
D) Ask them to lower expectations

Answer: B — Escalate immediately — honor the explicit request without first attempting to resolve it.

Q3. search_inventory returns zero matches for an oddly-spelled query; separately it times out on another call. How should these be treated?

A) Identically — same retry logic
B) Zero-match = valid successful response; timeout = access failure warranting a retry decision — must be distinguished
C) Zero-match is more severe (possible typo)
D) Both silently suppressed as success

Answer: B — Zero-match = valid successful response; timeout = access failure warranting a retry decision — must be distinguished.

Q4. 50-turn codebase exploration: agent starts saying "typically React hooks work like X" instead of referencing the 3 specific custom hooks it found 20 turns ago. Fix?

A) Restart the IDE — model bug
B) Context degradation; use a scratchpad file to persist key findings so later turns reference recorded facts, not generic patterns
C) Expected behavior, no fix needed
D) Switch to a smaller model

Answer: B — Context degradation; use a scratchpad file to persist key findings so later turns reference recorded facts, not generic patterns.

Q5. Extraction pipeline reports 97% overall accuracy; leadership wants to cut human review. What must happen first?

A) Reduce review immediately — 97% is high
B) Analyze accuracy by document type and field — aggregate accuracy can mask poor performance on specific segments
C) Increase the model's reported confidence threshold
D) Switch to Batches API to cut cost instead

Answer: B — Analyze accuracy by document type and field — aggregate accuracy can mask poor performance on specific segments.

Q6. Two credible sources give different unemployment figures in a synthesis report. Correct handling?

A) Pick the more recent-looking source, drop the other
B) Average the two values
C) Include both, explicitly annotated with sources; let the coordinator/reader decide reconciliation — don't arbitrarily pick one
D) Omit both to avoid appearing inconsistent

Answer: C — Include both, explicitly annotated with sources; let the coordinator/reader decide reconciliation — don't arbitrarily pick one.

Q7. A subagent's DB query times out mid-research. What should it return instead of a generic "search unavailable"?

A) Nothing — silence implies success
B) Structured error object: failure type, query attempted, partial results, alternative approaches
C) Empty result marked as a valid successful query
D) An exception terminating the whole workflow

Answer: B — Structured error object: failure type, query attempted, partial results, alternative approaches.

Q8. Two reports cite 2019 vs. 2026 studies with very different values for the same metric; reviewer calls it "contradictory sources." Best explanation/fix?

A) One source must be wrong; suppress the older one
B) Values may reflect real change over time, not contradiction; requiring publication/collection dates prevents temporal data from being misread as conflicting
C) Unavoidable, no fix exists
D) Always prefer the most recent source and auto-discard older ones

Answer: B — Values may reflect real change over time, not contradiction; requiring publication/collection dates prevents temporal data from being misread as conflicting.

No traps missed — 8/8. Domain 5 completes full coverage of all 5 content domains against the official guide.

Scenario Walkthroughs

Cross-domain, scenario-flavored questions using the exact tool names/framing from each of the 6 official scenarios — this is where domains combine the way the real exam frames questions.

Scenario 1: Customer Support Resolution Agent

Tools: get_customer, lookup_order, process_refund, escalate_to_human. Blends Domains 1, 2, 5.

Q1. Customer message has 3 concerns: non-delivery, double charge, address-update request (no tool exists for the last one). Best approach?

A) Resolve the double charge fully, ignore the delivery issue, explain no address-change tool exists
B) Decompose into 3 concerns, investigate the two tool-supported ones with shared context, synthesize one reply, and escalate/flag only the address-update piece specifically
C) Escalate the entire message to a human since it has three parts
D) Ask the customer to submit three separate requests

Answer: B — Decompose into 3 concerns, investigate the two tool-supported ones with shared context, synthesize one reply, and escalate/flag only the address-update piece specifically. C is a trap: over-escalates — 2 of 3 concerns are within the agent's own capability; escalation should be as narrow as the actual gap

Q2. get_customer returns two matching records (shared family plan phone number). Next step?

A) Proceed with the first record since get_customer "succeeded"
B) Ask for an additional identifier (email, order number) to disambiguate — not a heuristic pick
C) Auto-merge both records
D) Escalate immediately

Answer: B — Ask for an additional identifier (email, order number) to disambiguate — not a heuristic pick. D is a trap: multiple matches = information gap, not one of the 3 valid escalation triggers; the agent can make progress by asking one more question

Q3. lookup_order times out (backend outage) on one call; on another, a valid-but-nonexistent order number returns no results. Representation?

A) Both isError: true, same generic message
B) Timeout = isError: true + errorCategory: transient + isRetryable: true; nonexistent order = successful empty result
C) Both isError: false
D) Reversed from B

Answer: B — Timeout = isError: true + errorCategory: transient + isRetryable: true; nonexistent order = successful empty result.

Q4. A hook blocks process_refund above $500, redirects to escalate_to_human. Handoff payload should contain?

A) Just the amount + "needs approval" flag
B) Structured summary: customer details, root cause, recommended action — human has no transcript access
C) Full raw unformatted transcript
D) Nothing — human re-investigates from scratch

Answer: B — Structured summary: customer details, root cause, recommended action — human has no transcript access.

Q5. Need get_customer verified at some point before process_refund, across a long multi-turn session. Correct mechanism?

A) Forced tool_choice on the first call only — "persists" for the rest of the session
B) Programmatic prerequisite gate blocking process_refund at the tool-execution layer until get_customer has succeeded at any earlier point
C) System prompt reminder
D) tool_choice: "any"

Answer: B — Programmatic prerequisite gate blocking process_refund at the tool-execution layer until get_customer has succeeded at any earlier point. A is a trap: forced tool_choice is a single-call guarantee, not an open-ended session constraint

Q6. Order # (turn 2) and refund amount (turn 15) start getting lost/genericized by turn 22 after progressive summarization. Prevention?

A) Ask customer to repeat numbers periodically
B) Persistent "case facts" block in every prompt, outside the summarized narrative
C) Bigger context window
D) Never summarize at all

Answer: B — Persistent "case facts" block in every prompt, outside the summarized narrative.

Key lesson from this round: escalation is a narrow tool for 3 specific triggers (explicit request, policy gap, inability to progress) — not a general safety valve for "this is ambiguous/has multiple parts." Watch for the instinct to escalate whenever a request looks messy; check first whether the agent can resolve part of it or just needs one clarifying question.

Scenario 2: Code Generation with Claude Code

(pending)

Scenario 3: Multi-Agent Research System

Coordinator + web-search, document-analysis, synthesis, report-generation subagents. Blends Domains 1, 2, 5. First scenario quiz with properly randomized answer positions — bias-free 6/6.

Q1. Report on "risks to global semiconductor supply chains in 2025" — coordinator decomposes into 3 manufacturing-only subtasks; report misses geopolitical/natural-disaster/talent risk categories entirely, despite subagents executing flawlessly. Root cause?

A) Coordinator's task decomposition is too narrow, capturing only supply-side manufacturing risks while omitting other major categories
B) Web-search subagent's search engine has insufficient geopolitical coverage
C) Synthesis subagent's relevance filtering discarded valid findings
D) Report-generation template only has manufacturing sections

Answer: A — Coordinator's task decomposition is too narrow, capturing only supply-side manufacturing risks while omitting other major categories.

Q2. Coordinator needs web-search and document-analysis subagents to run concurrently, no dependency between them. Correct structure for true parallelism?

A) Emit one Task call, wait for result, emit the second in a separate turn
B) Set parallel_execution: true on AgentDefinition
C) Emit both Task tool calls within the same single assistant turn
D) Configure both subagents to share a context window to self-coordinate timing

Answer: C — Emit both Task tool calls within the same single assistant turn.

Q3. Synthesis subagent frequently needs simple fact-checks; full research stays with web-search via coordinator. Best tool distribution?

A) Give synthesis the full web-search tool set
B) Synthesis always returns to coordinator for any verification, however simple
C) Remove verification capability entirely from synthesis
D) Scoped verify_fact tool on synthesis for the common simple case; coordinator route preserved for rare complex cases

Answer: D — Scoped verify_fact tool on synthesis for the common simple case; coordinator route preserved for rare complex cases.

Q4. A DOI link is permanently broken (404, not transient) on one fetch; a separate valid-topic search returns zero relevant papers. Reporting?

A) Broken DOI = non-retryable access/validation failure with details of what was attempted; zero-relevant-papers = successful valid empty result — fundamentally different situations
B) Both treated as successful empty results
C) Both trigger immediate human escalation
D) Broken DOI auto-retried up to 5 times before reporting failure

Answer: A — Broken DOI = non-retryable access/validation failure with details of what was attempted; zero-relevant-papers = successful valid empty result — fundamentally different situations.

Q5. Two findings cite different EV market-share figures (18% June 2025, 22% December 2025, same research firm). Best synthesis handling?

A) Report only 22% since it's more recent
B) Average to 20%
C) Include both figures with dates and source attribution — likely reflects real change over time, not contradiction
D) Omit both since they disagree

Answer: C — Include both figures with dates and source attribution — likely reflects real change over time, not contradiction.

Q6. Coordinator always invokes all 4 subagents even for simple queries like "define supply chain resilience in one sentence," adding needless latency/cost. Fix?

A) Reduce subagents system-wide to just two
B) Coordinator analyzes query complexity and dynamically decides which subagents are needed, rather than always running the full fixed pipeline
C) Cache repeated simple queries (only helps on repeats, not the general problem)
D) Force tool_choice: "any" so the coordinator must pick exactly one subagent

Answer: B — Coordinator analyzes query complexity and dynamically decides which subagents are needed, rather than always running the full fixed pipeline.

Clean 6/6 — validated, bias-free signal of strong mastery across Domains 1/2/5 orchestration concepts.

Scenario 4: Developer Productivity with Claude

Built-in tools (Read/Write/Bash/Grep/Glob) + MCP servers, for codebase exploration and automation. Blends Domains 2, 3, 1. Bias-free randomized quiz — 6/6.

Q1. Find every file named like *.controller.ts, regardless of directory. Best approach?

A) Grep for the string "controller" across file contents
B) Read every file and check filenames manually
C) Glob with pattern **/*.controller.ts
D) Bash find piped through Grep searching file contents

Answer: C — Glob with pattern **/*.controller.ts.

Q2. utils/index.ts re-exports a function under a different name: export { formatDate as dateFormat } from './date'. Find every call site, including barrel-file imports as dateFormat. Correct approach?

A) Identify all exported/re-exported names (formatDate and dateFormat), then Grep for each
B) Grep only for "formatDate" everywhere
C) Grep only for from './date' imports
D) Read every file manually to scan for usages

Answer: A — Identify all exported/re-exported names (formatDate and dateFormat), then Grep for each.

Q3. Edit fails because anchor text "return null;" appears 14 times in the file (non-unique match). Best next step?

A) Keep retrying Edit with the same anchor text
B) Blind Bash sed regex replacement without reviewing context
C) Abandon the edit, ask the user to do it manually
D) Read the full file, make the change in memory, then Write it back

Answer: D — Read the full file, make the change in memory, then Write it back.

Q4. "Add comprehensive test coverage to this 15-year-old legacy billing module, no existing tests, undocumented business logic." Best decomposition?

A) Write tests for every function in file order immediately
B) Map the module's structure, identify highest-risk/highest-impact areas (money-handling logic), build a prioritized plan that adapts as discoveries happen
C) One subagent per file in parallel, each told "add tests"
D) Refuse until a human fully documents the business logic first

Answer: B — Map the module's structure, identify highest-risk/highest-impact areas (money-handling logic), build a prioritized plan that adapts as discoveries happen.

Q5. Team wants Jira integration so the agent can look up ticket details. Best practice?

A) Build a fully custom MCP server from scratch — always more reliable
B) Skip MCP, scrape the Jira web UI directly with Bash
C) Embed API keys directly in the system prompt for inline calls
D) Use an existing, well-supported community MCP server; reserve custom builds for team-specific workflows

Answer: D — Use an existing, well-supported community MCP server; reserve custom builds for team-specific workflows.

Q6. "Automate repetitive tasks" agent given full unrestricted Bash + 15 MCP tools "to be safe." Consequence and better design?

A) Tool-selection reliability degrades, agent may misuse out-of-scope tools; scope tool access tightly to the role's actual needs
B) No consequence — broader access always helps
C) Agent runs faster with more options
D) MCP servers auto-throttle excess registrations

Answer: A — Tool-selection reliability degrades, agent may misuse out-of-scope tools; scope tool access tightly to the role's actual needs.

Clean 6/6 — validated. Correctly avoided over-provisioning-as-safety trap (Q6) and applied the wrapper-export tracing skill correctly when the name actually changes (Q2), a subtler case than earlier drilling.

Scenario 5: Claude Code for Continuous Integration

Automated code review, test generation, PR feedback with minimal false positives. Blends Domains 3, 4. Bias-free randomized quiz — 6/6.

Q1. CI runs claude -p "Review this PR" --output-format json without --json-schema. Output is valid JSON but structure varies run to run, breaking the parser. Fix?

A) Remove --output-format json
B) Wrap the parser in a try/except that guesses structure at runtime
C) Switch to --output-format text and regex-parse instead
D) Add --json-schema to enforce a fixed, consistent output structure

Answer: D — Add --json-schema to enforce a fixed, consistent output structure.

Q2. "Missing null check" findings are a known false positive (handled safely elsewhere by a global exception wrapper) in ~70% of PRs; developers now ignore the bot entirely, including valid findings elsewhere. Fix?

A) "Be more careful and only report high-confidence null-check issues"
B) Shut down the entire bot until perfect
C) Temporarily disable the "missing null check" category while improving its prompt with explicit criteria (documenting the exception-wrapper case), restoring trust elsewhere
D) Lower temperature to reduce randomness

Answer: C — Temporarily disable the "missing null check" category while improving its prompt with explicit criteria (documenting the exception-wrapper case), restoring trust elsewhere.

Q3. A new commit triggers a re-review after 5 inline comments already posted. How to avoid duplicate comments on already-flagged, still-unfixed issues?

A) Include prior review findings in context; instruct the model to report only new/still-unaddressed issues
B) Just run fresh each time, post whatever comes back
C) Delete all previous comments, post fresh every time regardless of overlap
D) Skip re-review entirely until the final commit before merge

Answer: A — Include prior review findings in context; instruct the model to report only new/still-unaddressed issues.

Q4. Same session generates a bug fix AND the tests validating that fix. Tests almost always pass even when the fix is subtly wrong — they mirror the fix's own flawed assumptions. Diagnosis + fix?

A) Needs more extended thinking time in the same session
B) Same session carries its own reasoning/assumptions forward, so tests validate the fix's assumptions rather than probing them; use an independent instance without the fix's reasoning context to generate tests
C) Expected and acceptable — full context is good
D) Switch test frameworks

Answer: B — Same session carries its own reasoning/assumptions forward, so tests validate the fix's assumptions rather than probing them; use an independent instance without the fix's reasoning context to generate tests.

Q5. Severity labels are inconsistent — same issue type called "critical" in one PR, "minor" in another. Fix?

A) Remove severity labels entirely
B) Forced tool_choice to ensure the tool is called (doesn't address severity consistency)
C) Have the model double-check its own ratings by re-reading its own output
D) Define explicit severity criteria with concrete examples per level, reinforced with few-shot examples of correctly-classified findings

Answer: D — Define explicit severity criteria with concrete examples per level, reinforced with few-shot examples of correctly-classified findings.

Q6. Test-generation keeps proposing scenarios that duplicate the existing suite, wasting reviewer time. Fix?

A) Provide existing test files as context to avoid duplication, and document testing standards/criteria/fixtures in CLAUDE.md
B) Bigger context window, nothing else
C) Strict word-count limit on generated tests
D) Disable generation once the suite exceeds 100 tests

Answer: A — Provide existing test files as context to avoid duplication, and document testing standards/criteria/fixtures in CLAUDE.md.

Clean 6/6 — validated. Notable: correctly extended the self-review weakness (Domain 4.6) to test-generation-from-the-same-session, not just code-review-of-the-same-session (Q4) — good conceptual transfer.

Scenario 6: Structured Data Extraction

Extraction, JSON schema validation, edge cases, downstream integration. Blends Domains 4, 5. Bias-free randomized quiz — 6/6. Completes all 6 scenarios.

Q1. Schema requires non-empty patient_allergies array; many intake forms genuinely have none. Risk + fix?

A) Model consistently asks a human to review — can't satisfy required-but-empty
B) Extraction always fails validation and halts the pipeline — intended behavior
C) Model may fabricate a plausible allergy to satisfy the required field; fix by making it optional/nullable so null/empty is a valid, honest response
D) Not a real risk — tool_use schemas guarantee only true values

Answer: C — Model may fabricate a plausible allergy to satisfy the required field; fix by making it optional/nullable so null/empty is a valid, honest response.

Q2. governing_law_jurisdiction missing — the actual signed contract genuinely never specifies one. Correct handling?

A) Retry-is-futile (info absent from source); return null rather than retry or fabricate
B) Retry, asking the model to look harder — retries always eventually find missing fields
C) Default to the company's headquarters jurisdiction
D) Escalate to human review always, regardless of confidence

Answer: A — Retry-is-futile (info absent from source); return null rather than retry or fabricate.

Q3. 98% overall invoice accuracy hides 60% accuracy on handwritten invoices (99.5%+ on typed). Leadership wants to cut review based on the headline number. First step?

A) Approve the reduction — 98% clears typical thresholds
B) Increase reported confidence threshold uniformly
C) Switch to Batches API to cut cost while evaluating
D) Segment accuracy by document type before any review-reduction decision — aggregate masks the handwritten-invoice problem

Answer: D — Segment accuracy by document type before any review-reduction decision — aggregate masks the handwritten-invoice problem.

Q4. Batch-processing 10,000 receipts overnight, each sometimes needing a mid-extraction currency-conversion tool call before finalizing. Key Batches API limitation?

A) Full price for tool-using requests, eliminating savings
B) No multi-turn tool calling within a single request — can't call the tool mid-request and continue reasoning with the result in that same request
C) Only plain text, no document images
D) No limitation — identical to synchronous API

Answer: B — No multi-turn tool calling within a single request — can't call the tool mid-request and continue reasoning with the result in that same request.

Q5. Original contract + later addendum changing one clause; a field value differs between them. Correct handling in synthesis?

A) Preserve which document each value came from (with date/order), flag the discrepancy for review to confirm the addendum supersedes — don't silently pick one
B) Prefer whichever document is first alphabetically
C) Silently use only the original contract's value
D) Average/merge the two values

Answer: A — Preserve which document each value came from (with date/order), flag the discrepancy for review to confirm the addendum supersedes — don't silently pick one.

Q6. Resume parser outputs per-field confidence scores. Before using them to route to a limited review team, what must happen?

A) Trust raw scores immediately, route anything below 0.7
B) Ignore scores entirely, review every resume regardless
C) Calibrate field-level confidence against a labeled validation set first, to know what a score actually means in real accuracy, before setting routing thresholds
D) Only trust scores for numeric fields like years_of_experience

Answer: C — Calibrate field-level confidence against a labeled validation set first, to know what a score actually means in real accuracy, before setting routing thresholds.

Clean 6/6 — validated. Completes all 6 scenario walkthroughs.

Mock Exam Questions (Verified)

A 60-question third-party mock exam, extracted and cross-checked against the official guide and Claude Code documentation. Four questions were corrected during verification (Q9, Q11, Q26, Q57) — the answers below reflect the corrected, guide-aligned versions.

Mock Exam — Part 1: CI/CD Code Review & Prompt Engineering

Q1. Automated PR review calls a report_findings tool returning a JSON array. On a 30+ file PR, the response hits max_tokens and truncates, breaking the pipeline. Most effective fix?

A) Switch off tool use; have Claude return findings as a markdown list instead
B) Add retry logic that detects truncated JSON and re-sends asking for only critical/high severity findings
C) Increase max_tokens to the model's maximum and instruct Claude to keep descriptions under 50 words
D) Split the review into multiple API calls, each analyzing a subset of changed files, then merge the resulting findings arrays

Answer: D — Chunking is the scalable pattern for output-size limits; raising max_tokens still hits a hard ceiling eventually, and dropping severities changes review semantics.

Q2. 55% of generated unit tests are low-value (trivial, duplicate, convention-violating). How do you reduce this at generation time, not after?

A) Restrict test generation to directories where historical quality metrics are higher
B) Implement a two-phase generation where a second Claude call scores and filters low-quality tests
C) Document testing priorities, valuable-test criteria, fixtures, and good/bad examples in CLAUDE.md
D) Add post-generation coverage analysis that filters out tests not increasing line coverage

Answer: C — Improves the model's instructions/context before generation, rather than filtering after the fact. Matches Domain 3.6's CLAUDE.md-for-testing-standards skill.

Q3. Code review consistently flags intentional team patterns (force-unwrap in tests, large coordinator classes matching project architecture, deprecated-but-internally-approved imports). ~30% of findings are dismissed as project-specific false positives. Which approach prevents the model from generating these findings in the first place?

A) Post-process results to suppress findings containing terms like "force unwrap" or "large class"
B) Have developers add inline suppression comments/flags, preprocessed out of the diff
C) Document the team's accepted patterns and intentional conventions in CLAUDE.md so the model receives this context on every review
D) Analyze only the changed lines in the diff, without surrounding file context

Answer: C — Claude lacks project-specific knowledge; the code isn't wrong, it's following conventions Claude doesn't know about. CLAUDE.md is the mechanism for persistent review context.

Q4. ~35% false-positive rate on style/security/performance findings that are safe in this deployment's context. Which approach best enables the model to generalize its judgment to novel code patterns it hasn't seen before?

A) Post-processing keyword filtering for terms like "convention" or "trade-off"
B) Include a few annotated examples in the prompt distinguishing acceptable patterns from genuine issues, per category
C) Add instructions like "Be conservative" and "Consider that some patterns may be intentional"
D) Create a comprehensive reference specification of all patterns that should not be flagged, in the system prompt

Answer: B — Few-shot examples let the model infer underlying principles and apply them to new, unseen code; vague instructions and exhaustive specs don't teach nuance the same way.

Q5. Review correctly flags completely untested functions, but misses untested conditional branches/error-handling paths within tested functions. Most effective fix without overcomplicating the pipeline?

A) Restructure the prompt to interleave each function immediately followed by its test cases
B) Multi-phase pipeline: one call extracts all conditional branches, a second cross-references against test assertions
C) Add explicit instructions directing the model to enumerate each conditional branch/exception path and verify each has a corresponding test assertion
D) Include few-shot examples showing an uncovered branch paired with the review comment identifying the missing test

Answer: C — Turns the task into explicit structured reasoning (enumerate → verify) rather than relying on implicit reasoning, with minimal architectural complexity.

Q6. ~50% of findings are dismissed as correct-but-minor (style preferences, patterns acceptable in this codebase). Before adding infrastructure, what prompt design change most effectively reduces dismissible findings while keeping genuine-issue detection?

A) Implement a secondary classification model filtering findings by predicted developer acceptance
B) Append "Report findings you are highly confident are genuine problems" to every prompt
C) Add explicit criteria defining which issues to report (bugs, security) versus which to skip (minor style, local patterns)
D) Have Claude assign each finding a confidence score (0-10) and only include scores ≥8

Answer: C — Root cause is unclear review criteria, not poor reasoning; explicit inclusion/exclusion criteria align model behavior with actual team expectations.

Q7. Weekly release notes consolidate ~200 commits, one Messages API call per commit on a Sonnet-tier model. Results aren't needed until the next morning (~12h acceptable latency). Need lower per-token cost, same model/prompts/quality. Which approach fits?

A) Issue the 200 requests in parallel via concurrent connections, since concurrency lowers per-token price
B) Concatenate all 200 commits into one request so the model returns all summaries at once
C) Switch from Sonnet to a Haiku-tier model for lower per-token rates
D) Submit the 200 requests via the Message Batches API and retrieve results after the batch finishes, at a 50% discount

Answer: D — Matches every stated constraint: same model, same prompts, latency-tolerant, cost reduction via the Batches API's discount.

Q8. Review prompt includes: "Only flag critical issues that would definitely cause production failures. Ignore minor concerns and anything you're uncertain about." Developers confirm some missed bugs were real logic errors the model noticed internally but chose not to report. Output must stay structured/tagged/actionable. Best fix?

A) Remove the uncertainty-related instruction and let the model use default judgment
B) Add a second review pass rerunning the same prompt on the same diff
C) Enable extended thinking and step-by-step reasoning before producing the review
D) Instruct the model to report all findings with a confidence level and severity tag, deferring filtering to a downstream step

Answer: D — The prompt causes suppression before findings ever reach the user; returning everything with metadata and filtering downstream separates detection from filtering while preserving structure.

Q9. Large-PR reviews (150+ files) sometimes run 20+ minutes and cost $8-12 via an extensive agentic loop. The team needs Claude Code itself (not the external job runner) to abort once it hits a fixed iteration count and a fixed dollar amount, per invocation. Which configuration directly enforces both limits?

A) Add --max-turns and --max-budget-usd flags to the Claude Code invocation, capping iterations and spending
B) Set tool permissions so requests outside an explicit allow-list are denied
C) Set a duration variable in the CI job and monitor per-run costs in the usage dashboard
D) Add prompt instructions asking Claude to minimize iterations and lower per-call cost

Answer: A — Claude Code supports --max-turns (caps agentic turns) and --max-budget-usd (caps API spend) as hard, built-in execution limits. Permissions address security, not iteration/cost; dashboards observe but don't enforce; prompts are advisory only.

Q10. Claude Code returns feedback but only comments on the piped diff text — it never reads related files in the checked-out repo. Which change causes Claude to read related repo files while still applying custom review instructions?

A) Remove the custom system-prompt override; move review instructions into a root CLAUDE.md instead
B) Keep the custom system prompt, but add an option enabling recursive file access for otherwise-disabled filesystem tools
C) Append/extend Claude Code's default prompt with the review instructions, rather than replacing the built-in prompt entirely
D) A different, unrelated configuration option

Answer: C — Replacing the built-in system prompt can accidentally strip out the instructions that enable agentic behavior (reading files, using tools); appending preserves them. Confirmed via official docs: --append-system-prompt is the real, recommended mechanism.

Q11. CI takes ~18s to initialize before analysis begins, due to auto-discovery of hooks, MCP servers, plugins, and nested CLAUDE.md files across a monorepo. Only the root-level CLAUDE.md is actually needed. Most effective approach?

A) Keep default initialization; disable dynamic system-prompt sections to improve prompt-cache hit rates
B) Explicitly point Claude Code at the root-level CLAUDE.md needed for the review, rather than relying on full monorepo auto-discovery of hooks, MCP servers, plugins, and nested configs
C) Replace the default prompt entirely with one containing only the CLAUDE.md content
D) Run in a bare/minimal mode specifying all review criteria inline in the CI prompt argument

Answer: B — Explicitly providing the needed project context avoids expensive repository-wide discovery while preserving standards and default Claude Code behavior — explicit configuration beats broad auto-discovery when you already know exactly what's needed.

Q12. Review generates ~8 findings/PR; only ~4 are genuine bugs. Noise: style issues already caught by the linter, findings on auto-generated template code, and findings on intentional reusable-helper conventions. Most effective fix?

A) Configure separate CLAUDE.md files per code area (generated code, templates, general code)
B) Add explicit expectations to the project's CLAUDE.md: which patterns are intentional, that linting is handled elsewhere, and that the generated/template directory is auto-generated
C) Add --system-prompt instructions to the CI invocation covering all three noise sources
D) Create a REVIEW.md in the repo root with checklists for generated files and historical defects

Answer: B — A single well-written project-level CLAUDE.md is simpler and sufficient; the problem doesn't require splitting guidance by directory.

Q13. A developer implements a function with Claude Code, then asks the same session to review it before committing. A separate, independent CI review later catches several bugs the same-session review missed. Best explanation?

A) The CI environment has access to the full codebase, while the local session only saw the current file
B) The context window filled with conversation history, leaving less room for thorough analysis
C) Claude retains context about its own prior reasoning in the session, making it less likely to question or re-evaluate its earlier decisions
D) The CI review uses a more specific, better-calibrated prompt than the developer's general request

Answer: C — The same conversation that generated the code carries forward the reasoning and assumptions behind it, making independent critique less likely; a fresh session isn't anchored the same way.

Q14. A single review prompt covers security, API design, and business logic. API-design recall is ~82%, business-logic recall is ~35%. Adding business-logic few-shot examples raises that to ~41% but drops API-design recall. How do you improve both?

A) Upgrade to a more capable model tier, expecting stronger reasoning to eliminate the trade-off
B) Replace the few-shot examples with a detailed checklist of specific business-logic edge cases
C) Split the review into separate focused prompts (one per concern area), each with dedicated examples, then consolidate findings
D) Provide the full repository as context instead of only the changed files

Answer: C — A single prompt optimizing for multiple different objectives creates prompt interference; decomposing into focused prompts per concern removes the competition for context and attention.

Q15. Review prompt says: "Only report high-confidence issues you are certain about" and "err on the side of not commenting." Precision is high, recall is low — a race condition that caused a production outage went unreported. Need substantially better detection while keeping false positives manageable.

A) Split review into two Claude-based filtering stages: one flags everything with metadata, a second thresholds those findings
B) Expand context with related test files, recent git history, and the dependency graph
C) Add few-shot examples of bug categories to flag, while keeping the high-confidence filtering instruction
D) Remove the conservative filtering instructions, report all potential issues, then apply a programmatic downstream filter

Answer: D — The prompt's conservative instruction is the root cause of suppression; maximizing recall first and filtering deterministically downstream is the standard fix.

Mock Exam — Part 2: Multi-Agent Research System

Q16. The coordinator invokes web-search, waits for the response, then invokes document-analysis, waits again — but the two tasks are independent. How should the system be modified to run them concurrently?

A) Create an external async orchestration layer that spawns parallel coordinator-subagent pairs and aggregates results
B) Structure the coordinator to issue both tool calls in a single response/message, rather than across separate turns
C) Add detailed system-prompt instructions explaining the benefits of parallelism and requesting simultaneous invocation
D) Switch from Sonnet to Haiku so each individual invocation completes faster

Answer: B — Claude can invoke multiple independent tool calls within the same assistant turn; the runtime executes them concurrently, cutting latency without added infrastructure.

Q17. A financial-API agent (structured JSON), a news agent (prose), and a patent agent (structured data) all feed a synthesis agent that converts everything to bullet points — losing tabular clarity for financials and narrative flow for news. What change most improves briefing quality?

A) Standardize all subagent outputs to JSON with claim/evidence/source/confidence fields
B) Add a format-conversion layer transforming all outputs into one common intermediate representation
C) Update synthesis to render each content type appropriately — financial data as tables, news as prose, patents as structured summaries
D) Force all subagent outputs to be prose summaries with inline citations

Answer: C — Different information types communicate best in different formats; the fix is in the presentation layer, not data collection.

Q18. All four subagents have access to the complete tool set. The pricing agent frequently attempts web searches; the report generator tries to analyze documents. Primary cause?

A) Tool definitions consume too much context window space
B) Choosing from all available tools instead of only relevant ones increases decision complexity beyond reliable selection thresholds
C) The coordinator can't distinguish which capabilities each subagent has
D) Role descriptions in system prompts conflict with the granted tool access

Answer: B — Giving every agent every tool increases selection difficulty and cross-specialization misuse; least-privilege scoping is the fix.

Q19. The coordinator gives the web-search subagent exact queries, source priorities, and date filters. In production, the subagent reports "insufficient results" rather than trying alternatives when prescribed searches fail, and rarely surfaces valuable unexpected sources. Most effective fix?

A) Classify queries as "well-defined" vs. "exploratory" and use different instruction styles for each
B) Remove procedural details entirely, delegating with a simple goal like "research X thoroughly"
C) Add explicit fallback directives to the detailed instructions (e.g., "if fewer than N results, try alternative phrasings")
D) Specify research goals and quality criteria (coverage breadth, source diversity, recency) rather than procedural search steps, letting the subagent determine its own strategy

Answer: D — Over-constraining with exact procedures prevents adaptation; specifying the objective and letting the specialized agent choose its strategy restores adaptability.

Q20. A legal case citing 12 precedents is analyzed sequentially, taking 3+ minutes. Reduce latency while preserving the coordinator's ability to monitor and debug the system?

A) Recursive agent hierarchy subdividing work among child agents down to single-precedent granularity
B) A message queue processing precedent-analysis tasks asynchronously via a worker pool
C) Coordinator spawns parallel document-analysis subagents, each handling a subset of precedents, then aggregates before synthesis
D) Let the document-analysis subagent spawn its own specialized subagents dynamically when it hits many-citation cases

Answer: C — Precedents are independent, ideal for parallel fan-out/fan-in under the coordinator, preserving centralized observability and debuggability.

Q21. Simple fact-checks traverse the full 4-agent pipeline (40+ seconds); complex comparative queries genuinely need the full pipeline. Query distribution keeps evolving. Most effective approach?

A) Train a query-complexity classifier on labeled historical data, retraining periodically
B) Create a fixed fast path for factual questions that bypasses subagents entirely, full pipeline for everything else
C) Have the coordinator analyze each query and dynamically decide which subagents to invoke, based on its own assessment
D) Implement pattern-based routing categorizing queries by structure, mapped to predefined subagent combinations

Answer: C — Dynamic LLM-based routing adapts naturally as query types evolve, without retraining or maintaining brittle rules.

Q22. After web-search and document-analysis both complete successfully, the coordinator invokes synthesis — which responds that no research findings were provided. Most likely cause?

A) The synthesis agent's context window isn't large enough to hold both prior outputs
B) The subagents need to share a single AI conversation to enable automatic context sharing
C) The coordinator didn't include the outputs from the previous agents in the synthesis agent's prompt
D) The synthesis agent needs tools that fetch results directly from the other agents' conversation histories

Answer: C — Subagents don't automatically share context; the coordinator must explicitly collect and forward prior outputs into each new invocation's prompt.

Q23. Web-search returns "2024: 43.7% adoption"; document-analysis returns "2022: 28% adoption" for the same metric. Synthesis incorrectly flags these as contradictory instead of recognizing growth over time. Best fix?

A) Configure web-search to only return results from the past six months
B) Add a conflict-resolution agent that automatically discards older data whenever newer data exists
C) Require subagents to include publication or data-collection dates in their structured outputs
D) Instruct synthesis to always treat the most recent data as authoritative, placing older findings in a historical appendix

Answer: C — The sources don't actually disagree, they refer to different points in time; temporal metadata lets synthesis correctly interpret a trend instead of a contradiction.

Q24. Web-search has gathered sources; document-analysis now needs to examine them. How does information typically flow between these two subagents?

A) Through an event-driven message queue, with document-analysis subscribing to web-search completion events
B) Web-search directly invokes document-analysis, passing discovered sources as parameters
C) Each agent accesses a shared memory store where web-search writes and document-analysis reads
D) The coordinator receives web-search's output and includes the relevant findings in document-analysis's prompt when invoking it

Answer: D — Specialized subagents don't call each other directly or share memory automatically; the coordinator centralizes all information flow.

Q25. AgentDefinitions are configured correctly for four subagents. The coordinator reasons "I'll ask the web search agent..." but no subagent is ever invoked, with no errors in the logs, and the coordinator proceeds with incomplete information. Most likely cause?

A) The coordinator's reasoning is too long, truncating the tool invocation before the subagent type is specified
B) Subagent context isolation means task descriptions don't automatically reach subagents unless explicitly configured
C) The AgentDefinitions are fine, but the coordinator's system prompt doesn't explicitly list the available subagent types
D) The coordinator's allowedTools doesn't include the Task tool, so it can reason about delegation but can never actually invoke it

Answer: D — Reasoning about delegation is separate from actually invoking a subagent via the Task tool; without Task in allowedTools, the coordinator can talk about delegating but never can.

Q26. After web-search and document-analysis complete, the coordinator needs to give the synthesis subagent their findings. Correct approach?

A) Provide the subagent with tool definitions to request outputs from other subagents via callbacks
B) Spawn the subagent with only a brief task description, relying on automatic context inheritance from the coordinator
C) Include the complete findings from both subagents directly in the synthesis subagent's prompt
D) Pass reference identifiers and configure the subagent with read access to a shared memory store where other subagents deposited their results

Answer: C — Subagents don't automatically share context. The coordinator must include the complete findings from both prior agents directly in the synthesis subagent's prompt — passing references to a separate memory store adds unnecessary indirection for this use case and isn't how the guide's own explicit skill describes this pattern.

Q27. Sometimes conflicting subagent findings get flattened into an overconfident single statement (losing nuance); other times reports over-hedge into vague, unhelpful statements. E.g., web-search: "$5B (methodology varies)"; document-analysis: "$6B (±$7B, 95% CI)". What systematic approach best addresses this?

A) Instruct synthesis to structure reports with explicit sections distinguishing well-established findings from contested ones, preserving original source characterization and methodology
B) Configure subagents to only report findings meeting a high-confidence threshold, filtering uncertain information before it reaches the coordinator
C) Implement a confidence-calibration layer normalizing subagent uncertainty into standardized 0.0-1.0 scores, then weight-average findings
D) Add a verification subagent that only passes claims corroborated by at least two independent sources

Answer: A — The goal is communicating uncertainty correctly, not eliminating it; preserving disagreement with methodology context produces reports that are both accurate and transparent.

Q28. Synthesis flags three key research questions as unanswered because web-search and document-analysis found nothing on those subtopics. The coordinator currently proceeds straight to report generation anyway, producing incomplete coverage. Most effective fix?

A) Coordinator evaluates the synthesis output for gaps, re-delegates to research subagents with targeted queries, then re-invokes synthesis
B) Give the synthesis agent direct access to web-research tools so it can fill gaps autonomously
C) Increase the initial breadth of queries sent to research subagents to reduce the chance of missing information
D) Have report generation simply note which questions couldn't be answered

Answer: A — A good coordinator shouldn't accept an incomplete synthesis; it should detect gaps, re-research, and re-synthesize before finalizing.

Q29. Reports make factual claims without proper citations — the report generator can't attribute statements to sources because metadata was lost during summarization as findings passed through synthesis. Most effective fix?

A) Have each agent output structured data separating content summaries from source metadata (URLs, document names, page numbers)
B) Skip summarization; pass full raw outputs from web-search and document-analysis directly to report generation
C) Have the report generator re-query web-search to re-locate sources for each claim
D) Instruct synthesis to embed source references inline within its summary text using a consistent citation format

Answer: A — Every agent should produce structured outputs separating content from metadata, so provenance survives every stage of the pipeline.

Mock Exam — Part 3: Structured Data Extraction

Q30. A single analyze_document tool takes a document plus a free-text instruction. "Extract key financial metrics" sometimes returns narrative summaries; "summarize the methodology" sometimes returns raw data tables. 35% of results need re-requests. Most effective fix?

A) Split the generic tool into purpose-specific tools (extract_data_points, summarize_sections, verify_claim_against_source), each with well-defined I/O contracts
B) Expand the tool description with detailed examples showing how instruction phrasings map to output formats
C) Keep the single tool but add an analysis_mode enum parameter
D) Have the coordinator pre-classify each request before passing instructions to the same generic tool

Answer: A — One tool trying to perform several fundamentally different operations produces inconsistent output; splitting into specialized tools eliminates the ambiguity at its source.

Q31. A summary section states "Battery: 4000mAh," a detailed specs table states "Battery: 4200mAh." This occurs in ~15% of documents, and historical analysis shows the detailed table is correct 90% of the time. Most effective approach?

A) Change the field to an array capturing all values and source locations, letting downstream systems apply precedence
B) Implement schema validation that rejects results with conflicting values, requiring source correction first
C) Include extraction instructions to prefer the detailed specifications table when multiple values exist, keeping the single-value schema
D) Add an extraction_dispute boolean flag that triggers manual review whenever inconsistencies are found

Answer: C — Since a known, evidence-based precedence rule already exists (90% reliability), encode that rule directly into the extraction instructions rather than pushing complexity downstream or to manual review.

Q32. 98% accuracy under 50K tokens; drops to 77% at 175K-190K tokens (model's context window is 200K), with information from the final third of the document consistently missed. Most likely cause?

A) Schemas exceeding 40 fields increase decision complexity independent of document length
B) Very long documents exceed the model's effective attention span regardless of the hard context limit, degrading accuracy for content farther from the prompt instructions
C) The model distributes attention strictly proportionally across input length
D) Tool definitions plus system prompt plus document content approach the 200K context limit

Answer: B — The document technically fits, but effective attention over very long inputs is not uniform; content far from the prompt is more likely to be missed, independent of the hard limit. (The arithmetic also doesn't support option D — well under the ceiling.)

Q33. Multiple document-type-specific extraction tools exist. With tool_choice: "auto", Claude sometimes returns conversational text instead of calling a tool, breaking the parser. Document type is unknown in advance; guaranteed structured output is required. Most effective approach?

A) Set tool_choice: "any" with all extraction tools defined
B) Keep tool_choice: "auto" with stronger system-prompt instructions requiring tool use
C) Add a preliminary classification call, then make a second call with tool_choice forced to the identified extraction tool
D) Consolidate all document types into a single unified-schema extraction tool and force that tool

Answer: C — Classify first, then force the matching tool; "any" guarantees a tool call but not the correct one among several specialized tools, and prompting alone can't guarantee tool use.

Q34. A schema's required fields get fabricated values when source documents lack the information (e.g., an invented "weight: 2.3 kg"). Most effective schema fix?

A) Add prompt instructions to "only extract explicitly stated information; use placeholder text for missing values"
B) Implement semantic validation verifying each extracted value appears in or can be inferred from the source text
C) Add a self-reported confidence field per specification, filtering out low-confidence extractions
D) Change fields that may not exist in source documents from required to optional, allowing the model to omit them

Answer: D — Required fields pressure the model to invent plausible values when the real value is absent; making genuinely-sometimes-absent fields optional removes that pressure at the source.

Q35. A schema has pros/cons string arrays and an overall_sentiment enum. ~20% of terse reviews ("Great product!") cause fabricated pros/cons; sarcastic reviews force an arbitrary sentiment choice with no ambiguity option. Best schema fix for both?

A) Allow null values for pros/cons and add "neutral" to the sentiment enum
B) Make pros/cons optional fields and add "unclear" to the sentiment enum
C) Allow empty arrays for pros/cons as valid output, and add "unclear" to the sentiment enum
D) Add an extraction_confidence field per value and filter outputs below a threshold

Answer: C — An empty array honestly signals "nothing explicit was mentioned" (distinct from optional/null); "unclear" honestly signals genuine ambiguity instead of forcing a guess.

Q36. 12% of high-confidence (>85%) extractions still contain errors. Need a sustainable way to detect these and measure whether improvements reduce the error rate over time. Most effective approach?

A) Implement stratified random sampling, reviewing a fixed percentage of high-confidence extractions on a regular cadence
B) Implement heuristic rules flagging documents with comparison tables or appendices for review, regardless of confidence
C) Add a verification pass that re-extracts each high-confidence document, flagging attempts that disagree
D) Lower the confidence threshold from 85% to 75%, routing more volume to human review

Answer: A — Stratified random sampling gives an unbiased error-rate estimate, ongoing quality monitoring, and detection of novel failure modes.

Q37. 18% of invoices have line-item sums that don't match the stated grand total (OCR errors or model mistakes). The downstream accounting system rejects mismatches. Most effective fix?

A) Extract line items and totals independently, then use a separate validation model to reconcile which value is "most likely correct"
B) Implement post-processing that automatically adjusts line item amounts proportionally to match the stated total
C) Add few-shot examples of invoices where line items correctly sum to the stated total
D) Add a calculated_total field (model sums the extracted line items) alongside the extracted stated_total; flag records for human review when they differ

Answer: D — Preserve the original stated value, compute a derived total independently, compare, and flag discrepancies — a deterministic check that never silently rewrites financial data.

Q38. A property_type enum (house/apartment/condo/townhouse) fails validation 8% of the time as new types keep appearing (studio, loft, duplex, tiny house, converted warehouse). Most effective long-term solution?

A) Continuously expand the enum to include newly observed property types
B) Add an "other" value to the enum with a separate property_type_detail string field for specifics
C) Change property_type to a free-form string, normalized in post-processing
D) Add few-shot examples showing how to map unexpected property types to the closest existing enum value

Answer: B — Preserves a standardized set of common categories while allowing unforeseen values without schema failures, avoiding endless enum maintenance.

Q39. Restaurant menu prices appear as "$12" vs. "12.00"; dietary info as icons instead of text. Most reliable approach?

A) Use separate extraction calls for each field to ensure consistent per-type handling
B) Extract data as-is and normalize formats in post-processing code after Claude returns
C) Define a strict output schema and include format-normalization rules directly in the prompt
D) Request multiple extraction attempts per document and select the most common format

Answer: C — A strict schema plus explicit normalization instructions lets the model normalize during extraction, producing clean output directly.

Q40. 94% accuracy on short meeting transcripts (<30 min); only 80% on longer ones (>60 min) where discussion meanders and information is scattered. Both fit within the context window. Most effective pattern to improve accuracy?

A) Upgrade to a more capable model tier
B) Add few-shot examples demonstrating correct extraction from lengthy, scattered-information meetings
C) Split every transcript into chunks, extract from each chunk separately, then merge and deduplicate the results
D) Add a pre-extraction step summarizing key discussions and conclusions before structured extraction

Answer: C — Chunking reduces cognitive load per call, improves recall for information spread throughout the transcript, and scales to arbitrarily long documents. Summarizing first is lossy for structured detail.

Q41. A contract's original clause specifies "30-day payment terms"; Amendment 1 changes this to "45 days." Extraction inconsistently returns one or the other, with no indication of which currently applies. Most effective fix?

A) Preprocess with a classifier that identifies and removes superseded sections before extraction
B) Add prompt instructions to always extract the most recent amendment value and ignore superseded terms
C) Redesign the schema so amended fields capture multiple values, each with source location and effective date
D) Implement post-extraction pattern matching to detect amendments and flag those for manual review

Answer: C — The document legitimately contains multiple valid values (original + amendment); the schema should preserve this history with provenance rather than guessing which one should win.

Q42. Event-metadata extraction uses an all-nullable schema, but the model still frequently fabricates plausible values for fields the article never mentions (e.g., inventing "attendee_count: 500"). Most effective fix?

A) Make all schema fields required (non-nullable) with strict validation
B) Add prompt instructions to return null for any field not directly stated in the source, and not to guess or infer
C) Add a post-processing step using a second LLM call to verify each value exists in the source
D) Upgrade to a more capable model tier with improved instruction-following

Answer: B — The schema already allows null, but the model isn't explicitly told when to use it; an explicit "return null, don't guess" instruction aligns the prompt with the schema.

Q43. Only ~5% reviewer capacity is available. Most effective basis for selecting which extractions to route for human review?

A) Randomly sample 5% of extractions for review
B) Route extractions containing specific high-priority entity types (financial figures, dates), regardless of confidence
C) Route extractions where the model indicates low confidence or where source documents contain ambiguous/contradictory information
D) Route extractions for review only when downstream systems report data quality issues or processing failures

Answer: C — With scarce review capacity, risk-based routing (uncertain or ambiguous cases) maximizes the value of every human review.

Q44. Two document types share a schema: standard monthly reports (archived, no urgency) and urgent exception reports (must trigger alerts within 30 minutes). Minimize API cost while meeting latency needs. Best architecture?

A) Route standard reports to the Batch API for cost savings; route urgent exception reports to the real-time Messages API
B) Submit all documents to the real-time Messages API for consistent latency
C) Queue all documents and submit hourly batches, flagging urgent documents for expedited handling
D) Submit everything to the Batch API with outbound IDs; process urgent documents immediately when results arrive

Answer: A — Matching each API to its workload's actual latency requirement minimizes cost without violating the urgent-alert SLA.

Q45. Documents arrive continuously; want the Batch API's 50% discount while meeting a 30-hour SLA at 99.9% reliability. Most appropriate batching strategy?

A) Submit a single batch at the end of each day
B) Use the real-time Messages API for all documents instead of batching
C) Submit batches every 4 hours
D) Submit batches every 6 hours

Answer: C — Worst case is a 4-hour wait plus 24-hour batch processing = 28 hours, meeting the 30-hour SLA with a 2-hour buffer. End-of-day batching risks 48 hours worst case; 6-hour batching hits exactly 30 hours with zero margin.

Mock Exam — Part 4: Customer Support Resolution Agent + Agentic Loop Fundamentals

Q46. A billing dispute's root cause is confirmed (payment gateway timeout caused duplicate charges); the $650 refund exceeds the auto-authorization limit, requiring escalate_to_human. The human agent has no access to the conversation transcript. What should be passed?

A) The customer's original complaint verbatim, plus tool-result excerpts showing duplicate transactions
B) A structured summary: customer ID, root cause, refund amount, recommended action
C) Raw diagnostic logs and the refund amount only
D) The complete conversation transcript with all tool results

Answer: B — Pass structured state, not conversational history; the human needs who/what/why/how-much/what's-next, not a transcript to reconstruct the case from.

Q47. lookup_order_status sometimes returns errors ("order not found," temporary DB failures). Correct pattern for communicating this back to the agent?

A) Throw an exception from the tool handler so the framework can catch and log it
B) Return the error message in the tool result content with the MCP isError flag set to true
C) Log the error server-side and return an empty result to avoid confusing the model
D) Return a successful response with a "status" field describing the error

Answer: B — The tool completes successfully at the protocol level while isError = true signals the operation failed; the model receives a structured signal it can reason about.

Q48. Compliance requires ALL refunds over $500 to auto-escalate — no model discretion allowed. Despite clear prompt instructions, ~1% of high-value refunds still get processed directly. How do you achieve guaranteed compliance?

A) Implement a hard check in the tool/API layer that blocks refund processing above $500, forcing escalation
B) Strengthen the system prompt with emphatic language ("CRITICAL POLICY... NEVER process these directly")
C) Modify the refund tool to return an error like "Amount exceeds policy limit—please escalate" when the threshold is exceeded
D) Add few-shot examples demonstrating correct escalation behavior at various refund amounts

Answer: A — Hard compliance rules must be enforced programmatically in the backend/tool layer, never left to model reasoning or prompt discipline, however strongly worded.

Q49. Which approach most reliably identifies cases that genuinely require human intervention?

A) Escalate after three unsuccessful tool calls that fail to resolve the customer's issue
B) A rule engine mapping issue types, customer segments, and product categories to escalation decisions
C) Sentiment analysis monitoring frustration indicators, triggering escalation above a threshold
D) Escalate when the customer explicitly requests a human, when the issue requires policy exceptions, or when the agent cannot make meaningful progress

Answer: D — Capability- and policy-based criteria, not arbitrary heuristics like failure counts, static rule mappings, or sentiment thresholds.

Q50. What is the primary mechanism for deciding whether to continue the agentic loop or stop?

A) Detect whether the response contains a text content block — if present, assume the final answer is ready
B) Manually set the stop_reason parameter to "end" after the final expected tool call
C) Check the stop_reason field: continue while it's "tool_use", stop when it becomes "end_turn"
D) Count tool calls made and end the loop once a preconfigured maximum is reached

Answer: C — The application controls the loop based on the API-generated stop_reason, not text presence, manual overrides, or a fixed call-count cap.

Q51. get_customer and lookup_order succeed, but process_refund times out. The agent can explain the charges and confirm eligibility but can't actually process the refund. Best approach?

A) Implement automatic retries with exponential backoff, keeping the conversation open indefinitely until the refund succeeds
B) Explain the billing confirmation and eligibility, acknowledge the system issue preventing immediate processing, and offer escalation or a retry later
C) Confirm the refund will be processed and close the conversation since enough information exists to complete it
D) Escalate immediately to a human agent since the refund action couldn't be completed

Answer: B — Share verified information, be transparent about the failure, and offer a concrete next step; never claim an action succeeded when the tool failed, and don't over-escalate on a single recoverable hiccup.

Q52. Customer: "I've been going back and forth on this refund for days. I just want to speak to someone who can actually help me." The agent has already confirmed via the eligibility tool that the refund is straightforward, in-policy, and immediately processable. What should the agent do?

A) Call escalate_to_human immediately, purely to honor the request
B) Require specific policy criteria or multiple failed attempts before deciding to escalate or resolve
C) Acknowledge the frustration, explain the issue is resolvable immediately, and offer to complete the refund or escalate — customer's choice
D) Process the refund without addressing the request for a human, then inform them it's complete

Answer: C — The fastest resolution while preserving the customer's stated preference: acknowledge, explain the immediate fix is available, and let them choose.

Q53. A customer returns 4 hours after an initial billing dispute. The prior 32-turn session shows an earlier order status ("PENDING") from an old tool call; the agent sometimes references this outdated result even though a fresh call would show "REFUND PROCESSED." Most reliable approach?

A) Keep full history and automatically re-run every previously used tool at the start of every returning session
B) Keep full history and add a system-prompt instruction to always prefer the most recent tool results
C) Keep full history but strip out previous tool-result messages before resuming, forcing fresh data fetches
D) Start the new session with a structured summary of the previous interaction, then make fresh tool calls before responding

Answer: D — Preserve context via a concise summary rather than replaying full history, and treat tool outputs as ephemeral — external state may have changed, so re-query before deciding anything.

Q54. After get_customer and lookup_order, the agent determines the dispute involves a promotional-pricing error requiring approval beyond its authorization level. How should this mid-process escalation be handled?

A) Attempt the refund via process_refund anyway, escalating only if the backend rejects the transaction
B) Call escalate_to_human, passing only the customer's original message
C) Persist the complete conversation and tool-response history to a database, then call escalate_to_human with a reference ID
D) Compile a structured handoff (customer details, order info, identified issue, relevant context), then call escalate_to_human

Answer: D — A good handoff includes everything a human needs to continue immediately, minimizing repeated work and providing a smooth transition.

Q55. An MCP tool returns only {"isError": true, "content": "Operation failed"} for every failure. The agent retries non-existent orders 5+ times, escalates immediately on transient blips, and asks for clarification when the real issue is a backend permission error. Most effective improvement?

A) Implement retries with exponential backoff inside the MCP server for all errors
B) Add few-shot examples to the system prompt demonstrating how to interpret different error message patterns
C) Enhance the tool's error response with structured metadata: errorCategory, isRetryable, and a clear description
D) Create a second MCP tool the agent calls after every failure to classify the error and recommend an action

Answer: C — Without structured information, the model can't decide whether to retry, ask the user, or escalate; structured fields enable deterministic, policy-driven decisions instead of guessing from a generic string.

Q56. lookup_order has been called several times; each response has 40+ fields, and these now dominate the conversation context. The customer mentions two more orders to discuss. Most effective approach before making additional lookups?

A) Move all tool responses into a vector database with semantic indexing for retrieval
B) Proceed with additional lookups without modifying the existing tool-output context
C) Have the model generate a natural-language summary of each order, replacing the structured responses with prose
D) Extract only the relevant fields (items, purchase date, return window, status) from each existing response, discarding the verbose rest

Answer: D — Preserve structured, essential information; strip irrelevant/verbose fields rather than converting to lossy prose or introducing unnecessary retrieval infrastructure.

Q57. Customer: "This is frustrating. I've explained my issue twice and nothing is being resolved. I want to talk to a real person NOW!" The agent hasn't yet called any tool to investigate the account. Best first move?

A) Acknowledge the frustration and ask one targeted clarifying question before escalating
B) Call get_customer and lookup_account to gather context first, then escalate to a human
C) Briefly explain what the agent can help with and offer to resolve it quickly, escalating only if the customer repeats the request
D) Immediately call escalate_to_human with the conversation history

Answer: D — Honor an explicit, forceful request for a human immediately, without investigating first — this is a direct application of the escalation-triggers guidance. Asking a clarifying question first is the right move for a simple, non-explicit request for help, but once a customer has explicitly and forcefully asked for a human, escalate right away rather than delaying with more questions.

Q58. The agent sometimes hits its turn limit after collecting data but before completing resolution or escalating. Goal: guarantee every interaction ends with either a completed resolution or a human handoff, regardless of the agent's own estimate of remaining work. Best approach?

A) Escalate automatically at 80% of the turn limit, as a heuristic
B) Split the work across two agents, each with its own turn budget
C) Rely on the model predicting it won't finish in time and escalating proactively
D) An external orchestrator detects when the loop terminates without a completed resolution or escalation, and programmatically calls escalate_to_human with the accumulated context

Answer: D — This is the only option that provides a true guarantee; the model may misjudge remaining work, but a deterministic orchestrator can always detect an unresolved termination and force a final escalation.

Q59. After lookup_order shows an item was purchased 45 days ago, how does the agentic loop decide between calling process_refund or escalate_to_human next?

A) The agent executes a fixed sequence of steps planned at the start of the request
B) The orchestration layer automatically routes to the next tool based on the order's status field
C) The tool result is added to the conversation, and the model reasons about which action to take next
D) The agent follows a pre-programmed decision tree mapping order attributes to specific tool calls

Answer: C — The tool result becomes part of the conversation context; the model reasons over the updated context to decide the next action. Options A and D are both the pre-configured decision-tree anti-pattern in disguise.

Q60. Tools should return structured, informative errors instead of generic "failed" messages, so Claude can choose the correct recovery action for different failure types. Best mechanism?

A) Hide retries inside the tool via exponential backoff for all error types
B) Replace generic messages with more descriptive free-form text
C) Remove the error flag and treat failures as normal tool output
D) Add an error-classification step in the agentic loop that tags each error with a recommendation ("retry," "try_alternative," "escalate") and appends that recommendation to the tool result

Answer: D — Attaching structured classification and a recommended action gives Claude actionable information, rather than just an error string it has to interpret unassisted.