Independent guide
Start here · Step 1

Sign in with your partner-organisation email on the Skilljar site, not claude.ai

Create an Anthropic Academy (Skilljar) account, authenticate, and accept the EULAs — then every course and resource below unlocks.

Important: this is a separate account from claude.ai — not your Claude login. Sign up fresh with your partner-organisation email.

Sign in / sign up at the Anthropic Partner Academy ↗

An independent study guide · Claude Certified Developer - Foundations

Pass the
CCDV-F.

Build, integrate and ship production Claude applications. The exact prep path, the exam blueprint, and a guide to all 8 domains.

  1. Sign in at Skilljar with your partner-organisation email — not claude.ai.
  2. Practice on personal gear only — never run Claude on employer devices, networks, or data.
  3. Follow the prep path below (about 13 hrs).
  4. Book the exam — 53 Qs · 120 minutes · closed-book · pass 720/1,000.
Sign in with your partner email ↗ See the prep path →
53questions
120minutes
720to pass /1,000
8domains
01

Your prep path

This is the official Anthropic Academy prep path for this exam. Complete these courses in order — together they cover every domain. Each course opens on Skilljar — sign in first.

  1. 01 Course
    MSO Foundations
    57 min Start ↗
  2. 02 Course
    Production-Grade Prompting, Agents & Tool Use
    209 min Start ↗
  3. 03 Course
    Claude Code, MCP & Integration
    142 min Start ↗
  4. 04 Course
    Production Engineering, Evals & Security
    211 min Start ↗
  5. 05 Course
    Accelerators & IP Contribution
    155 min Start ↗

That’s the whole prep. Then practice hands-on (use the domain guides below as reference) and book the exam (sign in with your partner email first). ≈ 12.9 hrs total

02

Exam blueprint

A proctored, closed-book exam: 53 scenario-based multiple-choice / multiple-response questions in 120 minutes, no AI assistance. Scored to 1,000 with a passing bar of 720. It is proctored online or at a Pearson VUE test center, and the credential is valid for 12 months from the date the credential is awarded.

CCDV-F
exam code
53
questions
$125
exam fee
120 minutes
time limit
720/1,000
passing score
12 months
validity

Domains & weights

Study time should follow the weights. Click a domain to jump to its guide.

01 Agents and Workflows 14.7%
02 Applications and Integration 33.1%
03 Claude Code 3.1%
04 Eval, Testing, and Debugging 2.6%
05 Model Selection and Optimization 16.8%
06 Prompt and Context Engineering 11%
07 Security and Safety 8.1%
08 Tools and MCPs 10.6%
03

The five domains

Reference for each domain — the concepts to know, the official docs, and exam tips. The prep path above is what to take; this is what to know. Click a domain to expand it.

01

Agents and Workflows

14.7%

Tests whether you can decide when a task calls for a deterministic workflow versus an autonomous agent, then actually build that agent with the Claude Agent SDK, a custom loop, or a managed deployment.

Sub-domains & weights
  • Agent Architecture4.5%
  • Agent Construction with Claude5.3%
  • Agent Patterns and Frameworks4.9%
Key concepts to master
Workflow vs. agent decision criteria. A workflow follows a fixed, predefined sequence of LLM and tool calls; an agent lets Claude decide its own steps and when to stop. Pick a workflow when the steps are predictable and you want consistency and lower cost, and reach for an agent only when the path genuinely can't be determined in advance -- this is the single most-tested judgment call in the domain.
The core agentic loop (reason, call a tool, observe, repeat). Every agent runs the same cycle: Claude evaluates the current state, either answers directly or requests a tool call, your code executes that tool and returns the result, and the loop repeats until Claude stops asking for tools. Recognizing this loop is the foundation for both the Agent SDK and any custom harness you build.
Manager/supervisor and orchestrator-worker hierarchies. A lead agent decomposes a task and dispatches pieces to subordinate agents, then synthesizes their results rather than doing every step itself. This structure is how you scale an agent past what a single context window and a single line of reasoning can reliably handle.
Subagents and delegated task execution. A subagent runs in its own context window with its own tools and instructions, returning only a final result to whatever invoked it. Delegating a subtask to a subagent keeps the parent's context focused and lets you restrict tool access per subtask for safety and cost control.
Claude Agent SDK vs. a custom agent loop or harness. The Agent SDK gives you a maintained implementation of the tool-use loop, context handling, and permissioning out of the box; a custom loop or harness gives you full control at the cost of building and maintaining that machinery yourself. Know what the SDK is actually doing for you so you can explain the tradeoff, not just name it.
Hooks as deterministic control points in an agent loop. A hook is code that runs automatically at a defined point in the loop -- before a tool call, after one, at session start -- so you can force a check or an action the model can't skip or talk itself out of. Use hooks whenever a scenario needs a guarantee, not just a likely outcome.
Self-hosted vs. Anthropic-hosted managed agent deployment. A self-hosted agent runs inside infrastructure you operate and patch yourself; an Anthropic-hosted managed agent runs in a hosted, managed sandbox that offloads that operational burden. Choosing between them is a tradeoff of control versus operational overhead, not a capability difference.
Agentic abstraction frameworks (e.g., LangGraph, PydanticAI, Strands). These are third-party libraries that add graph-based orchestration, typed agent state, or other structure on top of an LLM's tool-use loop. The guide expects you to recognize what problem each class of framework solves, not to have production depth in any specific one.
Official documentation
Claude Agent SDK overview ↗ Building effective agents ↗ Agent SDK: subagents ↗ Agent SDK: hooks ↗
Exam pro tips
  • "Workflow vs. agent" is a judgment call that recurs across the whole exam, not just this domain — default to the least autonomous design that solves the problem, and only justify an agent when the steps genuinely can't be predicted in advance.
  • The guide names specific third-party frameworks as fair game. You don't need production depth in all of them, but you should recognize what problem each is solving.
  • Don't confuse hooks-for-deterministic-agent-actions (here) with hooks-for-guardrails (Security and Safety). Same mechanism, different exam framing — know both angles.
  • This domain is only 14.7%, smaller than it feels given how much attention agents get online. Get it solid, then put your remaining hours into Applications and Integration, which is more than double the weight.
02

Applications and Integration

33.1%

A third of the entire exam. Tests whether you can turn a business requirement into a working Claude integration — correct API usage, sound software-engineering practice, defensible application design across interfaces, and the configuration discipline to keep it maintainable.

Sub-domains & weights
  • Understanding Requirements3.4%
  • Systems Life Cycle2.8%
  • Claude API Mechanics6.8%
  • Software Engineering Foundations7.4%
  • Claude Application Design8.6%
  • Configuration Management4.1%
Key concepts to master
Functional vs. infrastructure requirements. Functional requirements describe what the system must do for its users; infrastructure requirements describe what it needs to run -- compute, networking, storage, rate limits. Separating the two keeps you from designing something that satisfies the feature list but can't actually be deployed or scaled.
Systems development life cycle (SDLC) stages. The standard stages -- plan, develop, test, deploy, operate, maintain -- apply to a Claude integration just as they do to any software system, but each stage carries Claude-specific concerns, like re-testing prompts after a model update. Know what changes about your integration at each stage.
Messages API mechanics (messages, tools, streaming, vision, extended thinking). This is the core request/response contract every integration is built on: how messages and roles are structured, how tool definitions and results flow through a turn, how streaming delivers partial output, how images are passed as content, and how extended thinking is requested and returned. Fluency here is non-negotiable -- it anchors the largest subdomain on the exam.
Prompt caching and cache breakpoints. Prompt caching lets you mark a prefix of a prompt as reusable so repeated calls skip reprocessing it, cutting cost and latency; a cache breakpoint is where you tell the API that reusable prefix ends. Placing breakpoints correctly is what actually captures the savings.
Realtime (Messages API) vs. Message Batches API tradeoffs. The realtime Messages API returns a response immediately for interactive use; the Message Batches API processes large volumes asynchronously within a 24-hour window at lower cost. A latency-tolerant, high-volume, cost-sensitive job is the batch API's signature use case.
REST, JSON, and asynchronous programming fundamentals. The Claude API is a REST API that exchanges JSON, and most real integrations call it asynchronously so a slow model response doesn't block the rest of the application. The exam treats these as baseline literacy it assumes you already have, not something it re-teaches.
Claude's behavior across interfaces (Claude Code, Desktop, claude.ai, API, SDKs). The same model is reachable through very different surfaces, and each interface has its own instruction-following conventions, content boundaries, and configuration surface. Assuming one interface behaves like another is a common source of wrong answers.
Configuration management (CLAUDE.md, settings.json, model pinning, prompt versioning). Treat your Claude configuration like any other production configuration: version it, pin the model version so an unannounced upgrade can't silently change behavior, and version your prompts so a regression can be rolled back. This subdomain is ordinary configuration discipline applied to Claude-specific artifacts.
Official documentation
Messages API reference ↗ Streaming Messages ↗ Batch processing ↗ Client SDKs ↗
Exam pro tips
  • This is 33.1% of the exam — a third of your score sits here. If you only deep-study two domains, make this one of them.
  • Candidates chronically under-study this domain because it reads as "generic software engineering" rather than "Claude-specific." It isn't generic here — know the Messages API mechanics (streaming, vision, thinking, caching, batch) cold.
  • The realtime-vs-batch tradeoff shows up repeatedly in scenario form: latency-tolerant, cost-sensitive, high-volume work points at the Message Batches API almost every time.
  • "Claude Application Design" spans multiple interfaces on purpose — expect a question testing whether instructions, permissions, and content boundaries behave differently in Claude Code versus the raw API versus claude.ai.
  • Configuration management questions often hinge on one idea: pinning. If a scenario worries about a model update silently changing production behavior, the answer is model version pinning, not vague monitoring.
03

Claude Code

3.1%

Tests operational fluency with the Claude Code CLI itself — its core building blocks, its session and execution modes, and how CLAUDE.md and settings.json configure it.

Sub-domains & weights
  • Claude Code Operation3.1%
Key concepts to master
Core components: Rules, Skills, Commands, Agents, Agent Memory. These are the building blocks you configure Claude Code with: Rules constrain behavior, Skills package a reusable capability, Commands are user-invoked shortcuts, Agents are specialized subagents, and Agent Memory persists information across sessions. Knowing which component fits a given customization need is the core of this domain.
CLAUDE.md hierarchy and load order. CLAUDE.md files exist at multiple scopes -- for example user-level and project-level -- and load in a defined order, with more specific scopes layering on top of broader ones. It's guidance the model reads at session start, not enforced configuration, a distinction the exam tests directly.
settings.json configuration. settings.json holds Claude Code's actual enforced configuration -- permissions and tool access among it -- as opposed to CLAUDE.md's advisory instructions. When a scenario needs a behavior to be reliably enforced, settings.json is the answer, not a memory file.
Session management. A session holds the running conversation state and history for a Claude Code interaction, and you can resume, branch, or start fresh sessions depending on the workflow. Understanding session boundaries matters both for continuity and for keeping context from bloating across unrelated work.
Built-in and custom slash commands. Slash commands are shortcuts that trigger a predefined action or prompt; Claude Code ships with built-in ones and lets you define custom ones for repeated project-specific tasks. Know that custom commands and Skills now overlap in what they can accomplish.
Headless mode. Headless mode runs Claude Code non-interactively from a script or CI pipeline instead of an interactive terminal session, typically invoked with a single prompt and structured output. It's how you automate Claude Code rather than operate it by hand.
Streaming mode. Streaming mode returns Claude Code's output incrementally as it's generated rather than waiting for the full response, which matters for responsiveness in both interactive and programmatic use. It's the same underlying idea as API-level streaming, applied to the Claude Code product.
Auto-mode. Auto-mode lets Claude Code proceed through steps with reduced manual confirmation, trading some human-in-the-loop control for speed. Know what it changes about approval behavior compared to Claude Code's more conservative default modes.
Official documentation
Claude Code overview ↗ Settings reference ↗ Memory (CLAUDE.md) ↗ Headless mode ↗
Exam pro tips
  • This is the most over-studied domain relative to its weight. It's only 3.1% of the exam — the most visible product, but not where the marks are. Get comfortable with it through normal use, then stop.
  • Don't confuse CLAUDE.md (guidance the model reads, not enforced) with settings.json (enforced configuration). The exam rewards knowing which one actually constrains behavior.
  • Know the difference between built-in slash commands and a project's custom ones — and that Skills and custom commands now overlap in what they can do.
  • If you already use Claude Code daily, this domain should cost you almost no extra study time. Verify gaps rather than relearning it from scratch.
04

Eval, Testing, and Debugging

2.6%

The smallest domain on the exam, and entirely about diagnosis: recognizing what kind of error you're looking at, choosing a recovery strategy, and reading a trace to work out whether a failure sits in your integration code or in what Claude produced.

Sub-domains & weights
  • Debugging and Error Handling2.6%
Key concepts to master
Error type identification (rate limit, authentication, invalid request, overloaded). Different API error classes demand different responses -- a rate-limit error calls for backoff, an authentication error calls for fixing credentials, an invalid-request error calls for fixing the payload. Misreading the error class is what leads to the wrong fix.
Recovery strategy selection (retry with backoff, fallback, escalation). Once you know the error type, you choose how to recover: retry with backoff for transient failures, fall back to an alternate path or model, or escalate to a human when automated recovery isn't appropriate. The exam tests matching the strategy to the failure, not memorizing one universal fix.
Trace analysis for failure-mode identification. A trace is the recorded sequence of reasoning, tool calls, and results in an agentic run, and reading it end to end is how you find where a failure actually originated. This is a hands-on diagnostic skill, not something you can reason about abstractly.
Integration-layer vs. model-output failure isolation. A bad outcome can come from your code -- a parsing bug, a wrong tool implementation, a bad schema -- or from what Claude actually generated. The exam consistently rewards explicitly isolating which side of that boundary a problem is on before proposing a fix.
Stop reasons and what they signal about a turn. The API reports why a turn ended -- for example that Claude finished normally, hit a token limit, or is waiting on a tool result -- and that signal tells you what to do next. Reading the stop reason correctly is often the fastest way to diagnose a stuck or truncated agent.
Idempotency and safe retries. A retried request is only safe to resend automatically if repeating it can't cause harm, such as a duplicate charge or a duplicate write. Before adding automatic retry logic to a tool call, know whether the action it performs is idempotent.
Structured logging of agent and tool traces. Logging each step of an agentic run in a structured, queryable form is what makes trace analysis and debugging practical at real scale, instead of re-reading raw transcripts by hand. It's the operational habit the exam's diagnostic scenarios assume you already have.
Transient vs. systematic failures. A transient failure clears on its own or with a retry, like a momentary rate limit; a systematic failure repeats identically until something changes, like a malformed schema. Retrying a systematic failure just wastes calls -- the exam uses this distinction to separate the right recovery strategy from a plausible-sounding wrong one.
Official documentation
Handling stop reasons ↗ Errors reference ↗ Develop tests ↗ Reduce hallucinations ↗
Exam pro tips
  • At 2.6%, this domain plus Claude Code together are under 6% of the exam combined. Learn the concepts properly, but don't let two small domains eat a disproportionate share of your study calendar.
  • The recurring skill being tested is origin isolation: is this bug in your code, or in what the model did? Practice asking that question before you look at answer options.
  • "Retry" is not a universal fix. Expect a distractor that retries a request that will deterministically fail again — the right answer is usually to fix the input, not resend it.
05

Model Selection and Optimization

16.8%

Tests baseline LLM literacy — tokens, context windows, sampling, non-determinism — alongside practical judgment: which Claude model tier fits a task, and how to manage tokens and caching to control cost and latency.

Sub-domains & weights
  • LLM Fundamentals5.2%
  • Technical Fundamentals6.1%
  • Model Selection and Tradeoffs2.7%
  • Cost and Token Management2.8%
Key concepts to master
Tokens and tokenization. Claude processes text as tokens, not characters or words, and both your input and Claude's output are measured, billed, and limited in tokens. Every discussion of context windows, cost, and limits in this domain is really a discussion about tokens.
Context window. The context window is the maximum number of tokens a model can hold across a request -- system prompt, history, and tool results included. Once you approach that limit, older content has to be pruned, summarized, or moved out, which is what makes context management a real engineering problem.
Sampling and non-determinism in next-token generation. Claude generates one token at a time by sampling from a probability distribution over likely next tokens, which is why the same prompt can produce slightly different output on different runs. Understanding this is the basis for why you can't treat Claude's output as perfectly reproducible.
Extended thinking, adaptive thinking, and effort levels. Extended thinking lets Claude reason through a hidden scratchpad before answering, adaptive thinking lets it decide how much reasoning a given request needs, and effort levels let you tune that tradeoff directly. All three exist to trade latency and cost against answer quality on harder problems.
Zero-shot, single-shot, and multi-shot prompting. These describe how many worked examples you give Claude before asking it to perform a task -- none, one, or several. More examples generally increase reliability and consistency at the cost of a longer, more expensive prompt.
Opus, Sonnet, and Haiku tradeoffs (capability, latency, cost). The three model tiers trade off raw capability against speed and price: reach for the top tier on genuinely hard reasoning, a mid tier for balanced production work, and the fastest, cheapest tier for high-volume or simple tasks. The exam tests this as a judgment call tied to a scenario, not as trivia about model names.
Prompt caching and cache checkpointing. Caching a stable prefix of your prompt avoids reprocessing it on every call, and checkpointing is how you mark where that stable prefix ends. This is one of the most direct levers you have for cutting both cost and latency on repeated, similar requests.
Breaking behavior changes across model releases. A new model version can change output style, refusal behavior, or formatting even when it's billed as an upgrade, which is why production systems pin a specific model version instead of always floating to the latest. This is the reason pinning matters, not just a good habit to recite.
Official documentation
Models overview ↗ Extended thinking ↗ Prompt caching ↗ Pricing ↗
Exam pro tips
  • At 16.8%, this is the second-heaviest domain after Applications and Integration. Treat it as core material, not background reading.
  • The guide places SDKs-that-wrap-REST-APIs and websockets under this domain's Technical Fundamentals subdomain, not under Applications and Integration — general engineering literacy is tested here too, not just Claude-specific mechanics.
  • Cost questions usually reward the caching or batching answer over the "use a smaller, cheaper model" answer when quality still matters — read for what the scenario is actually optimizing before picking a lever.
  • Know model-tradeoff scenarios cold: a scenario emphasizing speed and simple classification points at the smallest model tier; balanced production work points at the mid tier; hard multi-step reasoning points at the top tier. The exam tests the judgment, not the model names.
06

Prompt and Context Engineering

11%

Tests your ability to control Claude's behavior through what you put in the context window and how you write instructions, plus what you do with the output afterward: validate it, parse it defensively, and stay skeptical of confident-sounding answers.

Sub-domains & weights
  • Context Engineering3.8%
  • Prompt Engineering4.6%
  • Output Handling2.6%
Key concepts to master
Context window management and context drift/bloat. As a session runs longer, the context window fills with history and tool output, and irrelevant or stale content can crowd out what actually matters -- that's drift and bloat. Managing it deliberately is what keeps a long-running agent reliable instead of degrading over time.
Tool-output pruning and compaction. Pruning removes tool output you no longer need from the context, and compaction summarizes older conversation history into a shorter form, both freeing up room in a finite context window. These are the two main levers for controlling bloat in a long agentic session.
Context isolation via subagents or multi-step workflows. Instead of letting one context window accumulate everything, you can hand a subtask to a subagent with its own clean context, or split a task into separate steps that each start fresh. This keeps the main conversation lean and prevents one subtask's noise from degrading another's reasoning.
Instruction clarity and system vs. user placement. Vague instructions produce inconsistent output, and where you place an instruction -- system prompt versus a user turn -- changes how strongly Claude weighs it. Both are levers for controlling behavior before you ever touch a model parameter.
Few-shot examples and output constraints. Few-shot examples show Claude the pattern you want by demonstration rather than description, and output constraints -- format rules, length limits, schemas -- bound what a valid response looks like. Together they're often more reliable than a longer written explanation of what you want.
Iterative prompt refinement. Treat a prompt as a first draft: test it, look at where the output goes wrong, and adjust deliberately rather than making broad rewrites on a hunch. The exam expects you to know this as a disciplined process, not a one-shot writing exercise.
Input sanitization. Before untrusted text -- user input, a fetched document, tool output -- reaches a prompt, it should be treated as data, not as instructions, so it can't hijack Claude's behavior. This is the prompt-engineering-hygiene half of a concern that reappears as a security control in the Security and Safety domain.
Structured output patterns and defensive parsing. Structured output patterns get Claude to return data in a predictable, machine-readable shape, such as JSON matching a schema; defensive parsing means validating that output before your application trusts it. Assume any given response could be malformed or subtly wrong, and check rather than pass it straight through.
Official documentation
Prompt engineering overview ↗ Context windows ↗ Structured outputs ↗ Increase output consistency ↗
Exam pro tips
  • Context engineering and prompt engineering are graded as separate skills here — knowing how to write a good prompt isn't the same as knowing how to manage what's in the window over a long session. Study both.
  • Output Handling is only 2.6%, but its core lesson — stay skeptical of confident, fluent-sounding output and validate it rather than trust it — echoes through the Eval/Debugging domain too, so it pays twice.
  • Expect scenario questions where the obvious fix (rewrite the prompt again) is wrong and the real answer is architectural: prune the context, isolate a subagent, or add a validation step downstream.
  • Input sanitization shows up here and in Security and Safety. Here it's prompt-engineering hygiene; there it's a defense against prompt injection. Know both framings.
07

Security and Safety

8.1%

Tests secure-by-design thinking for Claude applications — defending against prompt injection and jailbreaks, layering guardrails, using hooks to block destructive actions, and handling credentials and access properly.

Sub-domains & weights
  • AI Application Security3.2%
  • Guardrails and Safe Deployment2.3%
  • Claude Hooks1.0%
  • Identity, Secrets, and Key Management1.6%
Key concepts to master
Prompt injection and jailbreak defense. Prompt injection is untrusted content trying to override your instructions; a jailbreak is an attempt to get Claude to bypass its own safety behavior. Defending against both means enforced controls -- isolation and permissioning -- not just a politely worded system prompt.
Untrusted input handling. Any content your application didn't author itself -- user messages, fetched web pages, tool results -- should be handled as untrusted and kept separate from trusted instructions. This is the general principle that prompt injection defense is one specific application of.
Data leakage and PII handling. Data leakage is sensitive information escaping through output, logs, or cached prompts where it shouldn't; PII handling is the discipline of recognizing and protecting personal data specifically. Both require thinking about where information flows, not just what a single response contains.
Authentication, authorization, confidentiality, integrity. Authentication confirms who's making a request, authorization confirms what they're allowed to do, confidentiality keeps data from unauthorized eyes, and integrity keeps data from unauthorized tampering. These four properties frame most of what secure-by-design means for a Claude application.
Guardrail layering and content policy. No single guardrail catches everything, so production systems layer several -- input filtering, output filtering, tool permissioning, human review -- so a failure in one layer doesn't mean total failure. Content policy defines what's acceptable in the first place; layering is how you actually enforce it in practice.
Least privilege and secure-by-design principles. Least privilege means giving an agent or a tool only the access it needs for its specific job, nothing more, so a compromise or a mistake has a limited blast radius. Secure-by-design means building that constraint in from the start rather than bolting it on after an incident.
Hooks as a safety control to block destructive actions. A hook can inspect a tool call before it executes and deny it outright, which makes it the mechanism you'd actually use to guarantee an irreversible action never happens without the check you require. It's the enforcement layer behind guardrails that would otherwise just be a policy on paper.
Secrets, credentials, and API key management. API keys and other credentials should live in environment variables or a secret manager, never hard-coded or committed to source control, and should be scoped to least privilege with access monitored. This is standard secrets hygiene applied specifically to Claude's API keys and any credentials your tools use.
Official documentation
Mitigate jailbreaks ↗ Reduce prompt leak ↗ Claude Code hooks reference ↗ Usage policy ↗
Exam pro tips
  • Temperature, model size, and "asking politely in the prompt" are recurring wrong answers to injection questions. The right answer isolates untrusted content and enforces access at the tool/permission layer.
  • Claude Hooks is only 1.0% of the exam on its own, but it's the mechanism-level answer to a lot of Guardrails and Safe Deployment questions too — study it once and it pays across both subdomains.
  • Identity, Secrets, and Key Management is small (1.6%) but concrete: expect direct questions on where a key should never live — source control, client-side code, logs — rather than abstract policy questions.
  • This whole domain rewards "enforced beats requested" as a general rule — a hook or a permission rule beats a system-prompt instruction whenever a question asks what always happens or is guaranteed.
08

Tools and MCPs

10.6%

Tests whether you can implement reliable tools for Claude to call, build and run an MCP server, and choose correctly among built-in tools, custom tools, Skills, and MCPs for a given use case.

Sub-domains & weights
  • Tool Implementation4.4%
  • MCP Server Development2.1%
  • Agentic Customization4.1%
Key concepts to master
Tool use and function calling mechanics. You describe a tool with a name, a description, and an input schema; Claude decides when to call it and with what arguments, and your code executes it and returns a result. This request-execute-return cycle is the mechanical foundation the rest of the domain builds on.
Tool description writing. Claude picks which tool to call based on the description you write, so a vague or overlapping description leads directly to the wrong tool being chosen. Writing precise, clearly scoped descriptions is one of the highest-leverage skills tested in this domain.
Client-side vs. server-side tool execution. A client-side tool runs in code you control and returns its result to the conversation yourself; a server-side tool executes on Anthropic's infrastructure without a round trip through your code. Knowing which model a given tool uses changes how you handle its errors and its latency.
Tool approval patterns. Some tool calls can run automatically, others need a human or an automated check to approve them first, and the right pattern depends on how reversible and how risky the action is. This is the same enforced-versus-requested judgment that shows up across the Security and Safety domain, applied specifically to tool execution.
MCP servers, resources, tools, and prompts. An MCP server exposes capabilities to any compatible client through three primitives: tools it can call, resources it can read, and prompts it can reuse. Knowing what belongs in each category is core to designing a server that's actually useful to the clients connecting to it.
MCP transport patterns (stdio, sockets/HTTP, client vs. server). MCP servers can communicate over stdio for a local process or over HTTP/sockets for a remote one, and the transport you choose determines where the server can run and how a client connects to it. This is a deployment decision as much as a technical one.
Built-in tools vs. custom tools vs. Skills vs. MCP servers. Built-in tools ship ready to use, custom tools are one-off implementations for your own application, Skills package a reusable expert workflow, and MCP servers expose a capability that many different applications can share and that's maintained independently. Choosing among them is a recurring scenario-based question, not a definitions quiz.
Tool set construction and error handling. A well-built tool set avoids overlapping or ambiguous tools, keeps each tool's scope narrow, and returns errors in a form Claude can actually reason about and recover from. Sloppy tool sets are a common root cause of an agent picking the wrong tool or failing to recover from a bad call.
Official documentation
Implement tool use ↗ MCP quickstart: build a server ↗ Connect Claude Code to tools via MCP ↗ Agent Skills overview ↗
Exam pro tips
  • MCP Server Development is only 2.1%, but it's the subdomain candidates most often skip hands-on practice for. Build one real server, even a toy one, rather than just reading the spec.
  • A reusable-across-multiple-apps requirement is the strongest signal for "build an MCP server" in a scenario question; a one-off need inside a single app usually points at a custom tool instead.
  • Bad tool descriptions are a favorite wrong-answer setup: if a scenario has Claude picking the wrong tool among similar options, the fix is almost always a clearer, more scoped description — not a bigger model.
  • Know the built-in/custom/Skill/MCP tradeoff as a decision tree, not a definition list — the exam asks you to pick one for a scenario, not to define all four.
04

Lab & study setup

You cannot pass this exam by reading alone — it tests hands-on building. This setup gets you a working local environment that exercises the same surface area the exam does: API mechanics, the Agent SDK, MCP, and a basic eval habit.

⚠ Practice on your own accounts and your own data

Do all of your exam preparation on a personal machine, a personal Anthropic account, and a personal API key, kept fully separate from any employer-managed device, network, or account. Practise on personal accounts and non-production data; never point exam practice at production systems, customer data, or corporate networks.

  • Use a personal device and a personal network for hands-on work, not employer-managed hardware or a corporate VPN.
  • Build every exercise with synthetic or throwaway sample data — never real customer records, internal source code, or credentials.
  • Keep your API key and account tied to you personally, not to any employer's billing or identity system.
  • Check your own employer's acceptable-use and AI-tool policies before using any work resources at all, even indirectly.
Subscriptions & access
Your environment
  • Install a recent Node.js and Python (with a modern package/environment manager), plus git and a code editor.
  • Create a personal Anthropic Console account and generate an API key; store it in an environment variable or a git-ignored .env file, never in source control.
  • Install the official Python and/or TypeScript SDK for the Claude API, and Claude Code itself, following the official setup docs.
  • Set a small spending limit or budget alert on your personal API account so practice runs don't surprise you.
  • Create one scratch repository and build every exercise below into it, so configuration (CLAUDE.md, settings.json) accumulates realistically instead of resetting each time.
Hands-on practice
  • Applications and Integration (33.1%, the biggest single target): call the Messages API directly — send a tool call, stream a response, submit an image, turn on extended thinking — then do the same job through the Message Batches API and compare cost and latency.
  • Agents and Workflows (14.7%): build one small agent with the Claude Agent SDK, then hand-roll the same task as a bare tool-use loop — watch for the tool-use stop reason, execute the tool, return a tool result, repeat — so you understand what the SDK abstracts away.
  • Tools and MCPs (10.6%): write a custom tool with a precise description, then build a minimal MCP server exposing it as something other apps could reuse; test it standalone before connecting it to a client.
  • Model Selection and Optimization (16.8%): run the same prompt through more than one model tier, toggle extended thinking, and add prompt caching to a repeated system prompt — track token usage and cost before and after.
  • Prompt and Context Engineering (11.0%) plus Security and Safety (8.1%): build a small pipeline that accepts untrusted input, isolates it from your instructions, produces structured output, and validates that output defensively before your code trusts it.
  • Eval, Testing, and Debugging (2.6%): write a small eval harness — a handful of test cases checking for expected properties, not exact strings — and run it against two prompt versions or two model tiers to see it catch a regression.
From people who passed
  • Match your study hours to the blueprint, not to what feels most familiar. Applications and Integration is a third of the exam; Claude Code and Eval/Debugging together are under 6%. Study Claude Code because you use it daily, not because it's heavily tested.
  • Build something real, even if small. Every domain here is described in terms of practices — implement, build, design, debug — and the exam is written to test judgment on scenarios, not term recall.
  • Treat the sub-domain weights as a study checklist. This is the only guide that publishes them, so use that granularity: if a 1.6% subdomain like Identity, Secrets, and Key Management is the only thing you haven't touched hands-on, close that gap before re-reading a 6.8% subdomain you already know cold.
  • When two answers both sound plausible, prefer the one that's enforced — a hook, a permission rule, a schema validation step — over the one that's merely requested, like a prompt instruction or a polite ask.
  • Read the exam guide's own blueprint before you study anything else. It is the authoritative scope, and this guide is unusually explicit about exact domain and sub-domain weights.

Sources:

05

Official resources

There is no single official “CCDV-F study guide” PDF. The real prep is the Anthropic Academy courses plus the official product docs — everything below is official.

  • Book the exam ↗

    The certification page where you schedule and sit the proctored exam. Sign in first — it's partner-gated, so the page only appears once you're signed in. — CCDV-F certification page

  • Partner portal — exam access ↗

    Where you actually book the exam. Sign in with your partner-organisation account to request the Claude Certified Developer – Foundations exam. — claude.com/partners

  • Anthropic Academy — prep path ↗

    The free, self-paced course path this guide's prep section is built from — sign in and enroll. — anthropic-partners.skilljar.com

  • Claude documentation ↗

    The source of truth for exam questions on the API, Agent SDK, and Claude Code. — docs.claude.com · code.claude.com/docs

  • Model Context Protocol spec ↗

    The MCP specification — server/client architecture, transports, and tool schemas. Directly tested in the Tools and MCPs domain. — modelcontextprotocol.io

  • All Claude certifications ↗

    The index of all four Claude certifications, with links to every certification page and exam guide. — Partner Academy certifications page

⚠ A word of caution

Skip third-party “free CCDV-F practice test” and brain-dump sites that crowd search results. They are not affiliated with Anthropic, are frequently inaccurate, and dump sites can violate exam terms. Stick to Anthropic Academy and the official docs above.

06

Frequently asked questions

The essentials on eligibility, cost, format, and access — answered from verified facts.

Who is the Claude Certified Developer – Foundations exam for?

Technical professionals who build, integrate, and ship Claude-powered applications, agents, and workflows — primarily AI/ML engineers, technical leads, and senior software engineers. Anthropic recommends one to five years of software engineering experience, at least six months hands-on with Claude or a comparable LLM system, and proficiency in Python and/or TypeScript with REST APIs and CLI tools. It is not aimed at non-technical users or roles limited to prompt writing without broader development responsibility.

What does the exam cost, and how many questions does it have?

$125 USD for 53 multiple-choice and multiple-response items — each item states how many responses to select — in a 120-minute time limit.

What score do I need to pass?

A scaled score of 720 on a 100–1,000 scale, set through a formal standard-setting study rather than a fixed percent-correct cutoff. Your score report also shows percent-correct by domain, but that breakdown doesn't itself determine your pass/fail result.

How long does the credential last?

12 months from the date it's awarded. On-time renewal is a free, non-proctored assessment through the Anthropic Partner Academy; if it lapses, you have to retake the full exam at full fee.

Do I need any specific prior courses or certifications to sit the exam?

No. There are no mandatory prerequisites — the recommended experience (software engineering background, hands-on Claude time, Python/TypeScript, REST/CLI fluency) is guidance for self-assessment, not a gate. The credential is awarded on exam performance alone.

Where do I register, and is prep free?

Registration and scheduling run through the Anthropic Partner Academy and Pearson VUE — exam access is gated to that partner channel, and your checkout price reflects your partner tier. Anthropic's own preparation courses on the Partner Academy are free; taking them isn't required, and no paid course guarantees a pass.

How is this different from the Architect certifications?

Developer – Foundations tests whether you can build and ship: write the integration, construct the agent, implement the tool or MCP server. Architect – Foundations and Architect – Professional test design judgment — making defensible tradeoffs, and for Professional, owning a solution's full lifecycle plus stakeholder and governance responsibility. Put simply: Developer builds, Architect designs.

What languages and tools should I already be comfortable with?

Python and/or TypeScript, plus fluency with REST APIs and command-line tools. The guide also expects a working understanding of LLM fundamentals, agents, context management, and MCP going in — this exam validates that knowledge, it doesn't teach it from zero.

Is the exam proctored, and what am I not allowed to do?

Yes — online proctored or at a Pearson VUE test center. You must stay in webcam view for the whole session if testing online, keep your workspace clear of notes, phones, and other monitors, not communicate with anyone during the exam, and not capture or reproduce any exam content. You also accept a confidentiality agreement before the exam starts.

What happens if I fail?

You can retake it, with waiting periods that grow per attempt: 14 days after the first fail, 30 after the second, 90 after the third, up to four attempts within a rolling 12-month period. The exam fee applies to each attempt.

What does the exam actually cover, and how is it weighted?

Eight domains, weighted very unevenly: Applications and Integration alone is 33.1%, Model Selection and Optimization is 16.8%, and Agents and Workflows is 14.7% — those three make up nearly two-thirds of the exam. Claude Code (3.1%) and Eval, Testing, and Debugging (2.6%) are the smallest. This is the only current Claude certification whose guide also publishes sub-domain weights, so you can plan study time at a fairly fine grain.

Can I use Claude or documentation during the exam?

No. It's a closed-book, proctored exam — no AI assistance, no reference material, no second monitor. Whatever you rely on has to already be in your head or worked out on any scratch material the proctor provides.