30 free CCDV-F sample questions

1. Q1 · Applications and Integration · 33.1%

   A support chat ships with a bug: after three or four exchanges Claude answers as though the earlier turns never happened. The handler builds each request from the newest user message plus a conversation id it stores in Postgres, and the replies themselves come back clean. Where does the fix belong?

   • AEnable server-side compaction so earlier turns are carried into the request automatically.
   • BKeep a running transcript in the system prompt and rewrite it after each exchange.
   • CSend the whole message list — every prior user and assistant turn — with each request.correct
   • DRaise `max_tokens` so replies are not cut off before they can reference earlier turns.

   The endpoint holds no state between calls, so a conversation exists only as the message array the client assembles. The id in Postgres identifies the thread for the application, not for the API, and nothing on the server can look it up.

2. Q2 · Applications and Integration · 33.1%

   A chat UI renders tokens as they stream. QA reports that about one saved transcript in ten is missing the assistant's answer even though the on-screen text was right. The handler writes to the database when the stream ends, using text it collected from delta events at index 0.

   • APersist on the content-block stop event rather than waiting for the message to finish, which is the earliest point a block is whole.
   • BTurn streaming off for the persistence path and issue a second non-streaming call.
   • CRead the answer from the message-delta event, which carries the assembled content.
   • DAccumulate deltas per block index and join the text blocks, or take the stream's final message.correct

   A response is a list of content blocks, and index 0 is not guaranteed to be the answer — a thinking block often sits ahead of it. Keying the buffer on the block index and joining the text blocks, or letting the SDK assemble the final message, survives whatever mix of blocks arrives.

3. Q3 · Applications and Integration · 33.1%

   An engineer has added a cache breakpoint to a high-volume endpoint and is asked to prove it works before the change ships. They have a staging key and can send whatever traffic they like against it. Which two observations demonstrate the prefix is being cached and read back? Select TWO.

   Select 2 answers

   • AThe first response reports a non-zero cache-creation token count.correct
   • BA second identical call returns measurably faster than the first.
   • CThe second response reports a non-zero cache-read token count.correct
   • DThe request carries no more than the four breakpoints a request permits.

   The usage block reports the two halves of the transaction directly: tokens written on the first call and tokens served from the entry on the second. Seeing both is the evidence that an entry was created and then actually reused.

4. Q4 · Applications and Integration · 33.1%

   A service's only integration test calls the live Claude API. It is slow and intermittently fails on rate limits, so it has been marked skipped in CI for months. The team wants the pull-request pipeline to catch integration mistakes again without making a live call. Select TWO.

   Select 2 answers

   • AIncrease the test's timeout and retry count so it passes reliably enough to unskip.
   • BAssert the built request payload against a recorded fixture on every pull request.correct
   • CMark the live test as expected-to-fail so it runs on every pull request without blocking.
   • DRun the live test on a schedule against a staging key and alert when it fails.correct

   Splitting the concern gives each half a job it can do well: a fixture check verifies the request the code constructs, deterministically and in seconds, while a scheduled live run keeps confirming the real endpoint still accepts it. Neither blocks a pull request on a rate limit.

5. Q5 · Model Selection and Optimization · 16.8%

   A billing dashboard for an internal Claude service estimates each request's input cost by running the prompt through `tiktoken` before the call. Finance reports the estimate consistently undershoots the invoice, and the gap is widest on requests carrying large code diffs. What should the team change?

   • AMultiply the current figure by a fixed correction factor taken from last month's invoices.
   • BCall `messages.count_tokens` with the same model and messages, and price from `input_tokens`.correct
   • CRead `usage.input_tokens` off the response afterwards and treat it as the full prompt size.
   • DReplace the estimate with a characters-divided-by-four heuristic over the rendered prompt.

   Token counts are model-specific, and the endpoint that produces them uses the same tokenizer the request will. A tokenizer built for another vendor's models miscounts Claude tokens systematically, and the error widens on code and non-English text where the vocabularies diverge most. Measuring against the model id the call will actually use removes the guesswork rather than papering over it.

6. Q6 · Model Selection and Optimization · 16.8%

   A regression harness pins Claude Opus 5 and asserts byte-identical output across runs of the same classification prompt. A developer's first fix for the flakes is to add `temperature=0`; that request comes back 400. The suite still has to be stable enough to gate a release. What is the workable move?

   • ASet `top_k` to 1 instead, so the highest-probability token is taken at each step.
   • BAdd `thinking: {"type": "disabled"}` so no reasoning tokens vary between runs.
   • CPin `output_config.effort` to `low` so the model returns the same short answer each time.
   • DAssert on a field constrained by `output_config.format` rather than on the raw string.correct

   The sampling parameters are gone on this model, and even where they existed they never guaranteed identical bytes. A gate wants the decision to be stable, not the prose around it: constraining the response to a schema and asserting on the parsed field tests what the release actually depends on and stops surface wording from failing the build.

7. Q7 · Model Selection and Optimization · 16.8%

   A shared request builder written for Claude Sonnet 4.5 is repointed at Claude Opus 5 with no other change. The first call returns 400 and the error names more than one field. Which TWO of the builder's current settings have to go? Select TWO.

   Select 2 answers

   • AThe `temperature` value it sets on every request.correct
   • BThe `max_tokens` ceiling it applies before streaming.
   • CThe fixed `budget_tokens` figure inside its `thinking` block.correct
   • DThe `anthropic-version` header it pins to `2023-06-01`.
   • EThe `stop_sequences` array it uses to close JSON output.

   Two families of parameter were withdrawn on this generation: the sampling controls, and the fixed thinking budget. Both are rejected outright rather than ignored, which is why a single migration produces an error naming more than one field. Behaviour that used to be steered by them moves to prompting and to the effort level respectively.

8. Q8 · Model Selection and Optimization · 16.8%

   A team is adding document upload to a service that already runs against Amazon Bedrock for one customer and the first-party API for the rest. They plan to upload once and reference the file id on every later call. Which TWO facts should shape the design? Select TWO.

   Select 2 answers

   • AUploaded files expire after 29 days and have to be re-sent.
   • BThe upload path is not available on the Bedrock deployment.correct
   • CReferencing a file id requires citations to be enabled on the block.
   • DThe beta flag is needed on the upload and on every call that references it.correct
   • EEach reference re-uploads the file, so the id saves storage rather than tokens.

   Two constraints shape this design. The upload surface is not offered on that partner platform, so the Bedrock customer needs an inline-document path regardless of what the rest of the fleet does. And the file-source block lives behind a beta flag that has to ride on both the upload and every referencing request, which is easy to get half right.

9. Q9 · Agents and Workflows · 14.7%

   A finance team wants incoming supplier emails sorted into six queues so the right group picks them up. The six categories are fixed, the judgement is 'read the email, pick one label', and volume runs about 8,000 a day. An engineer proposes building an agent with a tool loop so it can look things up when a message is ambiguous. What shape fits this?

   • AA tool-use loop with a lookup tool, so ambiguous emails can be resolved before labelling.
   • BAn orchestrator that spawns a worker per email and collects the labels it returns.
   • COne Messages API call per email, with the categories in the prompt and a constrained output.correct
   • DA prompt chain that summarises the email first, then labels the summary.

   Classification against a fixed label set is a single step that can be fully specified in advance, which puts it at the cheapest tier — one call in, one answer out. Every tier above that buys adaptivity the task does not use, and at 8,000 a day the added latency and cost land on every message.

10. Q10 · Agents and Workflows · 14.7%

    A marketing team generates localised product blurbs. Every run does the same three things in the same order: draft the English copy, check it against a brand-tone checklist, then translate into four languages. Quality matters more than turnaround, and the team wants a place to stop a bad draft before translation multiplies it. Which shape fits?

    • AOne call that returns drafted, checked and translated copy together.
    • BAn orchestrator that fans the four languages out to workers and merges what comes back.
    • CAn agent with a tone-checking tool and a translation tool, looping until it is satisfied.
    • DA prompt chain — one call per step, with a programmatic check between draft and translation.correct

    The steps are fixed, ordered and each feeds the next, which is the prompt-chaining signature. Splitting them also creates the seam the team asked for: the gap between two calls is where ordinary code can inspect the draft and refuse to go on, something a single generation gives you nowhere to put.

11. Q11 · Agents and Workflows · 14.7%

    A documentation agent must audit 60 pages against a style guide and produce one consolidated report. Run inline it exhausts its context around page 20, so the team is moving to a coordinator with workers. Which TWO decisions belong in that redesign? Select TWO.

    Select 2 answers

    • APut the page paths and the style guide's location into each worker's brief.correct
    • BHand every worker the coordinator's conversation so far, so it has the background.
    • CKeep the writing of the consolidated report on the coordinator, not a worker.correct
    • DHave each worker append its findings to the coordinator's system prompt.
    • ERaise the coordinator's `max_tokens` so all 60 audits fit in one response.

    Workers share the container's filesystem but not the coordinator's conversation, so each brief has to stand on its own — paths, guide location, expected report shape. Synthesis is the one part that genuinely needs to see everything, so it stays with the coordinator; that is what keeps each worker's window small enough to matter.

12. Q12 · Agents and Workflows · 14.7%

    A team is hardening an Agent SDK harness that runs unattended in CI against a checkout of the repository. They want a record of every shell command the agent runs, and they want a specific set of destructive commands refused outright. Which TWO belong in the harness? Select TWO.

    Select 2 answers

    • AA `PreToolUse` hook matching the shell tool, returning a deny decision for the listed commands.correct
    • BA `PostToolUse` hook on the shell tool that appends each command and its result to an audit log.correct
    • CA `systemPrompt` section listing the destructive commands and instructing the agent to avoid them.
    • D`permissionMode` set to `bypassPermissions`, so the unattended run never stalls on a prompt.
    • EA `Stop` hook that reads the finished transcript and refuses to accept runs containing those commands.

    The two requirements sit on opposite sides of execution, so they need different events. Refusal has to happen while the call is still a request, which is `PreToolUse` returning a deny decision; the audit record needs the outcome as well as the command, which only exists once the tool has run, so it belongs in `PostToolUse`.

13. Q13 · Prompt and Context Engineering · 11.0%

    A code-audit agent passes whole file bodies as arguments to a `lint_snippet` tool, sometimes 30 KB at a time. The team turns on context editing with the `clear_tool_uses_20250919` strategy, confirms from the response that edits are being applied, and finds window pressure barely moves. What should they set?

    • A`clear_thinking_20251015` as a second edit alongside the one already configured.
    • B`disable_parallel_tool_use` on `tool_choice`, so fewer calls pile up per turn.
    • C`clear_tool_inputs` to true on the same edit, so arguments go with the results.correct
    • D`compact_20260112`, so the cleared spans come back as a running summary.

    The clearing strategy removes tool results by default and leaves the `tool_use` parameters in place. When the bulk is in what the model sent rather than what came back, the extra flag on the same edit is what reaches it.

14. Q14 · Prompt and Context Engineering · 11.0%

    An agent runs with adaptive thinking on a long triage conversation. Tool results are already cleared as they age, and no single tool payload is large. Input token counts still climb turn over turn, and the growth tracks how much reasoning each turn needed rather than how many tools it called. Which change targets it?

    • A`clear_thinking_20251015`, which removes accumulated thinking blocks.correct
    • B`clear_tool_uses_20250919` with `clear_tool_inputs` set to true.
    • C`compact_20260112`, which replaces earlier turns with a summary.
    • DSetting `output_config.effort` to `low` so less reasoning is produced per turn.

    Thinking blocks are replayed with the rest of the conversation, so a reasoning-heavy agent accumulates them the same way a tool-heavy one accumulates results. There is a clearing strategy aimed specifically at them, and the symptom points straight at it.

15. Q15 · Prompt and Context Engineering · 11.0%

    A monitoring agent runs unattended from 20:00 to 06:00. By 03:00 it has stopped applying the escalation rules it worked out in the first hour, and its later reports contradict decisions it recorded earlier in the same run. The team has room for two changes before the next shift. Select TWO.

    Select 2 answers

    • ARaise `max_tokens` so each response has room to restate the current rules.
    • BEnable compaction so earlier turns are summarised as the window fills.correct
    • CAdd a `cache_control` breakpoint to the last block of every turn.
    • DHave the agent write confirmed findings to its memory directory as it goes.correct
    • ERaise `output_config.effort` to `max` for the overnight window.

    Two different things are leaving: the early turns are falling out of the window, and nothing durable is holding what they contained. Compaction keeps those turns present in summary form as the conversation grows, and the memory directory gives findings a home that outlives the window entirely. Together they cover both the in-run and the beyond-the-run half of the problem.

16. Q16 · Prompt and Context Engineering · 11.0%

    A prompt written for a much older model is being moved onto Claude Opus 5. It opens with "CRITICAL: You MUST call the search tool whenever the user asks anything", and a later section instructs the model to reason inside `<scratchpad>` tags before answering. Adaptive thinking is on. Which TWO edits does the migration call for? Select TWO.

    Select 2 answers

    • ARewrite the search instruction as a plain conditional naming when the tool applies.correct
    • BAdd a second capitalised line telling the model not to skip the search tool.
    • CDelete the scratchpad instruction and control depth with `output_config.effort`.correct
    • DSet `temperature` to 0 so the remaining instructions are followed consistently.
    • EMove both sections into the first user message so they are read most recently.

    Both lines were written to overcome an older model's reluctance, and both now over-apply. Current models follow the system prompt closely, so the shouted tool rule produces searches on questions the model could answer directly, and the scratchpad instruction duplicates reasoning the model already does natively and now exposes it in the visible response.

17. Q17 · Tools and MCPs · 10.6%

    An order-tracking agent asks for three shipment lookups in a single assistant turn. The dispatch loop runs them concurrently, then posts each `tool_result` back as its own user message. Two weeks later, traces show Claude issuing one lookup per turn instead of three, and end-to-end latency has roughly tripled. What should the loop do differently?

    • APost the three `tool_result` blocks together in one user message before the next request.correct
    • BSet `disable_parallel_tool_use: true` on `tool_choice` so the sequential pattern is deliberate.
    • CForce `tool_choice` to `{"type": "any"}` so Claude keeps reaching for the lookup tool.
    • DAdd `cache_control` to the final tool result so the batch is served from cache next turn.

    The three results answer one assistant turn, so they belong in one user turn. Splitting them across separate user messages teaches the model that its parallel batch is not answered as a batch, and over time it converges on a single call per turn. Restoring the batch shape restores the concurrency the loop was built around.

18. Q18 · Tools and MCPs · 10.6%

    A booking agent calls `hold_seat`, which times out against the reservation system. The harness logs the exception and leaves that tool out of the follow-up user message, sending back the other two results it did get. The next API call fails with a 400 before the model sees anything. What should the harness send instead?

    • AThe two successful results plus a text block describing the timeout to Claude.
    • BA `tool_result` carrying the same `tool_use_id`, `is_error: true`, and the timeout detail.correct
    • CA rewound conversation with the assistant turn holding the tool calls removed.
    • DA retry of `hold_seat` in a tight loop, so the turn stays clean once one attempt lands.

    Each `tool_use` block in an assistant turn needs a matching `tool_result` in the user turn that follows; leaving one out makes the turn structurally incomplete, which is what the 400 reports. Returning the failure as a result with `is_error: true` satisfies that pairing and hands Claude the information it needs to retry, route around the system, or tell the caller.

19. Q19 · Tools and MCPs · 10.6%

    A monitoring agent's `query_metrics` tool returns roughly 40,000 characters of raw series data per call, and the conversation runs out of room after four calls even though the model uses two or three fields from each response. The team wants the tool kept. Which TWO changes address the cause? Select TWO.

    Select 2 answers

    • AReturn a filtered, high-signal subset from the handler, with a pointer to the full payload.correct
    • BSet `disable_parallel_tool_use: true` so one large payload arrives at a time.
    • CHave Claude compose the calls in code execution so a script filters results before they return.correct
    • DRaise `max_tokens` so responses have more room after the results land.
    • EAdd `cache_control` to the tool result blocks so repeated payloads are cheaper.

    The context is being consumed by data nobody reads, so both fixes work on the same lever: stop the bulk from entering the conversation. Trimming in the handler is the direct version; programmatic tool calling is the version that keeps the tool general, because the script processes the full response in the execution container and returns only its conclusion.

20. Q20 · Tools and MCPs · 10.6%

    A stdio MCP server that has served one engineer well is being reworked so a distributed team can reach it as a hosted service. Which TWO changes does the Streamable HTTP transport require of the server? Select TWO.

    Select 2 answers

    • AMark the rarely used tool definitions for deferred loading so remote clients load fewer schemas.
    • BServe a single MCP endpoint path that accepts both POST and GET.correct
    • CAssign a session identifier at initialization and require it on every later request.
    • DValidate the `Origin` header on incoming connections.correct
    • EKeep newline-delimited framing on the response body so existing clients still parse it.

    Two things are mandatory when moving to Streamable HTTP: a single endpoint path handling both POST for client messages and GET for the optional server-to-client stream, and `Origin` validation on every incoming connection so a hostile page cannot drive the server. Everything else about the data layer — the tools, resources and prompts — carries over unchanged.

21. Q21 · Security and Safety · 8.1%

    A helpdesk agent pulls inbound customer emails through a `fetch_email` tool, and your service concatenates each email body into the system prompt before the run so Claude has the full thread. After a ticket arrived from an address nobody recognised, the agent called the refund tool without the operator asking for one. How should that email body reach Claude instead?

    • AKeep it in the system prompt but wrap it in `<email>` tags, the delimiting that suits long reference material your own systems produce.
    • BPrefill it as an assistant turn ahead of the drafting request, so the model treats it as material it has already reviewed.
    • CReturn it inside a `tool_result` block whose tool description states that the content is the body of an inbound email from an unverified sender.correct
    • DKeep it in the system prompt and add a directive telling Claude to disregard any instruction that appears inside email text, the untrusted-content policy the guidance recommends alongside placement.

    The system prompt is the channel your application speaks through, so text placed there inherits the authority of your own instructions. Claude is trained to treat content arriving in `tool_result` blocks as data rather than direction, and naming the source in the tool description gives it the context to calibrate how far to trust embedded directives. Moving the body into a tool result is what actually changes the trust level of the text; nothing else in the list does.

22. Q22 · Security and Safety · 8.1%

    Your research assistant retrieves passages from an internal wiki that partner vendors can edit. Twice this month it summarised a page and then called `create_ticket` with content nobody asked for. Retrieval already hands the passages back as tool results, and the system prompt already describes them as untrusted. What should you add to the retrieval path?

    • ARaise the number of passages retrieved per query, so a single poisoned page carries less weight, which is the lever to reach for when answers come back thin because too little context was returned.
    • BA classification call on a small model for each retrieved passage, reporting whether it contains redirection attempts, with a stripped summary substituted when it does.correct
    • CA move of the retrieved passages into the system prompt, so the model can weigh them against your instructions directly.
    • DFew-shot examples of well-formed summaries, so the model has a stronger template to follow when the summaries coming back vary in shape from one page to the next.

    Placement and prompt policy are already in place, so the remaining gap is that nothing inspects the retrieved text before it enters the context. Screening each tool output with a lightweight classifier whose verdict is constrained by structured outputs gives your application code a value it can branch on, so a flagged passage is replaced rather than delivered. The screen is a separate decision point, which is what makes it enforceable rather than advisory.

23. Q23 · Security and Safety · 8.1%

    An agent runs OCR over uploaded PDFs and can call `send_email` and `create_ticket`. During a red-team exercise, text rendered inside an uploaded image caused it to email a case summary to an outside address. The exercise report is due and you must pick the two changes to land first. Select TWO.

    Select 2 answers

    • ARaise the OCR engine's confidence threshold, so marginal text is discarded before it reaches the model.
    • BReturn the OCR text as a JSON-encoded tool result that names the source as a user-uploaded file.correct
    • CRequire explicit human confirmation before `send_email` runs with a recipient outside your organisation's domains.correct
    • DMove document processing into a nightly batch job, so extraction happens outside the interactive session.

    The two changes work on different halves of the problem. JSON-encoding the OCR output and labelling its source gives Claude unambiguous delimiters and the context that this is untrusted third-party content, which is what the injection relied on being absent. Confirming external recipients applies least privilege to the action that caused the damage, so even a successful injection cannot complete the exfiltration on its own. Neither change alone closes the path.

24. Q24 · Security and Safety · 8.1%

    An on-call agent has just been given the ability to apply Terraform plans in the production account, and it runs unattended overnight. The team is deciding what to put around it before the first unattended shift, and has room for two changes this sprint. Which two should they land? Select TWO.

    Select 2 answers

    • AA human approval gate between generating a plan and applying it.correct
    • BA system prompt directive telling the agent to pause and ask before any destructive change.
    • CA larger context budget, so the agent can read the whole plan output before deciding.
    • DA cloud role scoped to the resource types the on-call runbook actually covers.correct

    One control decides whether an action happens, the other bounds what any action can reach. An approval gate between plan and apply puts a person at the point where intent becomes change, which is the standard place to break an autonomous loop that touches production. Scoping the cloud role to the runbook's resource types means that even an approved-but-wrong apply, or one that slips past the gate, cannot touch systems outside the agent's remit.

25. Q25 · Claude Code · 3.1%

    A platform team wants every engineer in the payments repo to be told that migrations run through `make migrate` and that generated files under `gen/` are not hand-edited. Separately, they want a fixed set of shell commands pre-approved so nobody is prompted for them. Where does each piece belong?

    • ABoth go in `.claude/settings.json` — the conventions under a `rules` key, the commands under `permissions.allow`.
    • BBoth go in a root `CLAUDE.md`, since settings files are per-machine and are not shared.
    • CThe two conventions go in a `CLAUDE.md` at the repo root; the pre-approved commands go in `.claude/settings.json`. Both files are committed.correct
    • DThe conventions go in `~/.claude/CLAUDE.md` and the pre-approved commands in `.claude/settings.local.json`, so both travel with the engineer.

    The two files do different jobs and both are project-scoped and committed. `CLAUDE.md` is prose the model reads as guidance — conventions, constraints, how this repo does things. `settings.json` is structured configuration the harness acts on, including the `permissions` block that decides what runs without an approval prompt. Splitting them this way gets both to every teammate through a normal git clone.

26. Q26 · Claude Code · 3.1%

    An engineer joins a large repository that has no Claude Code configuration at all. They want a starting `CLAUDE.md` that reflects how this codebase actually builds, tests and is laid out, rather than one written from what they can remember after a day of reading. What is the intended first step?

    • ARun `/memory`, which opens the memory files for editing, and type the conventions in by hand.
    • BRun `/init`, which analyses the codebase and writes a `CLAUDE.md` for the project.correct
    • CAdd the build and test commands as a project skill under `.claude/skills/` so they are available on demand.
    • DPut the build and test commands in `permissions.allow` in `.claude/settings.json` so they run without an approval prompt.

    `/init` is the bootstrap step for exactly this situation: it inspects the repository and produces a `CLAUDE.md` documenting the codebase. It is the difference between a memory file grounded in what the repo contains and one grounded in a newcomer's impressions, and it leaves a normal markdown file the team can then edit and commit.

27. Q27 · Claude Code · 3.1%

    A team is hardening how Claude Code operates in a repository that also contains production deployment scripts. Reviewing their proposed changes, which two are enforced by the harness rather than relying on the model's judgement at the time? Select TWO.

    Select 2 answers

    • AA `PostToolUse` hook in `.claude/settings.json` that runs the linter after file edits.correct
    • BA line in `CLAUDE.md` stating that the production deploy script is not to be run.
    • CA `deny` entry in `.claude/settings.json` covering the production deploy script.correct
    • DA subagent whose `description` states that it is a read-only reviewer.

    Hooks and permission rules are evaluated by the harness around each tool call, so they hold regardless of what the model concluded — a hook fires on its event, and a denied command does not run. That is the distinction worth internalising when hardening a repository: guidance shapes intent and configuration sets boundaries, and only the second kind survives a model that misreads the situation.

28. Q28 · Eval, Testing, and Debugging · 2.6%

    A contract-summarization service returns summaries that stop mid-sentence whenever the uploaded document runs long. Those calls come back HTTP 200 with `stop_reason: "max_tokens"`, and short contracts are summarized correctly by the same code path. What should the team change?

    • ASplit each contract into sections, summarize the sections separately, and concatenate the results into one summary.
    • BRaise `max_tokens` and switch the call to streaming so the larger response does not hit an HTTP timeout.correct
    • CAdd a stop sequence for the end-of-section marker so generation terminates on a clean boundary rather than mid-word.
    • DPut a `cache_control` breakpoint on the contract block so the document text is cached between successive requests.

    `stop_reason: "max_tokens"` says generation reached the output ceiling the request asked for. The input was accepted and processed; it is the answer that ran out of room. The direct fix is a higher ceiling, and because a large `max_tokens` on a non-streaming call holds an idle connection open long enough to trip SDK and proxy timeouts, streaming is a companion change rather than an optional extra.

29. Q29 · Eval, Testing, and Debugging · 2.6%

    A nightly enrichment job pushes 40,000 records through Claude. Between 01:00 and 02:00 roughly 8% of calls return HTTP 529 `overloaded_error`; replaying the same records by hand an hour later succeeds unchanged. The job currently treats any non-200 as permanent and dead-letters the record. What should change?

    • ARotate the API key the job uses and confirm the replacement has access to the model.
    • BValidate each request body against the Messages schema before sending, so malformed payloads are caught inside the worker.
    • CRe-enqueue the affected records and retry with exponential backoff and jitter instead of dead-lettering them.correct
    • DReduce the size of each request so it stays under the maximum request body size.

    529 is a capacity signal from the service, not a defect in the request — which is exactly why the identical payload succeeds on replay. It belongs in the retryable class alongside 429 and 5xx, so the record should go back on the queue with backoff and jitter rather than into a dead-letter queue a human has to drain. Spreading the job's concurrency over a wider window reduces how often it happens at all.

30. Q30 · Eval, Testing, and Debugging · 2.6%

    A tool-using agent has started giving wrong answers in production. Before anyone rewrites the prompt, the team wants to establish whether the fault lies in the harness or in what the model returned. Which two observations point at the integration layer rather than the model's output? Select TWO.

    Select 2 answers

    • A`usage.cache_read_input_tokens` is zero request after request even though the system prefix has not changed.correct
    • BA `tool_use` block in the transcript has no `tool_result` carrying the same `tool_use_id`.correct
    • C`stop_reason` is `refusal` on the failing requests.
    • DThe final answer is fluent and well organised but asserts a fact the retrieved documents do not support.

    Both are properties of the request the harness constructed, verifiable without any judgement about answer quality. A prefix that never reads from cache means the assembly code is producing different bytes each time; an unpaired `tool_use` means the harness failed to return a result the model was owed. Either degrades answers on its own — the second in particular pushes the model to retry or guess — and both are cheap to check before touching a prompt.

Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.