8 of the 15 questions in this set, with the correct answer marked and every option explained.
1. In the Claude Messages API, how is conversation history maintained across turns?
✓The client sends the full sequence of prior messages with each request, because the API is stateless.
Each request is independent and carries whatever history the client chooses to include. This is why context management and token budgeting are the application's responsibility, and why long conversations grow in cost per request.
✗The server stores the conversation and the client sends only a session identifier.
That describes a stateful session API. The Messages API does not retain conversation state between calls.
✗History is inferred automatically from the API key's recent usage.
An API key authenticates and meters requests. It carries no conversational memory.
✗Only the most recent user message is ever needed, since the model remembers the rest.
The model has no memory between requests. Omitting history means the model genuinely does not see it.
2. What is the correct way to give a Claude API application standing behavioural instructions that apply to the whole conversation?
✓Use the top-level system parameter rather than prepending the instructions to the first user message.
The system parameter is the designated place for role and standing constraints. Keeping it separate from user turns makes the instructions easier to review, cache and reason about, and avoids conflating application policy with user input.
✗Prepend the instructions to every user message in the conversation.
This duplicates tokens on every turn and mixes application policy with user-supplied text — which is also a prompt injection hazard, since the boundary between the two becomes blurred.
✗Encode them in the API key's metadata.
API keys carry no prompt configuration. They authenticate the request.
✗Send them once in the first request; the model retains them for later requests.
The API is stateless. Anything omitted from a later request is simply not present for that request.
3. In a tool use flow, what does the application do after the model returns a tool_use block?
✓Execute the requested tool itself, then send the result back as a tool_result block in a subsequent request so the model can continue.
The model requests a call; it never executes anything. The application performs the work and returns the outcome, which keeps every side effect under application control and is the security boundary the whole design depends on.
✗Wait for the model to execute the tool on Anthropic's servers and return the result.
The model does not execute your tools. It emits a structured request describing the call it wants made.
✗Discard the block and re-prompt, since tool_use indicates the model was confused.
A tool_use block is the intended, successful behaviour when tools are provided — not an error signal.
✗Convert the tool_use block into a user message containing its raw JSON.
There is a defined tool_result content type for returning outcomes. Reinjecting raw JSON as user text abandons the structure the API expects.
4. A tool call fails because an upstream service is unavailable. How should the application respond?
✓Return a tool_result marked as an error with a clear message, so the model can decide whether to retry, try another approach, or explain the failure to the user.
The model can reason about a failure it is told about. Communicating the error through the same channel as success keeps the loop intact and lets the model adapt, which is far better behaviour than a silent gap or a crash.
✗Silently return an empty successful result.
The model will treat emptiness as a legitimate answer and may confidently report that nothing was found, which is a fabrication caused by the application.
✗Terminate the conversation and surface a stack trace to the user.
A transient upstream failure does not warrant destroying the session, and raw stack traces are poor user experience and a potential information leak.
✗Retry indefinitely until the service recovers.
Unbounded retries hang the request and can amplify load on a struggling service. Bounded retry with backoff, then reporting the error, is the correct pattern.
5. An application defines a tool whose JSON schema marks a parameter as optional, but the downstream service requires it. What is the likely consequence?
✓The model will sometimes omit the parameter, producing intermittent downstream failures that are hard to reproduce.
The schema is the contract the model reasons from. If it says optional, the model will legitimately omit it when it seems unnecessary — and the resulting failures appear random because they depend on the model's per-request judgement.
✗The API will reject the tool definition at request time.
The schema is internally valid; the API has no knowledge of what the downstream service requires. The mismatch is a design error, not a validation error.
✗The model will always include every parameter regardless of the schema.
Then optionality would have no meaning. The model does treat optional parameters as genuinely optional.
✗The downstream service will infer the missing value automatically.
Assuming a service will invent required input is not a safe design premise, and by the question's terms it requires the parameter.
6. A production application must guarantee that Claude's output can be parsed into a fixed data structure. Which approach is most reliable?
✓Define the structure as a tool schema and have the model call that tool, so output conforms to the schema rather than to a prose instruction.
Schema-constrained output is enforced by structure rather than by persuasion. Asking politely in a prompt works most of the time, and 'most of the time' is what causes production incidents.
✗Ask in the prompt for JSON only and parse whatever comes back.
This usually works and occasionally does not — a prose preamble or a trailing explanation breaks the parser. It is the failure mode schema enforcement exists to eliminate.
✗Post-process the response with a regular expression to extract the JSON.
A mitigation rather than a solution, and a fragile one. Regex extraction from free-form output fails in ways that are hard to anticipate.
✗Set max_tokens very low so the model has no room for extra prose.
This truncates output mid-structure, producing invalid JSON — a worse failure than the one being avoided.
7. A retrieval-augmented application passes retrieved document chunks to Claude along with the user's question. What must the application do with those chunks?
✓Present them as data to be used in answering, clearly delimited, and never treat text inside them as instructions to follow.
Retrieved content is untrusted by definition — anyone who can get a document into the corpus can attempt an injection. Clear delimitation and a data-not-instructions stance is the required handling.
✗Merge them into the system prompt so they carry maximum authority.
This grants untrusted content the highest level of trust in the request, which is precisely backwards and turns a corpus poisoning attempt into a system-level instruction.
✗Send them as a prior assistant turn so the model treats them as its own prior reasoning.
Attributing retrieved text to the assistant misrepresents its provenance and makes the model more likely to accept its content uncritically.
✗Concatenate them directly onto the user's question with no delimiter.
Without a boundary the model cannot distinguish the user's request from retrieved material, which is both a quality and a security problem.
8. Why would a developer enable streaming for a user-facing chat application?
✓Tokens are delivered as they are generated, so the user sees output beginning almost immediately instead of waiting for the entire response.
Streaming improves perceived latency, which for interactive interfaces matters more than total completion time. The user starts reading while generation continues.
✗Streaming reduces the total number of tokens billed.
Billing reflects tokens processed and generated. Delivery mode does not change the count.
✗Streaming allows the model to revise earlier parts of its answer as it goes.
Streamed tokens are already emitted. Generation is forward-only; the model cannot retract text the client has received.
✗Streaming is required for any request exceeding one thousand tokens.
There is no such requirement, though very long generations are a common reason to prefer streaming for practical timeout reasons.
7 more questions in the app
Practise the full 15-question set with a timer, scoring and progress tracking.