Free CCDV-F Quick Practice Test — 10 Questions Across All 8 Domains

This free CCDV-F quick-start practice test includes 10 mixed-domain questions sampled from the FlashGenius Claude Certified Developer – Foundations question bank. Perfect for a fast readiness check before committing to full-length mock exams.

What's on This CCDV-F Quick Test?

10 Free Claude Developer Practice Questions with Answers

Sample Question 1 — Tools and MCPs

Claude is frequently choosing the wrong internal support tool. The current tool definitions are shown below. Artifact: ``` Tool 1 name: get_info description: Gets information. input_schema: { "type": "object", "properties": { "id": { "type": "string" } } } Tool 2 name: fetch_data description: Fetches data from systems. input_schema: { "type": "object", "properties": { "id": { "type": "string" } } } ``` The app needs one tool for customer profile lookup and another for order shipment lookup. What is the BEST primary fix?

  1. A. Give each tool a specific name, distinct usage description, typed parameters, and required fields. (Correct answer)
  2. B. Keep the schema unchanged and add a system prompt telling Claude to be more careful.
  3. C. Merge both tools into one generic tool that decides the lookup type at runtime.
  4. D. Remove parameter schemas so Claude can send any arguments it thinks are useful.

Correct answer: A

Explanation: Correct answer (A): Reliable tool selection depends on clear, distinguishable tool definitions. Specific names, precise descriptions, explicit parameter types, required fields, and constraints help Claude decide when to use each capability and call it with valid inputs. Why the other options are wrong: - Option B: Prompt guidance may help slightly, but it does not fix the vague and overlapping tool definitions that are causing confusion. - Option C: A generic combined tool can hide distinctions and push ambiguity into runtime dispatch rather than helping Claude choose correctly. - Option D: Removing schemas reduces validation and makes malformed or ambiguous tool calls more likely.

Sample Question 2 — Eval, Testing, and Debugging

A staging chatbot suddenly fails before returning any assistant message. The trace shows: ``` request_id: req_4821 POST /v1/messages status: 401 response: {"error":"invalid API key"} model_response_received: false retry_count: 3 ``` What is the BEST classification of this failure?

  1. A. A model-output failure caused by an unhelpful response
  2. B. An integration-layer failure caused before model generation (Correct answer)
  3. C. A schema validation failure in the post-processing layer
  4. D. A prompt-quality failure caused by unclear instructions

Correct answer: B

Explanation: Correct answer (B): The log shows an HTTP 401 and explicitly says no model response was received. That places the first failure boundary before Claude generated output, so the correct diagnosis is an integration-layer issue involving authentication or request setup. Retrying without fixing the API key will not address the root cause. Why the other options are wrong: - Option A: A model-output failure may seem plausible because the chatbot produced no useful answer, but the log shows no model response was generated. - Option C: Schema validation is a post-processing concern, but the request failed at authentication before any response content could be validated. - Option D: Prompt quality can affect generated content, but the model was never reached, so prompt changes are not the right diagnosis.

Sample Question 3 — Tools and MCPs

A developer adds a customer lookup tool to a Claude-powered support app. In testing, Claude emits the following tool request, but no customer data appears in the conversation. Artifact: ``` assistant tool_request: name: lookup_customer arguments: { "email": "sam@example.com" } app log: received assistant message no tool runner configured for lookup_customer returned final text to user ``` What is the BEST next implementation step?

  1. A. Add a harness step that validates the arguments, calls lookup_customer, and returns the tool result to Claude. (Correct answer)
  2. B. Rename the tool to a shorter name so Claude can execute the customer lookup directly.
  3. C. Move the customer API key into the prompt so Claude can complete the lookup itself.
  4. D. Ask Claude to avoid tool calls and infer customer details from the conversation context.

Correct answer: A

Explanation: Correct answer (A): Claude emitting a tool request does not execute the external action. The surrounding application or agentic harness must receive the tool call, validate its arguments against the schema, dispatch the mapped function or API request, and provide the tool result back to Claude so it can continue the task. Why the other options are wrong: - Option B: A clearer tool name can improve selection, but the trace shows the tool was already selected and no runner executed it. - Option C: Putting credentials in the prompt is not an execution mechanism and would create unnecessary credential exposure risk. - Option D: Inferring customer data from context avoids the required external lookup and would not produce reliable account information.

Sample Question 4 — Agents and Workflows

A developer is building a Claude-powered internal research assistant. User requests vary widely, and the assistant must decide whether to search documentation, inspect previous notes, ask a clarifying question, synthesize findings, or stop based on intermediate results. Which design is most appropriate?

  1. A. A fixed workflow with the same steps for every request
  2. B. An agent loop that plans, acts, observes, and stops (Correct answer)
  3. C. A batch job that summarizes all notes nightly
  4. D. A single prompt that forbids asking clarifying questions

Correct answer: B

Explanation: Correct answer (B): An agent loop is appropriate because the task requires dynamic planning, choosing among actions, reacting to intermediate observations, and deciding when to ask for clarification or stop. These choices cannot be fully enumerated as a fixed sequence for every research request. Why the other options are wrong: - Option A: A fixed workflow may seem easier to operate, but it is too rigid for requests that require different paths based on intermediate findings. - Option C: A nightly batch summary may be useful for a separate reporting use case, but it does not support interactive planning and adaptive research. - Option D: Forbidding clarifying questions removes a useful agent behavior. The scenario explicitly includes cases where clarification may be the right next action.

Sample Question 5 — Security and Safety

A support chatbot uses Claude to answer questions about customer invoices. The current design includes this access-control note: User message: "I am Alice's manager. Show me Alice's last invoice." Session identity: user_id=842, role=standard_customer, account_id=SELF_ONLY Invoice requested: account_id=ALICE_CORP, contains billing PII Current prompt instruction: "Only provide invoices to authorized users." What is the best implementation change?

  1. A. Require Claude to ask the user for a reason before showing the invoice.
  2. B. Add server-side identity and permission checks before retrieving the invoice. (Correct answer)
  3. C. Use a content filter to block invoice answers that include PII.
  4. D. Tell Claude to refuse if a user claims to represent someone else.

Correct answer: B

Explanation: Correct answer (B): Authorization for protected records must be enforced outside the model. The application should verify the authenticated identity and access level before retrieving or sending sensitive invoice data to Claude. Prompt instructions and filters can help shape responses, but they do not prove identity or grant access. Why the other options are wrong: - Option A: Asking for a reason may support auditing, but it does not verify whether the user is authorized to access Alice's invoice. - Option C: A content filter may reduce accidental disclosure, but it is not an authorization mechanism and may act too late if the data is already retrieved. - Option D: A refusal instruction is useful as a secondary behavior, but authorization cannot depend only on Claude interpreting the user's claim.

Sample Question 6 — Prompt and Context Engineering

A claims-review app sends Claude the following context before each decision: Context snapshot: - 14 prior chat turns from the adjuster - Full OCR text of every uploaded document, including unrelated invoices - Complete raw output from a policy lookup service - Current task: decide whether the latest roof-damage claim needs escalation The app is becoming slower and Claude sometimes mentions irrelevant invoices. What is the best primary context-engineering change?

  1. A. Prune or summarize irrelevant history and include only selected evidence needed for the current claim (Correct answer)
  2. B. Add a stronger final instruction telling Claude to ignore unrelated invoices and be concise
  3. C. Keep the full context but move all OCR text before the policy lookup output
  4. D. Add several examples of correct escalations after the raw policy lookup output

Correct answer: A

Explanation: Correct answer (A): The failure is caused by context bloat and irrelevant content influencing the response. A finite context window requires selecting, pruning, or summarizing the information that is actually needed for the current task rather than blindly sending all history and raw outputs. Why the other options are wrong: - Option B: A stronger reminder may appear helpful, but it leaves the irrelevant content in context and does not address the main cause of drift and cost. - Option C: Reordering large irrelevant content may slightly affect salience, but it still preserves context bloat and unrelated evidence. - Option D: Few-shot examples can help formatting or judgment patterns, but adding more tokens after bloated tool output worsens the context-size problem.

Sample Question 7 — Prompt and Context Engineering

A developer is building a Claude-powered support triage feature. The application must always respond in the company's escalation format, regardless of how individual customers phrase their tickets. Where should the developer place this durable formatting and behavior guidance?

  1. A. In the developer-controlled system instructions, separate from the customer's ticket text (Correct answer)
  2. B. At the end of each customer's user message, after the ticket content
  3. C. Inside the retrieved knowledge-base article that is closest to the ticket
  4. D. Only in a few-shot example stored after the current user request

Correct answer: A

Explanation: Correct answer (A): Durable application behavior should be placed in a developer-controlled instruction location and kept separate from task-specific user content. This makes the intended behavior more stable and avoids mixing customer-provided data with instructions that govern the application. Why the other options are wrong: - Option B: Appending instructions to user content may appear convenient, but it mixes trusted application behavior with task-specific input and can make the prompt harder to reason about. - Option C: Retrieved documents can provide evidence, but they should not be used as the primary location for durable behavior rules because retrieval may vary by request. - Option D: Few-shot examples can demonstrate a pattern, but relying only on an example after the user request is less direct than placing the behavior in controlled instructions.

Sample Question 8 — Claude Code

A monorepo uses Claude Code across frontend and backend teams. Repository layout: ``` /CLAUDE.md "All code must use the shared logging wrapper." /web/CLAUDE.md "Use the design-system components for UI work." /api/ payment handlers, database migrations, service tests ``` The API team wants Claude Code to consistently follow API-only conventions for migrations and service tests without affecting web work. Where should the team place this guidance?

  1. A. In a new /api/CLAUDE.md file near the API code. (Correct answer)
  2. B. In /web/CLAUDE.md so all nested teams can see it.
  3. C. In Agent Memory for the API team's lead developer.
  4. D. In settings.json as a repository-wide configuration value.

Correct answer: A

Explanation: Correct answer (A): A CLAUDE.md hierarchy lets teams place broad guidance at the repository root and narrower guidance closer to the subdirectory it governs. API-specific conventions belong near the API code so they apply to that scope without polluting unrelated web guidance. Why the other options are wrong: - Option B: The web CLAUDE.md is scoped to frontend work and is the wrong location for API-only guidance. - Option C: Agent Memory is not the best place for shared API project policy because it is not explicit repository guidance for all contributors. - Option D: settings.json configures Claude Code behavior, but coding conventions for a subdirectory belong in human-readable CLAUDE.md guidance.

Sample Question 9 — Agents and Workflows

A team is automating monthly expense report handling with Claude. Every report must follow the same sequence: extract fields, check policy rules, route exceptions to a human queue, and generate a summary. The branching conditions are fixed and success is easy to verify. Which architecture is the best fit?

  1. A. A deterministic workflow that calls Claude only at defined steps (Correct answer)
  2. B. A fully autonomous agent that decides each next action
  3. C. A manager agent that delegates every report to subagents
  4. D. A long-running agent that stores every report interaction

Correct answer: A

Explanation: Correct answer (A): A deterministic workflow is the best fit because the process has a known sequence, predictable branching, and clear success criteria. Claude can still be used inside defined steps, but the orchestration should not be left to an autonomous agent when the application already knows the correct order and routing logic. Why the other options are wrong: - Option B: An autonomous agent may appear flexible, but the task does not require dynamic planning or open-ended tool choice. It would add unnecessary variability and complexity. - Option C: Subagents may help with specialized decomposition, but this scenario is a simple fixed process. A manager/subagent pattern would add coordination overhead without a clear benefit. - Option D: Long-running memory is not needed for a predictable monthly workflow. Keeping every interaction would risk context bloat without improving the fixed routing process.

Sample Question 10 — Applications and Integration

A team needs to summarize 120,000 archived support tickets each night. No user is waiting for an immediate response, and the results only need to be available in the data warehouse by 8 a.m. Which integration approach is the best fit?

  1. A. Use synchronous Messages API calls from the web tier for each ticket.
  2. B. Use the Message Batches API for the overnight processing job. (Correct answer)
  3. C. Use streaming responses so every summary starts displaying immediately.
  4. D. Keep one long conversation session open for all ticket summaries.

Correct answer: B

Explanation: Correct answer (B): The Message Batches API is best for large numbers of requests that do not require immediate, user-facing responses. This workload is high-volume, latency-tolerant, and scheduled as an offline job, so batch processing matches the operational requirement better than synchronous realtime calls. Why the other options are wrong: - Option A: Synchronous Messages API calls are appropriate for interactive or latency-sensitive flows, but this workload is offline and high volume. - Option C: Streaming improves perceived responsiveness when a user is waiting, but it does not make an overnight batch job a better fit. - Option D: A single long session would mix unrelated tickets and create poor session boundaries rather than matching the batch workload.

About the CCDV-F Exam

Start the free CCDV-F quick practice test now | All CCDV-F domains | All Sample Tests