Practice — CCDV-F Domain 2: Applications and Integration (33.1%)
20 scenario-based MCQs. Answer key + explanations at the bottom.
Q1
You're building a weather assistant on the Messages API. Your first messages.create call, made with a get_weather tool schema, returns a response with stop_reason: "tool_use". What must your application do next?
A. Return the response's text blocks to the user; the tool_use block is informational only
B. Send a new request containing a single tool_result block as an assistant-role turn
C. Execute the tool, append the assistant turn plus a user turn of tool_result blocks, and call again
D. Retry the identical request with tool_choice: "none" so Claude answers in plain text instead
Q2
A teammate builds a chatbot that sends only the newest user message on each messages.create call, expecting the API to use the id from prior responses to reconstruct the conversation. Claude keeps "forgetting" earlier turns. What is the actual behavior?
A. Conversations persist server-side for 5 minutes, and his requests are simply spaced too far apart
B. The API is stateless — every request must carry the full message history, which your app stores
C. He must pass metadata.user_id on each request so the server can link the turns into a session
D. Response IDs resume server-side state, but only when prompt caching is enabled on the request
Q3
A summarization endpoint intermittently returns responses that cut off mid-sentence. Inspecting the raw responses shows stop_reason: "max_tokens". What is happening?
A. The completion hit the request's max_tokens cap; raise the cap or handle continuation
B. The input exceeded the model's context window and was silently truncated on entry
C. A stop sequence supplied in the request matched partway through the generation
D. The account's rate limit throttled the response before generation could complete
Q4
Claude returns a single assistant turn containing three tool_use blocks — three flight lookups against different airlines, none depending on another. Which handling is correct?
A. Execute only the first block and ignore the rest; Claude will re-request the others next turn
B. Reject the turn and re-send the request forcing tool_choice: "auto" to get one tool at a time
C. Execute each tool sequentially and send each tool_result back as its own separate user turn
D. Execute all three in parallel and return all tool_result blocks in one user turn
Q5
A pipeline must extract invoice fields as JSON that downstream code parses without human review; reliability of the output shape is the top priority. Which approach is strongest?
A. Prompt "Respond with only valid JSON matching this schema" and set temperature to 0
B. Define a tool whose input_schema is the target schema and force it via tool_choice
C. Prefill the assistant turn with { so Claude is compelled to continue in JSON syntax
D. Set tool_choice: "any" so Claude must respond with some structured tool call
Q6
An extraction schema marks all 14 fields as required. On sparse source documents, Claude fills missing fields with plausible-looking fabricated values. What is the best schema-level fix?
A. Require only truly-mandatory fields and make the rest explicitly nullable
B. Lower temperature to 0 so the model stops inventing values under pressure
C. Group the optional fields into nested sub-objects so they can be omitted together
D. Abandon tool-based extraction and switch to prefilling { in the assistant turn
Q7
You're streaming a response that includes a tool_use block, and your UI crashes calling JSON.parse on each delta as it arrives. How does tool input actually arrive in a stream?
A. As one complete JSON object delivered inside the content_block_start event
B. As message_delta events that each carry the full accumulated input object
C. As incremental JSON objects that the client is expected to deep-merge per event
D. As input_json_delta string fragments, parsed only after the block stops
Q8
You submit 10,000 extraction requests in one Message Batches job. When it ends, 212 entries show result.type: "errored" while the rest succeeded. How should the pipeline map results and recover?
A. Match results by array position and resubmit the entire batch, since batches fail atomically
B. Match results to input rows via each request's custom_id; resubmit only the errored ones
C. Poll batches.retrieve separately for each failed request ID until every entry succeeds
D. Cancel the finished batch and rerun the 212 failed rows through streaming calls instead
Q9
A team runs two workloads: (1) an interactive support chat where perceived latency matters, and (2) a nightly job re-classifying 500K historical tickets. To cut costs, someone proposes routing both through the Message Batches API. What is the right split?
A. Batch for both — polling the batch every second makes it responsive enough for chat B. Realtime streaming for both, since streaming requests earn the same 50% discount C. Streaming for the chat; the Batches API for the nightly job's 50% discount D. Batch for the chat and realtime for the nightly job, which needs the higher throughput
Q10
An expense app photographs receipts on modern phones (~4000px on the long edge) and sends them base64-encoded to Claude for extraction. Vision token costs are far above projections. Which change gives the biggest cost reduction without hurting accuracy?
A. Resize images to roughly 1568px on the longest edge before sending them
B. Switch from base64 delivery to URL delivery, which is billed at fewer tokens
C. Split each receipt into several smaller crops and send them as separate images
D. Lower temperature so the model spends fewer tokens interpreting each image
Q11
An agent combines extended thinking with tool use. To save tokens, the developer strips thinking blocks from assistant turns before sending tool results back. Multi-step tasks begin failing in strange ways. Why?
A. Thinking blocks must be relocated into the system prompt for tool routing to work
B. Removing blocks changed the message count, which breaks strict role alternation
C. Extended thinking cannot be combined with tool use, so all behavior is undefined
D. The thinking blocks and their signatures must be preserved across tool-use turns
Q12
After enabling thinking: {type: "enabled", budget_tokens: 3500} on requests that set max_tokens: 4096, users report answers that trail off abruptly. What is the most likely cause?
A. The thinking signature consumes whatever output budget remains after the trace
B. Extended thinking shrinks the model's context window by the budget amount
C. Thinking spends from max_tokens, leaving little room for the visible answer
D. budget_tokens acts as a hard minimum, forcing 3500 thinking tokens every call
Q13
A support bot's system prompt is assembled as: a current-timestamp line, then a 2,000-token persona, then a 40K-token policy manual whose final block carries cache_control: {type: "ephemeral"}. Traffic is steady, yet cache_read_input_tokens is always zero. What is the root cause?
A. Reference documents of that size exceed what the cache will accept
B. The leading timestamp changes every request, so the prefix never matches
C. cache_control must be placed on the first block of the prefix, not the last
D. System prompts cannot be cached; only tools and message content can be
Q14
A monitoring job calls Claude every 15 minutes with a byte-identical 30K-token cached prefix. Usage consistently shows cache_creation_input_tokens ≈ 30K and cache_read_input_tokens = 0. What explains this, and what is the cheapest structural fix?
A. The request exceeds four cache breakpoints, disabling caching; consolidate to one B. The prefix has nondeterministic whitespace between runs; normalize the template C. A prefix cannot be read in the same request that wrote it; alternate two prefixes D. The default 5-minute TTL expires between runs; use the 1-hour TTL tier instead
Q15
During traffic spikes, a production app receives bursts of HTTP 429 responses from the Claude API. Which client-side handling is most appropriate?
A. Retry with exponential backoff and jitter; at scale, tier bulk traffic onto cheaper models B. Retry immediately in a tight loop, since 429 conditions typically clear within milliseconds C. Provision several API keys and rotate requests across them to stay under per-key limits D. Catch the 429, drop the affected requests, and show a generic error to protect the queue
Q16
An agent loop executes a create_refund tool call, then crashes before persisting the tool_result. On restart it replays the conversation, Claude re-issues the call, and the customer is refunded twice. Which fix addresses the root cause?
A. Add a system-prompt rule instructing Claude never to call the same tool twice
B. Lower temperature to 0 so the replayed conversation yields identical tool calls
C. Make the handler idempotent, keyed on the tool_use id, so replays are no-ops
D. Configure the loop to skip all pending tool calls whenever it restarts after a crash
Q17
Your company's internal ticket system should be reachable from claude.ai, Claude Desktop, Claude Code, and a custom API application the team is building. Which integration strategy minimizes duplicated work?
A. Build one MCP server for the ticket system and connect it from each surface B. Write tool definitions in the API app and copy those schemas into each other surface C. Package the integration as a Claude Code skill and distribute the skill file to users D. Build a separate lightweight plugin per surface to match each host's own conventions
Q18
A production summarizer's tone and formatting shift noticeably overnight; no deploy happened and no prompt changed. The service config specifies a model alias rather than a full version ID. What is the likely cause, and the durable fix?
A. Cache poisoning replayed a stale prefix; disable prompt caching on the endpoint B. The API's default temperature changed server-side; set every parameter explicitly C. Rate limiting silently downgraded the model at peak load; raise the account tier D. The alias moved to a newer snapshot; pin the exact model ID and version prompts
Q19
A team rule — "use pnpm, never npm; run tests with pnpm test:unit" — must reach every engineer's Claude Code session in the repo automatically, with no per-machine setup. Where does it belong?
A. Each engineer's ~/.claude/CLAUDE.md, so the rule applies across all of their projects
B. The repo's committed CLAUDE.md, which Claude reads automatically at session start
C. The repo's root-level CLAUDE.local.md, which each engineer maintains individually
D. The repo's .claude/settings.json, as entries under the permissions.allow list
Q20
To control context growth, a chat server prunes old history, deleting verbose tool_result blocks while keeping the assistant tool_use blocks that requested them. Later requests begin failing or behaving erratically. Which session-hygiene rule is being violated?
A. Old turns may never be deleted from a conversation once sent to the API
B. Pruning must always remove the newest turns first, never the oldest ones
C. tool_use and tool_result blocks must be kept or dropped as matching pairs
D. Tool results must be re-fetched from their sources before every new request
Answers
Q1: C. stop_reason: "tool_use" means Claude is asking your code to run a tool: execute it, append the assistant turn (with its tool_use blocks) plus a user turn containing tool_result blocks, and loop until end_turn. B encodes the classic confusion that tool results are an assistant or "tool" role — they go back as a user turn. A abandons the loop mid-flight; D discards the model's chosen action rather than completing it.
Q2: B. The Messages API is stateless — the server has no memory of prior turns, so conversation state lives in your application and every request replays the history. A confuses the prompt-cache TTL with conversation persistence; the cache saves cost, not state. C's metadata.user_id exists for abuse tracking, not session linking, and D invents a resume behavior caching does not have.
Q3: A. stop_reason: "max_tokens" means the completion hit the request's hard cap — raise max_tokens or design a continuation step. B would surface as a request error, not a truncated completion; C would report stop_sequence; D is not how rate limiting manifests (429s reject requests, they don't clip generations).
Q4: D. Claude can emit multiple tool_use blocks in one turn precisely so independent calls run in parallel — a major latency win — and all tool_result blocks must come back in a single user turn. C breaks strict user/assistant alternation by stacking consecutive user turns. A leaves tool calls unanswered, and B rejects a correct, well-formed response.
Q5: B. Forcing a specific tool with tool_choice: {type: "tool", name: ...} makes the tool's input_schema a contract Claude must satisfy — the most reliable structured-output technique. C, the runner-up, guarantees a JSON-ish start but nothing about conformance to your schema. A is the least reliable (prompt-only), and D forces some tool call without pinning which schema you get.
Q6: A. Overdoing required pressures the model to invent values for fields the document simply doesn't contain; require only what must exist and mark the rest nullable (e.g., "type": ["string", "null"]). B doesn't help — at temperature 0 the model still must fill a required field with something. C adds nesting the guidance says to avoid, and D trades down to a less reliable technique entirely.
Q7: D. Tool input streams as input_json_delta events carrying string fragments; you concatenate them and parse only after content_block_stop (unless you have an incremental JSON parser). A and B misplace where input arrives — content_block_start gives the tool's name and id, and message_delta carries top-level updates like stop_reason. C describes a merge semantics the API doesn't use: deltas are string pieces, not partial objects.
Q8: B. Batch failures are per-request — the batch as a whole still completes — so you map rows with custom_id and resubmit only the errored entries. A is wrong on both counts: order isn't the contract (custom_id is) and batches don't fail atomically. C polls at the wrong granularity (you poll the batch, then fetch results_url), and D forfeits the 50% discount for rows that don't need low latency.
Q9: C. Memorize the split: batch for offline volume, sync for interactive, streaming for first-token UX. The nightly job has no latency requirement, so it takes the 50% batch discount; the chat needs streaming for perceived responsiveness. A ignores that batch results can take up to 24 hours regardless of polling; B invents a streaming discount that doesn't exist; D is exactly inverted.
Q10: A. Image tokens scale with pixel dimensions, and ~1568px on the longest edge is usually plenty — larger images cost more tokens with no quality gain. B is the documented myth: URL vs base64 changes delivery, not token count. C multiplies image overhead rather than reducing it, and D confuses sampling with input-token billing.
Q11: D. When tool use is involved, prior thinking blocks — with their signatures intact — must be passed back in subsequent turns, or Claude loses the reasoning trace behind its own plan. The signature exists precisely so returned thinking can be verified; stripping it (or the block) is the documented failure mode. C is false (thinking and tools compose), and A and B misdescribe the mechanics.
Q12: C. budget_tokens is a soft cap on the thinking trace, and thinking spends from the same max_tokens budget — a 3500 budget under a 4096 cap leaves as little as ~600 tokens for the visible answer. Fix by raising max_tokens or lowering the budget. A and B invent overheads that don't exist, and D reverses the semantics: the budget is a ceiling, not a floor.
Q13: B. Any change to the cached prefix invalidates it, and the timestamp at position zero changes every request — so every call is a cache write, never a read. The fix is to keep the cacheable prefix stable and move volatile data (timestamps, user IDs) after the breakpoint. C reverses how breakpoints work (a breakpoint caches everything up to and including that block), and A and D are false — large system-prompt documents are a primary caching use case.
Q14: D. The default ephemeral cache lives 5 minutes past last use, so a 15-minute cadence misses every time and re-pays the ~125% write cost on each run; the 1-hour TTL tier ({"type": "ephemeral", "ttl": "1h"}) covers the gap. B would be plausible if the prefix weren't stated as byte-identical. A misstates the limit (up to 4 breakpoints are allowed, not fatal), and C invents a nonexistent rule.
Q15: A. 429s are throughput signals: retry with exponential backoff plus jitter, and at sustained scale tier high-volume, low-stakes work onto cheaper models to reduce pressure. B amplifies the spike and keeps you throttled; C tries to evade account limits rather than engineer around them; D silently drops user work when a short wait would have succeeded.
Q16: C. The root cause is a non-idempotent side-effecting operation replayed after a crash — classic distributed-systems hygiene applied to LLM calls. Keying the handler on the stable tool_use id makes the replayed call a no-op. A, the runner-up, is only a probabilistic instruction to the model, not a guarantee; B doesn't prevent the duplicate (an identical replay is exactly the problem); D breaks legitimate recovery paths.
Q17: A. MCP's core promise is "write one server, use it from every Claude surface" — one ticket-system server connects to claude.ai, Desktop, Claude Code, and your own app. B duplicates schemas and logic per surface, the exact maintenance burden MCP removes. C packages reusable know-how, not a live authenticated connection — a skill file can't serve ticket-system data to claude.ai or the custom API app. D is maximal duplicated work.
Q18: D. Aliases move to newer snapshots, so behavior shifts under you with no deploy — the blueprint's argument for pinning exact model IDs, paired with prompt versioning so any behavior change is a deliberate, testable diff. A and B invent server-side changes that don't occur (caches match exact prefixes; defaults don't silently mutate), and C describes a downgrade mechanism that doesn't exist.
Q19: B. The committed project-level CLAUDE.md is the shared "how to work in this repo" memory that every teammate's session reads automatically at start. A, the runner-up, applies only to one engineer's machine and pollutes their other projects. C is explicitly gitignored and per-user, so it can't reach the team, and D holds tool permissions, not workflow conventions.
Q20: C. tool_use and tool_result blocks form matching pairs; dropping one side orphans the other, which is a documented cause of API errors and "forgotten" tool calls. When compacting, prune the pair together (or summarize the result in place). A is false — compaction is expected and necessary; B inverts the standard oldest-first strategy; D confuses stale-data refresh advice with a structural requirement.