CCDV-F Practice Questions for the Claude Certified Developer: Foundations Exam

1. A team uses Claude Code from the terminal, from a VS Code extension, and from the desktop app against the same repository. What should they expect about project configuration?

   • A. Each surface keeps an isolated configuration store, so CLAUDE.md and any MCP server registrations must be duplicated once per surface.
   • B. Only the terminal CLI reads CLAUDE.md; the graphical surfaces rely solely on settings.json.
   • C. The surfaces share one underlying engine, so CLAUDE.md, settings and configured MCP servers carry across them.
   • D. MCP servers carry across surfaces but memory files and settings do not.

   Answer: C. The Claude Code surfaces (terminal, IDE extensions, desktop, web and mobile) are front ends over one engine, so project memory, settings and MCP server configuration apply consistently across them. A is wrong because duplication is unnecessary and would immediately drift. B invents a restriction that does not exist; memory loading is an engine behavior, not a terminal feature. D splits the behavior arbitrarily, and configuration and memory travel by the same mechanism as MCP registration.

   Exam domain: Applications and Integration

2. Which of these tool names is rejected by the Messages API tool-name constraint?

   • A. get_order_status
   • B. lookup-customer-record
   • C. inventory.check_stock
   • D. SearchDocs2

   Answer: C. Tool names must match ^[a-zA-Z0-9_-]{1,128}$: letters, digits, underscores and hyphens only. The dot in inventory.check_stock is outside that character set, so the request is rejected. A uses underscores, B uses a hyphen, and D mixes letters and a digit, all of which are inside the allowed set. Namespacing with a dot is a common habit from other RPC systems and is the trap here; use an underscore instead.

   Exam domain: Applications and Integration

3. A chatbot built on the Messages API sends only the newest user message on each request and users complain that Claude forgets everything.

   • A. The conversation ID was not supplied, so the server could not restore the thread.
   • B. The Messages API is stateless, so the client must send the full conversation history on every request.
   • C. Session memory expires after five minutes and the client must refresh it sooner.
   • D. Memory requires enabling the memory tool, which is on by default in Claude Code but must be requested explicitly through the API.

   Answer: B. The Messages API keeps no server-side conversation state; each request must carry the entire messages array the model should see. A invents a conversation identifier that would restore history. C describes cache TTL behavior, which affects cost and latency but never response content. D is wrong because the memory tool is a separate client-side persistence mechanism, not what makes ordinary multi-turn conversation work.

   Exam domain: Applications and Integration

4. A team is deciding between calling the Messages API with a hand-rolled HTTP client and using Anthropic's official Python SDK. What does the SDK actually give them?

   • A. A private binary protocol that is faster than the public REST endpoints.
   • B. Local caching of responses, which reduces billed input tokens on repeat prompts. The SDK keys the cache on the exact request body and reuses the stored completion whenever an identical request is sent inside the client's configured window.
   • C. A typed wrapper over the same REST endpoints, adding request and response models, automatic retries with backoff on transient failures, and streaming helpers.
   • D. A higher rate limit, because SDK traffic is pooled across the organization.

   Answer: C. The SDKs are thin, typed wrappers around the same public REST API, and their value is engineering ergonomics: typed models, sensible default retries on transient errors, and helpers that assemble streamed events into a finished message. A is wrong because there is no private protocol; the SDK sends ordinary HTTPS requests to the documented endpoints. B is wrong because the SDK does not cache responses, and billing savings come from server-side prompt caching, which you request explicitly with cache_control. D is wrong because rate limits are enforced per organization regardless of whether the caller uses an SDK.

   Exam domain: Model Selection and Optimization

5. Before sending a large assembled prompt, a service needs to know how many input tokens it will consume, without paying for a generation. What should it call?

   • A. POST /v1/messages/count_tokens with the same model, system prompt, tools and messages; it returns input_tokens, is free, and is rate limited separately.
   • B. POST /v1/messages with max_tokens set to 1 and read usage.input_tokens from the response.
   • C. Nothing. Client-side estimation at roughly four characters per token is the only supported method. Anthropic publishes that ratio for exactly this purpose and exposes no counting endpoint, because counting would require running the tokenizer server-side.
   • D. GET /v1/models, which returns the token count of the prompt you supply in the query string.

   Answer: A. The token counting endpoint exists precisely for this: it accepts the same request shape and returns input_tokens at no cost, under its own rate limit. B works but bills you for a real request and its output token, which is the thing the question asks you to avoid. C is wrong because a supported endpoint exists, and character heuristics are unreliable across languages and content types. D is wrong: the Models API returns model metadata such as max_input_tokens, max_tokens and capabilities, not a count of your prompt.

   Exam domain: Model Selection and Optimization

Want more? Finish the quiz above to unlock 15 more free questions, or open the full CCDV-F practice app.