Claude Certified Developer – Foundations (CCDV-F) Exam Guide

What the exam rewards

• ✓Distinguish workflows (predefined code paths orchestrate LLM calls) from agents (the LLM dynamically directs its own steps and tool use) before reaching for either
• ✓Match the workflow pattern to the task's shape: chaining for ordered pipelines, routing for distinct input categories, sectioning/voting for independent or redundancy-benefiting parallel work, orchestrator-workers when the subtask breakdown can't be known in advance, evaluator-optimizer when a generate-then-critique loop measurably improves quality
• ✓Reserve a manager/subagent hierarchy for tasks that are genuinely separable and heavy enough to justify coordination overhead — context isolation, not "more prompts," is the defining benefit
• ✓Choose the Claude Agent SDK when managed loop mechanics suffice, and a custom loop over the Messages API when full control over dispatch, logging, or stopping conditions is required
• ✓Place guardrails against destructive or high-stakes tool calls in a PreToolUse/PostToolUse hook, since hooks are deterministic code callbacks and a prompt sentence is only probabilistic guidance
• ✓Recognize the tool-use loop, subagent delegation, memory, and context-window management as recurring patterns any abstraction framework (LangGraph, PydanticAI, Strands, Agent SDK) packages — understand the underlying API calls before adopting a framework

Anti-patterns to reject

• ✕"Agents are always better than workflows" — the simplest thing that works is the right default; an agent adds latency, cost, and unpredictability a fixed-step task doesn't need
• ✕Confusing orchestrator-workers (subtasks decided dynamically at runtime) with parallelization sectioning (subtasks known and split up front)
• ✕Treating subagents as merely "more prompts" rather than a separate context window — their defining benefit is context isolation
• ✕Putting a safety rule only in the system prompt and calling it a guardrail, instead of a deterministic hook
• ✕Assuming a framework removes the need to understand the tool-use loop and context management it wraps

What the exam rewards

• ✓Translate a business requirement into functional and infrastructure requirements using the five extraction questions — latency, volume, accuracy/criticality, data sensitivity, cost — before picking an architecture
• ✓Run Claude applications through the standard SDLC, adding evaluation as a first-class phase, model-version pinning with regression testing, and continuous production monitoring in place of single equality asserts
• ✓Construct Messages API requests correctly: messages alternate user/assistant, system is a top-level parameter (not a role: "system" message), max_tokens is required, and integration code branches on stop_reason
• ✓Reserve extended thinking for steps whose reasoning depth pays for the added cost and latency; cache a stable, reused prefix; route latency-tolerant, high-volume, cost-sensitive work to the Message Batches API instead of parallelized synchronous calls
• ✓Treat the Claude API as standard REST/JSON, use async/await for I/O-bound calls, and apply exponential backoff with jitter to transient 429/529/5xx errors while fixing (not retrying) 400/401 errors
• ✓Match the instruction mechanism to the interface in play — system param + messages/tools for the API, chat + Project instructions for claude.ai, CLAUDE.md + settings.json for Claude Code — since none transfer verbatim across surfaces
• ✓Delimit untrusted content from trusted instructions, design output schemas strict but not brittle, and explicitly track enabled plugins/MCP servers with their permissions and versions
• ✓Version every configuration layer — CLAUDE.md, settings.json, model IDs, prompts, plugin dependencies — with the same discipline as code, pinning explicit model IDs and gating upgrades behind re-run evals

Anti-patterns to reject

• ✕Defaulting to the biggest model or the realtime API regardless of the requirement
• ✕Believing the system prompt is a role: "system" message, forgetting max_tokens is required, or assuming streaming reduces total tokens/cost rather than just perceived latency
• ✕Applying the same backoff-and-retry strategy to a 400/401 as to a 429/529
• ✕Assuming a CLAUDE.md configures a raw Messages API call, or that one interface's instruction mechanism generalizes to another
• ✕Relying on a floating "latest" model alias in production, or treating prompts/model IDs/config files as untracked local files rather than versioned configuration

What the exam rewards

• ✓Know the five core component types — Rules, Skills, Commands, Agents, and Agent Memory — and that CLAUDE.md is the primary instance of Agent Memory
• ✓Apply the four-level CLAUDE.md hierarchy (enterprise/system, user, project, subdirectory) knowing more specific files layer on top of broader ones, and commit project-level CLAUDE.md to version control
• ✓Configure settings.json for tool permissions, hooks, environment variables, model selection, and MCP servers — the deterministic control surface, never CLAUDE.md
• ✓Distinguish built-in slash commands from custom slash commands (Markdown prompt files in .claude/commands/)
• ✓Treat headless mode (non-interactive execution for CI/scripting) and auto-mode (reduced-confirmation autonomy) as independent axes, not synonyms

Anti-patterns to reject

• ✕Putting permission rules, hooks, or tool allow/deny lists in CLAUDE.md instead of settings.json
• ✕Treating CLAUDE.md as executable configuration rather than context/memory loaded into the model's prompt
• ✕Confusing headless mode (interactivity) with auto-mode (autonomy) as if they were the same setting
• ✕Treating a project-level CLAUDE.md as a personal, untracked scratch file instead of version-controlled team guidance
• ✕Assuming a more specific CLAUDE.md replaces a broader one rather than layering on top of it

What the exam rewards

• ✓Sort a failure into one of five buckets — transport/HTTP, request error, parsing/validation, model-output, or tool-loop — before touching any fix
• ✓Reproduce with the exact failing request, then inspect the raw response (status, stop_reason, usage, content blocks) before any post-processing code runs
• ✓Check stop_reason before concluding an invalid-JSON symptom is a model-output error — max_tokens truncation is fixed by raising the limit, not by rewriting the schema
• ✓In a multi-step workflow, log every model call, tool call, argument set, and tool result, and trace back to the earliest deviation rather than patching only the final failing output
• ✓Match the recovery strategy to the failure class: exponential backoff with jitter for transient 429/529/5xx, fix-and-resend for 400/401, defensive parsing/reprompt for malformed structured output, grounding for hallucination
• ✓Verify every fix with a representative eval set and a defined metric — a single manual spot-check cannot verify non-deterministic output

Anti-patterns to reject

• ✕Rewriting the prompt when a JSON parse crash on a successful response is actually an integration-layer parsing bug
• ✕Treating truncated (stop_reason: max_tokens) output as a schema or prompt problem instead of raising max_tokens
• ✕Debugging only the final output of a multi-step agent instead of tracing back through logged calls to the first faulty step
• ✕Treating "it looks fixed on one example" as verification instead of running it through an eval set and metric
• ✕Applying the same recovery strategy to every failure instead of matching the strategy to the actual failure class

What the exam rewards

• ✓Know that a token is roughly 3-4 characters of English, generation is autoregressive, and both input and output tokens are billed against one shared context-window budget
• ✓Remember temperature 0 reduces randomness without guaranteeing identical output — test with evals, not equality assertions
• ✓Reserve extended thinking for hard, multi-step reasoning steps, since thinking tokens are billed as output tokens and add latency
• ✓Right-size model tier to task difficulty — Haiku for high-volume simple tasks, Sonnet as the balanced workhorse, Opus for hard reasoning — and route each workflow step to its own fitting tier
• ✓Pin an explicit production model version rather than floating to "latest," and re-run evaluations before adopting any new release
• ✓Model cost as tokens-per-request-type times per-token price, using the usage field for real-time instrumentation, and cap max_tokens to a realistic ceiling
• ✓Cache a large, stable, reused prefix (writes cost slightly more, reads are heavily discounted, savings come from reuse) and route latency-tolerant, high-volume work to the Message Batches API — batching cuts cost, not latency

Anti-patterns to reject

• ✕"Temperature 0 makes Claude deterministic" — it reduces randomness but does not guarantee identical output
• ✕"Bigger context window means cheaper" — a larger window just permits more tokens, which usually costs more
• ✕"Always pick the most capable model to be safe" — right-sizing per task/step is the intended answer
• ✕Assuming a cache write is cheap like a cache read — writes cost slightly more; savings come from reuse across many calls
• ✕Assuming batching reduces latency, or that caching/smaller models don't reduce latency

What the exam rewards

• ✓State the task, constraints, and desired output explicitly and positively rather than relying on long negative "don't" lists
• ✓Keep durable role, rules, and output-shape constraints in the system prompt and the specific request plus per-request data in the user message
• ✓Use worked examples (zero-/one-/multi-shot) to lock in format and style, and with long input material, place the document first and the key instruction near the end
• ✓Delimit instructions from data with XML-style tags/headings so untrusted input can't be read as an instruction, then iterate: diagnose the gap, change one thing, re-run
• ✓Treat the context window as one shared budget across system prompt, tool schemas, history, tool results, and retrieved docs — aim for the smallest set of high-signal tokens, not the largest window
• ✓Counter context rot and drift with compaction, pruning, isolation, and just-in-time retrieval — complementary techniques, not interchangeable ones
• ✓Request machine-readable output via an explicit JSON schema plus tool-forcing rather than trusting temperature 0 to guarantee valid JSON
• ✓Validate both structure and semantics of model output, tolerate extra prose or truncation with defensive parsing, and stay skeptical of confident-sounding output on high-stakes claims

Anti-patterns to reject

• ✕Putting per-request data in the system prompt and stable rules in the user turn — the reverse of the correct split
• ✕"More prohibitions = safer" — positive, specific instructions steer better than long "don't" lists
• ✕Burying the key instruction at the top of a huge document instead of placing it after the material, near the end
• ✕"Just use the biggest context window and stuff everything in" — curation beats capacity
• ✕Confusing compaction (summarize to reclaim budget) with truncation (blindly dropping tokens and losing critical facts)
• ✕Trusting output because it sounds confident, or parsing it with brittle string operations instead of schema validation

What the exam rewards

• ✓Recognize prompt injection (malicious instructions hidden inside data) and jailbreaks (direct attempts to bypass safety) as distinct threats — there is no syntactic boundary between instructions and data in natural language
• ✓Isolate and delimit untrusted content, apply least privilege to tools, and back both with guardrails/hooks and input/output validation — no single mitigation is sufficient alone
• ✓Minimize PII sent to the model, redact or tokenize sensitive identifiers before they reach it, and scope tool/data access per user
• ✓Never place secrets in prompts or logs — store API keys in environment variables or a secrets manager, use separate keys per environment, rotate on a schedule
• ✓Layer guardrails as independent controls — input filtering, restricted permissions, output validation, monitoring — and route hard rules to deterministic hooks rather than prompt text
• ✓Authenticate every request and separately verify authorization/access level before an agent acts on a caller's behalf, and log both authorized and attempted access

Anti-patterns to reject

• ✕Believing raising temperature, a polite prompt caveat, or a bigger/more capable model defeats prompt injection
• ✕Broadening a tool's access so an agent can "self-correct" — this increases risk rather than reducing it
• ✕Putting secrets in prompts, logs, or hard-coding an API key instead of using environment variables or a secrets manager
• ✕Relying on a single guardrail layer instead of independent, layered defenses
• ✕Treating a system-prompt instruction as an enforceable control for a destructive action instead of routing it to a deterministic hook

What the exam rewards

• ✓Internalize the tool-use loop: send a tools array, Claude emits a tool_use block, your code executes it, you return a tool_result matched by tool_use_id, and Claude continues or ends the turn
• ✓Write tool descriptions that state what the tool does, when to use it, and what each parameter means — description quality is the top driver of correct tool selection
• ✓Return structured, informative tool errors so Claude can recover or retry instead of guessing, and right-size the tool set since too many overlapping tools cause misuse and context bloat
• ✓Gate sensitive or destructive tools behind an approval pattern before they execute
• ✓Recognize MCP as an open standard exposing tools (actions), resources (readable data), and prompts (reusable templates), not just tools
• ✓Match MCP transport to deployment shape: stdio for local, single-user subprocess integrations; streamable HTTP/sockets for remote or shared servers
• ✓Choose the extension mechanism by reuse profile: built-in tools for capabilities that already exist, custom tools for app-specific logic, Skills for packaged reusable know-how, MCP servers when reuse across apps with independent maintenance is required

Anti-patterns to reject

• ✕"Claude executes the tool" — it only requests the call; your application code runs it and returns the result
• ✕Vague tool descriptions — the description, not just the input schema, is the top cause of wrong tool selection
• ✕Forgetting to return a tool_result matched by tool_use_id, breaking the loop's continuation
• ✕Hard-coding integration logic into each app's own prompt for a capability that multiple apps need — an MCP server is the reusable answer
• ✕Assuming a built-in tool can reach any internal REST API — built-ins have fixed capabilities
• ✕Defaulting to one MCP transport regardless of deployment shape instead of matching stdio to local/single-user and HTTP/sockets to remote/multi-client