Free CCDV-F Model Selection and Optimization Practice Test — Claude Certified Developer Questions

This free CCDV-F Model Selection and Optimization practice test covers choosing the right Claude model and optimizing for cost, latency, and quality — model tiers, prompt caching, token counting, extended thinking, and context windows. Each question includes a detailed explanation aligned to Anthropic's official Claude Certified Developer – Foundations exam outline.

Key Topics in CCDV-F Model Selection and Optimization

6 Free CCDV-F Model Selection and Optimization Practice Questions with Answers

Each question below includes 4 answer options, the correct answer, and a detailed explanation. These are real questions from the FlashGenius CCDV-F question bank for the Model Selection and Optimization domain (16.8% of the exam).

Sample Question 1 — Model Selection and Optimization

A team is adding a Claude-powered intent router in front of a support system. The task is to map each message to one of 12 categories and return a short JSON label. A validation set shows simple examples with little ambiguity. Artifact: Workload: 3 million requests/month Target: p95 latency under 700 ms Business priority: lowest cost that still passes validation Quality bar: 95% label accuracy on held-out examples Current plan: use the most capable model for all requests What is the best initial model-selection approach?

  1. A. Start with Haiku and validate accuracy before rollout. (Correct answer)
  2. B. Use Opus because it provides the highest capability.
  3. C. Use extended thinking for every routing request.
  4. D. Use multi-shot examples with the largest context.

Correct answer: A

Explanation: Correct answer (A): For a high-volume, low-latency, cost-sensitive classification or routing task, Haiku is generally the best starting point when validation can confirm it meets the quality bar. The scenario describes a simple constrained-label task, a strict latency target, and a cost priority, so the developer should test the smaller/faster model rather than defaulting to a more expensive model or higher reasoning configuration. Why the other options are wrong: - Option B: Opus may be attractive because it is the most capable model, but the task is simple and highly cost- and latency-sensitive. It is not the best initial choice when a smaller model can be validated. - Option C: Extended thinking can help complex reasoning tasks, but this router only needs simple classification. It would add latency and token use without matching the stated priority. - Option D: Examples can improve behavior, but using many examples and the largest context increases token usage. The stem asks for model selection under a low-cost, low-latency goal.

Sample Question 2 — Model Selection and Optimization

A developer is building an internal contract review assistant. It summarizes clauses and flags unusual obligations for a legal operations team, but lawyers still review the final output. Artifact: Quality need: strong reasoning over long legal text Latency need: interactive responses under a few seconds when possible Budget: moderate; cannot use the highest-cost path for every request Risk: important, but not autonomous final decision-making Which model strategy is most appropriate as the default?

  1. A. Use Sonnet as the default and evaluate edge cases. (Correct answer)
  2. B. Use Haiku for all reviews to minimize cost.
  3. C. Use Opus for every clause regardless of complexity.
  4. D. Use fast mode only and skip quality evaluation.

Correct answer: A

Explanation: Correct answer (A): Sonnet is commonly the balanced default when an application needs strong quality while preserving better latency and cost than the most capable model. The task requires meaningful reasoning over legal text, so the smallest model for all cases is risky, but the scenario does not justify using the most expensive model for every request because lawyers review outputs and budget is moderate. Why the other options are wrong: - Option B: Haiku may reduce cost, but the scenario calls for strong reasoning over legal language. Choosing it for all reviews without validation would underweight quality requirements. - Option C: Opus may help the hardest cases, but the scenario states a moderate budget and interactive latency needs. Using it for every clause is not the best default. - Option D: Fast mode may improve latency, but skipping quality evaluation is inappropriate for a legal-review workflow with stated reasoning requirements.

Sample Question 3 — Model Selection and Optimization

A SaaS product uses Claude to answer questions about a customer's 80-page policy manual. Each request sends the same system instructions and the same manual, followed by a short user question. Artifact: Per request input: 58,000 stable tokens + 80 changing tokens Request pattern: 40,000 requests/day per large customer Manual update frequency: once per quarter Current issue: input-token cost is much higher than expected What is the best primary optimization?

  1. A. Use prompt caching for the stable manual prefix. (Correct answer)
  2. B. Switch every request to Opus for better quality.
  3. C. Increase output token limits for all answers.
  4. D. Move the changing question into the cached prefix.

Correct answer: A

Explanation: Correct answer (A): Prompt caching is most useful when many requests share a large, stable prefix or reusable context. Here, almost all input tokens come from the same manual and instructions repeated across many requests, while only a small user question changes. Caching the stable prefix can reduce repeated processing cost when the prompt is structured consistently around stable boundaries. Why the other options are wrong: - Option B: A larger model might improve quality in some cases, but the problem described is repeated input-token cost from stable context. Switching to Opus does not address that cost driver. - Option C: Increasing output limits could raise cost and latency. The artifact shows the main issue is large repeated input, not insufficient answer length. - Option D: Frequently changing content should not be placed in the cacheable prefix because it prevents cache reuse. The user question should remain outside the stable cached portion.

Sample Question 4 — Model Selection and Optimization

A developer wants to cache prompt content for a Claude-powered analytics assistant. The prompt is assembled in this order: Artifact: 1. System instructions, tool-use policy, and output format: changes monthly 2. Company data dictionary: changes monthly 3. User's selected dashboard filters: changes every request 4. Retrieved rows for the current question: changes every request 5. User question: changes every request The goal is to maximize cache reuse without serving stale request-specific context. Where should the cache checkpoint be placed?

  1. A. After the company data dictionary section. (Correct answer)
  2. B. After the selected dashboard filters section.
  3. C. After the retrieved rows for the question.
  4. D. After the final user question section.

Correct answer: A

Explanation: Correct answer (A): Cache checkpoints should align with stable prompt boundaries. The system instructions and data dictionary change infrequently and are reused across requests, while filters, retrieved rows, and the user question change every request. Placing the checkpoint after the data dictionary maximizes reusable stable content while keeping request-specific content outside the cached prefix. Why the other options are wrong: - Option B: Filters change every request, so including them in the cached prefix would reduce cache reuse and risk tying the cache to request-specific content. - Option C: Retrieved rows are request-specific and change every request. Placing the checkpoint there would make the prefix unstable and unlikely to be reused. - Option D: The final user question changes every request. Caching through it would defeat the purpose of a reusable prefix.

Sample Question 5 — Model Selection and Optimization

A product feature asks Claude to answer employee benefits questions. Most questions are simple policy lookups, but about 10% require comparing several policy sections and resolving exceptions. Artifact: Current setting: fixed high reasoning effort for every request Issue: simple questions feel slow and cost more than budgeted Quality issue: complex exception questions need deeper reasoning Goal: reduce unnecessary latency while preserving quality on hard cases Which runtime strategy is the best fit?

  1. A. Use adaptive thinking so effort varies by complexity. (Correct answer)
  2. B. Use fixed extended thinking for every request.
  3. C. Disable reasoning effort for every request.
  4. D. Move all requests to Haiku without evaluation.

Correct answer: A

Explanation: Correct answer (A): Adaptive thinking is useful when task complexity varies and the application benefits from allowing the model to spend more effort only when needed. The current fixed high-effort setting over-optimizes simple lookups, increasing latency and cost, while the hard exception cases still need deeper reasoning. Adaptive effort better matches the mixed workload. Why the other options are wrong: - Option B: Fixed extended thinking can help hard cases, but it repeats the current problem by adding unnecessary cost and delay to simple questions. - Option C: Disabling reasoning effort for all requests may improve speed but ignores the stated need for deeper reasoning on complex exception questions. - Option D: Haiku could be evaluated for simple lookups, but switching all traffic without evaluation does not address the mixed complexity and quality requirement.

Sample Question 6 — Model Selection and Optimization

A CI test calls Claude with the same prompt and compares the full response string to a stored golden response. The test is failing intermittently even though the answers remain semantically correct. Artifact: Run 1: "The renewal notice must be sent 30 days before expiration." Run 2: "Send the renewal notice at least 30 days before the policy expires." Run 3: "The notice deadline is 30 days before expiration." What is the best adjustment to the test strategy?

  1. A. Evaluate required meaning instead of exact wording. (Correct answer)
  2. B. Treat any wording difference as model failure.
  3. C. Switch to WebSockets to force identical output.
  4. D. Increase context size until responses match exactly.

Correct answer: A

Explanation: Correct answer (A): LLM outputs can vary across runs because generation is probabilistic and based on next-token prediction and sampling. For this type of CI check, exact string comparison is brittle when semantically correct answers can be phrased differently. The better test verifies required meaning, structured fields, or acceptance criteria rather than identical prose. Why the other options are wrong: - Option B: Exact wording comparison may be appropriate for deterministic code paths, but it is brittle for probabilistic model output when the meaning is correct. - Option C: WebSockets or streaming-oriented transports affect response delivery and perceived responsiveness. They do not make model generation identical across runs. - Option D: A larger context window does not guarantee identical wording. It can also increase cost and latency without fixing the test-design issue.

How to Study CCDV-F Model Selection and Optimization

Combine these CCDV-F Model Selection and Optimization practice questions with the official Anthropic documentation and hands-on projects. Build a small Claude-powered application with tool use, try Claude Code on a real repository, and iterate on prompts with evals — practical experience is the fastest way to master this domain.

About the CCDV-F Exam

Other CCDV-F Domains

Start the free CCDV-F Model Selection and Optimization practice test now | 10-question quick start | All CCDV-F domains