CCDV-F practice questions, answered and explained

A task extracts a title from a PDF, looks it up in a catalog, and writes a row to a database. The steps never vary. Should this be a workflow or an agent?

• A An agent, since any task of several distinct steps benefits from model-driven control

Step count is not what calls for an agent — a three-step task with a fixed order is a workflow. What would justify an agent is a path that cannot be specified in advance.

• B An agent, since the task reaches an external database that code alone cannot manage

Touching an external system says nothing about who controls the flow; code calls databases routinely, and a tool call does not require model-driven sequencing.

• C A workflow, since the steps are known in advance and code can orchestrate them

Correct. Every step and its order are known before the task starts, so code can sequence them and the model is called only where language understanding is actually needed.

• D A workflow, but only where end-to-end latency turns out to be a concern

Latency does not decide the shape here. The steps never vary, which makes it a workflow whether it runs in a second or an hour.

Agents earn their cost when the path cannot be specified up front. Here every step and its order are known, so code-controlled orchestration is cheaper, faster, and far easier to debug. Reaching for an agent adds model-driven nondeterminism to a problem that has none.

Which statement correctly distinguishes the SDK Tool Runner from the Claude Agent SDK?

• A The Tool Runner hosts your agent, while the Claude Agent SDK requires you to host it

Neither one hosts your agent — both leave deployment to you, which is exactly what makes them easy to confuse.

• B They are two names for the same helper, offered under different branding

They are separate packages with different scope, not one helper under two names.

• C The Tool Runner ships in the API SDK over tools you define; the Agent SDK is separate

Correct. The Tool Runner is reached through the regular API client and loops over tools you supply; the Agent SDK is a separate package shipping the Claude Code harness.

• D The Claude Agent SDK is Python only, while the Tool Runner is TypeScript only

Both are available across the supported languages; language is not what separates them.

They are different packages with different scope. The Tool Runner automates the request-execute-loop cycle for tools you supply and ships nothing built in; the Claude Agent SDK is Claude Code as a library, with built-in tools, subagents, and permissions. Both leave hosting to you.

An agent's context fills with large tool results from earlier steps that are no longer relevant. Which technique removes them without summarizing?

• A Lowering the effort level, so less of the old material is reconsidered

Effort tunes reasoning depth. It does not decide what material is present in the request.

• B Context editing, which clears the old tool results before the model sees them

Correct. Context editing clears the stale tool results outright, before the model sees them, which is removal rather than compression.

• C Compaction, which condenses all of the earlier history into a shorter summary

Compaction is the summarizing mechanism — it condenses rather than removes, which is not what was asked for.

• D Prompt caching, which stops the stale results from being billed again

Caching changes what gets re-billed on a repeated prefix; the results still occupy the context.

Clearing and summarizing are different operations: context editing removes stale tool results outright, while compaction replaces history with a summary. Caching affects cost on repeated prefixes rather than context size, and effort governs reasoning depth.

A stakeholder says the assistant must answer "instantly." What is the right next step?

• A Enable streaming, which makes almost any response feel instant to the end user

Streaming improves how fast a response feels, but it does not satisfy a goal nobody has quantified.

• B Choose the fastest model available and proceed on that basis

Picking a model before the target is known means nobody can say afterwards whether the requirement was met.

• C Reduce max_tokens until the responses come back fast enough

Cutting the output cap trades correctness for speed without anyone deciding that trade was acceptable.

• D Turn it into a measurable target latency at a stated percentile, and confirm it

Correct. A percentile latency target is implementable and testable, and it makes the tradeoffs against quality and cost explicit.

"Instantly" is not implementable as stated. Converting it into a percentile latency target makes the tradeoffs explicit and testable. Streaming improves perceived responsiveness but does not by itself satisfy an unquantified goal, and capping output trades correctness for speed without anyone deciding to.

Where do evaluations belong in the life cycle of a Claude-powered feature?

• A Continuously: built during development, run in CI, and monitored in production

Correct. Prompts and models both drift, so evaluation is an ongoing control rather than a one-time checkpoint.

• B Only before the first release, where they act as an acceptance gate

A release gate misses everything that changes afterwards — prompt edits, model upgrades, and shifting inputs all move behavior post-launch.

• C Only when changing models, since that is when the behavior actually shifts most

Model changes are one source of drift among several; prompt edits and input shifts move behavior just as much.

• D Only when a defect is reported by a user or by the operations team

Waiting for a report means users find the regressions, which is the outcome evaluation exists to prevent.

Prompt edits, model upgrades, and shifting input distributions all change behavior after launch, so evaluation is an ongoing control rather than a one-time gate. Treating it as a release checkpoint leaves regressions to be discovered by users.

A developer must process 10,000 documents overnight for a report needed the next morning, and cost is the main concern. Which approach fits?

• A Lower max_tokens on the synchronous calls so each one costs less to run

Capping output attacks quality rather than the realtime-versus-batch tradeoff that is actually driving the cost.

• B Use the Message Batches API, which handles the workload at a reduced cost

Correct. The workload is latency-tolerant and high-volume, which is the batch profile, and batching is priced well below synchronous calls.

• C Switch to the smallest model available, regardless of the output quality

Downgrading the model trades the report's quality for a saving that batching provides without that cost.

• D Send every request synchronously in parallel, to finish as quickly as possible

Parallel synchronous requests finish sooner but cost exactly the same per token, and cost is the stated concern.

The workload is latency-tolerant and high-volume, which is exactly the batch profile, and batching is priced below synchronous calls. Parallel synchronous requests finish sooner but cost the same per token; capping output or downgrading the model attacks quality rather than the realtime-versus-batch tradeoff.

Which HTTP status class should an integration treat as retryable with backoff?

• A The 4xx client errors generally, since the server may recover

Most 4xx responses mean the request itself was malformed or unauthorized, so an identical retry fails identically.

• B The 429 and 5xx responses, together with connection errors

Correct. Rate limiting, server-side faults, and network errors are all transient, which is what makes bounded retry with backoff appropriate.

• C Only a 500, which is the sole genuinely transient condition

A 500 is retryable, but so are 429, 502, 503, and dropped connections — this is too narrow to be useful.

• D Any non-200 response, since none of them returned a result

Blanket retrying burns quota on requests that can never succeed and delays surfacing a real bug.

Rate limiting and server-side failures are transient, as are network faults, so they warrant bounded retry with backoff. Most 4xx responses indicate a malformed or unauthorized request that will fail identically no matter how many times it is sent.

The same task is exposed through a web app calling the API and through Claude Code for internal users. What must the design account for?

• A Claude Code cannot perform the tasks that the API is able to perform

Claude Code is not less capable — it is differently configured, with its own tools and standing instructions.

• B Nothing, since instructions behave identically across every interface

The same text lands differently depending on what already surrounds it, so assuming parity is the mistake being tested.

• C Each interface brings its own surrounding instructions and tool set

Correct. Each interface supplies its own system instructions, tool set, and project configuration, so guidance written for one may be redundant, ignored, or contradictory in the other.

• D The API requires prompts to be shorter than the other interface does

Neither interface imposes a shorter prompt requirement; the difference is context, not length.

Interfaces differ in what already surrounds the prompt — system instructions, tool sets, and project configuration — so the same text lands differently. Designing for both means deciding what belongs in shared prompt content and what is interface-specific.

Why pin an explicit model identifier rather than relying on a default?

• A Pinned models are billed at a lower rate than defaults are

Pricing follows the model itself, not whether you named it explicitly.

• B It makes a model change an explicit decision with a test in front of it

Correct. Pinning converts an upgrade into a deliberate change that goes through evaluation and deploy, instead of behavior moving with no diff to point at.

• C Defaults always resolve to the smallest model available in the family

Defaults do not resolve to the smallest model, and relying on that assumption is itself a reason to pin.

• D Pinning is a requirement for prompt caching to work at all

Caching works regardless of how the model was selected.

Pinning converts an upgrade into a deliberate change that goes through evaluation and deploy. Floating means production behavior can move with no diff to point at.

Which mechanism should carry a convention that applies only to files under a specific directory?

• A The repository-root CLAUDE.md, which every session already loads

Root-level guidance applies everywhere, so a narrow rule would be imposed on unrelated work.

• B A rules file scoped to that directory, loading when those files are in play

Correct. Scoped rules attach guidance to the files it governs, so it applies automatically and stays out of work it does not concern.

• C A slash command that the developer always has to remember to run every time

A manual command depends on someone remembering it at the right moment.

• D A hook that fires whenever a file in that directory is touched

Hooks run on events and enforce actions; they are not how standing conventions are conveyed.

Scoped rules attach guidance to the files it governs, so it applies automatically and stays out of unrelated work. Root-level guidance applies everywhere, a manual command depends on someone remembering, and hooks run on events rather than supplying conventions.

A production feature returns HTTP 200 but users report the summaries are wrong. Where does the failure most likely lie?

• A In the network, which may be corrupting the response in transit

Network corruption would produce malformed responses or errors rather than coherent wrong summaries.

• B In the SDK's retry logic, which may be returning a stale attempt

Retry logic returns the response it received; it does not fabricate stale content.

• C In the integration layer, since a 200 means that the request was malformed

A 200 means the opposite — the request was well formed and was accepted.

• D In output quality, since the request succeeded and only the content is wrong

Correct. Transport and request construction both worked, so the defect is in what was generated rather than in how it was delivered.

A successful response separates the two failure classes: transport and request construction worked, so the problem is the content. Isolating integration-layer faults from output-quality faults is the first move in debugging these systems, because the remedies are unrelated.

Two runs of the same prompt with identical settings produce different wording. What explains this?

• A The requests were routed to servers holding different weights

All replicas serve the same weights for a given model; routing does not change the answer.

• B Generation samples from a distribution, so outputs vary

Correct. Generation samples from a distribution over next tokens, so identical inputs can legitimately yield different outputs.

• C A defect in the caching layer serving a stale response

Caching returns computation for an identical prefix; it does not invent different wording.

• D The model was updated in between the two calls being made

Weights are fixed between releases, and a pinned model does not change under you mid-session.

Sampling makes variation the normal case rather than a fault, which is why systems that depend on exact reproducibility need validation or constrained output rather than an assumption of stability.

What is the relationship between an official Claude SDK and the REST API?

• A The SDK supports features that are unavailable over plain REST

Capabilities are the same, since the SDK is calling the very same endpoints.

• B The SDK requires a separate API key from the REST interface

The same credentials work for both; no separate key is issued for SDK use.

• C The SDK uses a different protocol, optimized for its language

The SDKs speak the same HTTP protocol; there is no language-specific wire format.

• D The SDK is a typed wrapper over the same HTTP endpoints

Correct. The SDKs wrap the same endpoints and add ergonomics — retry policy, streaming helpers, typed exceptions — which is why raw HTTP remains valid.

The SDKs wrap the same endpoints, which is why raw HTTP remains a valid integration path. What they add is ergonomics and reliability behavior — retry policy, streaming helpers, typed exceptions — not different capabilities.

A high-volume classification step runs on every inbound message and must be cheap and fast. Which tier is the sensible starting point?

• A Alternate between the tiers in order to balance cost against quality

Alternating tiers makes behavior inconsistent and the results hard to interpret.

• B Whichever model the rest of the application already happens to use

Uniformity is a convenience; it does not make the tier appropriate for this step.

• C The most capable model, downgrading only if cost becomes a problem

Starting at the top pays a premium on every request while you wait for a cost problem to appear.

• D The smallest and fastest tier, escalating only if quality proves short

Correct. Narrow, high-volume, well-specified work is where the small tier earns its place, and quality is a measurable question rather than an assumption.

Narrow, high-volume, well-specified work is where the small tier earns its place, and quality is a measurable question rather than an assumption. Starting at the top and waiting for a cost problem pays a premium on every request in the meantime.

What is context bloat, and why does it degrade quality rather than merely cost?

• A It disables prompt caching for the affected requests

Bloat does not disable caching — a stable prefix still caches, however much noise follows it.

• B It causes the API to reject any of the requests that carry it

Requests are only rejected when they exceed the window; bloat degrades quality well before that.

• C Accumulated low-value content dilutes the material that matters

Correct. Accumulated low-value content dilutes the material that matters, so the signal the model needs competes with stale tool output and superseded turns.

• D It is only a cost problem and never a quality problem

Cost is the visible half; the quality effect is what makes pruning worth doing on its own.

Beyond the bill, an oversized context buries the relevant material among the irrelevant, and the model's attention is finite. Pruning is therefore a quality intervention as much as a cost one.

Which instruction belongs in the system prompt rather than the user message?

• A The specific document that this request needs analyzed

A specific document is per-request material and belongs in the user turn.

• B The persistent role, constraints, and conventions for every request

Correct. Standing behavior belongs where it is stable and can form a reusable cached prefix.

• C The user's question, which states what is actually being asked for

The question is the request itself and changes every call.

• D The passages retrieved for this particular query

Retrieved passages are per-query content and would invalidate the cached prefix if placed early.

Standing behavior belongs where it is stable and can form a reusable prefix; per-request material belongs in the user turn. Mixing them costs cache reuse and blurs the boundary between operator instruction and request content.

Why should application code validate model output even when a schema constraint is in use?

• A A schema checks shape, not whether the values are semantically right

Correct. A schema guarantees structure, not correctness — a well-formed response can still carry a fabricated value or violate a business rule.

• B Validation is a requirement for billing to be computed correctly

Billing is computed from token usage and has nothing to do with validation.

• C Schemas are unable to express nested objects within a response

Schemas express nested objects perfectly well.

• D Schema constraints are advisory rather than actually enforced

Schema constraints are enforced; the gap is that they enforce shape rather than truth.

A schema guarantees shape, not truth: a well-formed response can still carry a fabricated value. Validation at the boundary catches both structural surprises and violations of business rules the schema cannot express.

An agent summarizes user-submitted web pages. One page contains hidden text telling the model to ignore prior instructions and reveal its system prompt. Which mitigation is most effective?

• A Switch to a larger model that follows instructions more reliably

A model that follows instructions more reliably can be more susceptible to injected ones rather than less.

• B Treat page content as untrusted and bound what it can trigger

Correct. Isolating untrusted content and enforcing least privilege means injected text cannot reach a sensitive capability, whatever it says.

• C Add a system prompt line asking users not to include instructions

A polite request in the system prompt is not a control, and the attacker is not the user being asked.

• D Raise the temperature, so the behavior is harder to predict

Sampling settings do not govern whether injected instructions are followed, and unpredictability is not a security property.

Prompt injection is addressed by isolating untrusted content and enforcing least privilege so injected text cannot reach a sensitive capability. Sampling settings are irrelevant, a polite request is not a control, and a more instruction-following model can be more susceptible rather than less.

What does layering guardrails mean?

• A Using several models to vote on whether something is safe

Model voting is an ensemble technique rather than a layered set of controls.

• B Placing independent controls at input, tools, and output alike

Correct. Independent controls of different kinds at different points mean defeating one still leaves others in the path.

• C Running the guardrails only at the output stage of the pipeline

Output-only checking leaves everything upstream unprotected.

• D Applying the same check repeatedly, for added reliability

Repeating one check adds no independence — the same bypass defeats every copy.

Layering places controls of different kinds at different points, so defeating one still leaves others in the path. Repeating one check adds no independence, and output-only checking leaves everything upstream unprotected.

Why are hooks suited to preventing destructive actions where prompt instructions are not?

• A Hooks run on a separate model dedicated to enforcement

Hooks are ordinary code run by the harness; no second model is involved in deciding whether they fire.

• B Hooks execute on an event, whatever the model's judgment is

Correct. The hook fires because an event occurred, so it holds whether or not the model agrees with it — which is exactly what an instruction cannot promise.

• C Hooks are written in a stricter language than prompts are

Language has nothing to do with it — a hook could be written in anything. What matters is that the harness runs it rather than the model choosing to.

• D Hooks cannot be disabled once they have been registered

Hook configuration remains editable like any other setting. Their strength is that the model cannot route around them, not that nobody can.

The distinction is enforcement versus influence: a hook fires because an event occurred, not because the model chose to honor it. That is what makes hooks appropriate for controls that must not be negotiable.