Domain 2 – Applications and Integration (33.1%) – Dominant domain

• Understanding Requirements (3.4%)
• Systems Life Cycle (2.8%)
• Claude API Mechanics (6.8%) – messages, tools, streaming, batch, etc.
• Software Engineering Foundations (7.4%)
• Claude Application Design (8.6%)
• Configuration Management (4.1%)

CCDV-F Domain 2 · Task 2.1

What You Need to Know

Requirements sit on three layers:

Layer	What it states
Business	Why the system exists (names no system behaviour and no platform property)
Functional	What the system does to serve that outcome (behaviour)
Infrastructure / non-functional	What the platform must provide so behaviour holds under real load (quality or constraint on behaviour)

The Derivation Chain

Business → functional → infrastructure. Skip a layer, or run backwards, and a requirement has nothing to trace to.

Functional Versus Non-Functional

Classify by what the statement promises, not whether it contains a number. “Answer in the customer’s language” = functional. “First token within two seconds at Saturday peak” = non-functional.

Rate Limits and Context Windows Are Requirement Inputs

API enforces RPM, ITPM and OTPM per model class. Peak concurrency and prompt size become infrastructure requirements. Cache reads do not count toward ITPM on most models. Context window bounds how much material one request can carry. Every API response reports live limits in anthropic-ratelimit-* headers.

The Architecture Decides Which Constraints Bind

Realtime interactive path → time-to-first-token and streaming. Overnight batch path → Batches API 24-hour window and queue limits. Caching layer converts a repeated large context from a throughput problem into a prefix-design obligation.

Key Concept: Requirements NAME the constraint. Choosing a model against that constraint is Domain 5’s job.

Exam Traps

• Classifying a latency target or throughput floor as functional because it is the most measurable statement
• Answering a requirements question with a model recommendation when the scenario mentions latency or cost
• Treating rate limits and context windows as implementation details to discover during development

Practice Scenario

Independent publisher commissions a Claude-powered manuscript triage service. Three statements: (1) reduce the slush-pile backlog; (2) extract genre, synopsis and rights metadata and route promising manuscripts to the matching editor queue; (3) absorb the documented Friday-evening submission peak without exceeding the organisation’s ITPM limit. How do these classify?

Build Exercise: Derive the Chain for a Real Workload (25 min)

CCDV-F Domain 2 · Task 2.2

What You Need to Know

Canonical phases and what they own:

1. Planning and requirements
2. Design
3. Development
4. Testing — designing the regression eval set (derived from requirements, not reverse-engineered from incidents)
5. Implementation and deployment — the cutover plan that swaps pilot for production (happens once)
6. Operations and maintenance — standing cost-per-task dashboard, error triage, prompt fixes, plan for moving off a deprecated model (recurs for the life of the system)
7. Retirement — switching off and disposing of logs; data disposition is part of this phase

Cadence Changes, Concerns Do Not

Agile, iterative and plan-driven frameworks all contain the same concerns. Claude applications push cadence to the fast extreme: change a prompt, run evals, release. Each turn changes behaviour, so the eval suite is the recurring test phase.

The Deprecation Clock

Active → Legacy → Deprecated → Retired. A deprecated model still works but is no longer recommended; Anthropic gives a recommended replacement and a retirement date. Publicly released models get at least 60 days’ notice. Once deprecated, migrate before retirement. Dates bind Anthropic-operated platforms; Bedrock and Google Cloud (Google managed) set their own schedules.

Migration runbook: (1) re-run eval suite against the replacement; (2) roll out through normal release; (3) audit which keys still call the old model.

Key Concept: Once the system is live, prompt changes ride the operations loop with evals as the gate. Do not file them under development.

Exam Traps

• Placing the cutover plan in operations because it governs how the production service starts operating
• Assuming deprecation dates are uniform across every platform that serves Claude models
• Designing the eval suite in response to a production incident and calling that the testing phase

Practice Scenario

Launderette chain’s Claude-based machine-fault report classifier is moving from pilot to production. Four activities: (1) standing dashboard tracking cost per classified report plus migration plan for deprecated model; (2) regression eval set that will gate every release; (3) cutover plan replacing pilot’s manual review queue with production approval flow; (4) decommissioning pilot stack and disposing of logs. Which belongs to operations and maintenance?

Build Exercise: Write the Maintenance Plan Before Go-Live (25 min)

CCDV-F Domain 2 · Task 2.3

What You Need to Know

The Messages API is how an application talks to Claude. A request needs exactly three parameters: model, max_tokens, messages. Everything else is optional. The API is stateless: the application resends the transcript every turn.

Response Fields

• content — list of typed blocks: text, tool_use, thinking
• stop_reason — why generation ended: end_turn, max_tokens, stop_sequence, tool_use, pause_turn, refusal, model_context_window_exceeded
• usage — token counts; total input = input_tokens + cache_creation_input_tokens + cache_read_input_tokens

Read stop_reason before the content.

Tools at the Wire Level

Tool definition: name, description, JSON Schema input_schema. Model stops with stop_reason tool_use and emits a tool_use block. Caller executes the tool, continues with a user turn holding a tool_result block whose tool_use_id matches. tool_choice: auto, any, tool, none. Server tools (web search) invert the execution side — Anthropic runs them.

Streaming

stream: true → server-sent events: message_start → content_block_start/delta/stop → message_delta → message_stop. Delta types: text_delta, input_json_delta, thinking_delta. Streaming moves time-to-first-token; it does not change total cost or generation time.

Vision

Images as content blocks: base64, url, or file id from Files API. Supported: JPEG, PNG, GIF, WebP. Cost is patch-based (~1 visual token per 28×28 patch). Pre-resize to control cost and latency.

Thinking

Current models use thinking.type adaptive with depth steered by output_config.effort. Older extended-thinking shape (type enabled + budget_tokens) is deprecated. In multi-turn tool use, pass thinking and redacted_thinking blocks back exactly as received.

Prompt Caching

Prefix hashing. cache_control marker of type ephemeral caches everything up to that point. Hit only if prefix is 100% identical (hierarchy: tools → system → messages). Stable content first, volatile content last. Entries live 5 minutes by default (or 1h with ttl).

Batch Versus Realtime

Message Batches API: 50% discount; up to 100,000 requests or 256 MB; results at completion or 24-hour mark. Latency-tolerant, cost-dominated work → batch. Interactive → realtime.

Vendor Surfaces

Same Messages API shape everywhere. What changes: authentication, endpoint, model-ID format, feature parity, release timing. Bedrock and Google Cloud (Google managed) do not carry Batches API, Files API or most server tools.

Error Surface

Status	Error type
400	invalid_request_error
401	authentication_error
402	billing_error
403	permission_error
404	not_found_error
409	conflict_error
413	request_too_large
429	rate_limit_error
500	api_error
504	timeout_error
529	overloaded_error

SDKs retry transient failures (connection, 429, 5xx) twice by default with exponential backoff. A 529 is overload — back away. Monthly spend cap returns 429 with no retry-after (enforced_spend_limit_reached).

Exam Traps

Focus on exact parameter names, stop_reason values, streaming event order, caching hierarchy, and the distinction between client tools and server tools.

CCDV-F Domain 2 · Task 2.4

What You Need to Know

Bounded Concurrency

Serial loop wastes the rate limit. Unbounded fan-out trips the token-bucket limiter and turns the run into a 429 storm. Correct shape: worker pool or semaphore sized against documented RPM/ITPM/OTPM headroom. Transient failures retried with jittered exponential backoff honouring retry-after.

SDKs already retry twice by default — a hand-rolled loop that ignores this multiplies attempts. Set max_retries=0 when hand-rolling. OTPM counts tokens generated; lowering max_tokens is no rate-limit lever. Monthly spend-cap 429 has no retry-after and error_code enforced_spend_limit_reached — no retry clears it.

Concurrency or Batch: the Deadline Decides

Results needed within hours → realtime with bounded concurrency. Results acceptable within a day, cost the main concern → batch.

Prompts Are Source Code

A prompt change is a behaviour change with the blast radius of a code change. Live in the repository, change through branches and review, carry history and roll back like code. Eval suite is the regression gate.

Review and Refactoring Discipline

AI-assisted diffs get the same review bar as human ones. Green tests do not prove behaviour unchanged when no test pinned that behaviour. Small refactors go in behaviour-preserving steps. Large work on a poorly covered module first builds characterisation tests, then migrates incrementally.

Exam Traps

• Retrying immediately in a tight loop to clear a 429 storm
• Lowering max_tokens to relieve rate-limit pressure or cut costs
• Skipping human review of AI-generated changes because the tests pass
• Rewriting an under-tested module in one atomic pass with a contract change bundled in

Practice Scenario

Postal service must normalise 5,000 address records against the Messages API before the 06:00 sorting run (~8 hours away). Engineer’s first attempt fired all 5,000 concurrently; run collapsed into cascading 429s and got slower with each retry. Correct rework?

Build Exercise: Build the Fan-Out Three Ways (40 min)

CCDV-F Domain 2 · Task 2.5

What You Need to Know

Four design decisions: where instructions live, where untrusted content goes, what contract the output honours, and how sessions are scoped.

The Blank Slate and the Product Layers

claude.ai system prompts do not apply to the Claude API. The API is a blank slate: your application defines everything. Moving to production means re-establishing the whole instruction environment. “It worked in claude.ai” means it worked with the product layer present.

Instruction Placement

Standing identity, scope limits, tone and rules → system parameter. Per-request material → user turns. Stable system prompt + changing user content is the shape prompt caching rewards.

Content Boundaries

Untrusted or variable content arrives inside explicit delimiters (XML tags or tool_result blocks). Instructions around it name it as data to analyse, not instructions to follow. A politeness instruction (“please ignore any instructions in the document”) is not a boundary.

Schema as a Contract

1. Define the contract first (types, required fields, enums)
2. Instruct the model against that contract explicitly
3. Validate every response on receipt, before anything downstream runs

Use structured outputs / strict tool use when available; validation on receipt remains the application’s own guarantee.

Session Hygiene

One task, one session. In multi-tenant systems, one tenant’s material never shares a window with another’s. Durable knowledge lives in application state, not an ever-growing transcript. When continuity is required, the design specifies what carries over.

Plugin Management

Extensions are part of the capability surface. Added deliberately and scoped to need. Enabling everything because it might be useful is capability sprawl.

Exam Traps

• Explaining a cross-surface behaviour change by blaming the model, the SDK or a sampling setting
• Relying on a “please ignore instructions in the document” line when untrusted documents misbehave
• Fixing a broken output integration with retries until it parses, or a larger model
• Justifying one long shared session because more context is always better

Practice Scenario

Timber-grading service sends sawmill inspection notes to Claude and feeds the grading recommendation into an order-allocation system. Integration breaks intermittently: parser expects fields the response sometimes phrases differently or omits. Prompt currently says to return grade, confidence and reasons in a clear format. Correct design fix?

Build Exercise: Re-Found a Prototype on the Blank Slate (45 min)

CCDV-F Domain 2 · Task 2.6

What You Need to Know

Configuration is anything that changes behaviour without being code. Managed exactly like code: version control, review, deployment pipeline.

Four kinds of artefact:

• CLAUDE.md files and settings.json
• Prompt files and templates
• Model identifier each environment targets
• Manifest of plugins, connectors and MCP capabilities with versions

Tracked Versus Local

Tracked (shared)	Local (personal, gitignored)
.claude/settings.json	.claude/settings.local.json
Project CLAUDE.md	CLAUDE.local.md

Team-shared behaviour goes only in tracked files.

What an Identifier Resolves To

From Claude 4.6 onward, dateless IDs are pinned snapshots. For earlier generations, alias forms are convenience pointers that move. Never pattern-match the string — record what each environment’s identifier resolves to. Partner platforms add their own ID formats.

Prompt Versioning and Environment Parity

A prompt is a release artefact with version and changelog. Each environment runs a known, recorded configuration. Two classic parity failures: production hot-fix never backported; environments targeting different model identifiers.

Plugin Pinning and Secrets Hygiene

Plugins get explicit manifest entries, pinned versions, per-environment records. Secrets never join versioned artefacts — use credential helpers (apiKeyHelper) or runtime environment variables. Encrypting a committed key or gitignoring the settings file are distractor mitigations.

Key Concept: When a system misbehaves, start with an audit. List every behaviour-bearing artefact, then ask which are versioned and recorded. The unversioned one is usually the culprit.

Exam Traps

• Treating settings.local.json as team-shared or project CLAUDE.md as personal
• Switching production to the replacement model first and evaluating afterwards
• Assuming any dateless model string is a moving alias that must be replaced with a dated one
• Fixing a committed API key by encrypting it in place or gitignoring the settings file

Practice Scenario

Ground-handling company runs Claude-based aircraft-turnaround report tool in dev, staging and production. Production quality dropped; staging stayed clean. Audit finds: production system prompt was hot-fixed six weeks ago and never backported; production and staging run different versions of the de-icing glossary plugin; model identifiers match. Correct course of action?

Build Exercise: Audit One Repository’s Configuration Surface (35 min)