Eval, testing and debugging on CCDV-F: one skill, about one item, and no eval objective

Eval, testing and debugging on CCDV-F is Domain 4 of the Claude Certified Developer Foundations blueprint: 2.6 percent of 53 items, which rounds to one question. Despite the title, the v1.0 exam guide publishes a single skill under it, Debugging and Error Handling, and no skill statement on the CCDV-F blueprint contains the word eval or test outside that title. The item asks you to name an error type, pick a matching recovery, read a trace, or say whether the integration layer or the model output failed, before choosing a fix.

What eval, testing and debugging on CCDV-F weighs

Section 6 of the official guide gives Domain 4 a weight of 2.6 percent and one skill beneath it, Debugging and Error Handling, at the same 2.6 percent. On a 53-item paper that is 1.38 items, so the whole-number allocation is one scored question. It is the smallest domain weight on any of the four Claude blueprints: no domain on CCAO-F, CCAR-F or CCAR-P is under 7 percent.

Source: Claude Certified Developer Foundations Exam Guide v1.0, Section 6, Domain 4, from the Partner Academy certification page. Checked against the official sources on 17 September 2026. One item is an allocation, not a guaranteed count.

The name is the part worth noticing. Section 2 of the guide lists designing and running evals, trace analysis, validating structured output and monitoring production quality as one area a holder can demonstrate. The blueprint then splits that sentence: trace analysis lands here, response validation lands in Domain 6 under Output Handling, and eval design and production monitoring get no skill statement at all. A CCDV-F candidate studying eval methodology for this domain is preparing for a question the blueprint does not weight; that discipline is examined on CCAR-P at 16 percent and is set out in writing Claude evals for the exams.

Four competencies in one skill statement

The skill statement names error type identification, recovery strategy selection, trace analysis to identify failure modes, and problem origin isolation between the integration layer and model output. Each is a decision rule with a characteristic distractor, and the CCDV-F debugging and error handling item is built around one of them.

The official reference for the first two rows is the API errors documentation, which separates request, authentication and permission failures from rate-limit and overload responses; the tool call handling page covers errors inside a tool result. The item tests the distinction, not the page.

Integration layer or model output: the isolation rule

Nearly every plausible Domain 4 item turns on one distinction. An integration failure is a defect in the request, the transport, a tool or the response handling, and it is deterministic: identical input fails identically. A model output failure is a valid exchange whose content is wrong, and it is probabilistic: identical input may pass next time. The remedies are disjoint, so reproduce first.

The distractors are a firmer prompt for a parsing bug, and a retry for an answer that will be wrong again. Both begin with a remedy, which is the tell. The cross-track version of the rule is in troubleshooting on the Claude exams; the CCDV-F item adds the reproducibility test.

Match the recovery to the error type

Recovery follows classification, and the second distractor family treats every failure the same way. A transient failure (a rate limit, an overload, a timeout) is the only class where re-sending unchanged input is reasonable, and then with backoff and a bounded count. A validation failure means the input was wrong, so the input changes first. A permission failure means the caller is not authorised: escalate, since proceeding without the data is worse than stopping. A content failure means the pipeline worked and the answer did not, so change the prompt, context or grounding, never a bare retry.

One case sits outside the four, and the architect guide spells it out: a query that ran and matched nothing is a result, not an error, a point developed in tool design and MCP on CCAR-F. The classic miss is a retry wrapper that treats a permission error like a timeout: three attempts, three times the latency, one real failure.

Read the trace forwards, not backwards

A trace is the record of what happened: the requests, the tool calls, what each returned, and where the sequence left the intended path. The CCDV-F trace analysis skill is to locate the earliest divergence, not the loudest. Because a failure shows up downstream of whatever caused it, a backwards read from the symptom finds only the symptom. Two patterns recur: a step that returned nothing without raising anything, which never shows red in a log, and an error that surfaces one request after its cause.

A worked item written for this post

Two planning consequences. Spend one study session here and put the saving into Applications and Integration, a third of the paper. And read a percentage on a one-item domain as pass or fail, since it can only show 0 or 100; a miss is one question, not a verdict. The Claude certification study guide covers weighting a plan by blueprint share, and the which Claude certification guide compares the four tracks. The free 53-item CCDV-F mock follows the same allocation, so its Domain 4 filter is one item; the practice exams guide lists what else exists.

Key takeaways

• Domain 4 is 2.6 percent of 53 items, about one question, the smallest domain weight on any Claude blueprint.
• Its only published skill is Debugging and Error Handling. No CCDV-F skill statement contains the word eval or test outside the domain title.
• Reproduce before you remedy. Identical input failing identically is the integration layer; varying or valid-but-wrong output is the model.
• Retry only transient failures, change the input for validation failures, escalate permission failures, and treat a valid empty result as a result.
• Read a trace forwards to the first divergence, watching for silent empties and errors that surface one request late.