Applications and Integration

What this domain tests

33.1% — by far the heaviest domain on CCDV-F, roughly 17 to 18 of the 53 scored items. It is also the widest: six separately weighted skills, only one of which is the raw API surface most candidates study first.

The published weights matter, because they are not where intuition puts them:

Claude Application Design is the single heaviest skill on the entire exam — heavier than API mechanics, heavier than any Model Selection sub-skill, heavier than anything in Agents. Candidates who prepare by memorizing request parameters and skip the design layer are optimizing the wrong 6.8%.

The question character splits cleanly:

• Recall items cluster in API Mechanics and Configuration Management: which parameter, which header, which limit, which stop_reason, how model IDs are spelled per platform.
• Judgment items dominate Application Design, Understanding Requirements, and Systems Life Cycle: given a requirement, which integration shape fits; given a failure, which layer owns it; given a scaling constraint, batch or realtime.

First-hand reports rank CCDV-F as the second-hardest of the four certifications and describe it as configuration-specific — "you either know the value or you don't." That bites hardest here and in Model Selection.

Theory outline

1. Understanding Requirements (3.4%)

The blueprint scopes this to translating business requirements into functional and infrastructure requirements against a solution architecture. In practice the exam tests one skill: reading a scenario and identifying which technical characteristic the stated business need actually constrains.

Four requirement axes, and the API surface each one selects:

The published sample item for this domain is exactly this shape: 10,000 documents overnight, cost primary, results needed by morning. The correct read is that "overnight" plus "cost" selects Message Batches — not parallel synchronous calls (which do not reduce per-token cost), not a smaller max_tokens (which caps output length, not price per token), and not blindly downsizing the model (which trades quality for a saving the batch discount already gives you).

Infrastructure requirements show up as: where does the compute live, what is the egress policy, which platform is the org already on. That last one is load-bearing and is covered under API Mechanics below, because platform choice silently removes features.

2. Systems Life Cycle (2.8%)

The smallest skill in the domain, and the one candidates most often under-read. It asks how a Claude application is developed, deployed, operated, and maintained — the same lifecycle discipline you would apply to any service, with two Claude-specific wrinkles.

Wrinkle one: the model is a dependency that changes underneath you. Models are deprecated on published dates and then retired; a retired model ID returns 404. An alias resolves to the latest snapshot, which means behavior can shift without a deploy on your side. The lifecycle answer is the same one you would give for any upstream dependency — pin deliberately, track deprecation dates, and run an evaluation before moving.

Wrinkle two: non-determinism means the test strategy differs. You cannot assert exact string equality on generated output. Lifecycle-appropriate checks are: schema validation on structured outputs, an eval set with graded criteria, and monitoring of production quality signals. (Eval design proper is its own domain on this exam, at 2.6%.)

Standard lifecycle mechanics still apply and still get tested: staged environments, separate API keys per environment, configuration externalized from code, and rollback as a first-class path.

3. Claude API Mechanics (6.8%)

The blueprint's own wording for this skill: messages, tools, streaming, vision, thinking, caching, invoking Claude through third-party vendors, Messages API data access patterns, batch API use, and tradeoffs between realtime and batch selection.

The architectural fact everything else hangs off: everything goes through POST /v1/messages. Tool use, structured outputs, thinking, vision, and PDF input are features of that single endpoint, not separate APIs. The genuinely separate endpoints are Batches, Files, Token Counting, and Models — all of which feed into or support a Messages request. Options offering a "tools API" or a "vision endpoint" are fabrications.

Request anatomy

Required on every request: model, max_tokens, and a non-empty messages array. The first message must have role user, and malformed alternation returns a 400 whose message reads, verbatim, that roles must alternate between user and assistant.

The API is stateless. There is no server-side conversation. Multi-turn means resending the full history every request — which is precisely why prompt caching matters so much, and why the two topics keep appearing together in the same question.

Response anatomy

The response carries content (a list of typed blocks — text, thinking, tool_use, and the server-tool result types), stop_reason, usage, model, and id. Content is a discriminated union: you branch on the block's type, you do not index position zero and read text.

Two traps live in that table. pause_turn is not an error and does not need a nudge message — the API detects the trailing server-tool block and resumes on its own; adding "Continue." is the wrong answer. And max_tokens versus model_context_window_exceeded are different failures: the first is your requested output cap, the second is the input window.

Streaming

Streaming uses Server-Sent Events. The event sequence, in order:

message_start → content_block_start → content_block_delta (many) → content_block_stop → message_delta → message_stop

Delta types you branch on: text_delta, thinking_delta, and input_json_delta (tool arguments arriving incrementally). The message_delta event is where stop_reason and final usage appear — not message_stop.

The operational rule the exam likes: stream anything with a large max_tokens. Non-streaming requests risk SDK HTTP timeouts above roughly 16,000 output tokens; current models allow up to 128,000 output tokens (Haiku 4.5 caps at 64,000), and reaching those ceilings requires streaming. Every SDK exposes a helper that returns the assembled final message, so "I need the whole response" is not a reason to avoid streaming.

Vision and documents

Images ride in an image content block whose source is either a URL or base64 with an explicit media_type. Supported formats: JPEG, PNG, GIF, WebP.

Recent models raised the resolution ceiling to 2576 pixels on the long edge (older models capped at 1568), and coordinates the model returns map one-to-one to actual image pixels — no scale-factor arithmetic. The cost consequence is the tested part: a full-resolution image on a high-resolution model can consume roughly three times the image tokens of the older cap. Downsampling before upload is the lever when the fidelity is not needed.

PDFs ride in a document content block with source type base64 and media_type application/pdf. Two placement and formatting rules get tested:

• The document block goes before the text block in the user content array.
• The base64 string must contain no newlines.

Limits: 32 MB per request and 600 pages (100 pages on 200K-context models).

Files API

For a document used across many requests, upload once and reference by ID rather than re-encoding it every time.

• Upload returns an id, used as file_id.
• Reference it as a document block with source type file for PDFs and text, or an image block for images — the content-block type must match the file's MIME type.
• Beta header files-api-2025-04-14 is required on both the upload call and the messages.create that references the file.
• Limits: 500 MB per file, 100 GB per organization. File operations are free; the content is billed as input tokens when used in a message.

Citations

Set citations enabled on each document content block — all of them or none, mixing is invalid. The response then splits into multiple text blocks, and cited blocks carry a citations array. Each citation carries cited_text, document_index, document_title, and a location object whose shape depends on its type:

Citations are incompatible with output_config.format — requesting both returns a 400. That is a favorite distractor: a stem wanting "cited, schema-validated JSON" has no single-request answer.

Prompt caching

The one invariant everything follows from: prompt caching is a prefix match, and any byte change anywhere in the prefix invalidates everything after it.

Render order is tools, then system, then messages. A breakpoint on the last system block therefore caches tools and system together.

That last row is a real trap. Newer models cache shorter prefixes than some older ones, so a 3,000-token prompt can cache on one model and silently fail to cache on another — with no error, just a cache_creation_input_tokens of zero.

Verification is a named skill. Three usage fields:

• cache_creation_input_tokens — written this request, at the write premium.
• cache_read_input_tokens — served from cache, at about 0.1x.
• input_tokens — the uncached remainder only, not the total prompt.

Total prompt size is the sum of all three. Reading input_tokens as "the prompt size" understates a well-cached agent's context dramatically, and that misreading is a plausible wrong answer.

If cache_read_input_tokens stays zero across repeated requests with what you believe is an identical prefix, a silent invalidator is at work. The classic ones: a current timestamp interpolated into the system prompt, a per-request UUID early in the content, JSON serialized without sorted keys, or a tool set that varies per user.

Two subtler mechanics worth carrying in:

• The 20-block lookback window. Each breakpoint searches backward at most 20 content blocks for a prior cache entry. Agentic turns that append many tool_use and tool_result pairs can exceed that in one turn, and the next request silently misses.
• Concurrency. A cache entry becomes readable only once the first response begins streaming. Firing N identical requests in parallel means all N pay full price — none can read what the others are still writing. Send one, wait for the first token, then fan out.

Invalidation is tiered, not all-or-nothing. Changing tool definitions or the model invalidates everything. Changing the system prompt keeps the tools cache. Changing message content keeps tools and system. Toggling tool_choice or thinking keeps tools and system. So per-request tool_choice changes are cheap; adding one tool mid-conversation is not.

Message Batches

Each request carries a custom_id and a params object shaped like a normal Messages request. Results arrive in any order — key them by custom_id, never by array position. That is the single most-tested batch mechanic.

The realtime-versus-batch tradeoff, stated plainly: batch buys a 50% discount and full feature parity (vision, tools, caching all work) in exchange for asynchronous delivery within a 24-hour window. Choose it whenever no human is waiting. Choose realtime whenever one is.

Invoking Claude through third-party vendors

The blueprint names this explicitly, and it is the most-missed corner of API Mechanics.

Use the platform's dedicated client class — not the first-party client with a base URL override. Model ID spelling differs per platform:

The last row is the trap: Claude Platform on AWS is Anthropic-operated with same-day feature parity and takes bare model IDs. Amazon Bedrock is partner-operated and takes the prefixed IDs. Treating them as the same thing produces a 400 or a 404.

Platform choice silently removes features. Several capabilities are first-party-only or unavailable on specific partners — the Message Batches API, the Files API, and the Models API among them, plus several server-side tools. An architecture question whose stem specifies a partner platform and then asks for batch processing is testing whether you know availability varies. The correct instinct is to check availability per platform rather than assume parity.

4. Software Engineering Foundations (7.4%)

The second-heaviest skill, and the one most likely to be skipped because it sounds generic. The blueprint scopes it to REST APIs, JSON, asynchronous programming, version control, SDLC integration, code review, and small- and large-scale refactoring.

The exam does not ask abstract software-engineering trivia. It asks those principles as they apply at the Claude integration boundary:

JSON handling. Tool call inputs must be parsed as JSON, never matched as raw strings. Recent models may escape Unicode or forward slashes differently in the serialized input, so a substring check that worked against one model breaks against another. Every SDK already exposes the parsed object — use it.

Asynchronous programming. Three places it is load-bearing: streaming consumption, parallel tool execution, and batch polling. Parallel tool use is on by default — one assistant message can contain multiple tool_use blocks, and you execute them concurrently and return all tool_result blocks in a single user message. Splitting them across multiple messages silently teaches the model to stop making parallel calls. A tool that failed still needs a tool_result, with is_error set — dropping it is worse than returning the error.

Timeouts and retries. Client timeout defaults to 10 minutes, and the unit differs by SDK — some take seconds, some take milliseconds. max_retries defaults to 2 and covers 408, 409, 429, and 5xx plus connection errors. Because timeouts are themselves retried, worst-case wall-clock is roughly the timeout multiplied by retries plus one. A stem describing a request that "hung for 30 minutes" against a 10-minute timeout is describing exactly that arithmetic, not a bug.

Refactoring at scale. Large-scale refactoring of a Claude integration has a specific hazard the exam probes: a change that looks local can invalidate the prompt cache globally, because caching is a prefix match. Reordering tool definitions, "tidying" the system prompt, or making serialization non-deterministic are all correctness-preserving and cache-destroying.

Version control and SDLC integration. Prompts, tool schemas, and model pins are configuration that belongs in version control and moves through review like code. This overlaps Configuration Management below and the two skills reinforce each other.

5. Claude Application Design (8.6%)

The heaviest skill on the exam. The blueprint scopes it to how Claude interprets instructions across interfaces (Claude Code, Desktop, claude.ai, API, SDKs), content boundaries, schema design, session hygiene, and plugin management.

How Claude interprets instructions across interfaces

The core insight: the API gives you a bare model; the products give you a harness.

Consequences the exam tests:

• A prompt that behaves well in claude.ai may behave differently through the API, because the product's harness supplied context you did not.
• Reproducing product behavior through the API means reproducing the harness — the system prompt, the tool definitions, and the loop — not just the user message.
• Conversely, API-level instructions do not automatically apply inside a product surface.

Content boundaries — the design principle behind the security domain

Instructions and data must be separable. The published sample item on prompt injection resolves this way: a page containing hidden text that says to ignore previous instructions is handled by treating retrieved content as untrusted input, keeping it separate from trusted instructions, and using guardrails or hooks so injected instructions cannot trigger sensitive actions.

Note what is explicitly not the answer: raising temperature, adding a politely-worded system prompt line asking users not to include malicious instructions, or switching to a larger model. A larger, more instruction-following model can be more susceptible, not less — that inversion is the trap.

This is also where retrieval-augmented generation lands on this exam. The Claude API exposes no embeddings endpoint; retrieval and vector storage are external components you bring. The exam-relevant surface is not how you build the index but how retrieved content enters the request: as document blocks (optionally with citations for attribution), clearly delimited, and treated as data rather than instruction.

A related mechanism worth knowing: on supporting models, an operator instruction can be appended mid-conversation as a message with role system, rather than by editing the top-level system field. This is the non-spoofable operator channel — text embedded in a user turn can be forged by anything that writes to user-visible input — and it preserves the cached prefix, where editing the top-level system prompt would invalidate the whole conversation. It is not universally supported across models, and it cannot be the first message.

Schema design

Two schemas in a Claude application, and both are tested:

Tool input schemas. Clear names, descriptions on every property, enum for fixed value sets, and only genuinely required fields marked required. Tool descriptions should be prescriptive about when to call the tool, not merely descriptive of what it does — that materially changes how often the model reaches for it.

Structured output schemas. These go at output_config.format; the older top-level output_format parameter is deprecated API-wide. Two features share the machinery: constraining the response format, and strict tool parameter validation.

Strict mode is a field on the tool definition itself — alongside name, description, and input_schema — not on tool_choice. It requires the schema to set additionalProperties to false and to declare required. That placement is a recall item.

Schema constraint support has real gaps that get tested: recursive schemas are unsupported, as are numeric bounds (minimum, maximum, multipleOf) and string length bounds (minLength, maxLength). additionalProperties must be false and cannot be set to anything else. A new schema pays a one-time compilation cost on first use and is then cached for 24 hours — so a slow first request followed by fast ones is expected behavior, not a defect.

Session hygiene

Because the API is stateless, "the session" is whatever history you choose to resend — which makes trimming it a design decision rather than an optimization.

Three mechanisms, and they are different things:

Clearing is not summarizing — that distinction is the likeliest question here. Context editing prunes stale content and keeps the transcript's structure; compaction condenses history into a summary as you approach the window limit.

Compaction carries an implementation trap the docs call out explicitly: append the full response content back into your messages, not just the extracted text. The compaction blocks in the response are what the API uses to replace the compacted history on the next request. Pulling out the text string and appending that silently loses the compaction state.

Plugin management

Plugins and skills extend a Claude application with capability that loads on demand. The design property that matters is progressive disclosure: a skill's short description sits in context by default and the full instruction file is read only when the task calls for it. That keeps the fixed context small while making a large library of capability reachable — the same principle behind deferred tool loading.

6. Configuration Management (4.1%)

The blueprint names five things: CLAUDE.md files, settings.json, model version pinning, prompt versioning, and plugin dependencies. Pinning is the densest recall material.

Model version pinning

The rules, and each one is a question waiting to happen:

• Use the exact published alias string. Do not construct one and do not append a date suffix you half-remember. A malformed ID returns 404, not a helpful validation message.
• Aliases track the latest snapshot. That is convenient for staying current and dangerous for reproducibility. Pin explicitly when you need a fixed target.
• Platform spelling differs. Amazon Bedrock prefixes IDs with anthropic.; Vertex dated snapshots use an @ separator between name and date rather than a hyphen; Claude Platform on AWS and Microsoft Foundry take the bare alias.
• Switching models invalidates the prompt cache entirely. Caches are model-scoped. A model change is never just a string change — it is a cold cache and a re-baselined token count.
• Token counts are model-specific. Tokenizers differ between model generations, so a max_tokens ceiling or a context budget tuned on one model can truncate on another. Re-measure with the token counting endpoint against the model you are actually calling.

Never estimate Claude tokens with a third-party tokenizer. Counting endpoints exist for exactly this reason; borrowing another vendor's tokenizer undercounts, badly on code and non-English text.

Prompt versioning

Prompts are configuration with behavioral consequences, so they get the same treatment as code: version-controlled, reviewed, and evaluated before promotion. The Claude-specific reason to be disciplined is caching — an unreviewed one-word edit to a system prompt invalidates the cached prefix for every conversation using it.

CLAUDE.md and settings.json

CLAUDE.md files carry project instructions and follow a hierarchy, so a project-level file layers over broader ones. settings.json holds configuration for the surrounding tooling. The configuration-management framing the exam wants: both are checked-in configuration, they compose hierarchically, and hierarchy is how you get org-wide defaults with per-project overrides. (Claude Code operation proper is its own domain on this exam, weighted 3.1%.)

Worked problems

Problem 1. A team must run 40,000 support transcripts through a classification prompt to produce a monthly report. The report is compiled on the first of the month; the job can start three days early. Finance has asked for the cheapest option that does not degrade classification quality. Which approach fits?

A. Fan the requests out synchronously with a high concurrency limit to finish fastest B. Submit them through the Message Batches API C. Keep synchronous calls but lower max_tokens to reduce cost D. Switch to the smallest available model

Approach: The stem hands you the deciding variable twice — a three-day window and "cheapest without degrading quality." Latency tolerance plus cost sensitivity selects batch, which is a straight 50% discount with full feature parity. 40,000 requests is comfortably inside the 100,000-request ceiling.

Why the others fail: A finishes sooner but costs full price — parallelism is a latency lever, not a pricing one. C misreads max_tokens: it caps output length, so it can truncate classifications while barely moving cost on a workload whose spend is dominated by input. D explicitly degrades quality, which the stem forbids, and the batch discount already delivers the saving.

Answer: B

Problem 2. An engineer adds prompt caching to a support assistant. The system prompt is a 12,000-token product manual, marked with a cache_control breakpoint. After a week in production, cache_read_input_tokens is zero on every request while cache_creation_input_tokens is large on every request. The prefix looks identical in the code. What is the most likely cause?

A. The prefix is below the minimum cacheable length B. Something in the rendered prefix differs per request — a timestamp, a request ID, or non-deterministic serialization C. Cache reads are only reported on streaming requests D. The 5-minute TTL is too short for this traffic pattern

Approach: Writes succeeding while reads never happen is the signature of a prefix that is new every time. Caching is a byte-exact prefix match, so "looks identical in the code" is not the same as "renders identical." The named silent invalidators are a current timestamp in the system prompt, a per-request identifier early in the content, and JSON serialized without deterministic key ordering.

Why the others fail: A is contradicted by the evidence — a below-minimum prefix produces cache_creation_input_tokens of zero, and here writes are large. C invents a reporting rule; usage fields are populated regardless of streaming. D would produce intermittent misses on a quiet system, not a perfect zero under steady production traffic — and it would not explain a fresh write on literally every request.

Answer: B

Problem 3. A developer builds a contract-review feature. Requirements: the answer must quote the source passages with page numbers, and it must come back as JSON matching a fixed schema so the frontend can render it. They set citations enabled on the document block and also set output_config.format with a JSON schema. The request returns a 400. Why?

A. Citations require the Files API rather than base64 documents B. Citations and output_config.format are incompatible — the combination is rejected C. Page-level citations require the document to be uploaded as an image D. The schema must set additionalProperties to true when citations are enabled

Approach: This is a compatibility recall item dressed as a feature request. Citations and structured outputs are documented as mutually exclusive, and requesting both returns a 400. The design answer is to pick one per request — take the cited response and shape it in a second step, or drop schema enforcement and validate defensively.

Why the others fail: A is false; citations work with base64 documents and with Files API references alike. C inverts the mechanism — page_location citations with 1-indexed page numbers are precisely what a PDF document block produces. D is doubly wrong: structured output schemas require additionalProperties to be false, and it has nothing to do with citations.

Answer: B

Problem 4. An assistant calls three tools in one turn. One of them, an inventory lookup, throws a connection error. The developer decides to omit that tool's result and return the two that succeeded, planning to let the model figure it out. What goes wrong?

A. Nothing — omitting a failed tool result is the documented pattern B. Every tool_use block needs a matching tool_result; the failed one should be returned with is_error set rather than dropped C. The three results must each be sent as a separate user message D. Parallel tool use must be disabled before any tool can fail safely

Approach: Two rules collide here and both are tested. Results pair to their tool_use blocks, so a dropped result leaves an unmatched call. The documented handling for a failure is a tool_result with is_error set and an informative message — which lets the model adapt, retry differently, or tell the user, instead of reasoning over a hole.

Why the others fail: A states the anti-pattern as the pattern. C is backwards and is its own named trap: all results from one assistant turn go back in a single user message, because splitting them across messages trains the model out of parallel calls. D is unrelated — disabling parallel tool use limits the model to one call per response and does nothing about error handling.

Answer: B

Problem 5. A financial services team runs on Amazon Bedrock for procurement reasons. They want to move a nightly 20,000-document summarization job onto the Message Batches API for the 50% discount. What should the reviewing developer flag?

A. Bedrock model IDs need the anthropic. prefix on batch requests B. The Message Batches API is not available on that platform — the batch discount cannot be obtained there C. Batches on Bedrock cap out at 10,000 requests D. Batch requests on Bedrock require the Files API for inputs

Approach: The whole point of the blueprint calling out "invoking Claude through third-party vendors" is that feature availability varies by platform and several endpoints are first-party-only. Batches is one of them. The reviewer's job is to catch the plan before it is built, and the honest answer is that the discount is not reachable from that platform.

Why the others fail: A is a true statement about Bedrock model IDs but does not address the actual blocker. C invents a limit — the published batch ceiling is 100,000 requests or 256 MB, and it is not a per-platform variant. D fabricates a dependency, and the Files API is itself unavailable there.

Answer: B

Problem 6. An agent streams a long research response. The developer reads the accumulated text, then checks the final event for stop_reason to decide whether to continue the loop — and finds no stop_reason on it. Where does stop_reason arrive?

A. On message_stop, the final event B. On message_delta, which carries stop_reason and final usage before the stream ends C. Only on non-streaming requests; streaming callers must infer completion D. On content_block_stop for the last block

Approach: Pure event-sequence recall. The stream runs message_start, then content_block_start / content_block_delta / content_block_stop per block, then message_delta carrying message-level updates including stop_reason and usage, then message_stop as a terminator. Reading it off the last event is the natural guess and the wrong one.

Why the others fail: A is the trap — message_stop signals the end, it does not carry the reason. C is false; every SDK also exposes a helper returning the assembled final message with stop_reason intact. D confuses block-level termination with message-level termination — content_block_stop fires once per block and says nothing about why the message ended.

Answer: B

Exam traps

• Treating features as separate APIs. Tools, vision, thinking, and structured outputs are all parameters on POST /v1/messages. Options describing a distinct tools API or vision endpoint are fabricated. The genuinely separate endpoints are Batches, Files, Token Counting, and Models.
• Reading input_tokens as the prompt size. It is the uncached remainder only. Total prompt equals input_tokens plus cache_creation_input_tokens plus cache_read_input_tokens. A heavily cached agent showing a small input_tokens has not shrunk its context.
• Assuming prompt-cache minimums rise with model recency. They are not monotonic — some newer models cache shorter prefixes than older ones. A prompt that caches on one model can silently fail to cache on another, with no error at all.
• Sending "Continue." after pause_turn. Resend the conversation as-is; the API detects the trailing server-tool block and resumes. Appending a nudge message is the named wrong move.
• Confusing max_tokens with the context window. max_tokens caps output and produces stop_reason max_tokens. Exhausting the input window produces model_context_window_exceeded. Different failures, different fixes.
• Dropping a failed tool result. Return a tool_result with is_error set. And return all of a turn's results in one user message — splitting them across messages suppresses future parallel tool calls.
• Putting strict on tool_choice. Strict mode is a top-level field on the tool definition, beside name, description, and input_schema. It also requires additionalProperties false plus required.
• Pairing citations with structured outputs. That combination is a 400. Any option promising cited, schema-enforced JSON in one request is wrong.
• Forgetting the Files API beta header on the second call. It is required on both the upload and the messages.create that references the file_id.
• Assuming platform parity. Batches, Files, Models, and several server-side tools are unavailable on some partner platforms. Also: Claude Platform on AWS takes bare model IDs while Amazon Bedrock takes anthropic.-prefixed ones — they are different offerings.
• Estimating tokens with a third-party tokenizer. Undercounts Claude, worst on code and non-English text. Use the token counting endpoint, and re-count when the model changes.
• "Strengthen the system prompt" against prompt injection. The answer is a content boundary — untrusted content kept separate from trusted instructions, plus guardrails so injected text cannot reach sensitive actions. Switching to a more instruction-following model can make injection worse.
• Confusing context editing with compaction. Editing clears stale tool results and thinking; compaction summarizes. And when using compaction, append the full response content back — extracting only the text silently drops the compaction state.