20 Applications & API Integration Practice Questions & Answers
Every Applications & API Integration practice question from the Claude Certified Developer – Foundations Practice Test, with the correct answer and a short explanation.
Start practice test →1. A developer is making their first POST request to the Claude Messages API (/v1/messages). Which set of top-level parameters is required in every request body?
- A.api_key, messages, and stream
- B.model, max_tokens, and messages✓ Answer
- C.model, temperature, and prompt
- D.model, system, and messages
The Messages API requires exactly three fields in every request: model, max_tokens, and messages. system, temperature, and stream are optional, there is no top-level prompt field, and the API key is sent in the x-api-key HTTP header, never in the request body.
Source: Anthropic Messages API reference, docs.claude.com/en/api/messages — required request fieldsReport a problem with this question
2. A developer sends a Messages API request whose messages array begins with a message of role "assistant". What happens?
- A.The API returns a 400 invalid_request_error because the first message must have role "user"✓ Answer
- B.The API silently reorders the messages so a user message comes first
- C.The API returns a 401 authentication_error
- D.The API treats the assistant message as a system prompt and processes normally
The Messages API validates conversation structure: the first message must have role "user" and roles must alternate between user and assistant. A structurally invalid request is rejected with HTTP 400 invalid_request_error; the API never rewrites your input, and 401 is reserved for authentication failures.
Source: Anthropic Messages API reference, docs.claude.com/en/api/messages — message role constraints; API errors reference (400 invalid_request_error)Report a problem with this question
3. A developer builds a chat app that sends only the newest user message to the Messages API on each turn, and Claude keeps "forgetting" earlier turns. What is the root cause?
- A.The session token expired, which wipes server-side memory
- B.Claude only remembers context when streaming is enabled
- C.The developer forgot to enable the memory parameter in the request
- D.The Messages API is stateless, so the client must resend the full conversation history in the messages array on every request✓ Answer
The Messages API is stateless: the server retains no conversation memory between requests, so each call must include the entire prior exchange (alternating user and assistant messages) in the messages array. There is no server-side session, no memory parameter, and streaming does not affect context retention.
Source: Anthropic Messages API reference, docs.claude.com/en/api/messages — stateless design / multi-turn conversationsReport a problem with this question
4. Users of a web app complain about staring at a blank screen for a long time while Claude generates lengthy answers. Which change most directly improves the perceived responsiveness?
- A.Set stream: true so the response arrives as server-sent events and text can be rendered incrementally as it is generated✓ Answer
- B.Move the requests to the Message Batches API for faster processing
- C.Send the same request in parallel several times and display whichever finishes first
- D.Reduce max_tokens sharply so responses finish sooner
Streaming (stream: true) delivers the response as server-sent events, so the first tokens can be shown almost immediately instead of after full generation — it also avoids HTTP timeouts on long outputs. Batches trade latency for cost (they are slower, not faster), cutting max_tokens truncates answers, and duplicate parallel requests waste tokens without reducing time to first token.
Source: Anthropic streaming documentation, docs.claude.com/en/docs/build-with-claude/streaming — SSE delivery and latency benefitsReport a problem with this question
5. When consuming a streamed Messages API response, which server-sent event type carries the incremental chunks of generated text?
- A.message_start events containing the full text
- B.message_stop events containing the accumulated text
- C.content_block_delta events containing text_delta payloads✓ Answer
- D.content_block_stop events emitted for each token
In the streaming protocol, incremental text arrives in content_block_delta events whose delta has type text_delta; the client concatenates these chunks to build the response. message_start carries only metadata at the beginning, content_block_stop fires once when a block finishes, and message_stop marks the end of the message without content.
Source: Anthropic streaming documentation, docs.claude.com/en/docs/build-with-claude/streaming — SSE event types (content_block_delta / text_delta)Report a problem with this question
6. A developer wants Claude to analyze a photograph in a Messages API request. What is the correct way to supply the image?
- A.Paste the image URL into the plain text of the prompt; the API fetches any URL it sees in text
- B.Encode the image into the system parameter, since media is only accepted there
- C.Upload the image via a multipart form to a dedicated /v1/images endpoint
- D.Include an image content block (base64-encoded data or a URL source) inside the user message's content array, alongside a text block✓ Answer
Vision uses the same /v1/messages endpoint: a user message's content is an array of typed blocks, and images go in a block of type "image" with a base64 or URL source, typically placed before the related text block. There is no separate image endpoint, plain-text URLs are not fetched as images, and the system parameter does not accept media.
Source: Anthropic vision documentation, docs.claude.com/en/docs/build-with-claude/vision — image content blocks (base64 and URL sources)Report a problem with this question
7. A developer enables extended thinking with a token budget and gets a 400 error. Their request sets budget_tokens: 20000 and max_tokens: 8000. What rule did they violate?
- A.Extended thinking requires streaming to be disabled
- B.budget_tokens must be less than max_tokens, because thinking tokens count toward the response's total output limit✓ Answer
- C.max_tokens is ignored when thinking is enabled, so the error comes from another field
- D.budget_tokens must always be a multiple of 1000
With budgeted extended thinking, the thinking tokens are part of the response's output, so budget_tokens must be strictly less than max_tokens (and meet the documented minimum) or the API rejects the request with a 400. Streaming is fully compatible with thinking, and max_tokens remains enforced as the hard output ceiling.
Source: Anthropic extended thinking documentation, docs.claude.com/en/docs/build-with-claude/extended-thinking — budget_tokens must be less than max_tokensReport a problem with this question
8. A developer adds cache_control breakpoints to a large system prompt, but usage.cache_read_input_tokens stays at 0 on every request. The system prompt begins with "Current time: <timestamp>". Why is the cache never hit?
- A.Caching only activates after 100 identical requests
- B.Prompt caching is an exact prefix match, so the changing timestamp at the start makes every request's prefix unique and invalidates everything after it✓ Answer
- C.cache_control only works on the messages array, never on the system prompt
- D.The cache requires a paid add-on that has not been enabled
Prompt caching keys on the exact bytes of the prompt prefix up to each breakpoint; a single differing byte — like a per-request timestamp at the front — invalidates the cache for everything after it. The fix is to keep the prefix stable and move volatile content (timestamps, IDs) after the last cached breakpoint. cache_control is valid on system blocks, and no add-on or request threshold exists.
Source: Anthropic prompt caching documentation, docs.claude.com/en/docs/build-with-claude/prompt-caching — exact prefix matching and cache invalidationReport a problem with this question
9. An agent app caches its system prompt with cache_control. Midway through a session the developer adds one new tool to the tools array. What happens to the existing prompt cache?
- A.The cache automatically migrates to include the new tool at no cost
- B.Nothing changes, because tool definitions are not part of the cached prompt
- C.The entire cache is invalidated, because tools are rendered at the start of the prompt, before system and messages✓ Answer
- D.Only the tools section is invalidated; the cached system prompt and messages still hit
The prompt is rendered in the fixed order tools → system → messages, and caching is a prefix match. Because tool definitions sit at the very front of that prefix, adding, removing, or reordering any tool changes the earliest bytes and invalidates every cache breakpoint downstream — system and conversation history included.
Source: Anthropic prompt caching documentation, docs.claude.com/en/docs/build-with-claude/prompt-caching — prompt render order (tools → system → messages) and invalidation hierarchyReport a problem with this question
10. A company must classify 50,000 archived documents with Claude by tomorrow morning. No single result is needed immediately, and cost should be minimized. Which approach fits best?
- A.Use streaming on each request, since streamed tokens are billed at a discount
- B.Submit the requests through the Message Batches API, which processes asynchronously at 50% of standard token prices with a 24-hour completion window✓ Answer
- C.Concatenate all documents into one giant realtime request to pay for only one call
- D.Fire all 50,000 requests at the realtime Messages API simultaneously to finish fastest
The Batches API is designed for exactly this workload: large volumes of non-latency-sensitive requests processed asynchronously at a 50% discount on token prices, with most batches finishing well within the 24-hour maximum. Blasting the realtime API hits rate limits at full price, streaming changes delivery but not billing, and one giant request would exceed context limits and lose per-document results.
Source: Anthropic batch processing documentation, docs.claude.com/en/docs/build-with-claude/batch-processing — 50% pricing and 24-hour processing windowReport a problem with this question
11. After a message batch finishes, a developer reads the results file and assumes result N corresponds to request N in the order submitted. Why is this a bug?
- A.Results are returned in reverse submission order by design
- B.Batch results may be returned in any order, so each result must be matched to its request using the custom_id supplied at creation✓ Answer
- C.The order is alphabetical by model name, not by submission
- D.Batch results are unordered only when the batch contains errors
Batch requests are processed in parallel, so the documented contract is that results can arrive in any order; the custom_id you attach to each request is the only reliable join key back to the original input. Code that relies on positional order will silently mismatch results, which is why every batch request requires a unique custom_id.
Source: Anthropic batch processing documentation, docs.claude.com/en/docs/build-with-claude/batch-processing — results returned in any order, matched by custom_idReport a problem with this question
12. Which of the following workloads is a poor fit for the Message Batches API and should use the realtime Messages API instead?
- A.Bulk evaluation of thousands of prompts for a quality benchmark
- B.Weekly re-classification of an entire product catalog
- C.Nightly summarization of the day's support tickets
- D.A live customer-support chat where the user is waiting for each reply✓ Answer
The Batches API offers no per-request latency guarantee — a batch may take up to 24 hours — so it is unsuitable whenever a human is waiting synchronously for the answer, as in live chat. The other three are classic batch workloads: high volume, tolerant of delay, and cheaper at the 50% batch discount.
Source: Anthropic batch processing documentation, docs.claude.com/en/docs/build-with-claude/batch-processing — asynchronous processing, up to 24-hour completion, latency tradeoffsReport a problem with this question
13. A team must invoke Claude through Amazon Bedrock instead of the Anthropic API directly. Which pair of changes should they expect?
- A.Authentication uses AWS credentials/IAM instead of an Anthropic API key, and model identifiers carry an "anthropic." vendor prefix✓ Answer
- B.Bedrock accepts Anthropic model IDs unchanged but bills through Anthropic's console
- C.Only streaming requests are supported on Bedrock
- D.They keep the x-api-key header but must add an AWS region to it
On Bedrock, requests are signed with AWS credentials under IAM control and billed through AWS — no Anthropic API key is used — and model IDs take an "anthropic."-prefixed, Bedrock-specific form. A region must also be configured on the client. Both streaming and non-streaming invocations are supported.
Source: Claude on Amazon Bedrock documentation, docs.claude.com — AWS credential authentication and anthropic.-prefixed Bedrock model IDsReport a problem with this question
14. A developer initializes an AnthropicVertex client to call Claude on Google Cloud Vertex AI. Which configuration is required?
- A.An Anthropic API key passed in the x-api-key header, plus a GCP billing account number in the body
- B.An AWS access key, since Vertex proxies requests through Bedrock
- C.A GCP project ID and region, with authentication handled by Google Cloud credentials (Application Default Credentials) rather than an Anthropic API key✓ Answer
- D.Only an OAuth token generated from the Anthropic Console
The Vertex AI integration authenticates with Google Cloud's own credential chain (e.g., Application Default Credentials) and requires the client to be constructed with a GCP project ID and region; no Anthropic API key is involved, and billing flows through the Google Cloud account. Vertex and Bedrock are independent platforms — neither proxies the other.
Source: Claude on Google Cloud Vertex AI documentation, docs.claude.com — AnthropicVertex client (project_id, region, GCP Application Default Credentials)Report a problem with this question
15. A Messages API response comes back with stop_reason "tool_use" and a tool_use content block. What must the developer's code do next?
- A.Retry the same request with tool_choice set to "none" to get the final answer
- B.Execute the tool locally, then send a new request that appends the assistant's content and a user message containing a tool_result block with the matching tool_use_id✓ Answer
- C.Wait for the API to run the tool server-side and push the result over a webhook
- D.Return the tool output in a new system prompt on the next request
Custom (client-side) tools follow a request-execute-respond loop: Claude emits a tool_use block, your code runs the tool, and you continue the conversation by appending the assistant turn plus a user message whose tool_result block echoes the tool_use_id so the API can pair result with call. The API does not execute user-defined tools or push webhooks, and tool results never go in the system prompt.
Source: Anthropic tool use documentation, docs.claude.com/en/docs/agents-and-tools/tool-use — handling tool_use stop reason and tool_result blocksReport a problem with this question
16. A developer is designing the input_schema for a tool whose "unit" parameter accepts only "celsius" or "fahrenheit". What is the best schema design practice?
- A.Declare it as a free-form string and correct bad values after the model responds
- B.Create two separate tools, one per unit, so no parameter is needed
- C.Describe the allowed values only in the tool's name, e.g. get_weather_celsius_or_fahrenheit
- D.Declare the parameter as a string with an enum listing the two allowed values, plus a clear description✓ Answer
Tool inputs are defined with JSON Schema, and the documented best practice for a fixed set of values is an enum plus a per-property description — the schema itself constrains what Claude can emit, preventing invalid values instead of repairing them afterward. Splitting into near-duplicate tools bloats the tool set, and encoding constraints in a name gives the model no structural guarantee.
Source: Anthropic tool use documentation, docs.claude.com/en/docs/agents-and-tools/tool-use — input_schema best practices (enum for fixed values, detailed descriptions)Report a problem with this question
17. A production integration occasionally receives HTTP 429 (rate_limit_error) responses from the Claude API. What is the correct handling strategy?
- A.Treat 429 as permanent and drop the request without retrying
- B.Honor the retry-after header and retry with exponential backoff, since 429 is a transient, retryable condition✓ Answer
- C.Retry immediately in a tight loop until the request succeeds
- D.Rotate to a new API key, because 429 means the key was revoked
429 means a rate limit (requests or tokens per time window) was exceeded, which is transient by nature: the response includes a retry-after header telling you how long to wait, and exponential backoff prevents hammering the API. Tight-loop retries make the throttling worse, a revoked key returns 401, and dropping requests loses data unnecessarily. The official SDKs implement this backoff automatically.
Source: Anthropic API errors and rate limits documentation, docs.claude.com/en/api/errors and /en/api/rate-limits — 429 handling, retry-after header, exponential backoffReport a problem with this question
18. A team keeps project-specific coding conventions in a CLAUDE.md file at the root of their repository. In which interface do these instructions automatically shape Claude's behavior?
- A.Claude Code, which automatically loads CLAUDE.md from the project directory as persistent context at the start of a session✓ Answer
- B.Only direct Messages API calls, where the file is injected server-side
- C.All interfaces, including claude.ai web chat, which scans repositories for the file
- D.Claude Desktop only, via its file-indexing feature
CLAUDE.md is a Claude Code convention: the CLI reads it from the working directory (and parent/user locations) at session start and treats its contents as persistent project instructions. claude.ai, Claude Desktop chat, and raw Messages API calls know nothing about the file — with the API, any such instructions must be sent explicitly, typically in the system prompt. This illustrates that each interface has its own configuration surface.
Source: Claude Code documentation (code.claude.com/docs) — CLAUDE.md project memory loaded at session start; CCDV-F Exam Guide Domain 2 (instructions across interfaces)Report a problem with this question
19. A team's production pipeline broke after the behavior of the model behind a generic alias shifted with a new release. Which configuration-management practice best prevents this class of incident?
- A.Always point production at the newest alias so fixes arrive automatically
- B.Store prompts only in a shared document editor so anyone can hotfix them
- C.Pin production traffic to a specific dated model snapshot and keep prompts under version control, upgrading only after testing✓ Answer
- D.Hard-code the model name in many places so it cannot be changed accidentally
Aliases float to newer releases, so a pipeline pointed at an alias can change behavior without any code change; pinning a dated snapshot freezes model behavior until you deliberately migrate. Versioning prompts alongside code gives the same reproducibility for the other half of the system — you can test a new model or prompt against evals before promoting it. Scattered hard-coding and untracked shared docs make changes harder to audit, not safer.
Source: Anthropic models overview, docs.claude.com/en/docs/about-claude/models — dated model snapshots vs floating aliases; CCDV-F Exam Guide Domain 2 (model version pinning, prompt versioning)Report a problem with this question
20. After hours in a single Claude Code session spanning a bug fix, a database migration, and documentation edits, responses become slower and start mixing up the unrelated tasks. What is the best session-hygiene practice?
- A.Clear the context or start a fresh session when switching to an unrelated task, since accumulated irrelevant context degrades quality and wastes tokens✓ Answer
- B.Keep everything in one session forever so no detail is ever lost
- C.Repeat all previous instructions verbatim in every new message
- D.Increase max_tokens, which expands the context window
Model attention is spread across everything in context, so stale, unrelated history both dilutes focus and inflates token costs on every turn; clearing context (e.g., Claude Code's /clear) or starting a new session per task keeps the context relevant. max_tokens caps output length only — it does not change the context window — and re-pasting old instructions makes the bloat worse.
Source: Claude Code documentation (code.claude.com/docs) — /clear and session management best practices; CCDV-F Exam Guide Domain 2 (session hygiene)Report a problem with this question
Practice questions based on the official Claude Certified Developer – Foundations (CCDV-F) exam guide and Anthropic's public documentation. This is an independent study tool, not affiliated with or endorsed by Anthropic, and does not grant certification. The real exam is 53 questions, 120 minutes, passing at a scaled 720/1000, delivered via Pearson VUE ($125). Official certification page →