Foundations Mock Exam 2 — 60 Scenario Questions, Timed (Q589–Q648)

A full-length CCAR-F practice simulation, built like the official exam: 60 questions in 120 minutes, under 4 scenarios drawn from the bank of 6, 15 questions per scenario. This mock uses Customer Support Resolution Agent · Developer Productivity with Claude · Claude Code for Continuous Integration · Structured Data Extraction. Every question was written for this guide against a task statement of the official Claude Certified Architect – Foundations Exam Guide (v1.0, July 2026), and the domain counts follow its blueprint. 4 questions are multiple-response and say “Select TWO”; the rest say “Select ONE”. This is not an official Anthropic or Pearson VUE exam. It does not reproduce, reconstruct or recall any live exam item, and the guide’s sample questions are used only as a model of style. Other full mocks: Mock 1 · Mock 3 · Mock 4.

How to read your result. The runner reports a practice score: raw questions correct out of 60, a per-domain breakdown, the elapsed time and the unanswered count. Unanswered questions count as incorrect. The live exam reports a scaled score (pass mark 720 on 100–1,000); this page does not convert a raw score into a scaled score, because no public conversion exists. A useful study heuristic: aim for 80% here, with no domain under 65%, on a mock you have not seen before. Untimed practice by domain lives in Practice Questions and Concept Drills.

Foundations mock exam 2 · 60 questions (Q589–Q648)

Scenario 1 · Customer Support Resolution Agent

D1 · Agentic Architecture

Q589. A passenger writes one message: they were charged twice for a seat upgrade, their checked suitcase arrived with a broken handle, and they want the name spelling corrected on a booking for next month. Logs show the agent resolves the duplicate charge thoroughly and then closes the chat, leaving the other two requests unanswered. Which design change addresses this pattern? (Select ONE.) A) Have the agent handle only the first issue in each chat and ask the passenger to open a new chat for each remaining request after that. B) Raise max_tokens for each response so the agent has enough output space to discuss all three requests in a single long answer. C) Split the message into distinct issues, investigate each with the shared customer context, and send one reply covering all of them. D) Route every message that mentions more than one booking to escalate_to_human, because multi-issue cases are too complex for automation.

D4 · Tools & MCP

Q590. Besides the four core tools, the agent has one generic tool, account_action(action, params), that updates contact details, cancels bookings and applies travel credit. Logs show frequent malformed calls, such as a credit amount sent inside a phone-number field and cancellations sent without a booking reference. Which change would most improve reliability? (Select ONE.) A) Add few-shot examples to the system prompt that show a correctly formatted params object for each of the three actions the generic tool supports. B) Switch the agent to a larger model, which is better at remembering which parameter names belong to each action of a generic tool. C) Split account_action into update_contact_details, cancel_booking and apply_travel_credit, each with its own required inputs and a description of when to use it. D) Validate params inside account_action and return 'Invalid request' whenever the fields do not match the chosen action, so the agent tries again.

D1 · Agentic Architecture

Q591. A passenger returns the next day about a damaged suitcase. The agent resumes yesterday's session, whose lookup_order results showed the baggage claim 'under review', and repeats that status. Overnight, the baggage team approved a repair and finance applied a partial travel credit, but nobody knows which of yesterday's lookups changed. Which approach should the agent use for returning passengers? (Select ONE.) A) Start a new session seeded with a structured case summary, and let the agent call the tools again for current data. B) Fork yesterday's session with fork_session so the agent keeps all of the earlier context but works in an independent new branch. C) Resume yesterday's session and tell the agent that the repair was approved, so it updates only that single status. D) Resume yesterday's session as before and add a system note saying that some earlier tool results may be out of date by now.

D1 · Agentic Architecture

Q592. Human agents complain that escalated chats arrive as one line such as 'Passenger needs help with a refund', so they spend six minutes re-asking questions the agent already answered. Their case system cannot display chat transcripts, and privacy policy forbids copying transcripts into cases. What should the escalate_to_human call carry so humans can act at once? (Select ONE.) A) A link to the full chat transcript stored in the agent's session log, so the human can scroll through the conversation and find the details. B) A structured handoff with customer ID, booking references, the root cause found, amounts involved, steps already taken, and a recommended next action for the human. C) The passenger's sentiment score and the agent's confidence rating, so the human queue can prioritize the angriest and least certain cases first. D) A warm, empathetic paragraph written by the agent that retells the conversation in the passenger's own words and apologizes for the trouble.

{"customer_id": "C-48211", "booking_refs": ["K7Q2PF"], "root_cause": "Flight cancelled; passenger paid for a hotel night", "amount_usd": 640.00, "steps_taken": ["cancellation confirmed", "hotel receipt received"], "recommended_action": "Approve reimbursement; amount exceeds $400 refund limit"}

D4 · Tools & MCP

Q593. lookup_order searches two backends: the live booking database and an archive for bookings older than two years. When the archive is unreachable, the tool quietly returns only live bookings. Passengers asking about unused travel credit from 2022 trips are told 'that booking isn't on file' and give up. How should lookup_order report results in this situation? (Select ONE.) A) Retry the archive inside the tool until it finally responds, however long that takes, before returning any results to the agent at all. B) Keep the response unchanged and tell the agent in the system prompt that older bookings may sometimes be missing from lookup_order results. C) Return the live bookings plus a structured note that the archive query failed and is retryable, so older bookings are not denied. D) Return isError for the whole call whenever the archive is unreachable and discard the live bookings, so the agent never works from incomplete data.

D4 · Tools & MCP

Q594. To save effort, the platform team connected the agent to the airline's general MCP server, giving it 19 tools, including seat inventory adjustment, promo-code creation and crew schedule lookups. Since then, tool-selection errors have tripled, and the agent once created a 30% promo code instead of a travel credit. What change should you make? (Select ONE.) A) Rewrite all 19 tool descriptions with clear boundaries and examples, so the agent can choose correctly among the whole set of tools. B) Move to a larger model with a longer context window, so the agent can reason across all 19 tool definitions without confusion. C) Add a classifier in front of the agent that predicts the needed tool for each message and forces that tool with tool_choice. D) Expose only the tools the support role needs, such as the four core tools plus a travel-credit tool.

D5 · Context & Reliability

Q595. A passenger types only an email address. get_customer returns two accounts that share it, held by a parent and an adult child, and both have upcoming bookings. The agent chose the account with the more expensive booking and cancelled a trip that the other family member still planned to take. How should the agent handle lookups that return more than one account? (Select ONE.) A) Escalate to a human every time get_customer returns more than one account, because identity questions are too risky to automate. B) Pick the account whose upcoming bookings best match the problem the passenger describes, then read the trip details back for confirmation. C) Look up both accounts' bookings in parallel and act on whichever account contains the flight the passenger mentions in the chat. D) Ask the passenger for an additional identifier, such as a booking reference or date of birth, before continuing.

D1 · Agentic Architecture

Q596. Before moving to the Agent SDK, your team tested a prototype that runs its own loop on the Messages API. Transcripts show that when Claude returns a short sentence such as 'Let me pull up that booking' together with a lookup_order request, the prototype sends the sentence to the customer and ends the turn, so the lookup never runs. Which change fixes the loop's control flow? (Select ONE.) A) Keep calling the model until a fixed limit of eight calls is reached, then send the most recent text block to the customer as the reply. B) Loop on stop_reason: while it is "tool_use", run the requested tools and append their results; stop only when it is "end_turn". C) Tell Claude in the system prompt never to write text in a response that requests a tool, so any text block reliably marks the final answer. D) Scan each response for phrases such as 'let me check' or 'one moment', keep looping when one appears, and end the turn when none is found.

while True:
    resp = client.messages.create(model=MODEL, system=SYSTEM, tools=TOOLS, messages=messages, max_tokens=1024)
    messages.append({'role': 'assistant', 'content': resp.content})
    if resp.stop_reason != 'tool_use':
        break
    results = [run_tool(b) for b in resp.content if b.type == 'tool_use']
    messages.append({'role': 'user', 'content': results})

D5 · Context & Reliability

Q597. Coastline Airways is rewriting the agent's escalation criteria because first-contact resolution is stuck at 71%. The agent currently escalates angry passengers whose cases are simple, and handles some unusual requests on its own. Which TWO conditions should trigger escalation to a human? (Select TWO.) A) Policy is silent on the request, such as compensation for a pet carrier damaged in the cabin when policy covers only checked baggage. B) The agent reports a confidence below 0.6 in its proposed resolution, using a score it generates alongside its reply. C) The passenger explicitly asks to speak with a human, even if the issue looks simple for the agent to resolve right away. D) A sentiment classifier scores the passenger's latest message as very negative, which suggests the passenger is frustrated with the agent.

D1 · Agentic Architecture

Q598. The system prompt says refunds above $400 need supervisor approval, and few-shot examples show the agent escalating instead. A monthly audit still finds that about 2% of refunds over $400 went through process_refund directly, often after a passenger pushed hard. Finance requires this rule to hold every time. What should you implement? (Select ONE.) A) A PreToolUse hook on process_refund that blocks calls above $400 and redirects the case to escalate_to_human. B) A nightly job in which a second Claude instance reviews every refund issued that day and flags those above $400 for finance to reverse. C) A stronger system prompt that puts the $400 rule first, in capital letters, and adds more few-shot examples of passengers pushing for refunds. D) Remove process_refund from the agent entirely, so that every refund of any amount is handled by the human queue through escalate_to_human.

async def refund_limit(input_data, tool_use_id, context):
    amount = input_data['tool_input'].get('amount', 0)
    if amount > 400:
        return {'hookSpecificOutput': {
            'hookEventName': 'PreToolUse',
            'permissionDecision': 'deny',
            'permissionDecisionReason': 'Refunds above $400 need a supervisor: call escalate_to_human with the booking and amount.'}}
    return {}

D4 · Tools & MCP

Q599. You add a get_refund_status tool with a clear, detailed description. Weeks later, logs show the agent still calls lookup_order when passengers ask 'Where is my refund?', and calls it even for questions about the fare refund rules. The system prompt contains the line 'Whenever a passenger mentions a refund, always start with lookup_order.' What's the most effective first step? (Select ONE.) A) Merge get_refund_status into lookup_order as an extra mode, so that any refund question already reaches the right underlying function. B) Rewrite that system prompt line so it no longer ties the word 'refund' to lookup_order, and say when each refund-related tool applies. C) Add a routing classifier before the agent that detects refund-status questions and forces get_refund_status with tool_choice for them. D) Expand the get_refund_status description further with more example queries, input formats and edge cases so that it outranks lookup_order.

D4 · Tools & MCP

Q600. Coastline Airways keeps 140 policy documents, about 600,000 tokens in total, behind a search_policy MCP tool. Traces show the agent makes four to six exploratory search_policy calls per chat just to discover which policies exist, such as 'pet travel', 'delay compensation' and 'unaccompanied minors'. How can the MCP server reduce these exploratory calls? (Select ONE.) A) Expose a policy catalog as an MCP resource listing each document's title, scope and sections, so the agent sees what exists before searching. B) Load all 140 policy documents into the system prompt so that the agent never has to search for a policy during a chat. C) Tell the agent in the system prompt to make at most two search_policy calls per chat and to escalate if it finds nothing. D) Cache search_policy responses in the MCP server for an hour, so repeated exploratory searches return faster and cost less.

D5 · Context & Reliability

Q601. Long chats are summarized after 25 turns to save context. In one escalated case, the passenger had been promised a $187.40 credit for booking K7Q2PF by Friday, but the summary said only 'passenger discussed a credit for a delayed flight', and the agent later offered $150. How should you preserve such details across long chats? (Select ONE.) A) Keep a case-facts block of amounts, booking references, dates and promises, sent in every request outside the summarized history. B) Instruct the summarizer to be more detailed and to always keep any numbers, dates and booking references that appear in the conversation. C) Summarize less often, every 50 turns instead of every 25, so that more of the original wording stays in context for longer chats. D) Move the agent to a model with a much larger context window, so long chats never need to be summarized in the first place.

{"case_facts": {"customer_id": "C-30417", "bookings": [{"booking_ref": "K7Q2PF", "issue": "delayed flight", "credit_promised_usd": 187.40, "credit_due": "Friday", "status": "promised"}]}}

D4 · Tools & MCP

Q602. process_refund returns {"error": "Operation failed"} both when the payment gateway times out and when a ticket is a non-refundable basic fare. The agent retries the fare-rule failures three times and then tells passengers to try again later. For gateway timeouts, it sometimes gives up after one attempt. What change lets the agent respond correctly to each case? (Select ONE.) A) Log the full gateway error server-side and keep the generic message, so passengers never see technical details from the backend. B) Tell the agent in the system prompt to retry each failed refund exactly once and then escalate any case that still fails afterward. C) Make process_refund retry every failure automatically three times with backoff before returning, so the agent sees only final outcomes. D) Return isError with an errorCategory such as transient or business, an isRetryable flag, and a passenger-friendly fare-rule message.

[{"isError": true, "content": [{"type": "text", "text": "{\"errorCategory\": \"transient\", \"isRetryable\": true, \"message\": \"Payment gateway timed out\"}"}]}, {"isError": true, "content": [{"type": "text", "text": "{\"errorCategory\": \"business\", \"isRetryable\": false, \"customerMessage\": \"Basic fares are non-refundable; a travel credit may be available.\"}"}]}]

D5 · Context & Reliability

Q603. Each lookup_order result contains about 60 fields, including fare basis codes, aircraft tail numbers and tax breakdowns. Passengers with many bookings fill the context after a few lookups, and the agent has started missing details the passenger stated early in the chat. Refund handling needs about six of those fields. What change should you make? (Select ONE.) A) Trim each lookup_order result to the fields that refund handling needs before it is added to the conversation context. B) Instruct the agent in the system prompt to ignore fare-basis, aircraft and tax fields when it reads any lookup_order result. C) Trigger compaction more often, so older lookup_order results are summarized sooner when the context becomes too full. D) Use a model with a larger context window, so many full lookup_order results can fit alongside the whole conversation.

Scenario 2 · Developer Productivity with Claude

D1 · Agentic Architecture

Q604. A teammate proposes a fixed sequence for every Compass request to make runs predictable: Glob for files whose names match the request's keywords, Read the top five, then answer. Many requests are investigations, such as 'why does the nightly invoice job post twice?', where the next step depends on what a log, a test run or a caller reveals. Which design should Compass use for these requests? (Select ONE.) A) Let Claude choose each next tool from the results so far, and keep looping while it requests tools until it ends the turn with an answer. B) Use the fixed Glob-Read sequence for every request, and raise the number of files read from five to twenty to improve coverage. C) Run the fixed Glob-Read sequence first, then allow further tool calls only if Claude's answer contains a phrase such as 'need more information'. D) Build a decision tree that maps question words such as 'why', 'where' and 'how' to a predefined tool sequence written for each type of question.

D1 · Agentic Architecture

Q605. An engineer asks Compass to 'add meaningful tests to the legacy billing package', which has 140 Kotlin files and almost no tests. The first attempt wrote tests file by file in alphabetical order and spent most of its budget on small formatting utilities, while the invoice-posting path stayed untested. How should Compass decompose this task? (Select ONE.) A) Keep the file-by-file chain but sort the files by line count, so that the largest files are tested first and receive most of the budget. B) Spawn 140 parallel subagents, one per file, each writing tests for its own file, then merge all the resulting test files at the end. C) Ask Compass to reach 100% line coverage across the package, so that every file must get tests and the budget is spread evenly. D) Map the package structure first, identify high-impact areas such as money-moving paths, then follow a prioritized plan that adapts as dependencies are discovered.

D2 · Claude Code

Q606. Saltmarsh Payments wants to replace its in-house logging wrapper with SLF4J across about 60 modules. Some modules pass request IDs through the wrapper's thread-local context, and the team has not decided how to carry them through coroutines. An engineer plans to start Claude Code in direct execution and fix modules one by one. Which approach should the engineer take? (Select ONE.) A) Split the work into 60 separate direct-execution sessions, one per module, so each session stays small and focused. B) Use plan mode to explore usages and decide request-ID propagation, then use direct execution to apply the approved plan. C) Use direct execution throughout and commit after each module, so any mistakes in the propagation design can be reverted later. D) Use plan mode for the whole migration, including editing all 60 modules, so that no file is changed outside the planning phase.

D4 · Tools & MCP

Q607. Compass connects to two MCP servers: a community issue-tracker server with a search_issues tool, and an internal server with find_tickets, which actually searches incident postmortems. Both descriptions say 'Search tickets by keyword'. When engineers ask 'has this outage happened before?', Compass calls search_issues and misses the postmortems. What's the most effective first step? (Select ONE.) A) Disconnect the community issue-tracker server, so that find_tickets is the only search tool Compass can use when engineers ask about tickets. B) Build a routing layer that classifies each question as outage-related or not and forces the matching tool with tool_choice for that turn. C) Rename find_tickets to search_incident_postmortems and rewrite its description to explain what it searches, what it returns, and when to use it instead of search_issues. D) Add few-shot examples to Compass's system prompt showing outage questions answered with find_tickets and feature questions answered with search_issues.

D1 · Agentic Architecture

Q608. For a request to 'document every external dependency of the billing package', the coordinator spawns three explorer subagents, each told to 'find external dependencies in billing'. Their reports overlap by about 70%: all three read the same HTTP client wrappers, and none looked at the message-queue consumers. How should the coordinator split this kind of work? (Select ONE.) A) Keep the same instructions and spawn five explorers instead of three, so that random variation makes it more likely every area is reached. B) Give each explorer a distinct slice of scope, such as HTTP clients, queue consumers, or database access, so that together they cover the package without overlap. C) Let the three explorers share a scratch file where each one writes what it has read, so the others can skip files already covered. D) Spawn one explorer with a longer time budget instead of three, so that a single agent reads the whole package from start to finish.

D4 · Tools & MCP

Q609. An engineer asks Compass to find every caller of the TypeScript function postLedgerEntry before changing its signature. Compass greps for 'postLedgerEntry' and finds 6 callers, but the change breaks 15 files. The module billing/index.ts re-exports the function as postEntry and recordLedger, and some services import those names. How should Compass trace callers next time? (Select ONE.) A) Use Glob with **/ledger.ts to find every file with 'ledger' in its name, then Read each matching file to look for calls. B) Grep for 'postLedgerEntry' with case-insensitive matching enabled, so that variations in capitalization are also included in the results. C) Read the wrapper modules to list every exported name for the function, then Grep for each name across the codebase to find all callers. D) Read every TypeScript file in the services directory upfront, so that no import or call can be missed during the search.

D1 · Agentic Architecture

Q610. Compass's documentation writer is meant to update Markdown docs only. Reviews show it sometimes runs Gradle builds through Bash and edits Kotlin source files to 'fix' examples it documents. The explorer and the test writer legitimately need Bash. How should you configure the documentation writer? (Select ONE.) A) Remove Bash from the coordinator's allowedTools list, so that no subagent can run shell commands without first asking for approval. B) Give it an AgentDefinition whose tools list is only Read, Grep, Glob, Write and Edit, with a documentation-only prompt. C) Add a sentence to the documentation writer's prompt saying it must never run builds or change source code under any circumstances. D) Register one PreToolUse hook for the whole agent that denies every Bash call, whichever subagent makes it and whatever the command.

D1 · Agentic Architecture

Q611. Compass runs nightly maintenance jobs unattended through the Agent SDK. Two problems appear: the coordinator's attempts to spawn subagents are denied in these runs, and in interactive tests where spawning works, the three explorers start one after another, each in a separate coordinator turn. Which TWO changes address these problems? (Select TWO.) A) Add "Task" to the coordinator's allowedTools, so spawning is pre-approved when nobody can answer a permission prompt. B) Have the coordinator fork its own session for each explorer, so each subagent inherits the full coordinator history when it starts. C) List the three explorer names in the project's CLAUDE.md, so the coordinator knows which subagents it is allowed to start. D) Have the coordinator emit all three Task calls in a single response, so the subagents are spawned and run in parallel.

options = ClaudeAgentOptions(
    allowed_tools=['Task', 'Read', 'Grep', 'Glob'],
    agents={'explorer': AgentDefinition(
        description='Maps one assigned slice of the codebase',
        prompt='You explore only the slice you are given and report file paths.',
        tools=['Read', 'Grep', 'Glob'])},
)

D5 · Context & Reliability

Q612. Two hours into a session exploring the legacy billing package, Compass starts answering with phrases like 'services like this typically use a repository pattern' instead of naming LedgerRepository and InvoiceStore, which it found and discussed an hour earlier. Its answers about the same classes have also begun to contradict each other. What should you change? (Select ONE.) A) End the session every hour and start a new one with no carried context, so Compass re-explores the package from the beginning each time. B) Switch Compass to a model with a larger context window, so the whole two-hour exploration can stay in context without being degraded. C) Add a system prompt instruction telling Compass always to name specific classes it has found rather than describing typical patterns. D) Have Compass write key findings such as classes, paths and decisions to a scratchpad file, and consult it later.

D2 · Claude Code

Q613. Saltmarsh Payments engineers use a project skill, /map-module, in Claude Code to analyze a module before changing it. The skill reads dozens of files and prints about 3,000 lines of analysis into the conversation. After running it, engineers find their session sluggish and Claude losing track of the change they were planning. What should change in the skill? (Select ONE.) A) Add context: fork to the SKILL.md frontmatter, so the analysis runs in an isolated subagent context and returns only its result to the main session. B) Add an argument-hint to the SKILL.md frontmatter, so engineers are reminded to name a smaller module when they invoke the skill. C) Move the skill's instructions into the project CLAUDE.md, so the analysis guidance is always loaded and the skill is no longer needed. D) Add allowed-tools: Read to the SKILL.md frontmatter, so the skill can only read files during its run and produces less output.

---
name: map-module
description: Analyze a module's structure, dependencies and risks before a change
context: fork
argument-hint: <module-path>
---
Read the module, map its public API and callers, and return a summary under 40 lines.

D1 · Agentic Architecture

Q614. Compass has Bash so it can run tests and builds. Its system prompt forbids force-pushing, deleting branches and running database migrations against shared environments. Last week an Compass session ran a migration script against the shared staging database, which took the staging environment down for three hours. How should you prevent this class of command? (Select ONE.) A) Remove Bash from Compass's tools entirely, so it can only read and edit files and never execute any command on a machine. B) Leave Bash out of allowedTools, so each Bash command waits for permission and is denied when no person is present to approve it. C) Add a PreToolUse hook on Bash that inspects each command, denies the forbidden patterns with a reason, and allows the rest. D) Repeat the forbidden actions at the top and bottom of the system prompt and add examples of refusing dangerous commands that users request.

import re
FORBIDDEN = [r'git push .*--force', r'git branch -D', r'flyway migrate .*(staging|prod)']

async def guard_bash(input_data, tool_use_id, context):
    cmd = input_data['tool_input'].get('command', '')
    if any(re.search(p, cmd) for p in FORBIDDEN):
        return {'hookSpecificOutput': {
            'hookEventName': 'PreToolUse',
            'permissionDecision': 'deny',
            'permissionDecisionReason': 'Blocked by policy: use the local environment instead.'}}
    return {}

D1 · Agentic Architecture

Q615. Compass's coordinator sends every request through the full pipeline: the explorer maps the code, the test writer drafts tests, and the documentation writer updates docs. A question such as 'what does LedgerPoster.flush() return?' takes four minutes and produces unwanted test files. Engineers have stopped using Compass for quick questions. What should change in the coordinator? (Select ONE.) A) Keep the full pipeline but instruct the test and documentation writers to produce no output when the request does not need it. B) Remove the coordinator and let engineers pick which subagent to call directly by typing its name at the start of each request. C) Run the three subagents in parallel instead of in sequence, so the full pipeline finishes in about one third of the time. D) Have the coordinator analyze each request and invoke only the subagents that the request actually needs.

D4 · Tools & MCP

Q616. Compass must change the retry timeout for only the 'settlement' client in a YAML config file. The Edit tool fails repeatedly because the text 'timeout: 30s' appears four times in the file, once for each client, and Compass keeps retrying the same Edit call. What should Compass do to make the change reliably? (Select ONE.) A) Run Edit with replace_all enabled, so that every 'timeout: 30s' in the file is updated and the non-unique match error disappears. B) Write a new version of the file from memory with the corrected timeout, without reading the current file first, to save a step. C) Read the full file, change the timeout inside the settlement block only, and Write the complete updated file back. D) Use Bash to run a sed command that replaces the first 'timeout: 30s' it finds, assuming the settlement client appears first.

D1 · Agentic Architecture

Q617. The explorer reports that the refunds module uses a FakeClock fixture, a LedgerTestHarness for database state, and a strict rule against mocking the payments gateway. The coordinator then spawns the test writer with the Task prompt 'Write unit tests for the refunds module.' The tests use real clocks and mock the gateway. What should change? (Select ONE.) A) Include the explorer's complete findings in the test writer's Task prompt: fixtures, the harness, the no-mocking rule, file paths. B) Configure the test writer to inherit the coordinator's conversation history, so it can read the explorer's report from earlier in the session. C) Give the test writer access to the explorer's tools so it can call the explorer subagent directly whenever it needs project context. D) Tell the test writer in its system prompt to explore the refunds module again on its own before writing any tests for the module.

Goal: unit tests for refunds/ that pass review.
Findings from the explorer:
- Time: use FakeClock (test/support/clock.kt), never Instant.now()
- DB state: LedgerTestHarness.seed(...)
- Rule: never mock PaymentsGateway; use GatewaySandboxStub
- Files: refunds/RefundService.kt, refunds/RefundPolicy.kt
Quality bar: each public method has a happy path and one failure path.

D1 · Agentic Architecture

Q618. An engineer spent 40 minutes with Compass analyzing the build setup of 900 modules in a named session called 'build-audit'. Now the team wants to compare two migration strategies: moving to a Gradle version catalog, or keeping buildSrc with convention plugins. Each strategy needs its own exploration, and neither should affect the other or the original analysis. Which approach fits? (Select ONE.) A) Resume 'build-audit' and ask Compass to explore both strategies at once, alternating between them in the same conversation. B) Fork the 'build-audit' session twice with fork_session, exploring one strategy in each branch from the same baseline analysis. C) Start two new sessions with no prior context and repeat the 40-minute build analysis in each before exploring one strategy per session. D) Resume 'build-audit', explore the version catalog strategy, then tell Compass to forget that work and explore the buildSrc strategy next.

Scenario 3 · Claude Code for Continuous Integration

D2 · Claude Code

Q619. The team created .claude/rules/api-handlers.md with paths: ["src/api/.ts"] to load error-handling conventions for API handlers. The rule loads when Claude edits src/api/router.ts, but not when it edits handlers in src/api/v2/payments/refund.ts, where most handlers live. What change fixes this? (Select ONE.) A) Add a CLAUDE.md inside src/api/v2/payments/ that repeats the error-handling conventions for the handlers in that one directory. B) Change the glob to src/api/**/.ts, so the rule matches handler files at any depth below src/api. C) Rename the rule file to api-handlers-v2.md, so Claude Code associates it with the v2 directory where most handlers are stored. D) Move the conventions into the root CLAUDE.md, so they load in every session whether or not Claude is editing API handler files.

D2 · Claude Code

Q620. The test-generation job produces many tests that developers delete: about a third duplicate scenarios already covered in existing test files, and many others only check getters and setters. Developers also complain that generated tests build their own database setup instead of using the team's shared fixtures. What change would most improve the generated tests? (Select ONE.) A) Generate three times as many tests on each run, then keep only those that pass and increase coverage the most, discarding all of the others. B) Document testing standards, what makes a test valuable, and the available fixtures in CLAUDE.md, and include the module's existing test files in the job's context. C) Move the test-generation job to the Message Batches API overnight, so the extra time lets Claude write more careful and thorough tests. D) Filter the generated tests after each run by comparing test names with existing ones, and delete any generated test with a similar name.

D1 · Agentic Architecture

Q621. Lumen Ledger's review job checks the same aspects on every pull request in the same order: security, public API compatibility, database migration safety, then a short summary. A teammate proposes replacing it with an autonomous agent that plans its own investigation steps for each pull request. Reviews must stay consistent and auditable across 300 pull requests a week. Which decomposition should the job use? (Select ONE.) A) Four independent agents that each review one aspect and post their own comments directly, with no summary step joining their results. B) An autonomous agent that decides for each pull request which aspects to check and in what order, based on what it discovers in the diff. C) A fixed prompt chain with one focused step per aspect and a final summary step, keeping dynamic planning for open-ended jobs such as flaky-test investigations. D) One combined prompt that asks Claude to check security, compatibility and migrations together and then write the summary in the same response.

D2 · Claude Code

Q622. A staff engineer wrote Lumen Ledger's review criteria, such as 'flag any money arithmetic using floating point', in ~/.claude/CLAUDE.md on their own laptop. Their local reviews follow the criteria well, but the CI review job and other developers' sessions ignore them. The criteria must apply in CI and in every developer's session. What should the team do? (Select ONE.) A) Move the criteria into the project CLAUDE.md, so CI and every developer load them from the shared, versioned file. B) Put the criteria in .claude/settings.json, so they are applied as configuration to every Claude Code session that opens the project. C) Ask every developer to copy the criteria into their own ~/.claude/CLAUDE.md and add the same file to each CI runner's home directory. D) Pass the criteria to the CI job with a system prompt flag, and leave the staff engineer's user-level file as the source for local sessions.

D2 · Claude Code

Q623. A developer is using Claude Code to fix the script that posts review findings as inline comments. Three problems exist: comments on deleted lines land one line off, duplicate detection uses those line numbers as keys, and multi-line suggestions break at hunk boundaries. Changing the line mapping changes the duplicate keys and the hunk handling. How should the developer present these problems to Claude? (Select ONE.) A) Open three separate Claude Code sessions, one for each problem, so that each fix is developed in its own focused context. B) Report the off-by-one problem first, wait for the fix, then report the duplicate problem, and finally report the multi-line problem. C) Describe all three problems and how they interact in one detailed message, so Claude can design one consistent mapping fix. D) Ask Claude to 'fix the comment-posting bugs' and let it discover the three problems itself by reading the script and its logs.

D3 · Prompting & Structured Output

Q624. In the auto-fix job, one Claude Code session writes a fix for a failing test and then, in the same session, is asked to 'review your change for bugs before it is committed'. The self-review approves 98% of fixes, yet developers later find that one in eight auto-fixes breaks behaviour outside the failing test. How should the job review fixes? (Select ONE.) A) Use a larger model for the generating session, so that its fixes contain fewer bugs and its self-reviews become more reliable. B) Enable extended thinking in the generating session, so that it reasons more carefully when it reviews its own change before committing. C) Have a second, independent Claude instance review the diff and test results without the generator's reasoning, before commit. D) Ask the generating session to review its change twice in a row and commit only when both of its reviews approve the fix.

D2 · Claude Code

Q625. Developers raise two complaints about the review job. First, after each new commit to a pull request, the job posts comments again on issues it already reported. Second, the script that turns Claude's findings into inline comments breaks whenever the wording or layout of Claude's prose changes. Which TWO changes address these complaints? (Select TWO.) A) Run the review with --output-format json and --json-schema, so the findings arrive as structured objects the posting script can parse. B) Include the prior findings on each rerun and instruct Claude to report only new or still-unaddressed issues. C) Parse Claude's prose output with a more flexible regular expression that tolerates small changes in wording and line layout. D) Lower the temperature for the review so reruns produce identical wording, which lets GitHub merge repeated comments on the same code line.

claude -p "Review this diff. Prior findings are in prior.json; report only new or still-unaddressed issues." \
  --output-format json \
  --json-schema "$(cat .github/review-schema.json)"

D2 · Claude Code

Q626. Lumen Ledger's ledger/ directory has its own CLAUDE.md that imports money-handling rules with @import. A developer reports that in their local Claude Code sessions, Claude ignores those rules when editing ledger code, while teammates' sessions follow them. Nobody knows which memory files that developer's sessions actually load. What should the developer do first? (Select ONE.) A) Copy the money-handling rules into the developer's own ~/.claude/CLAUDE.md, so they load regardless of how the project is set up. B) Rewrite the money-handling rules in capital letters with stronger wording, so that Claude treats them as more important in every session. C) Reinstall Claude Code on the developer's laptop and clear its cache, so the next session starts from a clean installation state. D) Run /memory in a session working on ledger code to see which memory files are loaded, then compare the list with a teammate's session.

D4 · Tools & MCP

Q627. The review job should read linked tickets through the team's issue-tracker MCP server, and developers want the same server in their local Claude Code sessions. A developer added the server to the project's .mcp.json with the API token pasted in as plain text, and the security scanner flagged the commit. How should the server be configured? (Select ONE.) A) Store the token in the project CLAUDE.md with an instruction that Claude must pass it to the MCP server when it first connects. B) Add .mcp.json to .gitignore, so each developer and the CI job keeps a private copy of the file with the token written in directly. C) Keep the server in the project .mcp.json, reference the token as ${TRACKER_API_TOKEN}, and supply it from CI secrets and local shells. D) Move the server configuration into ~/.claude.json on every CI runner and every developer's laptop, so no token is ever stored in the repository.

{"mcpServers": {"tracker": {"type": "http", "url": "https://tracker.example.com/mcp", "headers": {"Authorization": "Bearer ${TRACKER_API_TOKEN}"}}}}

D2 · Claude Code

Q628. Since yesterday, the test-generation job fails on every run. The log shows "error: unknown option '--output-fromat'" and points to line 42 of .github/workflows/testgen.yml, where a teammate mistyped the flag during an unrelated change. A developer opens Claude Code to fix it. Which way of working fits this task? (Select ONE.) A) Use plan mode to explore every workflow file and propose a plan for the CLI flags they use before making any change at all. B) Use direct execution: ask Claude to correct the flag on line 42, then check the change and rerun the job to confirm it passes. C) Use the Explore subagent to survey all workflow files and summarize their flags, then decide whether a change is needed at all. D) Use the interview pattern so Claude asks questions about the team's CI design goals before it touches the workflow file.

D2 · Claude Code

Q629. Each of Lumen Ledger's twelve services keeps SQL migrations under services//db/migrations/. Migrations must follow strict conventions: reversible steps, no column drops without a deprecation period, and explicit lock timeouts. These conventions currently sit in the root CLAUDE.md and load for every task. What's the most maintainable way to apply them only when Claude works on migration files? (Select ONE.) A) Create a /migration-rules skill that developers must remember to invoke before Claude edits or reviews any migration file. B) Add a CLAUDE.md file to each of the twelve migrations directories, each containing a copy of the same migration conventions. C) Keep the conventions in the root CLAUDE.md under a clear 'Migrations' heading, so Claude can find them quickly when they matter. D) Create .claude/rules/migrations.md with a paths glob of services//db/migrations/**/.sql, so it loads only for those files.

---
paths:
  - "services/*/db/migrations/**/*.sql"
---
# Migration conventions
- Every step must be reversible.
- Never drop a column without a deprecation period.
- Set an explicit lock_timeout.

D3 · Prompting & Structured Output

Q630. Review comments fall into categories: security, correctness, and naming conventions. Naming comments have a 60% false-positive rate, and developers now dismiss review comments without reading them, including accurate security findings. The team expects that rewriting the naming criteria will take about two weeks. What should the team do now? (Select ONE.) A) Add 'be conservative about naming issues' to the prompt and keep all three categories running while the naming criteria are being rewritten. B) Keep all three categories but post naming comments at 'info' severity, so developers can tell them apart from the more important findings. C) Collapse all findings into one summary comment per pull request, so developers see fewer individual comments from every category combined. D) Turn off the naming category while its criteria are rewritten, and keep posting security and correctness findings.

D3 · Prompting & Structured Output

Q631. The review prompt says 'Flag performance problems. Be conservative and only report high-confidence findings.' Developers dismiss 80% of performance comments, most of which flag small loops over in-memory lists of a few items, while a real N+1 query in a request handler went unreported last month. How should the team change the prompt? (Select ONE.) A) Require that two separate review runs both flag the same performance issue before the job posts it as a comment on the pull request. B) Ask Claude to attach a confidence score from 0 to 1 to each finding and post only those performance findings scored above 0.9. C) Strengthen the instruction to 'be extremely conservative' and report a performance finding only when Claude is certain it is a real problem. D) Define which issues to report, such as queries inside request-handler loops, and which to skip, such as loops over tiny lists.

D2 · Claude Code

Q632. Lumen Ledger's root CLAUDE.md contains a 400-line release checklist covering changelog format, version bumps and API deprecation notices. Developers need it only when preparing a release pull request, about twice a month, but it loads into every session and every CI job. How should the team restructure it? (Select ONE.) A) Shorten the checklist to about 100 lines inside CLAUDE.md, keeping only the most important steps so it uses less context in each session. B) Move the checklist into each developer's ~/.claude/skills/ folder, so it stays out of the shared repository and loads only on demand. C) Move the checklist into .claude/rules/release.md without a paths field, so it lives in its own file separate from the main CLAUDE.md. D) Move the checklist into a project skill under .claude/skills/, committed to the repository, so developers invoke it on demand when preparing a release.

D2 · Claude Code

Q633. The auto-fix job runs on five self-hosted runners and behaves differently depending on the runner. On two runners, the service account has user-level hooks and plugins that another team installed, and they change how Claude Code acts. The job's instructions live in .github/autofix.md. Which invocation gives the same behaviour on every runner? (Select ONE.) A) claude -p with the instructions in CLAUDE.md, after asking the other team to remove their hooks and plugins from those two runners. B) claude -p --system-prompt-file .github/autofix.md, so the job's instructions replace the default system prompt on every runner the job uses. C) claude -p --bare --append-system-prompt-file .github/autofix.md, which skips auto-discovered configuration and adds the job's instructions explicitly. D) claude -p --bare, with the job's instructions moved into the project CLAUDE.md so that Claude Code picks them up automatically on every runner.

- name: Auto-fix failing tests
  run: |
    claude -p "Fix the failing tests listed in failures.txt" \
      --bare \
      --append-system-prompt-file .github/autofix.md \
      --output-format json

Scenario 4 · Structured Data Extraction

D3 · Prompting & Structured Output

Q634. The vehicle_vin field comes back null for 22% of repair estimates produced by three body-shop software packages, although a human can see the VIN on every estimate. These packages put it in a stamped box labelled 'VEH ID', or in the right column of a two-column header. The prompt already says to extract the vehicle identification number. What change would most effectively reduce these null results? (Select ONE.) A) Retry each estimate with a null VIN up to three times using the same prompt, and keep the first non-null value returned. B) Add a few examples showing correct VIN extraction from a 'VEH ID' stamp and from a two-column header layout. C) Add one sentence telling Claude that the VIN can appear under other labels and in other positions on a repair estimate. D) Make the vehicle_vin field required in the extraction schema, so Claude must always return a VIN for every repair estimate.

D5 · Context & Reliability

Q635. For one auto claim, the body shop's repair estimate states a total of 41,200 USD, while the line amounts in the adjuster's damage assessment add up to 39,800 USD. The pipeline currently keeps the estimate total and drops the adjuster figure without noting the difference. Regulators audit claim payments for overpayment. How should the extraction handle such conflicts? (Select ONE.) A) Record the average of the two values, so that the claim amount sits between the estimate figure and the adjuster's figure. B) Always keep the larger of the two values, since paying the higher amount is the safer choice when customer complaints are involved. C) Keep the value from whichever document has the later issue date, since the more recent document is the most likely to be correct. D) Record both values with source document and page, set a conflict flag, and let a reviewer or reconciliation step decide.

D3 · Prompting & Structured Output

Q636. To cut costs, Northfield wants to move extraction to the Message Batches API, which can take up to 24 hours to process a batch. Each new claim must have an initial reserve within 36 hours of its first document's arrival, and validation plus human review need up to 4 hours after extraction. Documents arrive steadily all day. How often should the application submit batches? (Select ONE.) A) Once a day at midnight, so that each batch contains a full day of documents and is as large and as cheap as possible. B) Every 12 hours, so each batch is large and the 24-hour processing window plus the wait before submission fits the deadline. C) Every 6 hours, so the worst-case wait plus 24 hours of processing and 4 hours of review stays within 36. D) Use the synchronous Messages API for every document, since any batch schedule risks missing the 36-hour reserve deadline.

D5 · Context & Reliability

Q637. On a labelled sample, overall field accuracy is 97%. Management proposes that extractions the model marks as high-confidence skip human review entirely, freeing the six reviewers for other work. You must protect claim payments from undetected errors. Which TWO steps should accompany this change? (Select TWO.) A) Rely on the 97% overall figure, since it exceeds the 95% target, and apply the change to every document type at the same time. B) Keep reviewing a stratified random sample of high-confidence extractions on an ongoing basis to measure error rates and spot new error patterns. C) Measure accuracy separately by document type and by field, and automate only the segments that meet the target on their own. D) Once the change is live, review only extractions marked low-confidence, and stop sampling the high-confidence group because it was already validated.

D3 · Prompting & Structured Output

Q638. For about 30% of medical bills, validation fails because provider_tax_id is missing. The pipeline retries each one three times with the validation error appended, and every retry still fails. Investigation shows that for these clinics the tax ID appears only in a separate assignment-of-benefits form, which is never sent to the extractor. What should change? (Select ONE.) A) Mark provider_tax_id as required in the schema, so that the model must provide a value before the extraction can be accepted. B) Add few-shot examples showing where the provider tax ID usually appears on medical bills from the most common clinics. C) Increase the retries to six and make the appended error message more detailed, so that the model searches the bill more carefully. D) Stop retrying these cases: return the field as missing with a reason, and route the bill to fetch the assignment-of-benefits form.

D3 · Prompting & Structured Output

Q639. A nightly batch of 18,000 archived claim documents completes with 210 failed requests. Their errors show the inputs exceeded the context limit: they are complete hospital records of 150 pages or more. Each request was submitted with a custom_id equal to the document ID. How should the team handle these failures? (Select ONE.) A) Resubmit only the 210 failed documents, identified by custom_id, after splitting each record into page ranges that fit. B) Resubmit the 210 failed documents with a higher max_tokens value, so that the model has enough room for the long record output. C) Resubmit the 210 failed documents unchanged in a new batch, since batch failures are often temporary and may succeed on a second try. D) Resubmit the whole batch of 18,000 documents the next night, so that all results come from one consistent processing run.

D5 · Context & Reliability

Q640. The six reviewers can check about 900 of the 25,000 daily claim documents. Today they pick documents at random, and most of what they check is already correct. The model can output a confidence score for each extracted field, and the team has 5,000 documents labelled by reviewers last quarter. How should review attention be routed? (Select ONE.) A) Route the longest documents to review first, since longer documents contain more fields and so are more likely to contain an error. B) Rotate review across repair shops alphabetically each day, so that every shop's documents receive the same amount of reviewer attention. C) Calibrate field-level confidence thresholds on the labelled documents, then route low-confidence fields and documents with conflicting sources to review first. D) Route documents to review by the model's document-level confidence score as it is produced, without comparing the scores to the labelled set.

D3 · Prompting & Structured Output

Q641. Repair estimates must not be paid, but final repair invoices must be. Many documents are ambiguous: an 'INVOICE' header with 'subject to teardown, amounts not final' in the footer, or 'ESTIMATE' crossed out by hand. A two-page list of classification rules in the prompt still produces inconsistent results on these documents. What should the team add? (Select ONE.) A) Two to four examples of ambiguous documents, each showing the classification and the reasoning for choosing it over the other type. B) More rules covering each ambiguous pattern found so far, so that the classification list becomes complete for every known variation. C) Three classification runs per document with a majority vote, so the more frequent answer is used for each ambiguous document. D) A keyword rule that classifies a document as an estimate whenever the word 'estimate' appears anywhere in its text, whether or not crossed out.

D1 · Agentic Architecture

Q642. Northfield's new enrichment stage runs on the Claude Agent SDK and calls two community MCP servers that the company does not maintain. One returns storm event times as Unix timestamps and severities as numeric codes; the other returns policy coverage end times as ISO 8601 local times and text statuses. The agent sometimes compares the two formats wrongly and reports covered losses as outside the policy period. What should you implement? (Select ONE.) A) A PostToolUse hook that converts every timestamp to ISO 8601 UTC and every numeric code to a named value before the agent sees the result. B) A post-processing step that converts timestamps in the agent's final JSON output to UTC after the agent has finished its reasoning. C) A request to both community projects asking them to agree on one timestamp format and one status vocabulary in their next releases. D) A system prompt section explaining both timestamp formats and the numeric severity codes, so the agent converts them correctly while reasoning.

from datetime import datetime, timezone
SEVERITY = {1: 'minor', 2: 'moderate', 3: 'severe'}

def normalize(record):
    t = record.get('event_time')
    if isinstance(t, (int, float)):
        record['event_time'] = datetime.fromtimestamp(t, tz=timezone.utc).isoformat()
    if isinstance(record.get('severity'), int):
        record['severity'] = SEVERITY.get(record['severity'], 'unknown')
    return record

D3 · Prompting & Structured Output

Q643. Extraction uses tool use with a strict schema, so every result is valid JSON. Business validation finds that in 4% of repair estimates the extracted line-item amounts do not add up to the extracted estimate total, usually because one line was read twice or skipped. Most of these source estimates are consistent when a reviewer checks them. What should the application do when this validation fails? (Select ONE.) A) Tighten the JSON schema with more constraints, so that line items that do not sum to the total are rejected as invalid output. B) Send a follow-up request with the original document, the failed extraction, and the specific error, such as 'lines sum to 1,240.00; total is 1,420.00'. C) Resend the original request unchanged, since a second attempt at the same extraction will often produce a different and correct reading. D) Set the temperature to 0 for all extraction requests, so that the model reads each estimate the same way and avoids random errors.

D3 · Prompting & Structured Output

Q644. Northfield extracts deductibles and limits from 70-page commercial property policies with many endorsements. A single extraction pass over each whole policy misses deductibles defined in middle endorsements, and sometimes returns contradictory values, such as a 2% wind deductible in one field and 5% in another. How should the extraction be restructured? (Select ONE.) A) Extract each section or endorsement in its own focused pass, then run a separate integration pass that reconciles values across sections and flags conflicts. B) Add an instruction asking Claude to read every endorsement carefully and to make sure all deductible values agree before it answers. C) Move to a model with a larger context window, so the whole 70-page policy fits comfortably into one extraction pass with room to spare. D) Run the same single-pass extraction twice on each policy and keep the union of all deductibles found across the two runs.

D4 · Tools & MCP

Q645. Each extraction must start with extract_claim_metadata, which identifies the policy number, document type and loss date, because the enrichment tools lookup_policy_coverage and validate_provider_id need the policy number it returns. In about 9% of requests, Claude calls lookup_policy_coverage first with a guessed policy number. How should you configure the requests? (Select ONE.) A) Add a system prompt instruction that extract_claim_metadata must always be called first, before any enrichment tool is ever used. B) Force tool_choice to extract_claim_metadata on the first request, then use auto on the follow-up turns. C) Force tool_choice to extract_claim_metadata on every request in the conversation, so it always runs before anything else happens. D) Set tool_choice to "any" on every request, so Claude must call one of the tools instead of replying with plain text at any step.

{"model": "MODEL_ID", "max_tokens": 1024, "tools": [{"name": "extract_claim_metadata"}, {"name": "lookup_policy_coverage"}, {"name": "validate_provider_id"}], "tool_choice": {"type": "tool", "name": "extract_claim_metadata"}, "messages": [{"role": "user", "content": "<document text>"}]}

D3 · Prompting & Structured Output

Q646. The medical bill schema marks diagnosis_code, the ICD-10 code for the injury, as required. About 18% of bills from small clinics do not list any diagnosis code. For these, Claude returns plausible-looking codes, and the medical review team has found several wrong ones on paid injury claims. What schema change addresses this? (Select ONE.) A) Keep diagnosis_code required and retry any bill whose code fails a format check, appending the format error to the retry request. B) Make diagnosis_code nullable, so Claude returns null when no code is shown, and route those bills to medical coders. C) Change diagnosis_code to an enum of the 200 codes Northfield sees most often, so Claude can choose only from codes known to be valid. D) Keep diagnosis_code required and add 'never guess a diagnosis code' to the prompt, so Claude leaves fewer invented values in the output.

{"type": "object", "properties": {"diagnosis_code": {"type": ["string", "null"], "description": "ICD-10 code exactly as printed on the bill; null if the bill shows none"}}, "required": ["diagnosis_code"]}

D3 · Prompting & Structured Output

Q647. Claim documents arrive in one shared upload queue, so their type is unknown. The application offers three extraction tools: extract_claim_form, extract_repair_estimate and extract_medical_bill. With tool_choice set to auto, about 5% of responses are plain text, such as 'This appears to be a police report with partial estimate data', which the parser cannot handle. What change guarantees structured output? (Select ONE.) A) Force tool_choice to extract_claim_form for every document, since claim forms are the most common document type in the queue. B) Keep auto and add a fallback parser that uses regular expressions to pull fields out of any plain-text responses Claude returns. C) Add a system prompt instruction that Claude must always respond by calling an extraction tool and must never answer in plain text. D) Set tool_choice to "any", so Claude must call one of the three extraction tools but still chooses the one that fits the document.

D5 · Context & Reliability

Q648. A coordinator processes each claim file of 6 to 40 documents by sending every document to an extraction subagent. When the OCR service times out on one document, the subagent raises an exception and the coordinator aborts the whole claim file, discarding the other good extractions and delaying the reserve. How should errors flow instead? (Select ONE.) A) The subagent retries the transient failure; if it still fails, it returns a structured error naming the document, what was tried, and partial results. B) The subagent catches the exception and returns an empty extraction marked as successful, so the coordinator can finish the file without interruption. C) The subagent returns the message 'extraction unavailable' to the coordinator, which then marks that document for manual entry by a reviewer. D) The coordinator keeps aborting the file on any failure, but automatically restarts the entire claim file from the beginning after a short delay.