Free Anthropic CCDV-F Practice Questions with Answers

24 free Anthropic CCDV-F practice questions from the CertStash pack of 96, each with the correct answer and a full explanation. The rule is the same for every exam: ten free on the product page, 24 free here, all 96 in the pack, and each step includes the one before it.

Get all 96 questions (US$39) · Download the first 10 as a PDF

Question 1

You are starting a new Claude application and have a small set of well-labeled examples that demonstrate the desired output format. You want to use these examples to guide Claude's behavior.

How would you guide the application's behavior?

Embed the examples in a database and retrieve them at runtime as reference material for the team.
Use zero-shot prompting and rely on the model's general capability to produce the desired output format consistently across all incoming requests.
Train a custom model on the labeled examples before deployment so that the application does not need to include the examples in any prompt during operation.
Use multi-shot prompting by including the labeled examples in the prompt so Claude can match the desired output format on each request.

Show answer and explanation

Correct answer: D. Use multi-shot prompting by including the labeled examples in the prompt so Claude can match the desired output format on each request.

Multishot prompting places a few well-labeled examples directly in the prompt so Claude can infer the desired output format and imitate it on every request. Anthropic's prompt engineering guidance recommends examples as one of the most reliable ways to steer format, structure, and tone, and notes that they are more effective than abstract instructions alone. Because the examples travel with each request, no training run, extra infrastructure, or model change is needed, and the behavior stays easy to adjust by editing the examples.

Why the other options are wrong

A. A database of examples kept as team reference material never reaches the model, so it cannot influence the format of Claude's output.
B. Zero-shot prompting gives Claude no demonstrations, so it discards the labeled examples and makes consistent adherence to a specific format less reliable.
C. Training a custom model is unnecessary for a small set of examples and removes the flexibility of simply showing Claude the examples in the prompt.

Question 2

Your Claude application's content policy specifies categories of content it should not produce under any circumstance. The application currently has no mechanism to enforce this policy, and content matching these categories is appearing in the application's output.

How would you enforce the content policy?

Enhance the system prompt to contain explicit instructions for the categories to avoid, complete with examples of each category. Treat the strengthened prompt as the primary enforcement mechanism for the application's content policy across all responses.
Remove the content policy entirely and let any output reach users during normal operation, accepting whatever content the application produces in response to incoming traffic.
Add deterministic output filtering that checks responses against the content policy before they reach users.
Move enforcement to users by asking them to report content policy violations after the violating content has already reached them in the application's responses.

Show answer and explanation

Correct answer: C. Add deterministic output filtering that checks responses against the content policy before they reach users.

A policy that must hold under any circumstance needs a check that does not depend on the model's judgment, so deterministic output filtering applied before responses reach users is the right control. Prompt instructions guide Claude but cannot guarantee compliance, while a filter or classifier on the output enforces the rule every time and can block or replace violating content. Anthropic's guardrail guidance likewise recommends screening and post-processing of outputs as a layer on top of prompting, and this layer also gives the team a record of what was blocked.

Why the other options are wrong

A. A strengthened system prompt improves the odds of compliance but is probabilistic, so on its own it cannot guarantee that prohibited content never appears.
B. Removing the policy abandons the requirement entirely and lets the prohibited content continue to reach users.
D. Relying on user reports only finds violations after the harm has occurred and shifts enforcement onto the people the policy is meant to protect.

Question 3

A new Claude model release includes performance improvements for several reasoning tasks but has changed the format of its responses to system prompts that use multi-section instructions. Your application uses multi-section system prompts heavily. Initial evaluation on the application's actual workload shows the new model performs 8 percent better on reasoning tasks but produces malformed output on roughly 3 percent of requests because of the format change. The team is debating whether to upgrade.

How would you decide?

Upgrade and add a downstream validation step that catches the 3 percent malformed output before it reaches users, treating the validation step as the team's mitigation for the format change.
Adapt the application's system prompt to the new model's format expectations and re-evaluate, then upgrade only if the adapted prompt eliminates the malformed output while preserving the reasoning improvements.
Stay on the previous model permanently to avoid the malformed output rate and any future format changes that subsequent model releases might introduce in the application.
Upgrade immediately, because the 8 percent reasoning improvement outweighs the 3 percent malformed output rate across the application's typical request distribution.

Show answer and explanation

Correct answer: B. Adapt the application's system prompt to the new model's format expectations and re-evaluate, then upgrade only if the adapted prompt eliminates the malformed output while preserving the reasoning improvements.

A format change in how a new model reads multi-section system prompts is usually something prompt adaptation can fix, so the sound approach is to adjust the prompt to the new model, then re-run the evaluation on the application's real workload. The upgrade should proceed only if the malformed output is eliminated and the reasoning gains remain. Anthropic's migration guidance recommends testing prompts against the new model and tuning them, because prompts written for one model often need small changes to get the best behavior from another.

Why the other options are wrong

A. Catching bad output downstream treats the symptom while leaving roughly 3 percent of requests failing and adding retry cost and latency, when the cause may be fixable in the prompt.
C. Staying on the previous model permanently gives up the reasoning gains and eventually runs into the model's deprecation and retirement schedule.
D. Upgrading immediately ignores that malformed output breaks the application's responses, and a reasoning gain does not offset requests that fail outright.

Question 4

Your team's Claude application has been in production for a year, and the team has decided to formalize its testing strategy. Currently, the team writes ad-hoc tests for individual features but has no overall testing approach.

What testing approach would you formalize?

Adopt a test-driven development practice where unit tests are written before each feature is implemented and must pass before code is merged.
Define unit tests for individual functions, integration tests for the Claude integration, and end-to-end tests for critical user flows, applied consistently across the codebase.
Continue writing ad-hoc tests as features ship and introduce a peer review step to ensure each test adequately covers the feature being released.
Define a single testing approach that uses end-to-end tests and apply it consistently across all new features as they are added to the codebase.

Show answer and explanation

Correct answer: B. Define unit tests for individual functions, integration tests for the Claude integration, and end-to-end tests for critical user flows, applied consistently across the codebase.

A formal strategy for a production Claude application should cover several layers: unit tests for individual functions, integration tests for the code that calls Claude, and end-to-end tests for the user flows that matter most. Each layer catches a different class of failure, from logic errors in helper code to prompt, tool, and response-handling problems at the Claude boundary to broken user journeys. Applying all three consistently across the codebase replaces the ad-hoc approach with predictable coverage and makes regressions easier to locate when behavior changes.

Why the other options are wrong

A. Test-driven development describes when tests are written, not which kinds of tests exist, so it leaves out the integration and end-to-end coverage a Claude application needs.
C. Continuing ad-hoc tests with a review step keeps the absence of an overall approach and does not define what should be tested.
D. Using only end-to-end tests is slow and makes failures hard to diagnose, and it skips the focused checks that unit and integration tests provide.

Question 5

Your Claude application makes high-volume API calls during business hours and very few calls overnight. The team is concerned about staying within rate limits during peak hours and wants to understand how the Claude API enforces those limits.

How would you proceed?

Examine the peak-hour request patterns in your application logs and smooth traffic by distributing requests more evenly across the business-hours window.
Assess the average payload size of current API calls and consolidate requests where possible to reduce the total number of calls made during peak hours.
Review the API documentation for streaming endpoints and evaluate whether migrating peak-hour calls to streaming reduces exposure to rate limit enforcement.
Identify the rate limits, design the application to stay within them during peak hours, and use exponential backoff when limits are reached.

Show answer and explanation

Correct answer: D. Identify the rate limits, design the application to stay within them during peak hours, and use exponential backoff when limits are reached.

The first step is to learn what limits apply: Anthropic sets requests per minute, input tokens per minute, and output tokens per minute by usage tier, and enforces them with a token bucket that replenishes continuously. The application should be designed to stay within those limits during peak hours, and when it still receives a 429 response it should back off exponentially, honoring the retry-after header. This addresses the real constraint directly instead of guessing at traffic changes that may not affect the enforced limits.

Why the other options are wrong

A. Smoothing traffic can help, but doing it without first identifying the actual limits is guesswork and gives no plan for what to do when a 429 response arrives.
B. Consolidating requests by payload size misreads the limits, which count requests and tokens separately, so fewer calls does not guarantee fewer tokens.
C. Streaming changes how a response is delivered, not how requests and tokens are counted against rate limits, so migrating to it does not reduce exposure.

Question 6

You are designing a Claude application that will require structured JSON output for downstream processing. The output schema is well-defined, and downstream systems will reject malformed JSON.

Your application design would ...

avoid structured output and use free-form text everywhere instead, on the grounds that free-form text is more flexible and handles edge cases better than structured schemas.
structure the prompt to request output in a schema that is described in plain English, with downstream systems parsing whatever shape Claude produces.
define a clear schema and structure the prompt to request output in that schema, with downstream systems handling any validation needed.
define a clear schema, structure the prompt to request output in that schema, and validate Claude's output against the schema before passing it downstream.

Show answer and explanation

Correct answer: D. define a clear schema, structure the prompt to request output in that schema, and validate Claude's output against the schema before passing it downstream.

When downstream systems reject malformed JSON, the design needs both a defined schema and a check that enforces it. Defining the schema and requesting it in the prompt makes valid output likely, and validating Claude's response against that schema before passing it downstream catches the rare failure so it can be retried or handled instead of breaking the pipeline. Anthropic also offers structured outputs for guaranteed schema conformance, but in either case the application should not assume that unchecked model output is valid.

Why the other options are wrong

A. Free-form text is harder to process reliably and does not meet the downstream requirement for a well-defined schema.
B. Describing the schema loosely in plain English and accepting whatever shape comes back invites inconsistent output that the downstream systems will reject.
C. Pushing validation onto downstream systems lets malformed output travel through the pipeline, where it causes failures instead of being caught at the boundary.

Question 7

Your Claude application produces good responses for typical inputs but struggles with edge cases. You have several labeled examples of edge-case inputs and the desired response for each. You want to use these examples to improve the model's handling of edge cases.

What is the best way to use these examples?

Embed the examples in a database for the model to find during inference.
Train a custom model on the edge-case examples and deploy that custom model in place of the team's current Claude integration.
Add the labeled edge-case examples to the prompt as few-shot examples so the model can learn the pattern.
Tell users to avoid submitting the edge-case inputs to the application by adding warnings in the application's user interface.

Show answer and explanation

Correct answer: C. Add the labeled edge-case examples to the prompt as few-shot examples so the model can learn the pattern.

Labeled input and desired-output pairs are exactly what few-shot prompting needs. Adding the edge-case examples to the prompt shows Claude the pattern for the hard inputs, and Anthropic's guidance describes examples as one of the most dependable ways to improve accuracy and consistency. This approach is quick to implement, costs nothing beyond the extra prompt tokens, and can be refined as new edge cases are found, without retraining or changing the user experience.

Why the other options are wrong

A. Storing examples in a database does nothing by itself, because the model sees them only if something retrieves them and places them in the prompt.
B. Training and deploying a custom model for a handful of examples is heavy and slow, and it replaces a simple prompt change with a large engineering effort.
D. Warning users away from the inputs leaves the weakness in place and degrades the application instead of improving how it handles those cases.

Question 8

The team is debating whether to build a new capability as a custom tool or to use an existing built-in tool that nearly covers the use case but lacks one specific feature.

How would you decide?

Review the built-in tool's documentation and assess whether its existing capabilities are sufficient to cover the use case without any modification or extension.
Identify whether the team has previously built similar custom tools and use those precedents to determine which approach is more consistent with the existing codebase.
Examine the custom tool option by scoping the implementation effort and determining whether the additional flexibility justifies the development and maintenance cost.
Evaluate whether the missing feature can be addressed by extending the built-in tool or warrants a custom tool, then choose accordingly.

Show answer and explanation

Correct answer: D. Evaluate whether the missing feature can be addressed by extending the built-in tool or warrants a custom tool, then choose accordingly.

The decision turns on the specific gap: whether the missing feature can be added by extending or configuring the built-in tool, or whether it is large enough to justify a custom tool. Evaluating that gap directly weighs the maintenance burden of new code against the value of the feature, and it favors reusing what already exists when that nearly covers the need. Making the choice only after that evaluation avoids both needless custom work and forcing a built-in tool to do something it cannot.

Why the other options are wrong

A. Checking only whether the built-in tool works unmodified ignores the stated situation, where it already falls short by one feature, and stops before considering extension.
B. Following precedent from earlier custom tools reflects past habit and consistency, not whether this particular gap warrants a new tool.
C. Scoping only the custom option looks at one side of the tradeoff and never tests whether extending the built-in tool would close the gap more cheaply.

Question 9

Your Claude agent's hooks are currently triggered for every action, which slows down the agent significantly even when actions pose no risk. The team wants to scope hooks more carefully.

How would you scope the hooks?

Replace hooks with system prompt instructions on the grounds that prompt instructions can produce the same enforcement effect that hooks produce on the agent's actions.
Scope hooks to only the high-risk actions, such as destructive operations or sensitive data access, and remove hooks from low-risk actions to balance safety with performance.
Disable all hooks while the team re-scopes them, treating the period of no hook enforcement as a temporary state during the re-scoping work.
Disable the agent during peak hours so the hook overhead does not slow the application down during the busiest periods of the day across the application's operation.

Show answer and explanation

Correct answer: B. Scope hooks to only the high-risk actions, such as destructive operations or sensitive data access, and remove hooks from low-risk actions to balance safety with performance.

Hooks run deterministic checks around tool calls, and Claude Code lets them be scoped with matchers on tool names, plus finer conditions on tool arguments. Limiting hooks to high-risk actions such as destructive operations or sensitive data access keeps the safeguards where they matter and removes the overhead from harmless actions. This preserves enforcement for the cases that could cause damage while restoring the agent's speed on routine work, which is the balance between safety and performance the team wants.

Why the other options are wrong

A. Prompt instructions guide behavior but are not deterministic, so they cannot provide the guaranteed enforcement that hooks do.
C. Disabling all hooks, even temporarily, leaves destructive and sensitive actions unprotected for the duration of the re-scoping work.
D. Turning the agent off at peak hours removes its availability when it is needed most and does not address the cause of the slowdown.

Question 10

You are running Claude Code as part of an automated continuous integration pipeline. The pipeline needs Claude Code to execute a set of well-defined tasks without prompting for confirmation, and the output needs to be captured for downstream processing.

How would you configure the pipeline?

Disable Claude Code's confirmation prompts globally across all environments so the pipeline runs without interruption from any prompt.
Run Claude Code in headless mode with the required permissions configured in settings.json and capture its output for downstream processing.
Replace Claude Code with a different tool that does not require any configuration to operate without confirmation prompts in the pipeline.
Run Claude Code in interactive mode and have a developer manually approve every confirmation prompt while the pipeline executes its tasks.

Show answer and explanation

Correct answer: B. Run Claude Code in headless mode with the required permissions configured in settings.json and capture its output for downstream processing.

Claude Code supports non-interactive use through its print mode, run with the -p flag, which suits automated pipelines. The permissions it needs can be pre-approved through allowed tool settings or rules in settings.json, so no confirmation prompt appears, and the output can be returned as plain text, JSON, or streaming JSON for downstream processing. This keeps the run scoped to the tools the tasks require, unlike removing safeguards wholesale, and it produces output that later pipeline steps can parse reliably.

Why the other options are wrong

A. Disabling confirmation prompts globally across all environments removes protection everywhere, instead of granting only the specific permissions the pipeline needs.
C. Replacing Claude Code abandons the requirement to use it, and any other tool would also need its own configuration for unattended operation.
D. Interactive mode with a person approving every prompt defeats the purpose of an automated pipeline and stalls whenever no one is present.

Question 11

You are building a Claude application that needs to maintain a persistent connection to a service that streams real-time updates. The team is unsure what communication pattern to use.

Which communication pattern would you use?

A single long HTTP request the server holds open indefinitely, with no standard websocket framing on the connection.
File-based communication where the service writes new updates to disk and the application polls the file system for changes.
A websocket, because websockets are designed for bidirectional, persistent, real-time communication between the client and the streaming service.
Repeated short-lived HTTP polling requests, where the application opens a new HTTP connection each time it checks for updates.

Show answer and explanation

Correct answer: C. A websocket, because websockets are designed for bidirectional, persistent, real-time communication between the client and the streaming service.

A websocket provides a single persistent connection that supports bidirectional, low-latency messaging, which makes it the standard choice when an application needs a persistent link to a service pushing real-time updates. Once the connection is established, either side can send data at any time without repeated handshakes, so updates arrive as soon as they occur. This avoids the overhead and delay of opening a new connection for each check.

Why the other options are wrong

A. A single long-held HTTP request without websocket framing gives only one-way delivery and is fragile when connections drop or proxies time out.
B. Polling the file system for changes is slow and awkward, and it does not provide a real-time connection between the application and a streaming service.
D. Repeated short HTTP polling adds latency and overhead, because each check opens a new connection and updates wait until the next poll.

Question 12

You have just shipped a new Claude-powered application to production. The development phase is complete, and the system is now in active use by internal teams. The next phase of work for this system is ...

operating and maintaining the system, including monitoring, responding to issues, and planning evolution.
handing the system over to a separate operations team that will manage it independently of the development team going forward.
retiring the system, since shipping is the final lifecycle stage for any application that reaches production.
running a formal post-deployment review that assesses the development phase before the team does any further work on the system.

Show answer and explanation

Correct answer: A. operating and maintaining the system, including monitoring, responding to issues, and planning evolution.

Shipping to production is not the end of the lifecycle. A live Claude application needs ongoing operation and maintenance: monitoring quality, cost, and latency, responding to incidents and regressions, and planning how prompts, models, and features evolve as usage grows and as models change. Because model behavior is non-deterministic and user inputs shift over time, problems surface only after real traffic arrives, so the team that built the system must stay accountable for how it performs. Operations, monitoring, and iteration are the next phase of work.

Why the other options are wrong

B. Handing the system to a separate team removes the builders' knowledge from day-to-day operation and is not the defining next phase.
C. Shipping is not the final stage, because a production system continues to need monitoring and improvement.
D. A review of the development phase is optional and does not describe the ongoing work a live system requires.

Question 13

Your team uses Claude Code across multiple repositories. You want the team's rules and general coding standards to apply to all repositories, and other rules to apply only to specific repositories. The team is currently duplicating instructions across every repository's CLAUDE.md file.

How would you address this?

Use a CLAUDE.md hierarchy that scopes general standards broadly and project-specific context within each repository's local CLAUDE.md.
Stop using CLAUDE.md altogether and ask each developer to configure Claude Code manually for each project they work on.
Move all instructions to a separate documentation site that developers consult during Claude Code sessions across all repositories.
Use a single repository's CLAUDE.md as the central source of truth and link to it from every other repository's CLAUDE.md file.

Show answer and explanation

Correct answer: A. Use a CLAUDE.md hierarchy that scopes general standards broadly and project-specific context within each repository's local CLAUDE.md.

Claude Code loads CLAUDE.md files from several scopes: a user-level file that applies across projects, files in a project root and its parent directories, and files in subdirectories. Files are combined, so broadly applicable standards can live in a shared higher-level location while repository-specific rules stay in each repository's local CLAUDE.md. A file can also import other files. This layering removes the duplication across repositories while keeping each repository's context specific to it.

Why the other options are wrong

B. Abandoning CLAUDE.md removes the persistent shared instructions that the memory system exists to provide and pushes inconsistent manual setup onto each developer.
C. An external documentation site is not loaded into Claude Code sessions automatically, so the instructions would not reliably reach the model.
D. Linking to one repository's file creates a fragile dependency and does not use the scoped loading that CLAUDE.md files support.

Question 14

You are writing a system prompt for a Claude application that needs to produce output in a specific JSON shape. The downstream system will reject any output that does not match the schema. Your prompt would need to ...

omit any reference to the format and rely on a post-processing step in the application to reshape Claude's output.
instruct Claude to return JSON sometimes and free text other times so the application's output captures both formats.
include explicit constraints describing the required JSON schema and an instruction to produce only output matching that schema.
instruct Claude to use whichever output format it considers most appropriate for each request the application handles.

Show answer and explanation

Correct answer: C. include explicit constraints describing the required JSON schema and an instruction to produce only output matching that schema.

When a downstream system rejects anything that does not match a schema, the prompt must state the required format explicitly: describe the JSON schema, give the field names and types, and instruct Claude to return only output matching it. Clear, specific format instructions, ideally with an example, are the basic way to get consistent structure from prompting. Where strict guarantees are needed, structured outputs add schema enforcement on top.

Why the other options are wrong

A. Leaving the format out gives Claude nothing to follow and forces fragile reshaping of unpredictable output.
B. Alternating between JSON and free text guarantees that some responses will be rejected by the downstream system.
D. Letting Claude choose the format produces inconsistent output that cannot satisfy a fixed schema.

Question 15

You are designing a Claude application that maintains user sessions across multi-turn conversations. The product team has asked how the application will handle session lifecycle: when sessions should expire, how state is reset, and how the application avoids carrying stale context into new conversations.

How would you design session lifecycle?

Define explicit session expiration rules but rely on users to start new conversations when they want fresh context, with no automatic reset triggers in the application.
Define explicit session expiration rules, state reset triggers, and rules for starting fresh sessions so stale context does not leak into new conversations.
Define a single short session timeout that applies across all conversations and treat the timeout as the application's complete session lifecycle mechanism.
Define state reset triggers tied to specific application events but apply them across all sessions globally, with no per-session expiration rules.

Show answer and explanation

Correct answer: B. Define explicit session expiration rules, state reset triggers, and rules for starting fresh sessions so stale context does not leak into new conversations.

The Messages API is stateless, so the application owns conversation state and decides what goes into each request. A sound lifecycle design therefore defines when a session expires, what events reset its state, and the rules for beginning a fresh session. Together these ensure that old context, such as earlier topics or outdated facts, does not leak into a new conversation, which would waste tokens and could mislead the model. Covering all three elements makes the behavior predictable and testable.

Why the other options are wrong

A. Depending on users to start new conversations leaves no automatic reset, so stale context persists whenever users do not act.
C. A single short timeout cannot reflect different conversation types and ignores event-based resets, so it is only one part of a lifecycle.
D. Global reset triggers with no per-session expiration leave idle sessions open indefinitely and cannot manage individual session lifetimes.

Question 16

Your enterprise has a contract with AWS that requires Claude API calls to flow through Amazon Bedrock rather than the direct Anthropic API. Your team is building a new Claude application and is unfamiliar with this constraint.

How would you build the application?

Build two parallel implementations of every call, one for the direct Anthropic API and one for Bedrock, and pick the faster one at runtime.
Configure the application to invoke Claude through the Bedrock-compatible API path while keeping the application's logic provider-agnostic.
Build the application against the direct Anthropic API and ignore the contractual requirement to route Claude calls through Amazon Bedrock.
Build the application against the direct Anthropic API now and migrate to Bedrock in a follow-up release once the team has more experience with the Bedrock API.

Show answer and explanation

Correct answer: B. Configure the application to invoke Claude through the Bedrock-compatible API path while keeping the application's logic provider-agnostic.

Anthropic's client SDKs support Amazon Bedrock directly, through Bedrock clients such as AnthropicBedrock in Python and the Bedrock SDK package for TypeScript. The team can therefore send every Claude call through Bedrock to satisfy the contract while writing application logic against the same Messages-style interface. Keeping the logic provider-agnostic means only client construction and model identifiers change by provider, which satisfies the requirement without duplicating the application.

Why the other options are wrong

A. Maintaining two parallel implementations and choosing at runtime would send some calls outside Bedrock, violating the contract, and doubles maintenance.
C. Ignoring the contractual routing requirement creates a compliance breach regardless of how well the application works.
D. Deferring Bedrock to a later release means early production traffic would break the contract, and the client SDKs make starting on Bedrock straightforward.

Question 17

You are choosing between using STDIO-based communication and HTTP-based communication for an MCP server. The server will be invoked by a Claude Code session running locally.

Which communication pattern would you use?

HTTP on the grounds that HTTP is preferable to STDIO in any context the application might encounter during normal operation.
HTTP polling against the MCP server, treating HTTP as a substitute for the standard MCP communication patterns.
STDIO and HTTP simultaneously for redundancy, with the team running two communication patterns at the same time across Claude Code sessions.
STDIO because STDIO is well-suited to local process communication and avoids unnecessary network setup.

Show answer and explanation

Correct answer: D. STDIO because STDIO is well-suited to local process communication and avoids unnecessary network setup.

For an MCP server invoked by a Claude Code session on the same machine, the STDIO transport is the natural choice: Claude Code launches the server as a local process and exchanges messages over standard input and output. This needs no network port, authentication setup, or hosting. HTTP is the recommended transport for remote servers, which is a different situation from a local process.

Why the other options are wrong

A. HTTP is suited to remote servers, and claiming it is preferable in every context ignores the simplicity of local STDIO.
B. Polling over HTTP is not a standard MCP communication pattern and adds complexity without benefit.
C. Running both transports at once adds operational overhead and provides no redundancy benefit for a single local session.

Question 18

A teammate has submitted a pull request that adds a Claude-powered feature to your service. The code works, but the prompt and model selection are hard-coded inline, error handling is missing, and there are no tests for the integration.

What would you request during code review?

Request changes that move prompt and model configuration to a configurable location, add error handling for Claude API failures, and add tests for the integration.
Request changes that move prompt and model configuration to a configurable location and add tests, treating the missing error handling as a follow-up release item.
Approve the pull request and add the missing pieces yourself in a follow-up commit so the teammate can move on to other work immediately.
Approve the pull request as-is, on the grounds that the feature works in the happy path and the missing pieces can be added in follow-up commits.

Show answer and explanation

Correct answer: A. Request changes that move prompt and model configuration to a configurable location, add error handling for Claude API failures, and add tests for the integration.

A production Claude feature needs three things the pull request lacks. Prompts and model identifiers belong in configuration so they can be changed, versioned, and tested without redeploying code. Calls to the Claude API can fail through rate limits, timeouts, and overloaded responses, so error handling is required. Non-deterministic behavior also calls for tests of the integration. Requesting all three changes before merging holds the feature to a production standard.

Why the other options are wrong

B. Deferring error handling leaves the feature exposed to API failures in production, which is a core requirement rather than a follow-up item.
C. Approving first and fixing later by yourself skips the review's purpose and leaves unready code in the main branch in the meantime.
D. A working happy path is not enough, since missing error handling and tests are the risks that show up in production.

Question 19

You are building a Claude application that needs to deliver model output to end users as it is generated, instead of waiting for the full response to complete. The Claude API mechanism you would use is ...

structured JSON output, which delivers responses only after the model has finalized the JSON shape across the entire response.
prompt caching, which speeds up the cost profile of future requests and does not affect the delivery timing of the first response.
streaming responses, which deliver tokens incrementally as the model generates them so users see output progressively.
the batch API, which delivers full responses after a delay suitable for non-interactive workloads.

Show answer and explanation

Correct answer: C. streaming responses, which deliver tokens incrementally as the model generates them so users see output progressively.

Setting stream to true on a Messages API request returns the response incrementally as server-sent events, so text arrives as the model generates it. The client SDKs wrap this in streaming helpers. An application can display tokens progressively as they arrive, which lowers perceived latency for interactive experiences because users see output begin right away instead of waiting for the full response to finish.

Why the other options are wrong

A. Structured JSON output constrains the format of the response and is not a mechanism for delivering partial output as it is generated.
B. Prompt caching reduces the cost and latency of repeated prompt content but does not deliver output progressively.
D. The batch API processes requests asynchronously and returns results later, which suits non-interactive work rather than live display.

Question 20

You are setting up the configuration management approach for a new Claude Code project. Your team will use CLAUDE.md files and settings.json files to control behavior, and you want to make sure changes are tracked and reviewable. The configuration management approach would ...

version-control CLAUDE.md alongside the project's source code and settings.json files in a separate repository from the project's source code.
version-control CLAUDE.md and settings.json files alongside the project's source code, with changes reviewed through standard pull request workflows the team applies.
duplicate CLAUDE.md and settings.json files in multiple repositories to provide redundancy, on the grounds that a single source of truth is risky for project configuration.
version-control CLAUDE.md and settings.json files in a separate repository from the project's source code, so configuration evolves independently from the application code over time.

Show answer and explanation

Correct answer: B. version-control CLAUDE.md and settings.json files alongside the project's source code, with changes reviewed through standard pull request workflows the team applies.

Claude Code's documentation describes the shared project settings file, .claude/settings.json, as settings the team checks into version control, and project CLAUDE.md files are shared the same way. Keeping both files in the project repository means every developer gets the same configuration and every change is tracked in history. Routing changes through the team's normal pull request workflow makes configuration changes reviewable, so permissions and instructions evolve with the code they affect.

Why the other options are wrong

A. Splitting CLAUDE.md and settings.json across two repositories separates related configuration and weakens consistent review.
C. Duplicating the files across repositories invites drift between copies and removes a single authoritative version.
D. Moving the files to a separate repository detaches configuration from the code it governs and from the project's own review workflow.

Question 21

A teammate has asked why your Claude application sometimes produces a response that includes the prompt text repeated back, and other times produces a response with the prompt text rephrased. They suspect a bug in the application's request construction.

How would you respond?

Explain that LLMs generate output token by token, and variation in how prompt content appears in output is a property of generation, not a bug in request construction.
Confirm that the variation is a bug in the application's request construction and start investigating which part of the application is producing the inconsistent prompt text.
Tell the teammate that the variation depends on which Claude model serves the request, and recommend pinning the application to a single model version to make the output behavior consistent.
Tell the teammate that the variation is caused by the application sending two different prompts on different runs and propose a code change that pins the system prompt to a single version.

Show answer and explanation

Correct answer: A. Explain that LLMs generate output token by token, and variation in how prompt content appears in output is a property of generation, not a bug in request construction.

Claude generates text one token at a time by sampling from a probability distribution, so the same prompt can lead to repeated wording in one run and a paraphrase in another. That variation is a normal property of generation. It does not indicate that the request was built incorrectly, and the right response is to explain this before investigating, then use clear instructions on whether to quote or restate content if a consistent behavior is wanted.

Why the other options are wrong

B. Declaring a bug without evidence misreads normal sampling behavior and sends the team investigating a defect that does not exist.
C. Pinning a model version can reduce changes across releases but does not remove the sampling variation seen between runs.
D. Nothing indicates that different prompts were sent, so a code change to pin the system prompt would address a problem that was not shown to exist.

Question 22

Your Claude application's prompt was written months ago and has not been updated. The team has discovered through evals that the prompt produces good results on common cases but underperforms on a specific category of inputs that has grown in volume.

How would you respond?

Replace the prompt with a new one aligned to the underperforming category, treating any common-case performance change as a known tradeoff.
Tell users to avoid the underperforming category by adding warnings in the application's user interface about handled inputs.
Iterate on the prompt to address the underperforming category, validate the change with evals, and continue refining as needed.
Add the underperforming category to a separate Claude application with its own prompt so the original prompt does not change.

Show answer and explanation

Correct answer: C. Iterate on the prompt to address the underperforming category, validate the change with evals, and continue refining as needed.

Prompt quality should be managed through an evaluation-driven cycle. When monitoring shows a growing category of inputs underperforming, the right response is to refine the existing prompt for that category, for instance with targeted instructions or examples, and then run the evaluation suite to confirm the fix works without hurting the common cases. Evals make the effect of each change measurable, and the team can keep iterating until performance on both the new and the existing categories meets the bar.

Why the other options are wrong

A. Replacing the whole prompt and accepting common-case changes as a tradeoff risks regressing the majority of traffic without measuring it.
B. Warning users away from the category shifts the burden to them and leaves the underlying weakness unaddressed.
D. Splitting the category into a separate application adds maintenance cost and avoids improving the prompt, which can be tuned and tested directly.

Question 23

You are designing a Claude application that will process customer support tickets in two stages: a triage stage that classifies tickets and a response stage that drafts replies. The team is debating whether to use a single Claude call that handles both stages or separate Claude calls for each stage.

How would you structure the application?

Use separate Claude calls for triage and response, because each stage has distinct inputs, outputs, and success criteria that benefit from focused prompts.
Use a single Claude call for triage and then use a non-Claude rule-based system for response generation, on the grounds that rule-based systems are more reliable for drafting replies.
Use multiple Claude calls in parallel that each draft a complete ticket reply, then have a fourth Claude call select the best one to send to the customer.
Use a single Claude call for both stages, on the grounds that a single call is cheaper than multiple calls in any production Claude application setup.

Show answer and explanation

Correct answer: A. Use separate Claude calls for triage and response, because each stage has distinct inputs, outputs, and success criteria that benefit from focused prompts.

Anthropic's guidance on building effective agents notes that models generally perform better when each consideration gets its own call, which allows focused attention on each aspect. Triage is a classification task with a constrained label output, while response drafting is open-ended generation with different inputs, tone requirements, and quality criteria. Separate calls let each stage have a focused prompt, its own evaluation set, and the freedom to use a different model, for example a smaller and faster one for classification. Failures are also easier to isolate, because you can tell whether a bad reply came from a misclassification or from the drafting step.

Why the other options are wrong

B. Rule-based systems cannot draft natural, context-aware replies reliably, so replacing Claude at the stage that most needs language generation is a poor design.
C. Drafting several complete replies and adding a fourth call to choose one multiplies cost and latency and does nothing to separate the triage and response stages.
D. A single call is not cheaper in every production setup, and merging unrelated stages into one prompt blurs the success criteria and makes each stage harder to tune.

Question 24

Your Claude application has multi-step workflows where each step's output is needed only briefly before the agent moves on. The cumulative tool output is filling the context window with content that is no longer relevant.

How would you handle the accumulating tool output?

Apply prompt caching to the accumulated tool outputs so the application does not re-pay for the older content on each subsequent step.
Keep every tool output in the context indefinitely so the agent has the full record of every step it has executed during the workflow.
Switch to a smaller Claude model that processes context more efficiently and treat any quality loss as a tradeoff for the cost reduction.
Apply tool output pruning to remove tool outputs that are no longer needed by later steps in the workflow.

Show answer and explanation

Correct answer: D. Apply tool output pruning to remove tool outputs that are no longer needed by later steps in the workflow.

When tool outputs are needed only briefly, the best fix is to remove them once they are no longer useful. Anthropic's context editing feature does this on the server by clearing the oldest tool results once the context passes a configured threshold and replacing them with placeholder text, while keeping a set number of recent tool uses. This keeps the context window focused on relevant content, lowers token usage, and avoids degraded performance from irrelevant material that would otherwise accumulate across steps.

Why the other options are wrong

A. Prompt caching lowers the cost of re-reading content but leaves the stale outputs in the context window, so the clutter remains.
B. Keeping every output indefinitely is exactly what fills the context window with content that is no longer relevant.
C. Switching to a smaller model trades away quality without removing the accumulated content that causes the problem.

That was 24 of 96.

The full Anthropic CCDV-F pack has all 96 questions, each with the answer, the explanation and why the other options are wrong, plus a questions-only copy for timed runs. US$39, paid once, with free monthly updates and a pass-or-your-money-back guarantee.

Get the full pack

Not ready yet? Get the first 48 free as one PDF by email. Get the Half Pack →