Anthropic Claude Certified Developer - Foundations CCDV-F Exam Questions

Page: 1 / 14
Total 95 questions

Want more questions? Get Premium Access.
()

Question 1

The product team has asked you to choose a Claude model for a new feature. The team has provided functional requirements but has not specified performance, cost, or quality targets. The team's product manager says, "Use whatever model gives us the best results."

How would you respond?

AAsk the product team to specify quality, latency, and cost targets, then select the model whose tradeoffs best fit those targets.

BRun every Claude model on a representative sample and pick whichever scores best on a generic benchmark.

CChoose a mid-tier model and ship the feature, because mid-tier models work for most use cases without specified targets.

DChoose the largest, highest-capability Claude model, on the grounds that 'best results' is most likely to mean highest quality.

Answer : A

Option A is correct because model selection requires measurable non-functional requirements, not an undefined objective such as ''best.'' Anthropic's model-selection guidance explicitly frames the decision around capabilities, speed, and cost and recommends identifying those requirements before narrowing the candidate models.

''Quality'' must also be translated into task-specific success criteria---for example classification accuracy, extraction correctness, acceptable false-positive rate, or human preference. Latency may be constrained by an interactive SLA, and cost may be defined per request, per user, or per completed task. Once those thresholds exist, representative evaluations can compare candidate models using the actual prompts and data.

B uses a generic benchmark that may not correlate with the application's workload. C chooses a model tier without requirements or evidence. D optimizes only for raw capability and ignores latency and cost, potentially producing an unnecessarily expensive architecture.

Thus, requirements definition precedes technology selection. Relevant Study Guide topics: Understanding Reqs, functional versus non-functional requirements, quality thresholds, latency budgets, cost constraints, acceptance criteria, workload-specific evaluation, and model-selection tradeoffs.

===============

Question 2

You are setting up the configuration management approach for a new Claude Code project. Your team will use CLAUDE.md files and settings.json files to control behavior, and you want to make sure changes are tracked and reviewable.

The configuration management approach would...

ADuplicate CLAUDE.md and settings.json files in multiple repositories to provide redundancy, on the grounds that a single source of truth is risky for project configuration.

BVersion-control CLAUDE.md and settings.json files in a separate repository from the project's source code, so configuration evolves independently from the application code over time.

CVersion-control CLAUDE.md alongside the project's source code and settings.json files in a separate repository from the project's source code.

DVersion-control CLAUDE.md and settings.json files alongside the project's source code, with changes reviewed through standard pull request workflows the team applies.

Answer : D

D applies configuration as code and is the answer explicitly selected in the supplied examination source. Claude Code treats project configuration as part of the repository's working context. Anthropic documents project-level CLAUDE.md as the mechanism for providing project instructions and context, while shared project configuration belongs in .claude/settings.json. Crucially, Anthropic states that .claude/settings.json is intended to be checked into source control and shared with the team.

Keeping these files alongside the code establishes a single versioned relationship between application behavior and the configuration that influences Claude Code. Standard pull requests then provide diffs, peer review, ownership controls, CI validation, audit history, and straightforward rollback. A particular commit can therefore reproduce both source code and its associated Claude project configuration.

A creates competing copies and synchronization risk. B artificially separates behavior configuration from the code version it affects. C creates the same problem specifically for settings.json.

Developer-local values remain distinct: .claude/settings.local.json exists specifically for settings that should not be committed.

Relevant Claude Developer topics: Confia Management, CLAUDE.md, settings.json, configuration as code, source control, pull-request review, reproducibility, auditability, and team-shared Claude Code configuration.

Question 3

Your Claude application validates structured output but has been treating validation failures as terminal errors. Each validation failure causes the entire user request to fail. The team wants to handle validation failures more gracefully.

How would you handle the validation failures?

APass validation failures directly to downstream systems and let each downstream system decide how to handle the malformed output.

BDisable output validation until the underlying cause of validation failures has been identified and addressed in a future release.

CTreat validation failures as a recognized error path that triggers retry, repair, or fallback logic before failing the user request.

DTell users that validation failures are unavoidable and instruct them to perform manual accuracy checks before relying on outputs.

Answer : C

C converts validation failure from an uncontrolled terminal condition into a first-class recoverable error path. The supplied exam item identifies C as correct. If structured output does not meet the application's contract, it should never be forwarded as though valid, but immediate user-visible failure is also unnecessary when bounded recovery is possible.

A robust flow can retry generation, ask Claude to repair the malformed structure using the validation error as feedback, switch to an approved fallback path, or ultimately return a controlled failure if the retry budget is exhausted. The application must cap these recovery attempts to avoid unbounded loops.

Anthropic's Structured Outputs documentation explains that unconstrained model generation can produce parsing errors, missing fields, inconsistent types, or schema violations that otherwise require error handling and retries. Current Structured Outputs can eliminate many schema-level failures through constrained decoding, although exceptional conditions such as refusal or output truncation still require explicit handling.

A violates the validation boundary. B removes a protective control. D transfers an engineering reliability responsibility to end users.

Relevant Claude Developer topics: Claude App Design, structured output, validation, retries, repair loops, fallback logic, bounded recovery, error paths, and resilient downstream integration.

===============

Question 4

Your team uses several plugins across multiple Claude applications, and a recent plugin update introduced a regression. The team had not been tracking plugin versions, so the team cannot easily identify which version was previously working. How would you address this?

AStop using all plugins until the team can rebuild equivalent functionality directly into the application code, treating plugin avoidance as a way to remove version-related risk.

BAdd explicit plugin version tracking to the project's configuration so the team can identify, pin, and upgrade plugin versions deliberately.

CTreat plugins as untrackable third-party code and rely on plugin authors to communicate breaking changes when they happen, with no internal version tracking.

DUpgrade every plugin to the latest version on a regular cadence to keep version drift small, on the grounds that drift contributes to regression risk.

Answer : B

Option B is correct because plugin dependencies and releases must be versioned deliberately if the team wants reproducible behavior and a reliable rollback path. Claude Code's plugin documentation supports explicit semantic versions in plugin manifests and marketplace entries, and the plugin system uses the resolved version as part of update detection and caching. Version constraints can also keep dependent plugins on a tested compatible range until the team intentionally upgrades.

The incident happened because the team could not determine which plugin version had previously worked. Explicit tracking solves that directly: record the version in project configuration, pin known-good releases where stability matters, test upgrades, and change versions through reviewed configuration updates. This creates traceability and makes regression isolation much faster.

Option A removes useful extension functionality instead of managing it. Option C treats third-party change as uncontrollable even though the platform provides version-management mechanisms. Option D automatically moving everything to the latest release increases change frequency and can reproduce the same regression problem.

Therefore, B is the correct configuration-management response. Relevant Study Guide topics: Claude Code plugins, semantic versioning, dependency constraints, reproducible configuration, controlled upgrades, rollback, and configuration management.

Question 5

A Claude application that worked well in testing is now occasionally returning outputs that mention information not present in the input. The development team initially assumed the model was hallucinating, so they asked you to troubleshoot.

What would you do first?

AExamine production traces to identify whether the issue is hallucination by the model, context loss, prompt injection, or another failure mode before recommending a fix.

BReplace the current model with a larger one to reduce the chance of hallucination, on the grounds that larger models tend to hallucinate less in typical applications.

CApply a retrieval-augmented generation pattern to ground the responses in source content before any further investigation of the production traces.

DAdd a system prompt instruction telling the model not to invent information, on the grounds that prompt-level instructions are the fastest fix for hallucination concerns.

Answer : A

Option A follows disciplined production debugging: diagnose the actual failure mode before changing architecture or prompts. An output containing unsupported information might indeed be hallucination, but similar symptoms can result from stale conversation state, incorrect retrieval, unexpected tool output, prompt injection, incorrect request construction, or mismatched model/configuration versions.

A production trace should capture the user input, system instructions, relevant conversation history, retrieved content, tool calls and results, model/version, request parameters, response, and identifiers necessary to compare successful and failing cases. This establishes whether the model invented a fact or whether that fact entered context through another path.

B changes the model before establishing causality. C may eventually be useful if the confirmed problem is insufficient grounding, but implementing RAG before diagnosis can hide rather than explain the defect. D similarly changes prompting before verifying that prompt behavior is responsible.

The engineering sequence should be observe, reproduce, classify the failure, form a hypothesis, apply a targeted correction, and validate the correction with evaluations. Relevant Study Guide topics: production troubleshooting, observability, tracing, hallucination analysis, prompt injection, context failures, regression diagnosis, and lifecycle monitoring.

===============

Question 6

The Claude application your team built has grown over six months, and the prompt-handling code has accumulated duplication and tangled control flow. The functionality is working, but new features are getting harder to add.

How would you address this?

APlan a refactoring pass to consolidate duplicated logic, separate concerns, and simplify control flow before adding new features.

BRefactor the prompt-handling code in small increments as part of each new feature ticket, treating the cleanup as a side effect of feature work.

CContinue adding features and plan a refactoring pass after the next two release cycles when the team has more bandwidth for internal work.

DMove all the prompt-handling code into a single large function to reduce the number of files developers have to navigate when reading the code.

Answer : A

The supplied Claude Developer item selects A. The symptoms---duplicated logic, tangled control flow, and increasing difficulty adding features---indicate accumulated technical debt in a component that has become structurally difficult to change. Because the problem is already materially reducing development velocity, deliberate refactoring should occur before additional feature pressure compounds it.

The objective is behavioral preservation with structural improvement. Duplicated prompt construction should be consolidated where the behavior is genuinely shared. Prompt preparation, configuration, API invocation, validation, error handling, and post-processing should have clear responsibilities. Control flow should be simplified so each stage is testable independently. Existing tests should first capture important current behavior so refactoring can proceed without silently changing application semantics.

B can be appropriate for minor cleanup, but the question describes broad systemic complexity. Mixing substantial structural refactoring into unrelated feature tickets makes scope, review, and regression analysis harder. C knowingly allows the debt to compound. D centralizes complexity rather than removing it and violates separation of concerns.

Relevant Claude Developer topics: SW Eng Foundations, refactoring, technical debt, DRY, separation of concerns, maintainability, modular design, regression testing, and control-flow simplification.

===============

Question 7

You are setting up a CI/CD pipeline for a new Claude application. The pipeline needs to run automated checks on every pull request before code can be merged.

The CI/CD checks would include...

AAutomated tests of the Claude integration, linting, and any other standard quality gates the team applies to its other services.

BA full end-to-end production deployment on every pull request to catch all possible issues before any code is merged into the main branch.

CAutomated tests of the Claude integration only, with linting handled separately during local development on each developer's machine.

DAutomated linting and security scanning, with Claude integration testing handled manually during pre-release verification by a designated reviewer.

Answer : A

Option A treats a Claude application as production software subject to the same disciplined engineering controls as other services while adding tests for its model integration. CI should provide repeatable feedback before merge, including deterministic unit/integration tests, linting, type or static checks where applicable, security checks, and organization-specific quality gates.

Claude-specific behavior should also be tested systematically rather than reserved for manual release verification. Anthropic's evaluation guidance recommends task-specific test cases reflecting realistic inputs and edge cases, measurable success criteria, and automation whenever practical. Claude Code documentation also explicitly identifies CI automation, including GitHub Actions and GitLab CI/CD, as supported development workflows.

B is excessive because every pull request should not directly deploy to production merely to obtain end-to-end coverage; testing environments and staged deployment exist for that purpose. C makes linting dependent on individual developer discipline rather than a shared merge gate. D delays Claude integration verification until pre-release and makes a repeatable automated check manual.

Therefore, A provides comprehensive and consistent pull-request validation. Relevant Study Guide topics: CI/CD, automated testing, integration testing, linting, evaluations, regression prevention, and quality gates.

===============