CCAR-F PrepJoin the AI Sprint

Learn & Review

The full 60-question bank

Every question in one scrollable page, grouped by domain, with the correct answer, why each wrong option is wrong, and a link to the exact Claude documentation page for the concept. Read it end to end, or use test mode to hide the answers and self-check.

Domain 1 · Agent Architecture & Orchestration

27% of the exam · 16 questions

D1-Q01Task 1.1

You are writing the agentic loop for a support agent on the Claude API. After each response you must decide whether to execute tools or hand the final answer back to the customer. Which signal should drive that branch?

  1. AThe stop_reason field on the response: keep executing tools while it is tool_use, and finish when it is end_turn.
  2. BWhether the assistant's text contains a closing phrase such as I hope that helps.
  3. CWhether the response contains fewer tokens than a threshold you tune per deployment.
  4. DWhether the loop has run fewer than five iterations.

Correct answer: A. stop_reason is the API's own statement of why generation stopped. tool_use means Claude has emitted one or more tool_use blocks and is waiting on their results; you execute them, append tool_result blocks, and call again. end_turn means Claude finished on its own and the loop terminates. It is a structured field, so the branch is deterministic.

Why not B: Completion phrasing is model- and prompt-dependent. Parsing prose for control flow is the classic anti-pattern this field exists to remove.

Why not C: Response length has no defined relationship to whether tools are pending. A long final answer and a short tool request would both be misread.

Why not D: An iteration cap is a safety valve against runaway loops, not a termination signal. Used as the primary check it truncates work that was still in progress.

Documentation for this topic →

D1-Q02Task 1.1

Your agent calls a lookup_order tool that raises a timeout against a flaky downstream service. What should the loop send back to Claude for that call?

  1. AA tool_result block for the matching tool_use_id with is_error set to true and a short description of the failure.
  2. BNothing for that tool — omit the result so Claude retries the call on its own.
  3. CA tool_result containing an empty object, so the agent treats it as no matching orders.
  4. DRaise the exception out of the loop and return a generic apology to the customer.

Correct answer: A. Every tool_use block must be answered by a tool_result block carrying the same tool_use_id. Marking it is_error: true with a brief description lets Claude see what went wrong and choose a recovery — retry, try another tool, or escalate — while keeping the conversation structurally valid.

Why not B: A missing tool_result for an emitted tool_use is a malformed request. The API rejects it rather than prompting a retry.

Why not C: Reporting a timeout as an empty result is a silent lie to the model. The agent will confidently tell the customer they have no orders.

Why not D: Aborting the turn discards a recoverable situation. A transient timeout on one tool does not have to end the conversation.

Documentation for this topic →

D1-Q03Task 1.3

A research coordinator delegates to four subagents. Reviewers report that subagent findings often contradict the source material, and the coordinator cannot tell which claim came from where. What change addresses the cause?

  1. ARequire each subagent to return structured output carrying the claim, a verbatim quote, the source URL, and the publication date.
  2. BIncrease the coordinator's max_tokens so it can hold more of each subagent's prose.
  3. CHave the coordinator re-run every subagent a second time and keep the answer that appears twice.
  4. DMove all four subagents into a single agent with a longer system prompt.

Correct answer: A. The coordinator can only synthesize as carefully as its inputs allow. Requiring structured, attributed output per finding gives it the provenance it needs to reconcile claims, flag disputes, and cite sources — and it makes an unsupported claim visibly missing its quote.

Why not B: The problem is that attribution was never captured, not that it was captured and truncated. More tokens carry more unattributed prose.

Why not C: Repetition measures the model's consistency, not the source's accuracy. Two identical hallucinations agree with each other.

Why not D: Collapsing the subagents removes the parallelism and the context isolation without adding any provenance.

Documentation for this topic →

D1-Q04Task 1.2

An audit finds that in roughly one refund out of eight, the agent calls process_refund without having first called verify_eligibility. The system prompt already instructs it to always verify first. What is the most reliable fix?

  1. AEnforce the ordering in code — reject a process_refund call whose session has no successful verify_eligibility result, and return that as a tool error.
  2. BRestate the instruction more forcefully in the system prompt, in capitals and at the end.
  3. CAdd few-shot examples showing verification happening before every refund.
  4. DLower the temperature so the agent follows instructions more consistently.

Correct answer: A. A step that must happen every time is a business rule, not a prompting preference. Enforcing the precondition in the tool layer makes the failure impossible rather than unlikely, and returning it as a tool error lets the agent recover by calling the verification tool.

Why not B: Emphasis shifts the probability of compliance; it cannot pin it at 100%. A one-in-eight failure on a money-moving action needs a guarantee.

Why not C: Few-shot examples help when the model has not seen the pattern. Here it has been told the pattern and still deviates, which points at enforcement rather than demonstration.

Why not D: Temperature affects sampling diversity, not instruction adherence, and at 0 the agent can still skip a step it did not plan.

Documentation for this topic →

D1-Q05Task 1.1

Traces show the agent resolving a simple request in four API round trips: it asks for get_customer, waits, then asks for lookup_order, waits, then asks for get_policy. The three lookups do not depend on each other. What reduces the latency?

  1. AInstruct the model to request every independent tool it needs in one turn, and execute the resulting tool_use blocks concurrently before returning all results together.
  2. BCache the tool results so the second identical request is faster.
  3. CRaise max_tokens so the model can plan more of the work up front.
  4. DSplit the three lookups across three separate subagents.

Correct answer: A. A single assistant turn can contain several tool_use blocks. Prompting for that, executing them in parallel, and returning all the tool_result blocks in one user message collapses three round trips into one.

Why not B: Caching helps a repeat of the same request. It does nothing for the first one, which is the case being measured.

Why not C: The model is not running out of output budget; it is choosing to ask for one tool at a time.

Why not D: Subagents add coordination overhead and their own round trips. Parallel tool calls in one turn are the lighter mechanism for independent lookups.

Documentation for this topic →

D1-Q06Task 1.3

A coordinator spawns four subagents. One of them times out. What should the coordinator do with the remaining three?

  1. AContinue with the partial results, recording which subagent failed and what is therefore missing from the synthesis.
  2. BDiscard everything and restart all four, so the report is built from a consistent run.
  3. CSilently omit the failed subagent's topic from the report.
  4. DSubstitute the coordinator's own knowledge for the missing subagent's findings.

Correct answer: A. Partial failure is the normal case in a multi-agent system. Continuing with what succeeded, and stating the gap explicitly, preserves most of the work and keeps the output honest about its coverage.

Why not B: Restarting throws away three successful, often expensive, research passes to recover one.

Why not C: An unmarked gap is the dangerous outcome: the report reads as complete when it is not.

Why not D: Filling a research gap from the model's own priors is exactly the unsourced claim the subagent architecture exists to avoid.

Documentation for this topic →

D1-Q07Task 1.2

Your agent calls three third-party MCP tools. One returns Unix timestamps, one ISO 8601 strings, and one a locale-formatted date. You do not control any of them, and the agent keeps misreading dates. What is the cleanest fix?

  1. ANormalize the outputs in a PostToolUse hook, so every tool result reaches the model in one date format.
  2. BDescribe all three formats in the system prompt and ask the model to convert them as needed.
  3. CFork each MCP server and change its output format.
  4. DAdd a convert_date tool the model can call after each lookup.

Correct answer: A. A PostToolUse hook sits between the tool and the model, so it can rewrite results deterministically. It works for servers you do not own and it removes the conversion from the model's job entirely.

Why not B: This makes correct date handling a probabilistic step on every single call, which is what is already failing.

Why not C: Forking three third-party servers to change a format is a maintenance burden you would carry forever.

Why not D: An extra tool call per lookup doubles the round trips and still depends on the model remembering to make it.

Documentation for this topic →

D1-Q08Task 1.2

A support agent must decide when to hand a conversation to a human. Which basis for that decision is the most defensible?

  1. AExplicit criteria — the request falls outside stated policy, the customer asks for a human, or the agent cannot make progress — supported by examples of each.
  2. BThe model rating its own confidence from 1 to 10, escalating below 7.
  3. CSentiment analysis of the customer's messages, escalating on anger.
  4. DA fixed rule that any conversation longer than eight turns escalates.

Correct answer: A. Escalation is a policy question, so it needs stated conditions a reviewer can audit and a model can apply consistently. Naming the triggers, and showing an example of each, is what makes the boundary reproducible.

Why not B: Self-rated confidence is not calibrated against anything. It moves with phrasing, not with actual risk.

Why not C: An angry customer with a policy-covered problem should be resolved, not transferred; a polite one asking for an unlisted exception should be escalated. Sentiment does not track the decision.

Why not D: Turn count is a proxy for difficulty at best, and it escalates long conversations that were going perfectly well.

Documentation for this topic →

D1-Q09Task 1.1

A response comes back with stop_reason of max_tokens in the middle of a long answer. What is the correct handling?

  1. ATreat the turn as incomplete — either raise max_tokens and retry, or send the truncated content back and ask Claude to continue.
  2. BTreat it like end_turn and show the user what arrived.
  3. CRetry the identical request, since the truncation is nondeterministic.
  4. DReduce the size of the system prompt, since max_tokens counts input.

Correct answer: A. max_tokens means generation hit the output ceiling, not that Claude finished. The content is a fragment, so you either give the turn more room or continue from where it stopped.

Why not B: Presenting a truncated answer as final is the failure mode this signal exists to let you avoid — often mid-sentence, sometimes mid-JSON.

Why not C: The same request with the same ceiling will truncate again. Nothing about the limit is random.

Why not D: max_tokens bounds the output only. Shrinking the system prompt frees context window, not generation budget.

Documentation for this topic →

D1-Q10Task 1.3

Two subagents return conflicting figures for the same statistic, each with a credible source. What should the coordinator do?

  1. AReport both values with their sources and dates, marked as disputed, rather than choosing one.
  2. BTake the value from the subagent whose source is more recent and drop the other.
  3. CAverage the two figures.
  4. DRe-run both subagents and keep whichever value comes back twice.

Correct answer: A. The coordinator has no basis for adjudicating between two sourced claims. Surfacing the disagreement with attribution is more useful to the reader than a confident single number, and it separates confirmed findings from contested ones.

Why not B: Recency is not authority. A newer blog post does not outrank an older primary source.

Why not C: Averaging two incompatible figures invents a third that no source supports.

Why not D: Re-running measures retrieval stability, not truth, and it costs another full research pass.

Documentation for this topic →

D1-Q11Task 1.2

Analysis shows that when a customer message contains the word account, the agent routes to get_customer 78% of the time regardless of what was actually asked. Tool descriptions are clear and distinct. Where should you look?

  1. AThe system prompt, for keyword-based routing guidance that is steering selection independently of the request's meaning.
  2. BThe tool schemas, for an overly permissive input type.
  3. CThe model version, which may have a selection bias.
  4. DThe conversation history, which may be too long.

Correct answer: A. A strong correlation between one token and one tool is the signature of an explicit routing rule. When descriptions are already clean, the next place a keyword heuristic can live is the system prompt, where it usually arrived as a well-meant hint.

Why not B: A loose input type would produce malformed arguments, not a consistent bias toward one tool.

Why not C: Blaming the model is unfalsifiable here and does not explain why the bias attaches to one specific word.

Why not D: History length affects what the model remembers, not a keyword-shaped routing pattern.

Documentation for this topic →

D1-Q12Task 1.2

A lookup_account tool takes a customer name. When the name matches several accounts it returns the most recently active one, and 15% of those resolutions are the wrong account. What is the right change?

  1. AReturn all matches and have the agent ask the customer for a disambiguating detail before acting.
  2. BImprove the tie-break so the most recently active match is chosen more accurately.
  3. CHave the tool return only an error when the name is ambiguous.
  4. DAsk the model to guess the intended account from conversation context.

Correct answer: A. The tool is resolving an ambiguity it has no information to resolve. Surfacing the candidates and letting the agent ask one clarifying question converts a silent 15% error rate into a brief, correct exchange.

Why not B: A better heuristic is still a guess. Recency does not mean the customer on the line.

Why not C: A bare error gives the agent nothing to work with and dead-ends conversations that a single question would resolve.

Why not D: The context does not contain the missing identifier either, so this relocates the guess rather than removing it.

Documentation for this topic →

D1-Q13Task 1.3

A subagent is asked to analyse a document the coordinator retrieved three steps earlier, and it repeatedly asks for information the coordinator already has. Why?

  1. ASubagents do not inherit the coordinator's conversation history; the context they need must be passed explicitly in their prompt.
  2. BThe subagent's context window is too small for the coordinator's history.
  3. CThe subagent lacks the tool needed to read the coordinator's messages.
  4. DThe coordinator is compacting its history before delegating.

Correct answer: A. Context isolation is the point of a subagent: it runs with its own window and sees only what it is given. Anything it needs — the document, the constraints, the definition of done — has to be stated in the delegation.

Why not B: The window size is not the issue; the history was never offered to the subagent in the first place.

Why not C: There is no tool for reaching into a parent's conversation, and adding one would defeat the isolation.

Why not D: Compaction would shorten what the coordinator remembers. It has no bearing on what a subagent receives.

Documentation for this topic →

D1-Q14Task 1.1

You want a specific turn to always produce a tool call rather than prose — the caller cannot handle a text answer. Which control does that?

  1. ASet tool_choice to any for that request, which requires the model to use one of the supplied tools.
  2. BSet tool_choice to auto and describe the requirement in the system prompt.
  3. CRemove the assistant's ability to emit text by setting max_tokens low.
  4. DRetry the request until a tool_use block comes back.

Correct answer: A. tool_choice moves tool use from a suggestion to a constraint: any forces some tool, and naming a specific tool forces that one. It is the API-level guarantee the situation calls for.

Why not B: auto leaves the decision with the model, so the prose case remains possible however firmly it is discouraged.

Why not C: A low output ceiling truncates the response; it does not change what kind of block the model emits.

Why not D: A retry loop converges eventually at the cost of latency and spend, and it is unnecessary when the parameter exists.

Documentation for this topic →

D1-Q15Task 1.1

You add a hard cap of 20 iterations to an agent loop. What is that cap for?

  1. AA safety valve against a runaway loop, alongside stop_reason — hitting it is an incident to investigate, not a normal ending.
  2. BThe primary termination condition, replacing stop_reason inspection.
  3. CA cost control that should be tuned down until most conversations hit it.
  4. DA way to bound latency, since each iteration takes roughly the same time.

Correct answer: A. The loop ends when stop_reason says so. The cap exists to stop a pathological case — a tool that always fails, a cycle of retries — from running forever, so reaching it should be logged and looked at.

Why not B: Using the cap as the termination condition truncates work mid-task whenever a legitimate request needs more steps.

Why not C: Tuning a safety limit down until it fires routinely converts it into a silent truncation mechanism.

Why not D: Iterations vary enormously in duration depending on the tools involved, so the cap is a poor latency bound.

Documentation for this topic →

D1-Q16Task 1.2

An agent handles single-issue requests well but does poorly when a customer raises three problems in one message, addressing the first and dropping the others. What is the most direct fix?

  1. AAdd few-shot examples that show the request being decomposed into separate issues, each investigated and then answered together.
  2. BInstruct the agent to ask the customer to send one issue per message.
  3. CRun the message through a classifier that splits it before the agent sees it.
  4. DIncrease the iteration cap so the agent has room to work through all three.

Correct answer: A. The model has the capability — it handles each issue well in isolation — but it has not been shown the decomposition pattern. Demonstrating it is the standard remedy for a missing procedure.

Why not B: This fixes the metric by pushing the work onto the customer, which is the opposite of what a support agent is for.

Why not C: A pre-splitting classifier is a separate system to build and maintain, and it loses the cross-issue context that sometimes matters.

Why not D: The agent is not running out of iterations; it stops because it believes it is finished.

Documentation for this topic →

Domain 2 · Tool Design & MCP Integration

18% of the exam · 11 questions

D2-Q01Task 2.1

Two tools, get_customer and lookup_order, are each described in a single short sentence. In production the agent frequently calls get_customer for order questions. What should you try first?

  1. ARewrite both descriptions to state what the tool returns, what its inputs mean, and when to use it rather than the other one.
  2. BAdd a routing classifier ahead of the agent that picks the tool from the customer's message.
  3. CMerge the two tools into one get_account_data tool that returns everything.
  4. DAdd ten few-shot examples of correctly routed requests to the system prompt.

Correct answer: A. A tool description is the model's entire specification for that tool. When two descriptions are thin and similar, selection is ambiguous by construction. Expanding them — inputs, outputs, boundaries, and an explicit contrast with the neighbouring tool — is the cheapest change and it addresses the actual cause.

Why not B: A classifier is a second system to build, host, and keep in sync, added to compensate for a description you have not written yet.

Why not C: Merging removes the choice by removing the capability boundary. It returns data the caller did not ask for and makes permissions coarser.

Why not D: Few-shot examples can help selection, but they patch over an ambiguous specification rather than fixing it, and they cost tokens on every request.

Documentation for this topic →

D2-Q02Task 2.2

You are exposing a company knowledge base through MCP. The client application decides which documents to attach to a conversation; the model should not be able to pull arbitrary files on its own. Which MCP primitive fits?

  1. AA resource — resources are application-controlled, so the host decides what is exposed to the model.
  2. BA tool — tools are the only way to surface external data to the model.
  3. CA prompt — prompts are the primitive for attaching document context.
  4. DA sampling request, so the server can ask the host for completions over the documents.

Correct answer: A. MCP splits primitives by who is in control. Tools are model-controlled: Claude decides when to invoke them. Resources are application-controlled: the host application selects them and passes them into context. Prompts are user-controlled templates the user invokes deliberately. A host-curated document set is exactly the resource case.

Why not B: Tools would hand the selection decision to the model, which is the behaviour the requirement rules out.

Why not C: Prompts are user-invoked templates, not a channel for the host to attach data silently.

Why not D: Sampling lets a server request a model completion through the host. It is not a mechanism for exposing documents.

Documentation for this topic →

D2-Q03Task 2.1

An extraction pipeline must return an invoice as an object with a fixed set of fields, and downstream code parses it directly. Which approach gives the strongest guarantee that the shape is respected?

  1. ADefine a tool whose input_schema is the invoice schema and let Claude call it, then read the validated tool input.
  2. BAsk for JSON in the system prompt and wrap json.loads in a try/except with one retry.
  3. CAsk for JSON and strip any Markdown code fences before parsing.
  4. DAsk for the fields as a numbered list and parse them positionally.

Correct answer: A. Tool input_schema is a JSON Schema the API validates the model's arguments against. Using a tool purely as an output contract turns a formatting request into a structural one, which is why it is the standard way to get reliably parseable output.

Why not B: A retry loop reduces how often malformed output reaches you; it does not constrain the model's output shape, and it doubles latency when it fires.

Why not C: Fence-stripping fixes one specific formatting habit. It does nothing about a missing field or a string where a number was expected.

Why not D: Positional parsing of prose is the most brittle option of the four — one reordered or omitted line silently corrupts every field after it.

Documentation for this topic →

D2-Q04Task 2.1

A create_ticket tool accepts a priority argument. The model supplies values like urgent, P1, high and critical, and your backend rejects most of them. What change to the tool fixes this?

  1. AConstrain priority in the input_schema with an enum of the accepted values.
  2. BAccept any string and map unknown values to a default priority.
  3. CAdd a sentence to the tool description listing the accepted values.
  4. DValidate the value and return an error so the model retries.

Correct answer: A. The input_schema is JSON Schema, and an enum makes the permitted set part of the contract the model is given rather than something it has to remember. It is the difference between describing a rule and encoding one.

Why not B: Silently defaulting turns a caller mistake into a wrong-priority ticket that nobody notices.

Why not C: Prose in the description helps, but it leaves the constraint advisory. The schema field exists precisely to make it binding.

Why not D: An error plus a retry costs a round trip on every miss and still relies on the model reading the message correctly.

Documentation for this topic →

D2-Q05Task 2.2

Your team wants a reusable, user-invoked template — summarize this pull request in our house format — exposed from an MCP server. Which primitive is it?

  1. AA prompt, which is user-controlled and surfaced for the user to invoke deliberately.
  2. BA tool, so Claude can decide when a summary is needed.
  3. CA resource, so the template is attached to the conversation as context.
  4. DA sampling request back to the host.

Correct answer: A. MCP prompts are parameterised templates the user chooses to run — typically surfaced in the client as a command. That matches a house-format summary the user asks for on purpose.

Why not B: A tool would let the model decide to summarize unprompted, which is not what a user-invoked template means.

Why not C: A resource supplies data to the context. The template here is an action the user triggers, not a document.

Why not D: Sampling lets a server ask the host for a completion. It is not a mechanism for publishing a reusable template.

Documentation for this topic →

D2-Q06Task 2.2

An MCP server runs as a local subprocess on the developer's own machine, launched by the client. Which transport does that describe?

  1. Astdio, where the client spawns the server and they exchange messages over standard input and output.
  2. BStreamable HTTP, since local servers still speak HTTP over the loopback interface.
  3. CWebSocket, which MCP uses for all bidirectional local transport.
  4. DUnix domain sockets, the required transport for same-machine servers.

Correct answer: A. stdio is MCP's transport for locally launched servers: the client starts the process and talks to it over stdin/stdout. Remote or shared servers use the HTTP transport instead.

Why not B: The HTTP transport exists, but it is for servers reached over a network rather than spawned as a child process.

Why not C: WebSocket is not the defined transport for a client-launched local server.

Why not D: Nothing in MCP requires Unix domain sockets, and they would not work on every supported platform.

Documentation for this topic →

D2-Q07Task 2.1

A search_documents tool can return several megabytes of matched text. Feeding that straight back blows the context window. What is the right tool design?

  1. AReturn a bounded page of results with identifiers and short snippets, and provide a second tool that fetches one document in full.
  2. BReturn everything and let the client truncate the result before it reaches the model.
  3. CReturn only the single best match, so the size is always small.
  4. DSummarize the matches with a model call inside the tool and return the summary.

Correct answer: A. Splitting search from retrieval keeps every tool result small and predictable, and it lets the model spend its context only on the documents it actually decides to read.

Why not B: Truncating at an arbitrary byte boundary discards results with no signal about what was lost, and often cuts a document in half.

Why not C: One result makes the tool useless for any question whose answer spans several documents, and it hides how much else matched.

Why not D: A hidden model call inside a tool adds latency and cost to every search and quietly loses detail the agent may have needed.

Documentation for this topic →

D2-Q08Task 2.1

A process_refund tool is occasionally invoked twice for the same order when a network retry duplicates the call. What property should the tool have?

  1. AIdempotency — accept a caller-supplied key so a repeated call for the same refund returns the original result instead of issuing a second one.
  2. BA confirmation argument the model must set to true on the second attempt.
  3. CA rate limit of one refund per order per minute.
  4. DA longer timeout, so retries are less likely to be triggered.

Correct answer: A. Retries are a fact of any networked system, so a money-moving operation has to be safe to repeat. An idempotency key makes the second call a no-op that returns the first result.

Why not B: This puts the safety of a financial operation in the model's hands, and a duplicate caused by a network retry never reaches the model at all.

Why not C: A time window narrows the race without closing it, and it blocks legitimate distinct refunds on the same order.

Why not D: A longer timeout changes how often duplicates occur. It does not make one harmless when it does.

Documentation for this topic →

D2-Q09Task 2.1

You are deciding between one manage_file tool with a mode argument of read, write, or delete, and three separate tools. Which is the better design and why?

  1. AThree tools, because each gets its own description and schema, and permissions can be granted for reading without also granting deletion.
  2. BOne tool, because a smaller tool list makes selection easier for the model.
  3. COne tool, because it guarantees consistent argument names across the operations.
  4. DThree tools, because the API limits how many arguments a single tool may take.

Correct answer: A. Distinct capabilities want distinct tools. Each carries its own guidance and its own schema, and — the decisive point — an allowlist can include the read tool while excluding the destructive one, which a mode argument makes impossible.

Why not B: Fewer tools is not automatically clearer; a single overloaded tool hides three different contracts behind one description.

Why not C: Consistent naming is achievable across separate tools and is not worth collapsing a permission boundary for.

Why not D: There is no such argument limit, so this is the right conclusion supported by a made-up reason.

Documentation for this topic →

D2-Q10Task 2.2

Two MCP servers configured in the same project each expose a tool called search. What is the practical consequence to design around?

  1. ATools are namespaced by their server, so both remain callable — but their descriptions must make the difference clear or the model will pick between them badly.
  2. BThe second server fails to connect, since tool names must be globally unique.
  3. CThe client silently drops one of the two tools.
  4. DBoth tools are merged into one whose arguments are the union of both schemas.

Correct answer: A. Server-qualified naming keeps both tools available, which moves the problem from a collision to a selection one: two tools called search need descriptions that say what each one searches.

Why not B: Names are scoped per server precisely so independent servers do not have to coordinate on naming.

Why not C: Dropping a configured tool without telling anyone would be a silent capability loss, not the defined behaviour.

Why not D: Merging schemas from unrelated servers would produce a tool matching neither backend.

Documentation for this topic →

D2-Q11Task 2.1

A tool's description reads, in full: Gets data for a user. Which rewrite most improves selection and argument quality?

  1. AState what it returns, what each argument accepts with an example, when to use it, and when to use a neighbouring tool instead.
  2. BAdd the tool's HTTP endpoint and authentication requirements.
  3. CAdd the average latency and the backend service that owns it.
  4. DRename it to get_user_data_v2 so its purpose is clearer from the name.

Correct answer: A. The model chooses a tool and fills its arguments from the description alone. Returns, argument formats with examples, and an explicit boundary against the nearest alternative are what actually change both decisions.

Why not B: Endpoints and auth are the caller's concern; the model never issues the request itself.

Why not C: Operational metadata does not help the model decide whether this tool answers the question in front of it.

Why not D: A longer name carries a fraction of the information a description can, and a version suffix says nothing about behaviour.

Documentation for this topic →

Domain 3 · Claude Code Configuration & Workflows

20% of the exam · 12 questions

D3-Q01Task 3.1

Your team wants every Claude Code session in a repository to know the project's build commands and architectural conventions, without anyone pasting them in. Where does that belong?

  1. AA CLAUDE.md at the repository root, committed so every contributor's session loads it.
  2. BA .claude/agents/ subagent definition that contributors invoke first.
  3. CA PreToolUse hook that prints the conventions before each tool call.
  4. DThe user-level ~/.claude/CLAUDE.md, so it applies wherever the developer works.

Correct answer: A. Project memory lives in CLAUDE.md at the project root. It is loaded automatically at session start and, because it is checked in, it reaches every contributor and is reviewed like any other file.

Why not B: A subagent has its own context and runs only when delegated to. It cannot supply baseline conventions to the main session.

Why not C: Hooks fire around tool calls, so the guidance would arrive repeatedly and only after work had begun.

Why not D: User memory is personal and uncommitted. It would apply to this developer in every repository and to no one else in this one.

Documentation for this topic →

D3-Q02Task 3.2

In CI you need Claude Code to refuse any command that writes to the production deployment directory, regardless of what the model decides. Which mechanism enforces that?

  1. AA PreToolUse hook that inspects the pending call and blocks it, since it runs before the tool executes.
  2. BA PostToolUse hook that reverts the write after it happens.
  3. CA line in CLAUDE.md instructing Claude never to write to that directory.
  4. DA Stop hook that checks what was written at the end of the session.

Correct answer: A. PreToolUse fires after Claude requests a tool but before it runs, and its result can deny the call. That is the only hook point that can prevent an action rather than react to one, which is what an enforceable guardrail requires.

Why not B: PostToolUse runs after the tool has already executed. Reverting a production write is damage control, not prevention.

Why not C: Memory is guidance the model can weigh against other instructions. It is not an enforcement boundary.

Why not D: Stop fires when the session ends, long after the write landed.

Documentation for this topic →

D3-Q03Task 3.3

A nightly job must run Claude Code non-interactively over a repository and emit machine-readable output for a downstream script. What is the right shape for that invocation?

  1. ARun it in headless mode with -p and a structured output format such as --output-format stream-json.
  2. BStart the interactive TUI under a pseudo-terminal and scrape the rendered frames.
  3. CRun the interactive session and have the model write its findings into a file the script then reads.
  4. DCall the Messages API directly, since Claude Code cannot run without a terminal.

Correct answer: A. Headless mode exists for exactly this: -p takes the prompt non-interactively, and the structured output formats give the caller parseable results instead of terminal rendering.

Why not B: Scraping a TUI couples your pipeline to the rendering layer, which is presentation and free to change.

Why not C: It works, but it routes a supported output contract through an unvalidated side channel and gives the script nothing to check when the run fails.

Why not D: Claude Code runs headlessly by design; dropping to the raw API discards the agent loop, tools, and project memory you wanted.

Documentation for this topic →

D3-Q04Task 3.1

A developer's personal ~/.claude/CLAUDE.md says to prefer tabs. The repository's CLAUDE.md says the project uses spaces. What should you expect, and what is the right response?

  1. AProject memory is the more specific instruction for work in that repository, so the project convention should win — and the conflict belongs in the project file, not in a personal preference.
  2. BUser memory always wins, because it is loaded last.
  3. CThe two files are concatenated and Claude picks whichever appears first.
  4. DA conflict between memory files is an error and Claude will ask which to use.

Correct answer: A. Memory is layered from broad to specific, and a project's committed conventions are the ones that apply inside that project. A personal preference that contradicts a repository standard is the thing to change.

Why not B: Load order is not a precedence rule, and a personal file overriding a team's committed standard would be the wrong outcome anyway.

Why not C: Precedence is defined by scope, not by position in a concatenated file.

Why not D: Claude does not halt on conflicting guidance; it resolves it, which is why the layering matters.

Documentation for this topic →

D3-Q05Task 3.1

Your CLAUDE.md has grown to several hundred lines covering four subsystems. You want to keep it maintainable without losing the guidance. What does Claude Code support?

  1. AImport other Markdown files from CLAUDE.md with @path/to/file, so each subsystem's conventions live in its own file.
  2. BSplitting it into CLAUDE.md, CLAUDE2.md and so on, which are all loaded automatically.
  3. CA claude.config.json listing additional memory files to load.
  4. DNothing — memory has to be a single file, so the content must be summarized.

Correct answer: A. CLAUDE.md supports @ imports, so a large set of conventions can be split by subsystem and pulled in from one entry point. Each file stays reviewable on its own.

Why not B: Numbered siblings are not a convention Claude Code recognises, so those files would simply never load.

Why not C: Memory files are not registered through a config file; the import syntax is the mechanism.

Why not D: Summarizing to fit an imaginary limit would throw away guidance that the import syntax lets you keep.

Documentation for this topic →

D3-Q06Task 3.2

You want Claude to follow your team's database-migration procedure automatically whenever a session involves migrations — without anyone remembering to invoke it. Skill or slash command?

  1. AA skill, because Claude decides to load it based on its description matching the task at hand.
  2. BA slash command, because it can be documented in the README for people to type.
  3. CA slash command, because only commands can contain multi-step procedures.
  4. DEither — skills and slash commands are two names for the same mechanism.

Correct answer: A. The distinction is who invokes it. A skill is model-invoked: Claude reads the descriptions available to it and pulls one in when the work matches. A slash command is user-invoked. Without anyone remembering is the skill case.

Why not B: A command that must be typed reintroduces exactly the human step the requirement removes.

Why not C: Both can hold multi-step procedures; the difference is the trigger, not the content.

Why not D: They are separate mechanisms with different invocation models, and the choice between them is the point here.

Documentation for this topic →

D3-Q07Task 3.3

A long refactor keeps filling the main session's context with search output, crowding out the actual work. What is the appropriate structure?

  1. ADelegate the exploration to a sub-agent, which runs in its own context and returns only its conclusions to the main session.
  2. BRaise the main session's context limit.
  3. CRun the searches in a second terminal session and paste the results in.
  4. DAdd a PostToolUse hook that truncates every search result to ten lines.

Correct answer: A. A sub-agent has its own context window. Sending the noisy exploration there means the main session receives a short answer instead of the transcript that produced it — which is what sub-agents are for.

Why not B: The window is a model property, not a setting to raise, and a bigger one would just fill up more slowly.

Why not C: This is the same volume of output arriving by a manual route, plus the copying.

Why not D: A blanket truncation discards the middle of results the agent may have needed, without knowing what mattered.

Documentation for this topic →

D3-Q08Task 3.2

In a CI pipeline you want Claude Code to run without stopping to ask about tool permissions, while still being unable to touch anything outside the checkout. What is the right approach?

  1. AConfigure explicit allow and deny rules in settings so the permitted set is decided up front, rather than disabling permission checks.
  2. BSkip all permission prompts, since CI is a trusted environment.
  3. CPre-answer the prompts by piping y into the process.
  4. DRun interactively under a pseudo-terminal and auto-confirm each prompt.

Correct answer: A. Non-interactive does not have to mean unrestricted. Declaring the allowed and denied tools in settings removes the prompts while keeping a boundary that a reviewer can read and a compromised prompt cannot widen.

Why not B: CI is trusted conflates the pipeline with everything it processes — including pull requests from outside the team.

Why not C: Blanket confirmation approves whatever is asked, which is the same as having no boundary.

Why not D: Automating the click is the same permissive outcome, reached through a more fragile mechanism.

Documentation for this topic →

D3-Q09Task 3.3

You want Claude to review pull requests when a team member mentions it in a PR comment. What is the supported route?

  1. AInstall the Claude Code GitHub Actions workflow, which responds to @claude mentions on issues and pull requests.
  2. BPoll the GitHub API from a cron job and run the CLI when a new comment appears.
  3. CAdd a git hook that runs Claude Code on push.
  4. DConfigure a PostToolUse hook that posts review comments back to GitHub.

Correct answer: A. The GitHub Actions integration exists for this: it wires mention-triggered runs into the repository's workflows, with the checkout, credentials, and comment-posting already handled.

Why not B: A polling service duplicates what the action already does, and adds latency plus somewhere to host it.

Why not C: A git hook fires on push from a developer's machine, so it cannot see a comment on a pull request.

Why not D: Hooks act inside a Claude Code session; they are not a trigger for starting one from a GitHub event.

Documentation for this topic →

D3-Q10Task 3.1

A change touches twelve files across three subsystems and the team wants to agree the approach before any code is written. Which Claude Code affordance fits?

  1. APlan mode, which explores and proposes an approach for approval before making edits.
  2. BA sub-agent, which will produce the plan in isolation.
  3. CA PreToolUse hook that blocks every edit until a human approves it.
  4. DHeadless mode, which does not write files.

Correct answer: A. Plan mode is the built-in look before you touch workflow: research and a proposed approach first, edits only once it is approved. That is precisely the review gate the team wants.

Why not B: A sub-agent isolates context. It is not a gate on whether edits happen.

Why not C: This gets an approval per file rather than one on the overall approach, which is the wrong granularity and exhausting.

Why not D: Headless mode changes how the session is driven, not whether it edits files — it certainly does.

Documentation for this topic →

D3-Q11Task 3.2

Your team wants one MCP server available to everyone working in a repository, checked in alongside the code. Where does that configuration belong?

  1. AIn the project's .mcp.json, committed to the repository so every contributor picks it up.
  2. BIn each developer's user-level configuration, documented in the README.
  3. CIn CLAUDE.md, as instructions telling Claude to connect to the server.
  4. DIn an environment variable exported by the project's setup script.

Correct answer: A. Project-scoped MCP servers live in a committed .mcp.json. The configuration travels with the repository, so it is reviewed like any other file and nobody has to set it up by hand.

Why not B: Per-developer setup drifts immediately and silently — the usual outcome is that half the team is missing the server.

Why not C: Memory is guidance to the model. It is not where a client's server connections are configured.

Why not D: An environment variable is not how MCP servers are registered, and it would not survive a fresh shell.

Documentation for this topic →

D3-Q12Task 3.2

A PreToolUse hook needs to reject a tool call and tell Claude why, so it can choose a different approach. How does the hook communicate that?

  1. AExit with the blocking status code and write the reason to stderr, which is fed back to Claude as the explanation.
  2. BExit 0 and print the reason to stdout.
  3. CExit 1, which Claude Code treats as a hard failure and reports to the user.
  4. DWrite the reason into CLAUDE.md so it is loaded on the next turn.

Correct answer: A. The hook contract distinguishes a non-blocking error from a deliberate block: the blocking exit code stops the call, and stderr carries the reason back to Claude so the next attempt can be better informed.

Why not B: Exit 0 means the hook approved the call, so the tool would run regardless of what was printed.

Why not C: A generic failure exit surfaces to the user rather than steering the model, so Claude learns nothing and retries the same thing.

Why not D: Memory is loaded at session start, so a mid-session write does not communicate anything about this call.

Documentation for this topic →

Domain 4 · Prompt Engineering & Structured Output

20% of the exam · 12 questions

D4-Q01Task 4.2

You enable extended thinking on an agent that also uses tools. Between turns, what must you do with the thinking blocks the API returns?

  1. APass them back unmodified in the conversation history alongside the tool_use blocks from the same turn.
  2. BStrip them before the next request, since they are debug output and waste input tokens.
  3. CSummarize them into a short note and send the summary instead.
  4. DStore them out of band and re-send them only if the tool call fails.

Correct answer: A. When extended thinking is combined with tool use, the thinking blocks from a turn must be returned verbatim with that turn's tool results. They carry the reasoning the tool call was based on, and the API validates that they arrive intact.

Why not B: Dropping them breaks the continuity between the reasoning and the tool call it produced, and the request is rejected rather than silently degraded.

Why not C: Rewriting a thinking block changes it. The requirement is that it comes back unmodified.

Why not D: Conditional re-sending leaves the successful path missing the blocks it was required to include.

Documentation for this topic →

D4-Q02Task 4.3

A long system prompt containing a large policy document is sent on every request in a high-volume support deployment, and cost is the main concern. What is the appropriate change?

  1. AMark the stable prefix with a cache_control breakpoint so it is served from the prompt cache on subsequent requests.
  2. BTrim the policy document to the sections most requests need and accept the coverage gap.
  3. CMove the policy document from the system prompt into the first user message.
  4. DSwitch to a smaller model for every request.

Correct answer: A. Prompt caching is designed for a large, stable prefix reused across requests. Marking it with cache_control means later requests read it from the cache at a fraction of the input cost, with no change to what the model sees.

Why not B: Truncating the policy trades correctness for cost. The cache removes the cost without removing the content.

Why not C: Position alone does not reduce cost — the tokens are billed either way — and it weakens the standing-instruction role of the system prompt.

Why not D: Downgrading the model changes answer quality across the whole deployment to solve a problem caching solves without any quality cost.

Documentation for this topic →

D4-Q03Task 4.1

A code-review prompt handles single-file diffs at 94% accuracy but drops to 58% on multi-file changes, where reviewers say it never inspects the relationship between files. Which change targets that gap?

  1. AAdd few-shot examples that demonstrate decomposing a multi-file diff and reasoning across the files before concluding.
  2. BIncrease max_tokens so the review has room to cover every file.
  3. CSend one request per file and concatenate the reviews.
  4. DAdd a sentence to the system prompt telling the model to be thorough.

Correct answer: A. The model performs the single-file task well, so the capability is there; what is missing is a demonstration of the decomposition pattern for the harder shape. Few-shot examples are the standard way to show a reasoning procedure the model has not inferred.

Why not B: The reviews are not being cut off, they are shallow. Extra output budget lengthens them without changing the approach.

Why not C: Per-file requests structurally prevent cross-file reasoning, which is the exact thing the reviews are missing.

Why not D: A generic exhortation gives the model nothing procedural to follow, which is why it is the weakest of these on a task with a specific shape.

Documentation for this topic →

D4-Q04Task 4.1

A prompt supplies a 40-page contract and then asks three questions about it. Where should the document go relative to the questions?

  1. AThe document first, then the questions, with the document delimited so its boundaries are unambiguous.
  2. BThe questions first, so the model knows what to look for while reading.
  3. CInterleaved — each question immediately after the section it concerns.
  4. DThe document in the system prompt and the questions in the user turn, in either order.

Correct answer: A. Long inputs belong ahead of the instructions that operate on them, and clear delimiters keep the model from confusing document text with instructions. It also puts the large, stable block in the position a cache breakpoint can cover.

Why not B: Leading with the questions buries them 40 pages back by the time the model reaches the end of the input.

Why not C: Interleaving requires you to have already decided which section answers each question, which is the work being delegated.

Why not D: Order is the thing being asked about, and either order discards the guidance that makes long-document prompts work.

Documentation for this topic →

D4-Q05Task 4.2

You enable extended thinking and set max_tokens to 4096 with budget_tokens of 8192. What happens?

  1. AThe request is invalid — the thinking budget must be smaller than max_tokens, since thinking tokens are drawn from the same output budget.
  2. BIt works; the thinking budget is counted separately from max_tokens.
  3. CIt works, but the thinking is silently truncated to 4096 tokens.
  4. DIt works and max_tokens is automatically raised to accommodate the budget.

Correct answer: A. Thinking tokens come out of the response's output budget, so budget_tokens has to be less than max_tokens (and at least the documented minimum). Inverting them is a configuration error, not a runtime adjustment.

Why not B: Treating thinking as free output would make max_tokens meaningless as a cost and length control.

Why not C: Silently reinterpreting a contradictory configuration would hide the mistake rather than surface it.

Why not D: The API does not raise a limit you set; that would override an explicit cost control.

Documentation for this topic →

D4-Q06Task 4.3

Without extended thinking, you want the response to begin with a JSON object and nothing else — no preamble. Which technique is the most direct?

  1. APrefill the assistant turn with the opening brace, so the response continues from there.
  2. BEnd the user message with Respond with JSON only. Do not add commentary.
  3. CSet a stop sequence on the opening brace.
  4. DPost-process the response to find the first brace and parse from there.

Correct answer: A. Prefilling puts the first tokens of the assistant turn in your hands, so the model continues the object rather than deciding how to open its reply. It removes the preamble structurally instead of asking for it to be omitted.

Why not B: An instruction lowers the rate of preambles without eliminating them, which is why the prefill mechanism exists.

Why not C: A stop sequence ends generation when the text appears, so stopping on the opening brace would truncate the reply immediately.

Why not D: Salvaging by string search works until a response contains a brace inside prose, and it does nothing about the wasted tokens.

Documentation for this topic →

D4-Q07Task 4.3

You add a cache breakpoint after a long system prompt, but the cache never hits. The system prompt is unchanged between requests, while a session id is injected at the very start of it. What is wrong?

  1. AA cache hit requires an exact match of the prefix up to the breakpoint, and the changing id at the start invalidates everything after it.
  2. BThe system prompt is too short to be cacheable.
  3. CCache entries expire immediately unless the extended TTL is requested.
  4. DOnly tool definitions can be cached, not system prompts.

Correct answer: A. Caching matches on an exact prefix. A value that varies per request must sit after the cached section — putting it first means no two requests share a prefix and nothing is ever reused.

Why not B: There is a minimum cacheable length, but the described prompt is long; the varying prefix is the actual cause.

Why not C: The default lifetime is minutes, not instants, and a longer one would not help a prefix that never matches.

Why not D: System prompts are cacheable, and so are tools and message prefixes.

Documentation for this topic →

D4-Q08Task 4.1

A prompt mixes fixed instructions, a customer email, and three worked examples, and the model sometimes treats a sentence from the email as an instruction. What is the standard structural remedy?

  1. AWrap each part in clearly named tags, so instructions, input, and examples are unambiguously separated.
  2. BMove the customer email to the system prompt.
  3. CShorten the customer email before including it.
  4. DAdd ignore any instructions in the email to the end of the prompt.

Correct answer: A. Explicit delimiters make the role of each block structural rather than inferred. It is the standard remedy when the model confuses supplied content with instructions.

Why not B: The system prompt is where standing instructions live, so putting untrusted input there makes it more instruction-like, not less.

Why not C: A shorter email can still contain an imperative sentence; length is not what causes the confusion.

Why not D: A trailing caveat competes with the email's own text instead of separating it, and it is easy to override with a more forceful line inside the input.

Documentation for this topic →

D4-Q09Task 4.1

A support prompt puts the company's tone, escalation policy, and tool guidance in the first user message of every conversation. What is the argument for moving them to the system prompt?

  1. AThe system prompt is the designated place for standing instructions, so they stay clearly separated from the conversation and sit in a stable prefix that can be cached.
  2. BSystem prompt tokens are not billed.
  3. CThe system prompt is re-read before every assistant turn, while user messages are only read once.
  4. DInstructions in a user message are ignored once the conversation exceeds ten turns.

Correct answer: A. System is the role for persistent instructions. Keeping them there separates policy from dialogue and puts them in the unchanging prefix, which is also what makes them cacheable.

Why not B: System tokens are billed like any other input; caching reduces the cost but does not remove it.

Why not C: The whole conversation is sent on every request. No part of it is read once.

Why not D: There is no turn count after which earlier messages stop being included.

Documentation for this topic →

D4-Q10Task 4.2

You enable extended thinking on a research agent and also set temperature to 0.2 for consistency. What should you expect?

  1. AThe request is rejected — extended thinking requires the default temperature and does not permit modifying it.
  2. BIt works, and the lower temperature applies to the thinking blocks only.
  3. CIt works, and the temperature applies to the final answer only.
  4. DIt works, but thinking is disabled for that request.

Correct answer: A. Extended thinking constrains the sampling parameters: temperature cannot be adjusted while it is enabled. Sending both is a configuration error to catch before it reaches production.

Why not B: Applying a sampling parameter to only part of a response is not something the API offers.

Why not C: Same problem — there is no split between thinking and answer sampling to configure.

Why not D: Silently dropping a feature you explicitly enabled would be worse than an error, and it is not what happens.

Documentation for this topic →

D4-Q11Task 4.1

Two worked examples in a classification prompt both happen to use the same category. Accuracy on that category is high and poor elsewhere. What is the lesson?

  1. AFew-shot examples must span the range of cases, because unrepresented categories are effectively undemonstrated.
  2. BTwo examples is always too few; the minimum is five.
  3. CExamples should be removed once accuracy on any category exceeds a threshold.
  4. DThe examples should be moved to the system prompt to apply more evenly.

Correct answer: A. Examples teach by demonstration, so they skew toward whatever they demonstrate. Coverage across the label space matters more than the raw count.

Why not B: There is no universal minimum. Two well-chosen, well-spread examples can outperform five clustered ones.

Why not C: Removing examples that are working would give up the gain rather than extend it.

Why not D: Relocating an unrepresentative set does not make it representative.

Documentation for this topic →

D4-Q12Task 4.3

An extraction task must return null for fields genuinely absent from a document, but the model invents plausible values instead. What most directly addresses that?

  1. AMake the schema admit null for those fields and state in the instructions that absence must be reported rather than inferred, with an example of a document missing a field.
  2. BLower the temperature to zero.
  3. CAsk the model to double-check its answer before responding.
  4. DReject responses containing values not found verbatim in the document.

Correct answer: A. If the schema has no way to say not present, the model has no compliant way to report absence. Allowing null, asking for it explicitly, and demonstrating it gives the correct behaviour somewhere to go.

Why not B: Temperature 0 makes the invented value consistent rather than absent.

Why not C: A self-check reviews the same output against the same schema, which still offers no way to express absence.

Why not D: Verbatim matching breaks every legitimately normalized field — dates, numbers, names — and still does not tell the model what to emit instead.

Documentation for this topic →

Domain 5 · Context Management & Reliability

15% of the exam · 9 questions

D5-Q01Task 5.3

You must classify 200,000 archived documents. There is no user waiting on the results, and the job should finish within a day at the lowest cost. Which approach fits?

  1. ASubmit the work through the Message Batches API and poll for results.
  2. BFan out synchronous Messages API calls across many workers to finish faster.
  3. CStream each request so partial results arrive sooner.
  4. DConcatenate documents into very large prompts to reduce the number of requests.

Correct answer: A. The Batches API is built for large asynchronous workloads: you submit many requests at once, results return within the batch window, and the tokens are billed at a discount. A job with no latency requirement is the case it exists for.

Why not B: Parallel synchronous calls buy latency you do not need, at full price, and push you into rate limiting.

Why not C: Streaming improves time-to-first-token for a human reader. Nothing is reading these in real time.

Why not D: Batching documents into one prompt degrades per-document accuracy and makes one failure spoil the whole group.

Documentation for this topic →

D5-Q02Task 5.2

A long-running assistant session approaches the context window limit mid-conversation. Which strategy preserves the most useful behaviour?

  1. ASummarize the older turns into a compact record of decisions and open threads, and keep the recent turns verbatim.
  2. BDrop the oldest messages one at a time until the request fits.
  3. CDrop the system prompt, which is typically the largest stable block.
  4. DStart a fresh session and ask the user to restate what they need.

Correct answer: A. Compaction trades fidelity for capacity where fidelity matters least. Decisions and unresolved threads are what later turns depend on; the exact wording of an early exchange usually is not. Recent turns stay verbatim because they are what the next response builds on.

Why not B: Naive truncation discards whatever happens to be oldest, including commitments and constraints the conversation still relies on.

Why not C: The system prompt carries the standing instructions and tool guidance. Removing it changes the agent's behaviour entirely.

Why not D: Restarting pushes the cost of the limit onto the user and loses everything the session established.

Documentation for this topic →

D5-Q03Task 5.1

Your service starts receiving HTTP 429 responses under load. What is the correct client behaviour?

  1. ABack off — honour the retry-after header when present, otherwise retry with exponential backoff and jitter, and cap the number of attempts.
  2. BRetry immediately, since the request itself was valid.
  3. CFail the request and surface the error, since 429 is not retryable.
  4. DRetry on a fixed one-second interval until it succeeds.

Correct answer: A. 429 means slow down, and the response says for how long when it can. Respecting retry-after, otherwise backing off exponentially with jitter and a bounded attempt count, recovers without amplifying the overload.

Why not B: Immediate retries add load to a service already telling you there is too much, and every client doing it converges on a stampede.

Why not C: 429 is the canonical retryable status; treating it as fatal fails requests that would have succeeded a moment later.

Why not D: A fixed interval synchronises every client onto the same schedule, which is what jitter exists to prevent.

Documentation for this topic →

D5-Q04Task 5.2

Which of these consumes the context window on a request?

  1. AThe system prompt, the tool definitions, the full message history, and the tokens generated in the response.
  2. BThe message history only; system prompts and tools are metadata.
  3. CThe current user message and the response, since earlier turns are stored server-side.
  4. DEverything sent as input, but not the generated output.

Correct answer: A. The window covers the whole request plus what is generated into it. Tool definitions in particular are easy to forget and can be substantial when a dozen servers are connected.

Why not B: Tool schemas are sent with every request and counted like any other input; a large tool list is a real budget item.

Why not C: The API is stateless — the entire conversation is resent on every call, which is why long sessions need managing.

Why not D: Generated tokens occupy the same window, which is why a long response can hit the limit even with modest input.

Documentation for this topic →

D5-Q05Task 5.3

Before dispatching a large request you want to know whether it fits the context window, without paying for a generation. What is available?

  1. AThe token counting endpoint, which returns the input token count for a request without running it.
  2. BDividing the character count by four for an estimate.
  3. CSending the request with max_tokens of 1 and reading the usage figures.
  4. DNothing — the count is only known after a response comes back.

Correct answer: A. There is a dedicated endpoint for counting the tokens of a prospective request. It gives an exact figure for the same payload you are about to send, with no generation.

Why not B: A characters-per-token heuristic is a rough guide; near a hard limit, rough is what fails in production.

Why not C: This does run the request and bill the input, which is the cost you were trying to avoid, and it fails outright if the input already exceeds the window.

Why not D: Giving up on a question the API answers directly is the wrong conclusion.

Documentation for this topic →

D5-Q06Task 5.3

A nightly batch of 40,000 classifications currently runs as synchronous requests and keeps hitting rate limits. Cost matters; latency does not. What changes?

  1. AMove it to the Batches API, which is built for this shape of workload and bills the tokens at a discount.
  2. BAdd exponential backoff and let it run longer.
  3. CRequest a rate limit increase and keep the synchronous design.
  4. DReduce the prompt size so more requests fit under the limit.

Correct answer: A. This is the batch case exactly: a large volume, no one waiting, and cost as the constraint. Submitting it as a batch removes the rate-limit fight and halves the token cost.

Why not B: Backoff stops the errors but leaves the job at full price, still fighting a limit it did not need to be near.

Why not C: A higher limit treats the symptom, keeps the synchronous premium, and depends on someone approving it.

Why not D: Trimming prompts reduces quality to work around a mismatch between the workload and the API being used for it.

Documentation for this topic →

D5-Q07Task 5.1

A request that generates a very long response intermittently fails with a client-side timeout. What is the appropriate fix?

  1. AStream the response, so tokens arrive incrementally and the connection stays active throughout the generation.
  2. BRetry on timeout, since the failure is intermittent.
  3. CRaise max_tokens so the response completes sooner.
  4. DSplit the request into several smaller ones and concatenate the results.

Correct answer: A. A long generation is exactly what streaming is for: the client receives tokens as they are produced, so there is no long silent wait for a single response to be assembled.

Why not B: Retrying pays for the whole generation again and hits the same wall, only later.

Why not C: A higher output ceiling permits a longer response, which makes the wait longer rather than shorter.

Why not D: Splitting a single coherent response across requests loses continuity and adds stitching logic to solve a transport problem.

Documentation for this topic →

D5-Q08Task 5.2

A report generator must let readers check every claim against the source documents it was given. Which capability is designed for that?

  1. ACitations, which ground statements in the supplied documents and return the referenced passages.
  2. BExtended thinking, so the reasoning that produced each claim is visible.
  3. CA lower temperature, which reduces unsupported statements.
  4. DA system prompt instruction to quote the source after every sentence.

Correct answer: A. Citations exist for exactly this: claims come back linked to the passages in the provided documents that support them, so verification is mechanical rather than a matter of trust.

Why not B: Thinking shows how the model reasoned, which is not the same as showing where a fact came from.

Why not C: Temperature affects sampling, not grounding. A confident unsupported claim is still unsupported.

Why not D: Asking for quotes yields quotes the model produces, which can be paraphrased or invented — the failure mode citations remove.

Documentation for this topic →

D5-Q09Task 5.2

A support deployment reuses a large cached system prompt, but traffic is bursty — sometimes twenty requests a minute, sometimes one every twenty minutes. Cache hit rates are poor during quiet periods. What is the appropriate response?

  1. AConsider the longer cache lifetime for the stable prefix, weighing its higher write cost against the reads it saves during quiet spells.
  2. BSend periodic dummy requests to keep the cache warm.
  3. CRemove the cache breakpoint, since caching does not suit bursty traffic.
  4. DSplit the system prompt into smaller pieces so each is cheaper to re-cache.

Correct answer: A. The default lifetime is short by design, and there is a longer option for exactly this pattern. It costs more to write and less to miss, so the decision is an arithmetic one against your actual traffic.

Why not B: Synthetic traffic buys cache warmth with real spend on requests nobody asked for, and it has to run forever.

Why not C: Giving up abandons the hits you do get during bursts, which are the majority of the volume.

Why not D: Smaller segments do not survive any longer; they just miss in smaller pieces.

Documentation for this topic →

Ready to sit it under time? The mock exam shuffles questions and options, runs a 120-minute clock, and scores you by domain.

Take the mock exam →

Original practice questions written by IntelliForge from the public exam blueprint and Claude documentation. These are not real exam questions, and this material is not affiliated with, sponsored by, or endorsed by Anthropic.