Claude Certified Developer – Foundations

1-Day Before Exam Review Notes

Use this as a final refresher, not as a replacement for the official certification materials or hands-on practice. Focus on architecture and implementation decisions, failure handling, tool boundaries, evaluation, and security—not memorizing phrases.

Aligned to the current CCDV-F practice blueprint · Updated October 2026

Start Free Mock Exam Official Certifications Page ↗

First: remember the practice blueprint

14.7%

Agents & Workflows

33.1%

Applications & Integration

3.1%

Claude Code

2.6%

Eval, Testing & Debugging

16.8%

Model Selection & Optimization

11.0%

Prompt & Context Engineering

8.1%

Security & Safety

10.6%

Tools & MCPs

1. Agents & Workflows

14.7%

Use deterministic workflows when the steps are known in advance; use agentic loops when the next action depends on intermediate results. Do not add autonomy where a fixed sequence is safer and easier to test.
For tool-using loops, inspect the model response, execute requested tools, return tool results, and continue until the model finishes. Treat the model’s stop condition as protocol state rather than trying to infer completion from natural-language wording.
Separate planning, execution, validation, and escalation when the task benefits from clear control boundaries. A coordinator should pass only the context a worker needs instead of copying the entire conversation everywhere.
Parallelize independent work, but keep dependent steps sequential. Parallel tool calls help latency only when the calls do not require each other’s results.
Escalate when policy, authorization, missing evidence, or repeated inability to progress makes further autonomous action unsafe. A human handoff should include concise facts, actions taken, unresolved issues, and required next steps.

2. Applications & Integration

33.1%

The Messages API is stateless from the service perspective: your application is responsible for sending the conversation context needed for each request. Keep only the context that is useful for the next step.
Design for partial failure. Timeouts, rate limits, malformed tool inputs, unavailable downstream services, and retries are normal production conditions. Retry transient failures with bounds and backoff; do not retry permanent validation or permission failures blindly.
Use streaming when users benefit from lower perceived latency, but do not confuse partial streamed output with a complete validated result. Downstream actions should wait for the required completion and validation conditions.
Keep secrets and privileged credentials on the server. Browser code should never contain API keys, answer keys, internal authorization tokens, or privileged integration credentials.
For structured application outputs, validate against a schema and then validate business meaning separately. Schema correctness does not guarantee that the values are true, complete, authorized, or internally consistent.
Use idempotency or application-side deduplication for actions that could be repeated after retries, especially payments, ticket creation, provisioning, notifications, and other side-effecting operations.
Instrument latency, token usage, error rates, tool-call outcomes, retries, and task-level success. Production quality is measured by end-to-end task outcomes, not only whether the model returned text.

3. Claude Code

3.1%

Keep durable project-wide instructions in CLAUDE.md and more specialized instructions close to the relevant project area. Avoid loading every possible convention into every task when only a subset is relevant.
For larger changes, inspect the repository and existing instructions before editing. Prefer small, reviewable changes and validate with the project’s real build, tests, and lint/typecheck commands.
Use non-interactive/print-oriented execution for automation and CI scenarios, and machine-readable output when another system must consume the result.
Treat Claude Code as an engineering collaborator, not a substitute for repository controls. Branch isolation, code review, tests, secret handling, and deployment authorization still matter.

4. Eval, Testing & Debugging

2.6%

Define an evaluation around the behavior you need: representative inputs, expected properties, failure conditions, and a scoring method. Do not require exact string matches when multiple outputs could be equally correct.
Temperature 0 does not make model output perfectly deterministic. Tests should target functional contracts and behavioral assertions rather than assuming identical wording on every run.
Separate generation from evaluation when possible. A reviewer should use explicit criteria and test cases instead of simply asking the same model whether its prior answer looks good.
When debugging, isolate whether the failure came from prompt/context, model behavior, tool execution, integration code, permissions, or downstream data before changing multiple layers at once.

5. Model Selection & Optimization

16.8%

Choose models from measured workload requirements: quality, latency, cost, context needs, tool use, reliability, and safety. The newest or largest model is not automatically the best production choice.
Start with a strong reference model to establish quality, then test whether a faster or lower-cost model meets the same acceptance criteria. Optimize only after you have an evaluation baseline.
Reduce cost by removing irrelevant context, shortening repeated instructions, caching or reusing stable context where supported, batching latency-tolerant work, and selecting an appropriately capable model.
Do not trade away correctness or safety for token savings without measuring the effect. Optimize task-level cost per successful outcome rather than cost per individual API call.
Use controlled experiments for prompt or model changes. Compare on the same representative test set and inspect regressions by task category rather than trusting a single aggregate score.

6. Prompt & Context Engineering

11.0%

Put stable role, policy, output, and tool-use instructions in the system layer; put task-specific data and user intent in the user message. Keep instructions unambiguous and avoid conflicting requirements across layers.
Use examples when the desired judgment or output format is hard to specify abstractly. Examples should demonstrate the decision boundary, not just repeat nearly identical easy cases.
Longer context is not automatically better. Keep high-value facts, remove irrelevant history, summarize bulky tool output, and preserve critical identifiers and constraints through compaction or handoffs.
When source evidence is required, keep claim-to-source provenance intact. A fluent answer without traceable support is not equivalent to a verified answer.
Treat retrieved or user-supplied content as data unless it is explicitly trusted instruction. Prompt injection can arrive through documents, webpages, tool output, or other external content.

7. Security & Safety

8.1%

Use least privilege for tools and integrations. An agent should receive only the permissions and actions required for its current role and task.
Keep authorization checks outside model discretion for sensitive actions. The model can recommend an action, but deterministic application logic should enforce identity, permissions, limits, and policy gates.
Treat external content as potentially adversarial. Do not allow retrieved text, webpages, emails, or documents to silently override trusted system instructions or expand tool permissions.
Protect secrets in logs, prompts, browser bundles, telemetry, and error messages. Redact or avoid storing sensitive values that are not necessary for observability.
Require confirmation or human approval before high-impact or irreversible operations when the workflow calls for it. Safety boundaries should be enforceable even if the model behaves unexpectedly.

8. Tools & MCPs

10.6%

A tool definition needs a clear name, description, and input schema. Good descriptions make tool boundaries obvious and reduce ambiguity between similar tools.
Validate tool arguments before execution and validate returned data before using it. A syntactically valid tool request can still be unauthorized, unsafe, or semantically wrong.
Return structured tool errors that distinguish validation, permission, business-rule, transient, and unavailable-service failures. The orchestrator should not have to parse prose to determine retry behavior.
MCP standardizes how AI applications discover and use tools, resources, and related capabilities. Use it to create consistent integration boundaries rather than embedding one-off connector logic into every prompt.
Use resources for reference/context that should be discoverable and tools for actions or computations. Keep credentials and privileged configuration outside shared source-controlled MCP definitions.
Fewer well-scoped tools are often more reliable than a large overlapping tool catalog. Give the model only the tools relevant to the current task whenever practical.

High-value distinctions to remember

Workflow vs agent

Fixed known sequence vs dynamic next-step selection based on intermediate results.

Schema-valid vs correct

Structured output can satisfy a schema and still contain wrong or unsupported values.

Retryable vs permanent failure

Retry timeouts/rate limits selectively; fix validation, authorization, or policy failures instead of repeating them.

Model quality vs system quality

A strong model cannot compensate for weak permissions, broken tools, missing validation, or poor observability.

Prompt instruction vs enforced control

Prompts influence behavior; application logic, permissions, and policy gates enforce behavior.

Context quantity vs context quality

More tokens can add noise. Preserve the facts and evidence that actually affect the next decision.

Final 30-minute checklist

Re-read the differences between fixed workflows, agents, parallel calls, and human escalation.
Review API failure handling: rate limits, timeouts, retries, idempotency, streaming, and server-side secret boundaries.
Review tool schemas, validation, MCP resources vs tools, structured errors, and least-privilege permissions.
Review evaluation design and why temperature 0 does not imply perfectly deterministic output.
Review model-selection tradeoffs using measured quality, latency, cost, context, and safety requirements.
Review prompt-injection boundaries and why deterministic authorization belongs outside the model.
Stop studying new material. Use the mock exam or missed-question review only to reinforce weak areas.

These are independent preparation notes for AICertPilot users. They are not official Anthropic exam materials, are not affiliated with or endorsed by Anthropic, and do not represent an official passing score or guarantee exam coverage.