Last 90 days of practice answers

Hardest Claude Certified Developer - Foundations questions in the last 90 days

Visitors answered these free Claude Certified Developer - Foundations practice questions wrong most often in the 90 days to 11 Nov 2026. Each ranked question has 20 or more answers.

How to use this list

  1. Step 1Start with question 1 and read the short answer explanation.
  2. Step 2Open the full explanation for the concept before you move to the next question.
  3. Step 3Retake the practice test and check whether you still miss these questions.
937
answers in the last 90 days
62
practice sessions in the last 90 days
10
questions ranked, 20 or more answers each

Email this list to yourself

The button opens your own email app with the 10 questions and their explanation links.

Email this list
#1 most missed

Messages API & Conversation

Applications and Integration
30% missed, 56 answers

A developer expects the Messages API to remember a user's previous request, but the second call has no context. What is the correct fix?

Correct answer
C. Send the relevant prior user and assistant turns again in the messages array

Messages API calls are stateless with respect to conversation history. The application owns state and must include the relevant prior turns in each request.

#2 most missed

Message Batches API & API Failure Diagnosis

Eval, Testing, and Debugging
31% missed, 32 answers

A nonprofit relief organization runs Claude via the Messages API on an air-gapped private network with no outbound internet access. During a batch eval run using the Message Batches API, every request returns an HTTP 529 status code. The engineering team must determine whether this is an API-layer failure or a model-quality failure before filing a support ticket. Which diagnostic step most accurately distinguishes between the two failure types given the private-network constraint?

Correct answer
B. Inspect the 529 status code, which indicates the Anthropic API is temporarily overloaded; this is an API-layer infrastructure failure unrelated to model output quality.

HTTP 529 is documented by Anthropic as 'API overloaded'—a server-side infrastructure error signaling the API cannot accept new requests at that moment. This is unambiguously an API-layer failure, not a model-quality failure; no prompt or output evaluation is needed to diagnose it. Re-running prompts synchronously to compare quality scores tests model behavior, not infrastructure availability, and cannot resolve a 529. Increasing max_tokens addresses response length, which has no bearing on overload errors. Switching model variants conflates model availability with server capacity; 529 is not model-specific.

#3 most missed

Claude Code & Settings

Claude Code
28% missed, 32 answers

A media archive company stores millions of video assets and uses Claude Code to automate metadata tagging. Traffic spikes unpredictably when major events occur, causing Claude Code sessions to attempt bulk file operations that overwhelm the archive's storage API. The team wants to use repository-level configuration to constrain which tools Claude Code can invoke automatically versus which ones require explicit human approval. Which Claude Code settings mechanism best addresses this integration tradeoff?

Correct answer
A. Use the 'permissions' block in a .claude/settings.json file to set specific tool allow/deny rules, restricting bulk file-write tools to require approval while permitting read-only tools to run automatically.

Claude Code's .claude/settings.json supports a 'permissions' block where operators can explicitly allow or deny individual tools and require human approval for sensitive actions. This is the authoritative mechanism for controlling tool invocation behavior at the repository level. A CLAUDE.md description alone provides context but does not enforce tool restrictions—Claude may still invoke disallowed tools. Switching models via ANTHROPIC_MODEL addresses cost, not permission enforcement. A pre-commit hook operates on git commits, not on Claude Code tool execution, and cannot selectively restrict specific tools mid-session.

#4 most missed

Claude Code

Claude Code
25% missed, 28 answers

An agricultural cooperative uses Claude Code to assist agronomists with soil-analysis scripts. Their legacy data pipeline exports CSV files with non-standard encodings and expects shell commands to follow a strict naming convention for output files. The team wants to evaluate whether placing workflow instructions in CLAUDE.md is sufficient to ensure consistent compliance across all sessions, or whether a more enforceable configuration layer is also needed. Which evaluation design approach best reveals the reliability gap between instruction-only and permission-enforced configuration?

Correct answer
A. Run identical tasks under two configurations, CLAUDE.md alone and CLAUDE.md plus .claude/settings.json permission rules, and measure non-compliant tool calls and naming violations across many sessions.

A rigorous evaluation compares the two configuration layers—CLAUDE.md instructions alone versus CLAUDE.md combined with .claude/settings.json permission enforcement—across repeated sessions, measuring objective violation rates. This surfaces whether natural-language instructions reliably produce compliant behavior or whether enforceable permission rules are necessary. A single manual inspection lacks statistical power and cannot reveal intermittent failures. Grepping stdout for an encoding string checks only that the string appeared, not that the correct tool behavior occurred. Self-reporting by Claude is unreliable as a compliance metric because the model cannot objectively audit its own tool calls.

#5 most missed

Agents & Workflows

Agents and Workflows
17% missed, 66 answers

A document pipeline always performs the same three steps: extract fields, validate them against a schema, and write an approved record. Which design is the best default?

Correct answer
D. A fixed workflow that calls Claude only for extraction and uses code for validation and writing

The sequence and control logic are known, so deterministic orchestration is simpler and safer. Claude can handle the ambiguous extraction while code enforces schema and write rules.

#6 most missed

Tools & Descriptions

Tools and MCPs
12% missed, 43 answers

Claude repeatedly chooses `search_customers` when it should use `get_customer_by_id`. What is the best first improvement?

Correct answer
A. Make both tool names, descriptions, parameters, and use boundaries precise and non-overlapping

Tool descriptions and schemas are part of the model's selection interface. Clear, mutually distinct contracts directly address systematic misselection.

#7 most missed

Agent Loop & Stop Reason

Agents and Workflows
12% missed, 43 answers

A custom agent receives an assistant response whose stop reason indicates tool use. What should the application do next?

Correct answer
C. Execute the requested allowed tool, append the tool result to the conversation, and call the model again

A tool-use stop indicates that the model is waiting for a tool result. The client must execute the authorized tool, return a correctly formed result block, and continue the loop.

#8 most missed

Eval, Testing, and Debugging

Eval, Testing, and Debugging
11% missed, 28 answers

A team is building an eval harness to measure Claude's output quality across 10,000 test cases. They need the harness to reliably distinguish between API-level failures (network errors, rate limits, malformed responses) and model-level failures (incorrect answers, missed instructions, reasoning errors) so that each failure type can be routed to the correct remediation workflow. Which harness design most clearly separates these two failure classes at scale?

Correct answer
B. Record the full messages array for every trial as the transcript, capture the final environment outcome separately, and tag each result with the HTTP status code and stop reason so that network and rate-limit errors are distinguished from responses where the model produced output but answered incorrectly.

Distinguishing API failures from model failures requires capturing different signals at different layers. The transcript—the complete messages array including all tool calls, intermediate results, and returned responses—records what the model did. The outcome—the final state in the environment, such as whether a database record was created or a classification matched the label—records whether the task succeeded. HTTP status codes and stop reasons surface infrastructure problems: a 529 overloaded error, a 429 rate-limit error, or a network timeout is an API failure regardless of what the model would have said. A response with a 200 status and a valid stop reason that nonetheless answers incorrectly is a model failure. Keeping these signals separate allows each failure type to be routed to the correct remediation workflow. Treating every wrong answer as a model failure and every SDK exception as an API failure conflates cases where an API error caused a degraded but non-exception response, and misses cases where a malformed model output triggers a downstream exception. The classification is too coarse to drive targeted remediation. Running cases synchronously and logging only final text discards the intermediate signals—tool calls, stop reasons, status codes—needed to diagnose root cause. Human post-hoc review cannot recover information that was never recorded. Prompt caching is a latency and cost optimization. Cache state reflects whether a prompt prefix was reused, not whether the API layer or the model layer caused a failure. Using cache hits and misses as a proxy for failure classification produces a categorization with no causal relationship to the actual failure modes.

#9 most missed

Security and Safety

Security and Safety
10% missed, 30 answers

A fleet-maintenance provider stores vehicle inspection records in a regulated database. Their Claude-powered agent can both read inspection histories and permanently delete records flagged as duplicates. Regulations require that deletion events be auditable and reversible for 90 days. A developer proposes embedding the database service-account password directly inside the agent's system prompt so that the model can reference it when constructing deletion queries. Which security boundary decision best addresses both the regulatory requirement and the credential exposure risk?

Correct answer
C. Store the service-account password in a dedicated secrets manager outside the prompt, and gate every delete action behind an explicit human-approval step that logs the approver identity and timestamp before execution.

Credentials must never appear in prompts. Prompt content can be logged by the application layer, cached by the API, echoed back in model outputs, or exposed through prompt-injection attacks—any of these paths would leak the password. A secrets manager keeps credentials entirely outside the conversation, injecting them only at the application layer when a specific, authorized action is about to execute. Separately, permanent deletion is a consequential and difficult-to-reverse action. Requiring an explicit human-approval step before each deletion—with the approver's identity and a timestamp recorded—creates the auditable, reversible-within-90-days trail the regulation demands. These two controls together satisfy both requirements. Hashing the password before embedding it in the system prompt does not protect the credential: the hash is still present in prompt logs and caches, and a hash of a known password can be used to verify guesses or, for weak passwords, reversed. The plaintext is also still needed by the database driver, so the application must store it somewhere anyway. Rotating the password daily reduces the window of exposure after a leak but does not prevent the leak itself. The password is still written into the prompt on every request and is therefore still exposed to every logging and caching pathway. Removing delete capability entirely eliminates the credential-in-prompt risk but also eliminates a legitimate operational function. The correct approach is to govern the capability with proper secrets handling and human approval, not to abandon it.

#10 most missed

Evals & Regression

Eval, Testing, and Debugging
8% missed, 50 answers

A prompt change improves five hand-picked examples but user complaints rise after release. What test gap most likely caused this?

Correct answer
A. The eval set was not representative of production inputs and failure modes

Hand-picked successes do not estimate production behavior. A representative regression set should include common cases, edge cases, and known failures.

Retake the test

Retake the free Claude Certified Developer - Foundations practice test and check whether you still miss these questions. No signup required.

Start the free diagnostic