The right Claude exam for people who write the code. It is an application engineering exam more than an agents exam: a third of it is Applications and Integration (API mechanics, software engineering basics, application design and configuration), and almost none of it is Claude Code.
Take it if
You ship Claude features and your company is in the Claude Partner Network.
Skip it if
You mostly design systems and hand them off. Take the Architect exam instead, because it tests judgment over API detail.
Before you start
Check yourself against this list first. If something is missing, close that gap before you pay for an exam.
One to five years of software engineeringAnthropic recommends this, and a third of the exam assumes it.
Six months with Claude or a comparable LLMShip one small feature first. Reading alone will not get you there.
Python or TypeScript, REST and CLI toolsBe comfortable with async code and reading JSON responses.
Your employer is in the Claude Partner NetworkOnly partner staff can register. Membership is free to apply for. Learn more
1 to 5 years of software engineering, 6+ months with Claude or a comparable LLM
If you fail
Wait 14, then 30, then 90 days
What the exam covers
Agents and Workflows14.7%
Applications and Integration33.1%
Claude Code3.1%
Eval, Testing, and Debugging2.6%
Model Selection and Optimization16.8%
Prompt and Context Engineering11.0%
Security and Safety8.1%
Tools and MCPs10.6%
What to focus on
The Messages API in detail: streaming, tools, vision, thinking, caching, and when batch beats realtime.
Ordinary engineering: REST, JSON, async, version control, code review and refactoring. Do not skip this because it feels easy.
Model tiers and cost: Opus against Sonnet against Haiku, token budgets, prompt caching and cache checkpoints.
Choosing between a built-in tool, a custom tool, a Skill and an MCP server. That trade-off alone is 4.1% of the exam.
Claude Code is only 3.1% here against 20% on the Architect exam. Know CLAUDE.md, settings.json and headless mode, then move on.
Everything on one mapEvery topic and key idea in this certification.
mindmap
root((CCDV-F))
Agents and workflows
Workflow or agent
Custom loop or Agent SDK
Subagents
The API and integration
Realtime or batch
Streaming
Configuration
Claude Code and debugging
CLAUDE.md hierarchy
Headless mode
Isolating a failure
Model choice and cost
Tiers
Prompt caching
Thinking and effort
Prompts and context
Context drift and bloat
Instruction placement
Defensive parsing
Security and safety
Prompt injection
Hooks as guardrails
Keys and access
Tools and MCP
Tool descriptions
Client and server tools
Tool, Skill or MCP
The loop every agent runsYour code owns the loop. Claude only asks for tools to be run.
sequenceDiagram
participant App as Your code
participant C as Claude
participant T as Tool
App->>C: Messages plus tool definitions
loop While stop_reason is tool_use
C-->>App: tool_use block
App->>T: Run the tool
T-->>App: Result
App->>C: Append tool_result and call again
end
C-->>App: Final answer with end_turn
Lesson 1 of 7, 14.7% of the exam
Agents and workflows
You need to know when an agent earns its extra cost, and how to build one when it does.
Workflow or agent
If the steps are known in advance, a workflow is cheaper and easier to test. Use an agent when the path depends on what it finds.
Custom loop or Agent SDK
A custom loop gives full control. The Agent SDK gives you the loop, tools and hooks ready-made, so you write less plumbing.
Subagents
A subagent works in its own context, which keeps long discovery output out of the main conversation.
Workflow or agentFixed steps stay in your code. Open-ended work goes to the model.
flowchart LR
subgraph W["Workflow: you own the order"]
W1["Extract"] --> W2["Validate"] --> W3["Store"]
end
subgraph A["Agent: the model picks the next step"]
A1["Goal"] --> A2["Choose a tool"]
A2 --> A3["Observe the result"]
A3 --> A2
A3 --> A4["Done"]
end
Common trap
Reaching for an agent when the steps never change. Questions like this usually want the workflow.
Try it yourself
Build the same task twice, as a fixed chain and as an agent, then compare cost and how predictable each is.
This is a third of the exam, and it is mostly normal engineering applied to the Messages API.
Realtime or batch
Use the Messages API when someone is waiting. Use batch when a job can wait, because it costs less and has no latency promise.
Streaming
Streaming shows tokens as they arrive. Total generation time stays the same, but people feel the wait far less.
Configuration
Pin model versions, version your prompts, and keep CLAUDE.md and settings.json in the repo, so behavior changes through review.
Which API call fits?Start from whether a person is waiting.
flowchart TD
A{"Is someone waiting?"} -->|Yes| B{"Long answer?"}
A -->|No| C{"Large volume?"}
B -->|Yes| D["Messages API with streaming"]
B -->|No| E["Messages API"]
C -->|Yes| F["Message Batches API"]
C -->|No| E
Common trap
Skipping the software engineering objectives because they look easy. REST, JSON, async, Git and refactoring carry real marks.
Try it yourself
Build one small service that streams answers, accepts an image, and sends a nightly batch.
These two are small here, so learn the essentials and stop. Together they are under 6%.
CLAUDE.md hierarchy
User, project and directory files stack. Only project files reach your teammates.
Headless mode
Running with -p makes Claude Code non-interactive, which is what you need in scripts and CI.
Isolating a failure
Look at the trace first. Decide whether the integration sent the wrong thing or the model returned the wrong thing, then fix that side.
Where CLAUDE.md appliesLater levels add to the earlier ones. Only project files reach teammates.
flowchart TD
A["~/.claude/CLAUDE.md, you only"] --> B["Project CLAUDE.md, shared in Git"]
B --> C["Subdirectory CLAUDE.md, that folder"]
C --> D["What Claude Code loads for a task"]
Common trap
Over-preparing here because you use Claude Code daily. The Architect exam weights it far higher.
Try it yourself
Add a project CLAUDE.md, run one task with -p, then break a tool call on purpose and find it from the trace.
Every design decision has a price, and this domain tests whether you can reason about it.
Tiers
Opus, Sonnet and Haiku trade capability against cost and speed. Test on your own task before you decide.
Prompt caching
Caching matches an exact prefix, so stable content goes first and anything that changes goes last.
Thinking and effort
Extended thinking and effort settings spend more tokens for harder problems. They are not free defaults.
How a cached prompt is builtStable content first. One changed byte in the prefix misses the cache.
flowchart LR
A["Tools"] --> B["System prompt"] --> C["Long documents"] --> D(["Cache breakpoint"]) --> E["Latest user message"]
D -.-> F["Everything before this can be reused"]
E -.-> G["Changes on every call, so it goes last"]
Common trap
Putting a timestamp or user name at the top of a cached prompt. The prefix changes, so the cache never hits.
Try it yourself
Cache a large system prompt, then read the cache fields in the usage response and work out your saving.
Long sessions fail quietly, so you need to control what stays in context.
Context drift and bloat
Tool output piles up and pushes out what matters. Prune it, compact it, or move the work to a subagent.
Instruction placement
Stable rules belong in the system prompt, and few-shot examples show the format better than more rules.
Defensive parsing
Validate model output, because a confident answer can still be malformed or wrong.
Keeping context under controlEach option removes a different kind of bloat.
flowchart TD
A{"What is filling the context?"} -->|"Verbose tool output"| B["Prune fields before they enter"]
A -->|"Long history"| C["Compact into a summary"]
A -->|"Exploration noise"| D["Move it to a subagent"]
A -->|"Facts must survive"| E["Keep a case-facts block"]
Common trap
Assuming max_tokens controls context. It only limits the reply.
Try it yourself
Trim a verbose tool result to the fields you use and measure the token difference over ten turns.
Treat retrieved content as data, not instructions, and keep it apart from your trusted prompt.
Hooks as guardrails
Hooks run in your code, so they hold even when the model is persuaded. Prompt rules do not.
Keys and access
Keep secrets out of prompts and repos, and give each component the least access it needs.
Where a prompt injection gets stoppedThe model may be fooled. The hook is not, because it runs in your code.
sequenceDiagram
participant D as Web page
participant C as Claude
participant H as Hook
participant T as Sensitive tool
D->>C: Hidden text says send the data out
C->>H: Tool call requested
H-->>C: Blocked by policy
Note over H,T: The tool never runs
Common trap
Fixing injection with a sentence in the system prompt. That is a request, not a control.
Try it yourself
Plant an instruction in a test document, then block the dangerous tool call with a hook.
Most agent quality problems are really tool design problems.
Tool descriptions
The description is how the model chooses. Say what the tool returns and when to use it over similar ones.
Client and server tools
Client tools run in your code. Server tools run on Anthropic's side, so the loop differs.
Tool, Skill or MCP
A Skill packages know-how, a custom tool does one job for one app, and MCP shares an integration across many apps.
Pick the right extension pointThe exam weights this choice at 4.1%.
flowchart TD
A{"What do you need?"} -->|"Repeatable know-how"| B["Skill"]
A -->|"An action in one app"| C["Custom tool"]
A -->|"One integration for many apps"| D["MCP server"]
A -->|"Read or search files"| E["Built-in tool"]
Common trap
Building an MCP server for something only one app uses. A custom tool is simpler.
Try it yourself
Write one MCP server with two tools, connect it to Claude Code, and improve the descriptions until selection is reliable.
Exam facts checked on October 31, 2026 against CCDV-F exam guide, July 2026. Lessons are our own explanations, so use the official docs as the final word, and confirm price and dates before booking.
