Alloy
Depth page/Claude Certified Developer - Foundations (CCDV-F) Exam Prep

Claude Certified Developer – Foundations for working developers: where the exam's weight actually sits

Claude Certified Developer – Foundations (CCDV-F) is Anthropic's proctored certification for engineers who build, integrate and ship production applications on Claude. It is written for AI and machine-learning engineers, technical leads and senior software engineers — typically one to five years of software engineering and at least six months of hands-on work with Claude or a comparable LLM system. There are no prerequisites; the credential is awarded on exam performance alone.

Updated
The argument, in short

A working developer's instinct is to revise the Claude-specific mechanics: tool calls, streaming, MCP. The published blueprint says most of the marks are somewhere else.

Where the weight sits

The exam has 53 items in 120 minutes, spread across eight weighted domains:

DomainWeightExpected items of 53
Applications and Integration33.1%~18
Model Selection and Optimization16.8%~9
Agents and Workflows14.7%~8
Prompt and Context Engineering11.0%~6
Tools and MCPs10.6%~6
Security and Safety8.1%~4
Claude Code3.1%~2
Eval, Testing, and Debugging2.6%~1

The guide publishes the weights; the item estimates are each weight multiplied by 53 and rounded, an expectation rather than a published count.

Applications and Integration is a third of the exam on its own — more than the next two domains combined, and more than the four lightest together. It is also the domain developers most often under-read, because its name sounds like "the API chapter". It is not. It carries six weighted sub-objectives: Understanding Requirements, Systems Life Cycle, Claude API Mechanics, Software Engineering Foundations, Claude Application Design and Configuration Management. Requirements gathering and placing work in the right life-cycle phase are graded here.

The weights below the domains

CCDV-F is the one certification in Anthropic's family whose guide publishes weights for 25 sub-objectives beneath the eight domains, each with its own share of the whole paper. That lets you rank topics rather than whole domains, and three results are worth carrying:

  • Claude Application Design is the heaviest single sub-objective at 8.6%. On its own it outweighs the entire Security and Safety domain (8.1%), and it is larger than Claude Code and Eval, Testing, and Debugging combined (5.7%).
  • Software Engineering Foundations, at 7.4%, is heavier than Tool Implementation (4.4%), the largest sub-objective in Tools and MCPs. Ordinary engineering discipline around a Claude application is worth more on this exam than the Claude-specific mechanics most people revise.
  • Claude Hooks, at 1.0%, is the smallest sub-objective on the paper — about half an item. Know what a hook is; do not spend an evening on it.

What each domain is really asking

Anthropic's courseware frames every topic the same way: each one exists because it prevents a specific production failure. Read the domains as "which implementation decision prevents which failure" and the scenario questions stop looking like trivia.

  • Applications and Integration (33.1%) — take a requirement, place the work in the right life-cycle phase, and design a Claude application that survives production: request and response shape, stop_reason branching, error paths, configuration and versioning. The courseware makes the versioning point with a deployment that broke when a model alias moved.
  • Model Selection and Optimization (16.8%) — tokens, the context window as a fixed budget, sampling and non-determinism, cost and token management, and the difference between choosing a model and enabling a reasoning mode such as extended thinking.
  • Agents and Workflows (14.7%) — choosing between a workflow and an agent, wiring tools and context into a loop that terminates, managing memory across sessions, and placing human-in-the-loop checkpoints where actions are irreversible. These items frequently reward the smaller architecture.
  • Prompt and Context Engineering (11.0%) — system prompts, XML structure, few-shot examples, output constraints, the context-management moves (compaction, clearing history, subagent handoff) that keep a long session inside budget, and output handling — the parsing side.
  • Tools and MCPs (10.6%) — declaring a schema Claude selects correctly, returning results in the expected form, and building an MCP server with the right transport and configuration scope.
  • Security and Safety (8.1%) — prompt injection from fetched content, jailbreaks, untrusted input, scoped identity, secrets that must not reach a config file, and data boundaries that hold under a compliance review.
  • Claude Code (3.1%) — the explore–plan–code loop, permission modes matched to risk, and durable project context.
  • Eval, Testing, and Debugging (2.6%) — defining "done" before deploying, choosing a grading method, and telling retriable errors from terminal ones.

What the fundamentals look like in practice

The course's first domain lesson — free, with its podcast — is on what a request costs, why it varies and how it reaches Claude. It shows the level of precision the exam expects:

  • Tokens are the billing unit and the budget unit. Thinking tokens are billed as output tokens even when the reasoning is not returned. A token count does not transfer between models: on Claude 4.7 and later, a newer tokenizer produces roughly 30% more tokens for the same text, so a cost model built on an older model is wrong before you change the prompt.
  • One request, one budget. The system prompt, tool definitions, the history your application re-sends on every call and the generated output all share one context window; the API keeps no state between calls. The two overflow failures differ: input that alone exceeds the window returns a 400 before generation, while generation that reaches the ceiling stops with stop_reason: "model_context_window_exceeded" — a truncated answer, not an error.
  • Sampling makes identical inputs produce different text. The newest models reject non-default temperature, top_p and top_k with a 400; where temperature is accepted, 0 makes output more repeatable without making it identical. Tests assert properties — the structure parses, the field is present, the value is in range — never exact prose.
  • Thinking, effort and fast mode are per-request settings, not different models. Effort has five levels with high as the default and affects every token, tool calls included; only max_tokens is a hard ceiling. Fast mode raises output tokens per second at premium pricing, not time to first token.
  • An SDK is a REST client that adds retries, timeouts, typed errors and a request id. Synchronous, streaming, async and batch answer one question — who is waiting — and Claude streams over server-sent events, never a websocket.

Where developers go wrong

  • Spending revision on the enjoyable topics. Claude Code and Eval, Testing, and Debugging together are about three items.
  • Reading Applications and Integration as "the API chapter" and skipping requirements, life cycle, engineering foundations and configuration management.
  • Picking the option with real API fields that fixes a different class of defect — a required array added to a schema when the error names a mismatched tool_use_id.
  • Choosing an anti-pattern that sounds disciplined — rotating a key but leaving it in the credentials file, or concatenating every past transcript "for memory".
  • Believing `temperature: 0` makes output deterministic, or that streaming makes generation faster.
  • Treating 720 as a percentage. It is a scaled score on 100–1,000 and converts to no number of correct items.

One exception to ordering study by weight: a domain where you are near zero rather than merely weak. Going from nothing to competent in Security and Safety is a bigger swing than its 8.1% suggests, because security items are decidable once you know the failure modes and undecidable when you do not.

How the course is laid out against the blueprint

Thirteen lessons: an exam-strategy lesson, then twelve domain lessons in a teaching order — fundamentals before API mechanics, mechanics before what is built on them. Applications and Integration gets four lessons (API mechanics; requirements and the systems life cycle; software-engineering foundations; application design and configuration management); Model Selection and Optimization gets two; every other domain gets one.

Next step

Create a free account and take the CCDV-F diagnostic before you study anything: 24 questions, about 20 minutes, weighted like the exam, with each domain reported as questions right out of questions asked. The exam-strategy lesson and the lesson on what a request costs, why it varies and how it reaches Claude are both free, with their podcasts.

Free, with an account
Every course opens with two free lessons — how to take the exam, then a full first lesson of the real material, each with its podcast — plus a free 24-question diagnostic for each of the four prep courses.
Create a free accountOne signup — one balance across all four prep courses.

Alloy is exam preparation built from the official exam guides — only what the exam asks for.