CCD-Foundations: What the Developer Exam Actually Tests
An orientation to the Claude Certified Developer – Foundations exam (CCDV-F): the eight weighted domains, how it differs from the Architect exam, the running application this series builds, and the run-everything verification convention behind every code sample.
There are two Claude Foundations certifications, and you should know which one you’re studying for. The Architect exam (CCAR-F) is about design judgment — which approach fits, what the tradeoffs are, when to escalate. The Developer exam (CCDV-F) is the subject of this series. It’s about building the thing: integrating Claude through the API, constructing agents and MCP servers, handling streaming and errors, managing tokens and cost, and shipping it without leaving a security hole. It’s a builder’s credential, and the blueprint reflects that.
This series is a study guide for CCDV-F, organized as a book. Every chapter maps to the exam blueprint. And because this is a developer exam about code that has to actually run, every code sample in it was executed against the live Claude API. Not written from documentation and hoped over. More on that convention below.
The exam at a glance
| Credential | Claude Certified Developer – Foundations |
| Code | CCDV-F |
| Items | 53 |
| Format | Multiple-choice and multiple-response (each item says how many to pick) |
| Time | 120 minutes |
| Passing score | 720 on a 100–1,000 scale |
| Fee | $125 USD |
| Validity | 12 months |
Two format details matter for how you study. First, it’s 53 items in 120 minutes: a shade over two minutes each, comfortable pacing, so the pressure is knowledge, not clock. Second, some items are multiple-response: “select two,” “select three.” Partial-credit guessing is weaker here, so shallow familiarity with a topic tends to cost you the multi-select items even when you’d have scraped the single-select version. Depth pays.
The score report gives you pass/fail plus percent-correct per domain. That’s useful for a retake but not for passing: the pass/fail line is your total scaled score, so a weak domain can be carried by strong ones. That shapes strategy — don’t neglect the 33%-weighted giant to perfect a 2.6% corner.
The blueprint — and why it’s lopsided
Eight domains, and the weights are wildly uneven. This table is the study plan:
| # | Domain | Weight |
|---|---|---|
| 2 | Applications & Integration | 33.1% |
| 5 | Model Selection & Optimization | 16.8% |
| 1 | Agents & Workflows | 14.7% |
| 6 | Prompt & Context Engineering | 11.0% |
| 8 | Tools & MCPs | 10.6% |
| 7 | Security & Safety | 8.1% |
| 3 | Claude Code | 3.1% |
| 4 | Eval, Testing & Debugging | 2.6% |
Domain 2 alone is a third of the exam. It covers the Messages API in depth: streaming, vision, thinking, caching, batch, and third-party access via Bedrock and Vertex. It covers the software-engineering foundations around it — REST, JSON, async, version control, refactoring. And it covers how Claude interprets instructions across its different interfaces, plus configuration management. So take one thing from this orientation: more than anything, this is an API integration exam. Model optimization (Domain 5, 16.8%) and agents (Domain 1, 14.7%) come next. Claude Code and formal evals loom large in tutorials but are small slices here — 3.1% and 2.6%.
That imbalance is why this series is organized as a developer’s build journey, not one chapter per domain. Some domains are too small to carry a chapter alone; others need six. The arcs below follow how you’d actually build a Claude application, weighted the way the exam is.
Who the exam is for
The blueprint names its minimally qualified candidate precisely: one to five years in software engineering, at least six months hands-on with Claude or a comparable LLM, proficient in Python and/or TypeScript, fluent with REST APIs and CLI tools. It explicitly excludes prompt-only and non-technical roles. If you’ve built and shipped one real Claude application, you’re the audience — API calls, a tool or two, some prompt and context work, a little security. If you haven’t yet, the fastest preparation is to build that application. This series is structured so you can build it as you read.
The running example
Like the Architect series, this one uses a single running application so the concepts compound instead of scattering: a bookshop assistant, the same domain as this blog’s dbt, Kubernetes, and LangGraph series. It answers customer questions, looks up orders, and processes refunds through tools. By the capstone it runs as a small production service with streaming, error handling, caching, and guardrails. Every mechanic in the exam shows up somewhere in building it.
The verification convention
This blog has one governing rule: a technical claim is either run against a pinned version or flagged in the text as unrun. There is no third state. Documentation describes intent; a live call describes behavior, and the two disagree more often than anyone expects.
So this series is pinned and executed. The versions, current as of writing:
anthropic0.120.2 (Python) — the Claude API SDKclaude-agent-sdk0.2.128: the Agent SDK (formerlyclaude-code-sdk)mcp1.29.0: the MCP SDKstrands-agents1.50.2,pydantic-ai2.21.0, andlanggraph1.2.10 (withlangchain1.3.14 /langchain-anthropic1.5.3) — the agent frameworks the blueprint names- Model for verification runs:
claude-haiku-4-5, because the mechanics the exam tests — response shapes, streaming events, error types, caching behavior, batch semantics — are model-independent, and Haiku makes running them cost cents
Where a claim is about the API contract, you’ll see what the live call returned. Where it’s about model quality (does few-shot help, does one model beat another), that’s inherently model-dependent and flagged as such. And a few things need credentials this series verifies separately: the Amazon Bedrock path is confirmed against real AWS access when we reach it; Vertex/GCP is documented rather than run. Those are called out in place.
The payoff: when a chapter tells you a streaming tool call arrives as input_json_delta fragments you accumulate and parse at content_block_stop, or that the SDK retries twice by default, or that a batch finishes with per-request custom_id matching — those aren’t recollections. They’re what happened when the code ran.
Setting up to follow along
Every code block in this series is a self-contained program you can run. The quickest way to a working project is uv, which scaffolds the project and installs the exact versions the series was verified against:
uv init claude-dev && cd claude-dev
uv add anthropic==0.120.2 claude-agent-sdk==0.2.128 mcp==1.29.0 \
strands-agents==1.50.2 pydantic-ai==2.21.0 \
langgraph==1.2.10 langchain==1.3.14 langchain-anthropic==1.5.3That pins Python 3.13-compatible releases; run any snippet with uv run python script.py. The three frameworks (strands-agents, pydantic-ai, langgraph) are used only in Arc 2’s framework comparison — drop them from the uv add if you’re skipping that chapter.
Two things the code needs from outside itself:
- An API key, from the environment. The
anthropicclient and the Agent SDK both readANTHROPIC_API_KEYfrom the environment — a.envfile is not loaded automatically. Export it (export ANTHROPIC_API_KEY=sk-ant-…),sourcean env file, or load it in Python withpython-dotenvbefore the first call. With no key reachable, a call fails with an authentication error rather than hanging. - The
claudeCLI, for the Agent SDK.claude-agent-sdkdrives theclaudecommand-line tool under the hood, so its examples need the Claude Code CLI installed and on your PATH (npm install -g @anthropic-ai/claude-code, or the native installer from Anthropic’s docs). The plainanthropicexamples don’t need it. The Bedrock chapter additionally needs AWS credentials, covered there.
The map
The series runs in six arcs plus this orientation and a capstone:
- Arc 1 — Integrating Claude (Domain 2): the Messages API, streaming, multi-format input, errors and retries, Bedrock and batch, application design and configuration.
- Arc 2 — Agents & workflows (Domain 1): workflow-vs-agent, building agents with the SDK and custom loops, and the frameworks — LangGraph, Strands, PydanticAI — stood up and compared.
- Arc 3 — Tools & MCPs (Domain 8): tool implementation, building MCP servers, and choosing among built-in tools, custom tools, Skills, and MCPs.
- Arc 4 — Model selection & optimization (Domain 5): LLM fundamentals and thinking, picking a model tier, and cost, tokens, and caching.
- Arc 5 — Prompt & context engineering (Domain 6): writing prompts that hold, and managing context and structured output.
- Arc 6 — Security, operations & evals (Domains 7, 3, 4): application security, guardrails and secrets, and Claude Code plus debugging.
Each chapter names the domain and skills it covers, treats them completely, and ends by pointing at the next. The goal isn’t to memorize the blueprint — it’s to build the thing the blueprint describes, and recognize every exam item as a decision you’ve already made in code.
Next: the Messages API in depth — the request and response shapes every other chapter builds on.
Comments