Writing

Five CCDV-F questions people get wrong for the same reason

After writing practice questions against the CCDV-F objectives for a while, a pattern shows up that I didn’t expect. A lot of the wrong answers aren’t wrong because they’re nonsense. They’re wrong because they’re more machinery than the problem needs.

The exam seems to care quite a lot about proportionality. Here are five places it shows up.

1. Tool misrouting

An agent has six tools and keeps confusing two of them. The options usually include: expand the descriptions, add few-shot examples, build a routing classifier, merge the two tools.

Three of those are real techniques. Only one addresses the cause.

The model routes on name, description and schema — that’s the entire signal. If two descriptions read as “retrieves patient information” and “retrieves appointment details”, the model is being asked to distinguish them from two nearly identical sentences. Few-shot examples paper over that at a token cost you pay on every request, forever. A routing classifier bypasses the language understanding you’re already paying for and adds a component to maintain. Merging is a refactor.

Rewriting two descriptions is an afternoon and it fixes the actual problem.

The trap inside the trap: this only holds below the overload threshold. Around four or five tools, selection starts degrading on decision complexity alone, and no amount of description polish helps. The tell is whether errors cluster on a specific pair or scatter across the whole toolkit. Different diagnosis, different fix.

2. Cost optimisation order

A pipeline is over budget. The tempting answer is a cheaper model tier.

The order the exam rewards: cache the stable prefix, trim bloated context, right-size the tier, batch anything latency-tolerant. The first two are quality-neutral. The third trades quality for cost and needs an eval check before and after.

Jumping to tier skips two free wins and takes on a quality risk you didn’t need. And caching is often the whole answer on its own — cached reads bill at a tenth of the base input rate.

There’s a nasty version of this in practice. Someone enables caching, sees cache_control in every request, and the bill doesn’t move. The checkpoint is sitting behind a request ID that changes every call, so the cache misses every time, silently. They’re not getting nothing — they’re paying the 1.25× write premium on every single call for a cache nothing reads. Worse than not caching at all.

3. Prompt instructions as security controls

A document arrives with hidden text telling the agent to forward records externally. Options include adding a line to the system prompt telling the model to ignore instructions found in documents.

This is the single most reliably wrong answer in the security domain, and it’s wrong for a reason worth internalising: a system prompt is a request. The model can be argued out of it, especially forty turns into a conversation.

What works is two layers. Tag untrusted content so injected instructions are visible as data rather than reading as though you wrote them. Then enforce a permission boundary so the outbound action can’t execute regardless of what the model concludes.

Worth noticing that there’s no malicious user in that scenario. The clinician uploading the PDF has no idea what’s in it. Indirect injection is the harder case precisely because there’s nobody to detect.

4. Agent when a workflow would do

A patient intake bot: greet, collect details, verify insurance, book a slot. Same four steps every time, conversational interface.

People call this an agent because it talks. But a conversational front end isn’t evidence of agency. The only question is whether the sequence varies with what gets discovered. Here it doesn’t, so an agent buys nondeterminism and cost with no added capability.

The version that genuinely needs an agent is the one where step three’s result decides what step four even is — a claims assistant choosing which forms to pull based on what it found in the last document. You can’t draw that flowchart in advance.

5. Blaming the model for an integration bug

An assistant confidently tells someone their insurance is active. It isn’t — the eligibility tool returned a cached value from last week.

Every hour spent rewriting the prompt here is wasted. The model reasoned correctly over bad input.

The diagnostic question is short: given what it was told, was the reasoning sound? If yes, the fault is upstream. This one matters more in real life than on the exam, because in real life nobody tells you which category you’re in, and “the AI hallucinated” is a very comfortable place to stop looking.

The through-line

Once you notice it, a lot of questions resolve the same way. When two options both solve the stated problem, the exam wants the one with less machinery. Better descriptions before routing layers. Scoped access before broad access. An existing MCP server before a custom build. Caching before a tier downgrade. A workflow before an agent.

That’s not a trick for guessing, and I’d be careful using it as one — plenty of questions have a genuinely more involved right answer, and the security domain in particular sometimes wants the more rigorous option because a cheap one isn’t enforceable. But when you’re stuck between two plausible answers and one of them involves building something new, the other one is usually it.


Written against the objectives in Anthropic’s CCDV-F Exam Guide v1.0 (July 2026). These are patterns in how the published objectives are phrased, not real exam questions — nobody publishing actual exam items is doing so legitimately.

Curriculum · Diagnostic · Changelog