The mental model that passes the CCDV-F exam
One engineering stance underlies most of the fifty-three questions.
Engineer against the contract, not the content.
Every Claude API call gives you two very different things. There is a contract —
stop_reason, usage, content block types, tool call IDs, HTTP status codes,
rate-limit headers, schema-constrained output. That part is deterministic, documented and safe to branch
on. And there is content — the text the model generated. That part is a very good
guess, and nothing more.
Nearly every wrong answer on this exam involves treating content as if it were contract: parsing prose to decide control flow, trusting a JSON blob that was merely requested rather than constrained, assuming a tool call is well-formed, believing a cited figure. And nearly every correct answer routes the decision through something the platform actually guarantees.
| Decision | Wrong instinct | The exam's answer |
|---|---|---|
| Is the agent loop finished? | Check whether the text says it is done | Branch on stop_reason — tool_use, end_turn, max_tokens, refusal |
| Is the output valid JSON of the right shape? | Ask for JSON in the prompt and json.loads it | output_config.format with a schema, or strict: true on the tool |
| Should I retry this failure? | Retry everything with backoff | Retry 429, 500, 504, 529 honouring retry-after; surface 400, 401, 403, 404, 413 |
| How much did this cost? | Estimate from characters | Read usage, including the cache fields; count ahead with the token-counting endpoint |
| Am I near a rate limit? | Wait for the 429 and react | Watch the anthropic-ratelimit-*-remaining headers |
| Do I need an agent here? | Build an agent; it is more flexible | Use the simplest pattern that meets the requirement — usually a workflow |
| Is content from a tool safe to act on? | It came back from our own tool, so yes | Treat every tool result as untrusted data, never as instructions |
The second principle: start simple, add complexity only when it earns its place
Anthropic's own guidance on building agents is unusually blunt about this, and the exam reflects it. A single well-built prompt beats a chain. A chain beats a router. A router beats an orchestrator. An orchestrator beats an autonomous agent. Each step up buys flexibility and costs predictability, latency, money and debuggability.
So when a question offers you a sophisticated architecture and a plain one that both satisfy the requirement, the plain one is the answer. Complexity is justified by a requirement in the stem — unpredictable subtasks, genuinely independent parallel work, iterative refinement against a clear criterion — not by ambition.
Four corollaries
- Read the whole response object.
stop_reasonandusageanswer most operational questions, and most candidates only ever look atcontent[0].text. - Errors are typed for a reason. A permanent failure retried three times is three times the latency and none of the success.
- Cost is an architectural property. Model tier, prompt caching, batch processing and token discipline are design decisions, not a finance problem to solve later.
- Untrusted input is anything you did not write. Documents, web pages, emails, tool results, MCP server responses — all data, never instructions.
← Previous: CCDV-F study guide (start here) | Next: Domain 1 — Applications and Integration →
Explore Other Certification Study Guides
Switch to another exam guide to prepare for your next Claude certification:
Claude Certified Associate — Foundations
Entry-level certification for non-coders: prompting, output evaluation, model selection, workflow integration, configuration, governance & responsible use.
Claude Certified Architect — Foundations
Core architectural principles: agentic loops & orchestration, tool design & MCP, Claude Code workflows, prompt engineering, and context reliability.
Claude Certified Architect — Professional
Advanced enterprise architecture: solution design, system integration, evaluation frameworks, governance, safety & developer enablement.