CCDV-F Cheat Sheet: Claude Certified Developer Foundations Quick Reference [2026]

This is your quick-reference cheat sheet for the Claude Certified Developer - Foundations (CCDV-F) exam. It compresses all 8 domains into the decision rules, API mechanics, and contrasts you need to have cold on exam day. Use it as a final-week companion: skim it once per day, drill any section where a rule surprises you, and re-read the trap patterns the night before you sit the exam.

Exam Quick Facts

Three logistics details worth memorizing. First, roughly a quarter of the 53 items are multiple-response ("Select TWO" or "Select THREE") with no partial credit, so every selected option must be defensible on its own. Second, registration runs through the Anthropic Partner Academy and requires Claude Partner Network membership, which is free to join. Scoring is scaled from 100 to 1000 with a 720 pass mark, and the score report shows percent-correct per domain, so a failed attempt still tells you where to focus. Third, the credential is valid for 1 year with a free non-proctored renewal assessment available before expiration; a lapsed credential means a full proctored retake. Anthropic recommends one to five years of software engineering plus six or more months of hands-on Claude work, but these are recommendations rather than enforced prerequisites. If you are choosing between developer and architect tracks, see CCDV-F vs CCA-F.

Domain Weights at a Glance

With 53 scored questions, each weight translates into an approximate question count. Budget your remaining study hours accordingly: the top two domains alone are half the exam.

Domain 1: Applications and Integration (33%)

The heaviest domain by far. Expect around 17 questions on how the Claude API actually behaves.

Messages API essentials

• The API is stateless. You send the full conversation history on every request; messages alternate between user and assistant roles, and the first message must be from the user.
• max_tokens is a hard output cap and stop_reason tells you why generation ended (end_turn, max_tokens, tool_use, refusal). Check it before parsing content, because a truncated or refused response breaks code that reads the first block unconditionally.
• Vision inputs arrive as content blocks containing base64 data or a URL reference, placed before the text question. Images bill as input tokens, so downsample when full resolution adds cost without adding accuracy.

Streaming

Streaming delivers the response incrementally over server-sent events instead of waiting for the full completion. It solves two problems: perceived latency (the user sees the first token quickly) and long outputs (large max_tokens values risk HTTP timeouts without it). Decision rule: user-facing chat streams, and any request with a large output budget streams.

Prompt caching mechanics

Prompt caching stores the processed form of a stable prompt prefix (system prompt, tool definitions, reference documents) so repeated calls skip reprocessing it. Cached reads bill at a steep discount to fresh input tokens (roughly a tenth of the base rate), while cache writes carry a small premium.

• Caching is a prefix match. Any byte change anywhere in the prefix invalidates everything after it, and the request renders in a fixed order: tools, then system, then messages.
• Cache checkpoints (cache_control breakpoints) mark where the cacheable prefix ends. You get up to 4 per request; place them at stability boundaries, and remember that a checkpoint on the last system block caches the tools and system prompt together.
• Structure prompts stable-first, volatile-last. Classic cache breakers: a timestamp or user ID early in the system prompt, tool definitions that reorder between calls, and non-deterministic JSON serialization.
• It pays off when a long stable prefix is reused within the cache lifetime, and it silently does nothing for prompts below the minimum cacheable length. Verify with the cache_read_input_tokens usage field rather than assuming.

Batch vs realtime

Decision rule: if a human is waiting on the response, use realtime with streaming; if the work can wait until tomorrow, the batch discount is free money.

Configuration management

• Version-control the configuration that shapes model behavior: CLAUDE.md files, settings.json, and prompt templates belong in the repository so changes are reviewable and revertible.
• Pin model versions in production. Pinning a specific model identifier keeps behavior stable; upgrades then happen as deliberate, evaluated changes rather than silent drift.
• Version prompts like code. A prompt registry or template store with history lets you correlate output changes with prompt changes.

Domain 2: Model Selection and Optimization (17%)

LLM fundamentals

• Tokens are the unit of billing and of context: the context window bounds input plus output together.
• Sampling makes outputs non-deterministic. Identical inputs can produce different outputs, so never build tests that string-match a full response; assert on structure and key facts instead.

Tier decision rules

The exam tests tradeoff judgment across capability, cost, and latency rather than memorized model names. Reason by tier.

• High-volume bounded task: Haiku class. Complex reasoning: Opus class. That single rule answers a surprising number of questions.
• Default to the balanced tier and move on evidence. Upgrade when evals show reasoning failures, and downgrade when evals show the cheap tier holds accuracy.
• Routing beats a single model at scale: a fast-tier model triages requests and escalates only the hard slice.

Thinking, effort, and fast mode

• Extended thinking gives the model room to reason internally before answering, buying accuracy on multi-step problems at the price of extra output tokens and latency.
• Effort levels dial how much reasoning and token spend the model applies without switching models; lower effort suits routine work, higher effort suits intelligence-sensitive work.
• Fast mode serves the same model at higher output speed for premium pricing, aimed at latency-critical paths.

Cost levers, in order

Trim context, cache stable prefixes, route easy traffic to the fast tier, and push non-urgent volume through the Batch API. Downgrading the model tier comes after those levers, and only with eval evidence. Use the token counting endpoint to measure prompts rather than estimating.

Domain 3: Agents and Workflows (15%)

Workflow vs agent

Before choosing an agent, apply the four-question test: is the task genuinely multi-step and hard to specify (complexity), does the outcome justify the cost and latency (value), is the model capable at this task type (viability), and can errors be caught and recovered (cost of error)? A single no means stay at a simpler tier. When one well-scoped call solves it, both answers involving loops are wrong.

Hierarchies, SDK, and deployment

• Manager and subagent hierarchies are justified when subtasks are independent. The orchestrator decomposes the task, each subagent works in a fresh isolated context, and the orchestrator merges the reports. A narrow single-domain task belongs to one agent.
• The Claude Agent SDK packages the full agent harness as a library: the loop, built-in file and shell tools, context management, hooks, permissions, and subagents. A custom loop means you own the request-execute-repeat cycle yourself; hooks let either approach run deterministic code at lifecycle points such as before a tool executes.
• Managed deployment means the provider runs the loop and the sandbox for you, while self-hosted keeps execution on your infrastructure for control and compliance. Scenarios naming data residency or custom runtimes point self-hosted; scenarios emphasizing speed to production point managed.
• Frameworks such as Strands, LangGraph, and PydanticAI add orchestration graphs and state management on top of the API. The tested judgment is recognizing when a framework earns its complexity and when a direct SDK loop is simpler.

Domain 4: Prompt and Context Engineering (11%)

• Attention concentrates at the beginning and end of the context window. Put critical instructions and key facts there, because long middles get skimmed.
• Context bloat is accumulated stale content (old tool results, dead ends) and drift is the model gradually losing the original instructions under that weight. Two fixes: pruning removes stale content outright, while compaction summarizes earlier history into a shorter form. Know which is which.
• Subagents isolate context. Delegating a reading-heavy subtask to a subagent keeps the main loop lean, since only the report comes back.
• Instruction clarity means testable criteria. "Flag SQL injection and authentication bypass" is checkable, while "be careful" is a criterion nobody can verify. Few-shot prompting uses 2 to 4 worked examples, ideally including a correct rejection so the model learns what to leave alone.
• Structured outputs constrain the response to a schema, and defensive parsing handles the rest: parse with a real JSON parser, validate against the schema, and handle refusal and truncation stop reasons. Regex over raw response text is the tested anti-pattern.

Domain 5: Tools and MCPs (10%)

• Tool descriptions decide tool selection. A strong description states what the tool does, when to use it, when to leave it alone, and what each parameter means. When the model picks the wrong tool, the first fix is the description rather than more tools.
• Client-side tools execute in your application (the model emits a call, you run it and return the result), while server-side tools execute on Anthropic infrastructure (web search, code execution) with no execution loop on your side.
• MCP (Model Context Protocol) is an open standard for exposing tools, resources, and prompts through servers that any compliant client can connect to, over stdio for local processes or network transports for remote ones.

Decision rule: Skills change what the model knows, tools change what it can do, and MCP is the answer when the scenario mentions reuse across multiple surfaces. Wrapping a one-off, single-app integration in MCP adds maintenance without benefit.

Domain 6: Security and Safety (8%)

• Prompt injection is malicious instruction smuggled through content the model processes: user input, retrieved documents, tool outputs, or web pages. A jailbreak is a direct attempt to talk the model out of its own policy. Injection questions hinge on untrusted data channels.
• Defense is layered, in order: input validation and injection screening, system prompt constraints, least-privilege tool and permission scoping, output filtering, and human review for high-stakes actions. Prompt instructions are probabilistic, while permission scoping and output validation are deterministic, so compliance-critical controls must include the programmatic layers.
• Claude Code Hooks work as deterministic guardrails: shell commands that run at lifecycle points, such as blocking a dangerous command before it executes. On guardrail questions, a hook beats a plea in the system prompt.
• Data leakage and PII: redact sensitive fields before they reach the model, scrub logs and traces, and treat tool outputs as a leakage channel too.
• Authentication and authorization: agents act with the calling user's permissions, and a shared over-privileged service account is the tested anti-pattern because it erases per-user boundaries and audit trails. API keys live in environment variables or secret managers, never in prompts, code, or committed configuration.

Domain 7: Claude Code (3%)

Only about 2 questions, and most test whether you can map a need to the right component.

• CLAUDE.md is hierarchical. A user-level file applies to all of that person's projects and stays personal, the project-root file is committed to the repository and reaches every teammate, and subdirectory files add narrower guidance. More specific scopes layer on top of broader ones, and enterprise-managed policy sits above everything.
• settings.json carries permissions, hooks, environment variables, and model configuration. The shared project file is committed for the team, while a local settings file stays personal and out of version control. When a question asks how a whole team reliably gets a behavior, the answer is version-controlled project configuration.
• Headless mode runs Claude Code non-interactively from a single command, which is the answer for CI pipelines and scripted automation; session management lets you resume prior interactive sessions with context intact.

Domain 8: Eval, Testing, and Debugging (3%)

The core skill here is isolating where a failure lives before fixing it.

Trace analysis means logging the full request and response, token counts, stop reason, and every tool call with inputs and outputs, so you can attribute a failure to its layer instead of guessing. Retryable errors (rate limits, overload, server errors) get backoff, while 4xx client errors get fixed rather than retried.

Trap Answers to Watch For

Foundations-level distractors are plausible and true in some other context. These recurring patterns mark an option as wrong for the scenario at hand:

• The flagship-everywhere trap. Recommending the top capability tier for every workload ignores cost and latency. Tier must match task difficulty and volume.
• The agent-by-default trap. Choosing an agent loop when a fixed workflow, or a single call, meets the requirement. Autonomy without a reason is a defect.
• The prompt-guarantee trap. "Add it to the system prompt" as the enforcement mechanism for a security or compliance requirement. Guarantees come from permissions, validation, and hooks.
• The cache-the-volatile trap. Placing timestamps or per-user content early in the prompt, or expecting caching to help when the prefix changes every request.
• The batch-for-interactive trap. Taking the Batch API discount on a user-facing path, or paying realtime rates for overnight bulk work.
• The everything-through-MCP trap. Wrapping a one-off, single-application integration in an MCP server when a direct custom tool is simpler.
• The more-tools trap. Fixing wrong tool selection by adding tools instead of sharpening descriptions and removing overlap.
• The shared-credential trap. One over-privileged service account for all users, or secrets embedded in prompts and committed files.
• The personal-config trap. Putting team-wide behavior in user-level settings, where it never reaches anyone else.

For multiple-response items, apply the traps to each option independently: one prompt-guarantee or flagship-everywhere pick among your selections costs the whole question. More exam-day tactics are in How to Pass CCDV-F on Your First Attempt.

Final-Week Checklist

Work through this list in your last week. Anything you cannot check honestly is your next study block.

Next Steps

You now have the compressed version of every heavily tested CCDV-F concept. For the reasoning behind any rule on this page, return to the Complete CCDV-F Guide or the Domains Breakdown, and use the 4-Week Study Plan if your exam date is further out.

The fastest way to find your remaining gaps is timed practice. Preporato's CCDV-F practice tests include 6 full-length exams of 53 questions each, mirroring the 8-domain blueprint with explanations for every answer, plus a 500-card flashcard deck for the definitions on this page.