Claude Certification Blog

Agent SDK, Claude Code, or the API: which one the exams mean

Three surfaces sit between you and the model, and the four Claude certification tracks weight them so differently that preparing from the wrong track's material is a calibration error no amount of revision fixes.

20% versus 3.1%Which layer owns itNo code required

8 min read

The Agent SDK, Claude Code and the raw API are three levels of the same stack, and the exams treat them as three different subjects. CCAR-F gives Claude Code an entire domain worth 20% of the paper. CCDV-F gives Claude Code Operation 3.1% and spends 6.8% on API mechanics instead. Nothing on any track asks you to write code against any of them. What is examined is which layer owns a given decision, and what you gave up to get the layer above it.

20%CCAR-F Claude Code domain
3.1%CCDV-F Claude Code skill
6.8%CCDV-F API mechanics
5.3%CCDV-F agent construction

The three surfaces, in one table

SurfaceWhat you are responsible forWhere it is examined
The APIYou own the loop, the state and every retryCCDV-F, 6.8% as API mechanics
The Agent SDKThe loop is supplied; you own tools, hooks and limitsCCAR-F O05, CCDV-F 5.3%
Claude CodeA configured harness you steer rather than buildCCAR-F 20%, CCDV-F 3.1%

Read down the middle column and the pattern is a handover. At the API you write the loop that gathers context, calls, inspects the result and decides whether to go again. The SDK hands you that loop and asks you to supply the parts that are specific to your problem. Claude Code hands you a working environment and asks you to configure it. Each step up removes work and removes a decision, and the exams care about the second half of that sentence.

How differently the tracks weight them

What each layer gives you and what it takes backEACH LAYER TRADES A DECISIONAPIEvery decision is yours to makeAgent SDKThe loop is given; its shape is now yoursClaude CodeYou steer the environment, not its design
Every row is a benefit and a burden in one sentence, which is the whole reason more than one layer exists.

The weight gap is the practical point. Twelve items on CCAR-F turn on configuration files, scoping, plan mode, permissions and workflow integration. One or two items on CCDV-F turn on the same product. If you are sitting CCDV-F, the depth that CCAR-F candidates need on this material is time you do not have — 8.6% of your paper is application design and 7.4% is software engineering foundations, both inside the domain that is a third of that exam. The published domain weights are worth checking before you allocate a single evening.

Borrowed study material is a calibration risk, not just a scope risk

Most of what circulates about the Claude exams is written for one track and read by candidates sitting another. The content is often correct and the emphasis is often wrong, which is harder to notice: nothing you read is false, and you still spend a week on something worth one item.

The question every item is really asking

Strip the product names out of these scenarios and a single question remains: at which layer does this decision belong. A retry that must not repeat a side effect is not an SDK feature, it is a property of the operation. A rule that must hold on every run is not a configuration preference, it is an interception point. A limit on what an agent can reach is not an instruction, it is the set of tools it was given.

That is why the answers rarely name a product. The option that says “use the built-in feature for this” is attractive and frequently wrong, because the built-in feature is a default and the scenario has already described a requirement the default does not meet.

Hooks: where enforcement actually lives

Both developer-facing tracks examine this, and it is the clearest example of the layer question. CCAR-F names Agent SDK hooks for tool-call interception and data normalisation as an objective. CCDV-F publishes Claude Hooks as a skill in its Security and Safety domain, worth 1.0% of the paper.

A hook sits in front of a tool call and decides whether it proceeds. An instruction sits in the context and asks the model to make a particular choice. Both are legitimate, and only one of them still works on the run where the model gets it wrong. Where a scenario uses the words never, always or without exception, the instruction-shaped option is the distractor — the same shape covered in prompt injection and guardrails and in Claude Code configuration.

The unattended case

CCAR-F carries an objective on integrating Claude Code into CI/CD pipelines, and it exists to test one shift: with nobody at the keyboard, a decision that would have been made on the spot has to have been made in advance. Anything that would pause for approval simply stops. Anything you would have noticed by watching has to be reconstructed from what the run left behind.

Two adjacent traps show up here. Fewer approval prompts is not the same as fewer safeguards, and a setting that answers on your behalf is a different thing from one that skips the check. And the verification burden moves in inverse proportion to how closely you watched — see writing evals for how the exams expect that evidence to be produced.

Preparing for the right one

The practical advice is short. Find your track's published weights, and spend time in proportion to them rather than in proportion to how interesting the material is. Claude Code is the most enjoyable surface of the three to study and it is worth 3.1% on CCDV-F. API mechanics is the least glamorous and it is worth more than twice that on the same paper.

If you are still deciding which exam to sit, the certification chooser compares the four on scope rather than on difficulty, which is the more useful axis. And if you have already sat one and are moving to another, treat the overlap as smaller than it looks: going from one track to the next is mostly a re-weighting exercise.

Key takeaways

  • Three surfaces, three weightings. Claude Code is 20% of CCAR-F and 3.1% of CCDV-F; API mechanics is 6.8% of CCDV-F and background elsewhere.
  • Each layer trades a decision for a default. The exams ask what you gave up, not how to call the thing you gained.
  • No code is required. Nothing on any track asks you to write against the SDK, the CLI or the API.
  • A hook decides; an instruction asks. Where the scenario says the rule must always hold, the instruction-shaped option is the distractor.
  • Unattended changes the question. Permissions get settled in advance and verification is reconstructed afterwards.
  • Borrowed material mis-calibrates you. Content written for another track is usually true and usually weighted wrong.

The weighting only becomes real when you sit a full paper

Reading a blueprint tells you what a domain is worth; a timed mock tells you where your hour actually goes. Papers built to your track's own allocation are the fastest way to find out whether you have been studying the enjoyable 3% or the decisive 8%. Our claude certification study guide covers how to sequence them.

See the CCAR-F blueprint

Questions

Frequently asked

The follow-up questions people search next.

Do the Claude exams test the Agent SDK?

CCAR-F does, by name: one of its objectives is applying Agent SDK hooks for tool-call interception and data normalisation. CCDV-F reaches the same material through Agent Construction with Claude, a published skill worth 5.3% of that paper. Neither asks you to write SDK code.

How much of the exam is Claude Code?

It depends entirely on the track. CCAR-F has a whole domain for it — Claude Code Configuration and Workflows, 20% of a 60-item paper, roughly 12 items. CCDV-F publishes Claude Code Operation as a 3.1% skill, roughly one or two items on a 53-item paper. That is a sixfold difference in what the same product surface is worth.

Do I need to know the API to pass?

On CCDV-F, Claude API Mechanics is a 6.8% skill covering messages, tools, streaming, caching and stop reasons — the second-heaviest single skill after application design. On the other three tracks the API appears as background rather than as an examined surface.

What is the difference between a hook and an instruction?

A hook intercepts a tool call before it runs, so it decides whether the action happens. An instruction asks the model to behave a certain way, so it influences a decision the model still makes. That distinction is examined directly, and the option that offers an instruction where the scenario needs a guarantee is the standard wrong answer.

Is deploying or hosting any of this examined?

No. Infrastructure for running integration servers sits on the out-of-scope lists. Configuration, scoping, permissions and failure behaviour are examined; provisioning is not.

Keep reading

Related posts

Not affiliated with, or endorsed by, Anthropic or Pearson VUE. Details are summarised from publicly published program 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.