Cred Farmer

Anthropic · Developer

CCDV-F Study Guide: Claude Certified Developer - Foundations

The developer credential. Covers building on the Claude API: context engineering, tool use, agents, Claude Code and MCP integration, plus the production concerns of shipping an LLM application. 53 items in 120 minutes, 720 of 1,000 to pass, $125 USD at list price, valid for 12 months.

Who it is for: Engineers building applications on the Claude API.

53 items120 minutes720 of 1,000 to pass$125 USD fee
Start preparing freeCCDV-F mock, no accountCCDV-F flashcardsSee the tested domains

The study guide

What CCDV-F is, and what this guide covers

This ccdv-f study guide is written from the official Exam Guide, version 1.0, effective July 2026. CCDV-F is the Claude Certified Developer - Foundations exam: 53 multiple-choice and multiple-response items in 120 minutes, a pass mark of 720 on a scale of 100 to 1,000, a fee of $125 per attempt and a credential valid for 12 months from award.

The exam is for people who write the code around Claude, not people who only write prompts. It checks, at a foundational level, whether you can build agents and workflows, integrate the API into an application, operate Claude Code, engineer prompts and context, debug a failing call, pick a model tier on cost and latency, secure the application and build tools or MCP servers. Its two heaviest skills lean on general software engineering more than on Claude features, which most candidates underestimate.

Below, each of the eight domains gets its published weight, its skills paraphrased with a link to the Anthropic documentation that covers them, the decision rules the site has derived from the guide, and the wrong-answer patterns to watch for. Then a curriculum index of the signed-in study sections and the questions searchers ask.

Study guide text checked against Exam Guide v1.0 (July 2026) on 17 September 2026. It is written from the published blueprint and the official documentation, never from a sitting.

Exam format

CCDV-F at a glance

The numbers that shape how you should prepare.

53Items
120Minutes
720To pass, of 1,000
$125Fee, USD list price
8Domains
25Objectives
CCDV-F exam facts
CertificationClaude Certified Developer - Foundations
Exam codeCCDV-F
Item formatMultiple-choice and scenario-based multiple-response; each item states how many responses to select
DeliveryProctored via Pearson VUE, online or at a test centre, closed book
ScoringScaled 100 to 1,000; 720 required to pass
Fee$125 USD list price per attempt, before partner-tier discounts. Confirm the price at registration before booking.
RetakesWait 14 days after a first failed attempt, 30 after a second and 90 after a third; up to 4 attempts in any rolling 12 months. The fee applies to each attempt.
Validity12 months, counted from the award date. Renew on time and the renewal is a free assessment without a proctor, taken on the Anthropic Partner Academy; let it lapse and the full exam is due again.
PaceAbout 135 seconds per item

Checked against Exam Guide v1.0 (July 2026) on 17 September 2026. Official sources: Anthropic's CCDV-F certification page, the certification FAQ and Pearson VUE's Anthropic exam page.

The fee by partner tier, the Global Premier waiver and what a retake costs are in the Claude certification cost guide; who can register, and how, is in the eligibility guide.

Before you book: check you are eligible

Claude certification exams are currently open to people at Claude Partner Network organisations, and registration needs a partner email on a recognised company domain; a personal Gmail address will be rejected. Joining the Partner Network is free. Read the full eligibility guide

No account needed

Try CCDV-F without an account

Everything on Cred Farmer is free. These run in your browser with no account; an account adds the five timed forms, saved progress and a readiness score capped by your first sitting of each form. Every item was written for this site from the official guide, never recalled from a sitting.

Mock exam

CCDV-F mock exam

53 items · timed, scored by domain

Sit the full paper under the clock, then read the reason every option holds or fails.

Sit the mock

Worked questions

CCDV-F practice questions

Ten worked scenarios with the reasoning

Ten original scenarios written to the guide, each with its key and why every wrong option fails.

Work through the ten

Flashcards

CCDV-F flashcards

40 cards · flip, shuffle, copy for Anki

One deck across every domain, written from the published objectives, with every front and back on the page.

Open the deck

Study plan

Study plan, week by week

Three experience levels · 4 to 8 hours a week

A course, a build and a question set for every week, grouped by the official weights, with the mock placed where it tells you something.

Read the plan

Audience

Who should take CCDV-F

Engineers building applications on the Claude API.

The official guide lists no mandatory prerequisites or required courses, and no other Claude credential has to be held first. The credential is awarded on exam performance alone. Not sure this is the right one? Compare all four.

  • The guide names AI and machine learning engineers, technical leads and senior software engineers who sit between a business requirement and a working system. It recommends one to five years of software engineering experience and at least six months of hands-on work with Claude or a comparable LLM system, plus working Python or TypeScript, comfort with REST APIs and the command line, and a basic grasp of LLMs, agents, context management and MCP. None of that is mandatory: there are no prerequisite courses, and the credential is awarded on exam performance alone.

  • It is explicitly not aimed at non-technical or casual users, at anyone without hands-on development experience, or at prompt-writing roles with no wider responsibility for the application. If your work is mostly configuring Claude for a team rather than shipping code, CCAO-F is the closer fit; if you already design multi-agent systems for a living, look at the architect track instead.

The blueprint

Exactly what CCDV-F tests you on

8 domains and 25 published objectives, each with its official weight, what the domain tests, the decision rules that settle most of its items, the traps the wrong options set, and every objective in plain words, with the official documentation page to read where there is one.

Agents and Workflows

14.7% of the exam · 3 published objectives

14.7%

Agents and Workflows is 14.7 percent of the exam, about eight items, split almost evenly across three skills: agent architecture, building agents with Claude, and recurring patterns and frameworks. The domain turns on one judgement: does the task need a model choosing the next step at run time, or is the sequence knowable up front and better run as a pipeline? Everything else in the domain follows from that call.

Items are framed as a team with a multi-step task and a proposed design. You decide which shape fits, whether a supervisor delegating to specialist subagents is warranted, whether to run the loop yourself or hand it to Anthropic's hosted option, and what belongs in a hook rather than an instruction. Framework names are context, not the thing tested; the pattern behind the name earns the mark.

Decision rules

  • If every step is knowable before the run starts, build a workflow; keep an agent for tasks where each step depends on the last result.
  • Add a supervisor and subagents only when specialists need isolated context or different tools, never for the hierarchy itself.
  • Anything that must happen on every iteration, a permission check or a log write, belongs in a hook or in code, not in the prompt.
  • Self-host when you need control of the loop, runtime and data path; use the hosted option when configuration is enough.

Traps

  • The option that makes the system more autonomous when the scenario describes a repeatable, fully specified pipeline.
  • Adding agents to fix a quality problem that a clearer tool description or a tighter prompt would have fixed.
  • Treating a hook and a prompt instruction as interchangeable when only one is guaranteed to run.
  • Choosing a framework by name recognition when the question is about a pattern any of them could implement.

Objectives

  • Agent Architecture. Decide between a scripted workflow and an autonomous agent, and know when a supervisor with subagents genuinely improves a task. Read: Multi-agent orchestration
  • Agent Construction with Claude. Build an agent with the Claude Agent SDK or a hand-written loop, choose between self-hosting and Anthropic's managed option, and use hooks for steps that always run. Read: Claude Agent SDK overview
  • Agent Patterns and Frameworks. Recognise the standard agent patterns, tool loops, subagents, memory and window management, and what a framework such as LangGraph or PydanticAI adds. Read: Subagents

Applications and Integration

33.1% of the exam · 6 published objectives

33.1%

Applications and Integration is 33.1 percent of the exam, about 17 items, more than the next two domains together. Of its six skills the two heaviest, application design at 8.6 percent and software engineering foundations at 7.4 percent, lean on general engineering more than on Claude features: they test whether you can scope a requirement, shape a schema, keep sessions clean and treat prompts and configuration as versioned, reviewed code. The most Claude-specific weight is API mechanics at 6.8 percent: the Messages API, tools, streaming, images, thinking, caching, the Batches API and reaching Claude through a cloud vendor.

Items describe a team with a constraint, most often cost, latency or a deadline, and ask which API mode, design or configuration decision fits. The guide's own sample here is an overnight job where cost matters and results are not needed until morning; the answer is the batch path, and every distractor either speeds up something that did not need speed or cuts quality to save money badly. Expect that structure to recur.

Decision rules

  • Match the API mode to the deadline: a waiting user gets the Messages API, streamed if the response is long; a report due tomorrow goes through the Batches API for less.
  • Put the material that never changes first and the material that varies last, so prompt caching can reuse the prefix.
  • Pin the model version in configuration and move it deliberately, with an evaluation run, so a release never changes behaviour unnoticed.
  • Keep CLAUDE.md, settings.json and prompt versions in version control beside the code they govern, and review them the same way.

Traps

  • Parallelising synchronous calls to go faster when the scenario said cost mattered and time did not.
  • Cutting max_tokens or dropping to the smallest model as a cost fix when the real problem was the wrong API mode.
  • Hard-coding data or logic into a system prompt when the scenario asked for something maintainable across applications.

Objectives

  • Understanding Requirements. Turn a business requirement and a solution architecture into functional and infrastructure requirements before choosing any Claude feature.
  • Systems Life Cycle. Place a Claude application inside a standard systems life cycle, from development through implementation, operation and maintenance.
  • Claude API Mechanics. Know how the Messages API behaves, including tools, streaming, images, thinking, caching, batch processing and cloud-vendor access, and when realtime or batch is right. Read: Messages API reference
  • Software Engineering Foundations. Apply everyday software engineering, REST and JSON, asynchronous code, version control, code review and refactoring at any scale, to code that calls Claude. Read: Get started with the Claude Developer Platform
  • Claude Application Design. Design applications around how instructions are read on each surface, where content boundaries sit, how schemas are shaped and how sessions and plugins stay clean. Read: Building with Claude
  • Configuration Management. Manage configuration deliberately: CLAUDE.md files, settings.json, pinned model versions, versioned prompts and plugin dependencies. Read: Claude Code settings

Claude Code

3.1% of the exam · 1 published objective

3.1%

Claude Code is 3.1 percent of the exam, about two items, from a single skill. The objective is close to a vocabulary list: the components (rules, skills, commands, agents and agent memory), the features (session management, slash commands, headless, streaming and auto modes), the CLAUDE.md hierarchy, repository initialisation and settings.json. Know what each thing is and where it lives; a two-item domain has no room for anything deeper.

Items ask which component holds a given kind of instruction, or which mode suits a described run. The same product surface is worth several times more on the architect foundations track, and candidates studying from that track's materials routinely overspend here. Read the section once, confirm you can place each term, and give the saved hours to Applications and Integration.

Decision rules

  • Persistent instructions go in the CLAUDE.md that owns them, user, project or directory; one-off notes stay in the conversation.
  • A repeatable action invoked by name is a command or skill; a standing constraint is a rule; a delegated specialist is an agent.
  • Headless mode is for scripts and CI where nobody is at the keyboard; interactive sessions are for exploration and review.
  • Cap the study time: two items cannot repay a week.

Traps

  • Answering with a Claude Code component when the question is really about the API or an agent loop.
  • Any option that puts a secret or a temporary note into CLAUDE.md.
  • Confusing which settings.json a value is read from with what the value does.

Objectives

  • Claude Code Operation. Operate Claude Code day to day: its components, its session and mode features, the CLAUDE.md hierarchy, repository set-up and settings.json. Read: Claude Code overview

Eval, Testing, and Debugging

2.6% of the exam · 1 published objective

2.6%

Eval, Testing, and Debugging is 2.6 percent of the exam, roughly one item, and despite the domain title its only listed skill is debugging and error handling. There is no eval-design objective; evaluation appears on this exam as the thing you run after fixing something, mostly in other domains. The one question is about locating a fault: what kind of error is it, what recovery fits, what does the trace say, and did the integration layer or the model output go wrong.

The framing is a symptom and a set of remedies, and the credited option classifies before it acts. A transient failure gets a bounded retry, an authorisation failure gets a person, a malformed response gets validation and a repair step; the option that skips the classification is the distractor even when it sounds decisive.

Decision rules

  • Classify before responding: a transient error earns a capped retry, an authorisation error earns a human, a malformed output earns validation and repair.
  • Read the trace before touching the prompt; if the request never reached the model correctly, the fix is in the integration layer.
  • Change one variable at a time when isolating a fault, and keep a known-good case to compare against.

Traps

  • Retrying an error a retry cannot fix, such as a permission denial or a bad schema, and calling it resilience.
  • Switching model tier for a fault the request payload or the parser caused.
  • Reading a single wrong answer as a systemic failure without checking whether the input was unusual.

Objectives

  • Debugging and Error Handling. Identify an error's type, pick a recovery that fits, read traces to find the failure mode and decide whether the integration or the model output is at fault. Read: API errors

Model Selection and Optimization

16.8% of the exam · 4 published objectives

16.8%

Model Selection and Optimization is 16.8 percent of the exam, about nine items, and is named for its smallest skill. Choosing between Opus, Sonnet and Haiku is 2.7 percent; the weight is in LLM fundamentals at 5.2 percent (tokens, context windows, sampling, non-determinism, thinking modes and effort levels, zero- to few-shot prompting) and technical fundamentals at 6.1 percent, the plumbing of SDKs over a REST API and connections such as websockets. Cost and token management, 2.8 percent, covers usage tracking, cost modelling and caching.

Items give you a task and ask for a tier and a reasoning setting, a symptom and ask for the mechanism, or a bill and ask what to change. The exam rewards the cheapest configuration that a measured result shows is good enough, and punishes reaching for the most capable model or the deepest thinking as a reflex.

Decision rules

  • Start with the cheapest tier that could plausibly pass, and move up only when a measured result says it does not.
  • Tier and thinking are separate dials: enable extended or adaptive thinking for the step that needs deliberation, not for every call.
  • Measure tokens per call before optimising; the largest saving is usually a cached prefix or a shorter context, not a smaller model.
  • Treat a model upgrade as a change that needs an evaluation run, because behaviour can shift between releases.

Traps

  • The most capable model as the answer to every quality complaint, when the scenario describes a bounded task a lighter tier handles.
  • Enabling extended thinking globally to fix one hard step, then paying for it on every call.
  • Confusing the context window with the output-token limit, or a rate limit with either.

Objectives

  • LLM Fundamentals. Explain tokens, context windows, sampling and non-determinism, the fast, extended and adaptive thinking options and effort levels, and zero-, one- and few-shot prompting. Read: Glossary
  • Technical Fundamentals. Handle the engineering plumbing under an AI application: SDKs that wrap the REST API and connection patterns such as websockets. Read: Client SDKs and libraries
  • Model Selection and Tradeoffs. Choose between Opus, Sonnet and Haiku on quality, latency and cost, know which support adaptive thinking, and plan for behaviour changes between releases. Read: Choosing a model
  • Cost and Token Management. Track token usage, model an application's cost, and bring it down with prompt caching and cache checkpoints. Read: Prompt caching

Prompt and Context Engineering

11% of the exam · 3 published objectives

11%

Prompt and Context Engineering is 11.0 percent of the exam, about six items, across three skills: prompt engineering at 4.6 percent, context engineering at 3.8 percent and output handling at 2.6 percent. Together they are the discipline of making a single call behave: what goes in the system prompt and what in the user turn, when an example is worth its tokens, how a long session is kept from drifting, and what a program can safely do with the result.

Items show a first draft that underperforms and ask what to change first, a long task that has degraded and ask which technique fits, or an output that code will parse and ask how to make that safe. The credited answers are the unglamorous ones: clarify before adding examples, compact rather than expand, validate before trusting.

Decision rules

  • Fix clarity and structure before adding examples; an example is a measured fix for a demonstrated miss, and each one costs tokens on every call.
  • Stable role and rules belong in the system prompt; the task and its data belong in the user turn.
  • When a long task degrades, compact history mid-task, clear it between tasks, and hand a large side investigation to a subagent.
  • If a program reads the output, enforce a schema and validate before use; prose is for people.

Traps

  • Adding more examples when the instructions were unclear to begin with.
  • The option that finds a bigger context budget rather than curating what is in the window.
  • Parsing free text with string matching when a structured output was available.

Objectives

  • Context Engineering. Keep the context window useful: prune tool output, compact history, prevent drift and bloat, and isolate work in subagents or separate steps. Read: Context windows
  • Prompt Engineering. Write and iterate prompts with clear instructions, well-chosen examples, the right split between system and user content, explicit output constraints and sanitised input. Read: Prompt engineering overview
  • Output Handling. Produce, validate and consume output safely through structured patterns, response validation, defensive parsing and scepticism toward confident text. Read: Structured outputs

Security and Safety

8.1% of the exam · 4 published objectives

8.1%

Security and Safety is 8.1 percent of the exam, about four items, spread over four skills: application security at 3.2 percent, guardrails and safe deployment at 2.3 percent, identity and secrets at 1.6 percent, and hooks at 1.0 percent, half an item on average, which may not appear on your form at all. Prompt injection is the anchor; the guide's own sample here is a summariser reading a page that carries hidden instructions, and the credited answer separates untrusted content from trusted instructions and scopes what the acting tool may do.

Items present untrusted input reaching the model, an irreversible action that needs a gate, or a credential in the wrong place, and ask for the most effective control. The distractors are controls that feel like controls and are not: a request in the system prompt, a change of temperature, a more obedient model.

Decision rules

  • Anything that arrived from outside, a page, a file or a tool result, is data, never instruction; keep it apart from trusted instructions and limit what the acting tool can do.
  • Enforce the rules that matter with a control the model cannot argue with: a hook, a permission boundary, or human confirmation of irreversible actions.
  • Least privilege applies to the model's tools as much as to people: grant what the current step needs and widen only after review.
  • Secrets live in a secret manager or the environment, never in prompts, CLAUDE.md, logs or committed configuration.

Traps

  • A polite line in the system prompt presented as a security control.
  • A larger or more instruction-following model offered as the fix for injection, when it can be more exposed, not less.
  • Temperature or other sampling settings offered as a mitigation for anything security related.
  • A guardrail placed after the action instead of before it.

Objectives

  • AI Application Security. Defend an application against prompt injection and jailbreaks, handle untrusted input and personal data, prevent leakage, and enforce authentication, authorisation, confidentiality and integrity. Read: Mitigate jailbreaks and prompt injections
  • Guardrails and Safe Deployment. Deploy responsibly with a content policy, layered guardrails and secure-by-design principles: privacy, identity and access management, least privilege.
  • Claude Hooks. Use hooks as enforcement, so a destructive action inside a Claude application is blocked rather than merely discouraged. Read: Hooks reference
  • Identity, Secrets, and Key Management. Manage secrets, credentials and API keys across development and production, validate identity, approve access at the right level and monitor use. Read: Admin API

Tools and MCPs

10.6% of the exam · 3 published objectives

10.6%

Tools and MCPs is 10.6 percent of the exam, about six items, across tool implementation at 4.4 percent, agentic customisation at 4.1 percent and MCP server development at 2.1 percent. Note the order: choosing the delivery mechanism for a capability (built in, custom, a Skill, or a server) is worth twice as much as knowing how to write the server. The domain is the contract between the model's judgement and the outside world, and a tool's description is the whole of how the model chooses it.

Items describe a capability a team needs and ask which delivery mechanism fits, a tool that fires wrongly and ask what to change, or a reuse requirement and ask where the logic lives. The guide's sample is an internal inventory API several applications must share; the answer is an MCP server, and the distractors paste data into context, bury logic in prompts, or assume a built-in tool can reach a system it has no connector for.

Decision rules

  • A description is how a tool gets chosen; when the wrong tool fires, fix its name, description and parameters before changing anything else.
  • Build an MCP server when a capability must be shared across applications and maintained on its own; keep a single-app capability as a custom tool.
  • Prefer what is built in when it covers the need, a custom tool for your own systems, a Skill to package a way of working, a server to share access.
  • Match the transport to the topology: stdio when the server runs beside the client, a network transport when they are apart.
  • Gate high-impact tools behind approval and keep their permissions narrow, because the tool set is also a security boundary.

Traps

  • Pasting live data into the prompt instead of giving the model a tool that fetches it.
  • Assuming a built-in tool can reach an internal system it was never connected to.
  • Hard-coding integration logic into each application's prompt when reuse was the stated requirement.
  • Fixing a tool-selection problem with a bigger model rather than a clearer description.

Objectives

  • Tool Implementation. Implement tools well: input schemas, descriptions the model can act on, error handling, client-side versus server-side execution, approval patterns and coherent tool sets. Read: Tool use overview
  • MCP Server Development. Author, deploy and integrate an MCP server that exposes resources, tools and prompts over the right transport, and know the client and server roles. Read: Connect Claude Code to tools via MCP
  • Agentic Customization. Compare the four delivery mechanisms, Anthropic's built-in tooling, your own custom tools, Skills, and MCP servers, and pick the right one for the use case. Read: Agent Skills overview

Weights are the official domain weightings from the exam guide. Objective titles are Anthropic's published wording; the sentence after each is ours.

Practice

Six CCDV-F practice questions, written for the 2026 blueprint

Written for this page from the official guide's domains and objectives, never recalled from a sitting. Each shows its key and the reason every option holds or fails. The CCDV-F mock exam has the full paper under a clock, with no account needed.

Question 1 · Domain 2: Applications and Integration · Single response

Answers from a support assistant run about 700 tokens. Users see nothing for nine seconds, and 18 percent leave. Text must appear within a second, and answers cannot be shortened. Which change works?

  • A. Cap max_tokens at 250 on every support request.
  • B. Cache the system prompt with a cache_control block.
  • C. Stream the response and render each delta.
  • D. Send the requests through the Message Batches API instead.

Answer: C. Streaming fixes the wait without shortening answers

The nine seconds go into generating about 700 output tokens, and without streaming nothing is shown until the last one. A streamed response delivers content in deltas as the model writes, so text appears within the first second and the answer stays complete. Capping max_tokens would finish sooner only by cutting answers, which the stem rules out. Caching speeds up a repeated input prefix but not generation, and a batch request comes back hours later.

A. A 250-token cap does finish sooner, but only by cutting answers that must not be shortened.

B. A cached prompt is read faster, but the nine seconds are spent writing output, which caching leaves untouched.

C. Correct. Text shows up within the first second as deltas arrive, and nothing is cut from the answer.

D. Batch requests trade speed for price and can return hours later, so users would wait longer, not less.

Question 2 · Domain 2: Applications and Integration · Single response

Associates paste full contracts into one long conversation that is reused across client matters. Answers about the current contract sometimes cite clauses from an earlier client's agreement. Which design change fixes this?

  • A. Summarize each earlier contract before the next one is pasted in.
  • B. Move all pasted contracts into the system prompt of the conversation.
  • C. Start a new conversation for each matter, carrying over only the standing system prompt.
  • D. Ask the model to ignore earlier contracts when it answers.

Answer: C. Reset the session between unrelated matters

Each client matter is a separate task, and while earlier contracts stay in the conversation the model can quote from them. A new conversation for each matter leaves only the current client's documents in context, with the standing instructions carried over. Summaries of earlier contracts still keep other clients' terms in view. Contracts moved into the system prompt are still part of what the model reads, and asking the model to ignore them does not take them out.

A. Summaries still carry earlier clients' terms into the conversation, so the model can still cite them.

B. Contracts placed in the system prompt are still read on every turn, so all clients' terms stay in view.

C. Correct. A new conversation per matter holds only that client's documents, so earlier agreements cannot be cited.

D. Asking the model to ignore earlier contracts leaves them in the conversation, where it can still draw on them.

Question 3 · Domain 5: Model Selection and Optimization · Single response

You classify three million product descriptions a month with a 93 percent accuracy target. On a labeled set, Haiku scores 94.1 percent, Sonnet 94.8 and Opus 95.0. Which model meets the target most cheaply?

  • A. Sonnet, 0.7 points above Haiku.
  • B. Haiku alone, for the entire monthly volume.
  • C. Opus, with extended thinking turned on.
  • D. Haiku first, then Sonnet to recheck every label.

Answer: B. Pick the lightest tier that passes the measured target

All three tiers clear the agreed 93 percent target on the labeled set, and the question asks for the lowest cost, so the lightest tier that passes is the answer. Opus, Sonnet and Haiku trade capability against latency and cost, and the extra accuracy of a heavier tier is real but was not the requirement. Running two models on every item, or paying for headroom nobody asked for, raises spend without meeting any stated need.

A. The gain is real, but Haiku already meets the agreed target, so the extra cost buys accuracy nobody asked for.

B. Correct. Haiku clears the 93 percent target on the labeled set and has the lowest cost per item of the three.

C. Opus with extended thinking costs the most per item, and headroom above the target was not the requirement.

D. Running two models on every item more than doubles cost to beat a target that one cheap model already meets.

Question 4 · Domain 1: Agents and Workflows · Single response

An agent with nine tools processes permit applications whose four steps are fixed by regulation. Some runs take a different tool sequence, and auditors require identical steps for every application. Which change fits best?

  • A. Replace the agent loop with a workflow that runs the four steps in order.
  • B. Add a supervisor agent that watches tool calls and steps in when the order drifts.
  • C. List the four steps in the system prompt, numbered in the order regulation sets.
  • D. Move the agent to the strongest model tier on offer.

Answer: A. Fixed regulated steps call for a workflow

The four steps are fixed by regulation and auditors need them identical every time, which is the case for a workflow over an agent. Code runs the steps in order and calls Claude only inside the steps that need language. An open agent loop picks its own path, which is why some runs differ. A supervisor or a numbered prompt still leaves a model choosing the sequence, and a stronger model follows instructions better but guarantees nothing.

A. Correct. A workflow runs the same four steps in the same order every time, which is what the auditors require.

B. A supervisor is another model watching the first one, so the sequence is still chosen by a model and can still differ.

C. A numbered list in the prompt makes the right order more likely but cannot guarantee it, and auditors need it every time.

D. A stronger model may drift less often, but the loop still lets it choose its own sequence of tool calls.

Question 5 · Domain 6: Prompt and Context Engineering · Single response

A dispatch agent keeps one session for a whole shift. Each turn adds about 4,000 tokens of tracking JSON, mostly unused. By turn 30 it re-queries resolved shipments. What helps most without a reset?

  • A. Use a model with a context window large enough for a whole shift.
  • B. Tell the agent to remember which shipments it has already resolved.
  • C. Ask the agent for shorter replies on every turn of the shift.
  • D. Prune tool results and compact older turns.

Answer: D. Curate what stays in the window

Most of each 4,000-token result is fields the agent never uses, and that noise buries what it has already resolved. Pruning tool results to the fields it uses, and folding older turns into a short running summary, keeps the useful state in a small context with no reset. A larger window just lets more noise pile up. An instruction to remember adds text without removing any, and shorter replies leave every bulky result in place.

A. A bigger window still fills with unused fields, and the agent still has to find its state among them.

B. An instruction to remember cannot recover facts that are buried in noise, and it adds more text to the context.

C. Shorter replies trim the agent's own text, but every 4,000-token tracking result still stays in the context.

D. Correct. Smaller tool results and a compacted history keep the resolved shipments in view for the whole shift.

Question 6 · Domain 8: Tools and MCPs · Single response

Developers in a dozen repositories need Claude Code to follow a 30-page documentation style guide. It needs no live system, and it should load only for documentation tasks. Which approach fits best?

  • A. Package the guide as a Skill with reference files that Claude loads when relevant.
  • B. Build an MCP server with a get_style_guide tool in every project's config.
  • C. Paste the whole guide into each repository's CLAUDE.md file.
  • D. Write a custom tool in each app that returns the guide.

Answer: A. Procedural knowledge without a live system is a Skill

A style guide is procedural knowledge with no live system behind it. A Skill packages instructions and reference files, and Claude loads it only when a task matches, here documentation work. MCP servers exist to reach external systems and would add a server to run. CLAUDE.md loads all 30 pages into every session, and a custom tool in each app repeats work that one Skill does once.

A. Correct. A Skill holds the guide and its references, and Claude loads it only when a documentation task calls for it.

B. An MCP server is for live external systems. A static guide needs no server, and running one adds work for no gain.

C. CLAUDE.md loads into every session, so all 30 pages would fill the context even for unrelated tasks.

D. A custom tool in every application duplicates effort and still needs instructions telling the model when to call it.

Sit the CCDV-F mock, no account

Study strategy

How to prepare for CCDV-F

Strategy derived from the published blueprint and the exam's format, not recollections of live exam content, which candidates are bound not to share.

Start with a measurement, not a reading list. The free CCDV-F mock at /practice/ccdv-f has 53 fresh items allocated to the eight domains by published weight, runs timed at 120 minutes or in a 30-item quick mode, needs no account and shows the key and a reason for every option once you submit. Sit it cold. Its per-domain table is the map for everything that follows, and it usually shows that Applications and Integration, not Claude Code, is where the marks leak.

With that map in hand, follow the two-week plan at /blog/two-week-study-plan-ccdv-f, which allocates study days by weight so the one-third domain gets a third of the time. Keep the cheat sheet at /blog/ccdv-f-cheat-sheet open while you work: it holds 33 decision rules across the eight domains and the trap each one catches, the quickest way to turn a miss into a rule you keep. Ten more items with a self-scored miss map are at /blog/ccdv-f-practice-questions.

When your free-mock misses are down to the awkward ones, sign in. The account carries five timed forms of 53 items each, 265 in total, written to the same eight-domain blueprint, plus drills by objective and a readiness view capped by your first sitting of each form. Drills and re-sits never count as evidence for it. Practice items are not exam items, and no practice percentage converts to a scaled score, so read every result as a direction, not a verdict.

Quick rules

Start with the blueprint, not a course. The 25 objectives above are the actual assessed skills. Rate yourself 1 to 5 on each, then spend your time on the 1s and 2s.

"Applications and Integration" carries the most published objectives (6 of 25), making it the densest area of the blueprint and a sensible place to go deep first.

Practise under the real clock. 53 items in 120 minutes is about 135 seconds per item. Timing pressure, not knowledge, is what most candidates underestimate.

Read every item's response count. Items state how many options to select; multiple-response questions are where careless marks are lost.

Build something real. These are scenario-based exams: questions describe situations rather than quiz definitions, so hands-on familiarity beats memorisation.

Rehearse closed-book. No notes, docs, or AI assistance are permitted, so practise the same way from the start.

The gated study guide

The CCDV-F study sections, chapter by chapter

30 chapters with an account, written to the 8 official domains. What each one covers, in a sentence.

Chapter 1

How to use this guide

Starts with the diagnostic, then Mock Exam 1, and covers reviewing each miss, the Core, Practice and Reference tiers, and how chapters are built.

Chapter 2

Official exam snapshot

The published facts of the exam, the eight domain weights and the skill weights within them, scoring, and the official retake and renewal policies.

Chapter 3

Model selection and optimization

Tokens, sampling, the context window and the reasoning modes, then how to pick a tier and keep the bill predictable.

Chapter 4

Prompt and context engineering

Making one call behave: instruction placement, when examples pay for themselves, compaction, and validating what comes back.

Chapter 5

Agents and workflows

When a task needs an agent rather than a pipeline, how to build one with Claude, and which patterns recur.

Chapter 6

Claude Code

The two-item domain: components, run modes, the CLAUDE.md hierarchy and settings.json, sized to its 3.1 percent.

Chapter 7

Security and safety

Prompt injection, guardrails that enforce rather than ask, hooks as a control, and where secrets and keys belong.

Chapter 8

Applications and integration

The one-third domain: requirements, life cycle, API mechanics, engineering fundamentals, application design and configuration.

Chapter 9

Tools and MCPs

Tool contracts, descriptions the model can act on, MCP server basics, and the built-in versus custom versus Skill choice.

Chapter 10

Eval, testing and debugging

The single debugging skill: classify the error, read the trace, and decide whether the integration or the output failed.

Chapter 11

Precision clinics: high-ambiguity objectives

Close reads of the objectives whose wording admits two interpretations, with the distinction an item is likely to test.

Chapter 12

Cross-domain decision tools

One table per recurring choice: tier, examples, tool or prompt, structured output, context triage, failure handling and platform.

Chapter 13

Reusable prompt library

Templates for the prompt shapes the exam expects you to recognise, each annotated with why its structure works.

Chapter 14

Hands-on labs

Short build exercises that touch the API, a tool, a prompt iteration and a guardrail, following the guide's advice to build something.

Chapter 15

40-question mastery checkpoint

A mid-course check across every objective, to find the domains that need another pass before the timed forms.

Chapter 16

Mastery checkpoint answer key

The key to the checkpoint with the reasoning behind each answer and the objective each item maps to.

Chapter 17

120 rapid-recall flashcards

Card-sized recall of terms, weights, thresholds and decision rules for the last few days before the sitting.

Chapter 18

Glossary

The vocabulary of the blueprint defined in plain terms, from adaptive thinking to the stdio transport.

Chapter 19

30-day study plan

A month-long schedule that opens with the diagnostic, spaces the domains by weight between the later mocks, then tapers for three days.

Chapter 20

Exam-day checklist and policies

Identification, the rescheduling deadline, retake waits, the four-attempt limit, and what to bring or leave outside.

Chapter 21

Source register

Every source the guide draws on, listed by domain, so each claim can be traced back to its original.

Chapter 22

Anatomy of an exam question

How a scenario item is assembled, where the deciding constraint hides, and how distractors are made to look right.

Chapter 23

Guided worked solutions

Step-by-step reasoning through representative items, showing how to eliminate options before committing to one.

Chapter 24

Test-taking playbook

Pacing, flagging, select-two strategy, and how to read a stem for the constraint that decides the answer.

Chapter 25

Why candidates fail (and how not to)

The recurring miss patterns, from over-investing in light domains to picking the most technical-sounding option.

Chapter 26

Mindset and exam-day nerves

Managing pressure across a two-hour sitting so a hard early item does not cost you the easier ones later.

Chapter 27

Exam-day war room (final crammer)

A compressed final review of the facts, rules and traps most worth having fresh on the morning of the exam.

Chapter 28

Exam logistics and what to expect

Registration through the Partner Academy and Pearson VUE, proctoring options, check-in, and how results are reported.

Chapter 29

Domain cheat sheets

One page per domain with its weight, its skills and its rules of thumb, laid out for quick revision.

Chapter 30

Concept map

The eight domains drawn as one system, with the edges between them and the single question each domain asks.

Open the CCDV-F study sections

Prepare for CCDV-F with the blueprint in front of you

Anthropic retired its official practice exam in the move to Pearson VUE. Cred Farmer covers CCDV-F with study sections mapped to all 8 domains, 5 timed forms labelled blueprint-aligned (four full-length 53-item mock exams and a mastery test), flashcard drills, and a per-domain breakdown of your measured results. Every item carries the key and a reason for every option, and each form can be flagged as you go and reviewed afterwards by domain and by objective. Free while in open beta.

Start CCDV-F prep free

Questions

CCDV-F FAQ

The questions candidates ask most often.

What is CCDV-F?

CCDV-F is the exam code for Claude Certified Developer - Foundations, one of Anthropic's four Claude certifications. The developer credential. Covers building on the Claude API: context engineering, tool use, agents, Claude Code and MCP integration, plus the production concerns of shipping an LLM application. It is a proctored Pearson VUE exam of 53 items in 120 minutes, with a pass mark of 720 on a scaled range of 100 to 1,000, and it costs $125 USD at list price.

How hard is CCDV-F?

Anthropic publishes no pass rate, so treat the guide's sample questions as the honest difficulty reference. The weights show where the work is: Applications and Integration is 33.1 percent, and its two heaviest skills lean on general software engineering rather than Claude features. The awkward items make you choose between two defensible options on a stated constraint.

Is there a free CCDV-F mock exam?

Yes. The mock at /practice/ccdv-f has 53 fresh items allocated by the published domain weights, a 120-minute timed mode, a 30-item quick mode and an untimed review, with no account required. After you submit it shows the key, a reason for every option and a per-domain breakdown.

How long should I study for CCDV-F?

With the recommended background of a year or more of software engineering and six months with Claude, two focused weeks is realistic; the site's plan allocates them by weight. Without that background, budget a month and build one small application first, as the official guide itself advises.

What score do you need to pass CCDV-F?

A scaled score of 720 on a scale of 100 to 1,000. The exam is criterion-referenced, so you are measured against a fixed standard rather than against other candidates. Your report also shows percent correct by domain, but those figures are informational and play no part in the pass or fail decision.

Should I take CCAO-F or CCDV-F first?

Take CCDV-F if you write the code: it tests API integration, agent construction, tools and MCP servers. Take CCAO-F if you configure and operate Claude for a team without owning an application. Neither is a prerequisite for the other, and only the developer exam assumes Python or TypeScript fluency.

Does the CCDV-F certification expire?

Yes, 12 months after it is awarded. Renewing on time means reviewing what has changed and completing a free, non-proctored assessment on the Anthropic Partner Academy. If the credential lapses you retake the full exam at full fee, and Anthropic may require a full retake after a significant content change.

Who can take the CCDV-F exam?

Claude certification exams are currently available to people at organisations in the Claude Partner Network, and registration requires a partner email address on a recognised company domain; personal email addresses are not accepted. Partner Network membership has no fee, though joining commits the organisation to certifying practitioners. Check your eligibility before you book.

How much does the CCDV-F exam cost?

$125 USD per attempt at Anthropic's list price, before partner-tier discounts. Select, Preferred and Global Premier partners receive 50 percent off, and Global Premier partners pay nothing through 31 December 2026. A retake costs the same as a first attempt at your tier. Confirm the price shown at registration before booking.

How many questions is the CCDV-F exam, and how long do I get?

Claude Certified Developer - Foundations is 53 items in 120 minutes. Items are multiple-choice and scenario-based multiple-response; each item states how many responses to select. Expect additional seat time for check-in on top of the 120-minute clock.

What score do I need to pass CCDV-F?

720 on a scaled range of 100 to 1,000. Scaled scoring equates results across exam forms that may differ slightly in difficulty, so the raw number of questions you need right is not fixed, and no practice percentage converts to it.

What happens if I fail CCDV-F?

You can retake it after a waiting period that grows with each failed attempt: 14 days after the first, 30 after the second and 90 after the third, up to 4 attempts in any rolling 12 months. Each attempt is charged the exam fee, and the score report's percent-correct by domain tells you where to study.

Is there an official CCDV-F practice exam?

No. Anthropic's practice exam was retired when exam delivery moved to Pearson VUE, so the only official practice material is the sample questions inside the exam guide. Cred Farmer fills that gap with 5 timed forms for CCDV-F, each labelled blueprint-aligned, plus a mock exam that needs no account.

Is the CCDV-F exam open book?

No. All Claude certification exams are closed book. Notes, documentation, and AI assistants are not permitted during the exam, and sessions are proctored with identity verification.

Not affiliated with, or endorsed by, Anthropic or Pearson VUE. Exam details are summarised from publicly published programme information and can change; always confirm against the official exam guide before booking.

We use cookies and privacy-friendly analytics to understand usage and improve Cred Farmer. Essential features work either way. See our Cookie Policy.