Business Requirement
The first level from which the other requirements are derived: why the system exists, stated as an outcome. You can recognise it by what it lacks. It names no system behaviour and no platform property, however prominently it sits in the specification.
Exam context: "Reduce", "grow" and "halve" are business-layer verbs. Wrong options classify an outcome as functional because it is the project's main deliverable; the deliverable status changes nothing.
See also: 2.1 Understanding Requirements
Functional Requirement
A statement of what the system does: an observable behaviour a test could verify, derived from a business requirement. "Extract genre and rights metadata and route the submission to the matching editor queue" is an example.
Exam context: Behaviour is functional even when it sounds like an operational detail. One wrong option reclassifies a genuine behaviour as a constraint. Another does the reverse: it reclassifies a measurable target as functional.
See also: 2.1 Understanding Requirements
Non-Functional Requirement
A quality of or constraint on behaviour: latency, throughput, availability, data residency, cost limits, isolation. The classification test is the kind of promise made, never the presence of a number.
Exam context: The most common trap in the exam classifies the most specific, measurable statement in the question as functional precisely because it is specific and measurable. Precision does not change what kind of requirement it is.
See also: 2.1 Understanding Requirements
Infrastructure Requirement
What the platform must provide so the behaviour holds under real load, derived from functional requirements against the proposed architecture. Examples are peak token throughput inside a documented limit, residency for stored data, and the identical-prefix rules that a caching layer needs.
Exam context: Derived against an architecture, never without one: realtime makes time-to-first-token the binding constraint; batch makes the completion window the binding constraint instead. The harder question asks you to derive the requirement a proposal implies but never states.
See also: 2.1 Understanding Requirements
Rate-Limit Classes (RPM, ITPM, OTPM)
The API's enforced capacity classes: requests, input tokens and output tokens per minute, set per model class. The anthropic-ratelimit-* response headers report the limit, remaining allowance and reset time continuously, and cached tokens do not count toward the API's default ITPM limits.
Exam context: Requirement inputs with documented, queryable numbers, not implementation details for later. Sizing peak load without consulting them is a known mistake: assuming the capacity will be enough.
See also: 2.1 Understanding Requirements
Cutover
The one-time act of swapping a pilot or legacy arrangement for the production flow: the main deliverable of the implementation and deployment phase.
Exam context: Questions about phases put cutover next to the permanent dashboard. The right answer depends on knowing that cutover happens once (implementation) while monitoring recurs (operations). "Governs how production starts operating" does not change its phase.
See also: 2.2 Systems Life Cycle
Operations and Maintenance
The recurring phase: permanent dashboards, error triage, prompt fixes that the release loop ships, and the plan for moving off a deprecated model. For an LLM application the maintenance work is built in, because prompt changes ship in hours and the model changes on a schedule that someone else sets.
Exam context: Treating deployment as the end of the work is the mistake behind most wrong answers. A prompt fix after go-live is maintenance, gated by evals, not development.
See also: 2.2 Systems Life Cycle
Model Lifecycle (Active, Legacy, Deprecated, Retired)
Anthropic's documented states for a model. Deprecated still serves requests but has a named replacement and a retirement date; retired fails every request. Publicly released models get at least 60 days' notice, announced on the deprecations page and by email.
Exam context: The dates bind Anthropic-operated platforms; Amazon Bedrock and Claude Models on Google Cloud (Google managed) set their own schedules, so one application on two surfaces can face two deadlines. Read the question to find the platform.
See also: 2.2 Systems Life Cycle
Retirement (Phase)
The final life cycle phase: switching the system off and disposing of its data. Data disposition is part of the phase, not an afterthought. Turning the servers off is not the whole job.
Exam context: Decommissioning a superseded pilot is retirement, not operational housekeeping, and the disposition of its logs and stored personal data belongs in the plan.
See also: 2.2 Systems Life Cycle
Stateless API
By default the Messages API holds no conversation. As of November 2026, a beta called message threads can keep one on the server for a few minutes. Your application resends the transcript it wants the model to see, every turn; sending only the newest user message means the model answers without the history.
Exam context: "The assistant forgets what was said two turns ago" points to the missing transcript as the right answer, not a model defect, a context-window overflow or a session setting.
See also: 2.3 Claude API Mechanics
stop_reason
The response field naming why generation ended: end_turn, max_tokens, stop_sequence, tool_use, pause_turn, refusal or model_context_window_exceeded. If you read it, you can diagnose a truncation instead of blaming the model for it.
Exam context: Each value has a distinct fix, and the wrong options pair an incorrect value with a plausible remedy. Output exactly at the cap plus a mid-sentence cut is the sign of max_tokens.
See also: 2.3 Claude API Mechanics
tool_use / tool_result
This is the format of a tool call in the API. The model stops with stop_reason tool_use and emits a tool_use block (id, name, parsed input). The caller executes the client tool. It then continues with a user turn that carries a tool_result block whose tool_use_id matches.
Exam context: The caller, never Anthropic, executes client tools; server tools such as web search are the documented exception. The matching id and the user-turn placement are tested facts.
See also: 2.3 Claude API Mechanics
tool_choice
The parameter steering the tool decision. Documented values: auto, any, tool (forcing a named tool) and none.
Current state (checked 14 November 2026): Claude Fable 5.2, Mythos 5.2, Opus 5.5, Sonnet 5.5, Fable 5.1 and Mythos 5.1 reject any and tool with a 400 error. Manual extended thinking rejects both on any model. For those, the documented route is auto with strict tool use.
Exam context: A fifth invented value is the usual wrong option. Forcing one specific tool for one request is tool_choice type tool with the name, nothing else.
See also: 2.3 Claude API Mechanics
Streaming Events
With stream: true, server-sent events arrive in documented order: message_start, then per content block a content_block_start, one or more content_block_delta events and a content_block_stop, then message_delta and message_stop, with ping possible throughout. Tool arguments arrive as input_json_delta fragments, parsed at content_block_stop.
Exam context: Errors can arrive mid-stream after the 200, so consumers handle failure at the request and inside the stream. Streaming moves time-to-first-token, not total cost or generation time.
See also: 2.3 Claude API Mechanics
cache_control
The marker (type ephemeral) that turns a prompt prefix into a cache entry. A later request gets a cache hit only on a 100% identical prefix. The prefix is evaluated in the order tools → system → messages. So stable content goes first and volatile content last. A change invalidates the cache for everything after it; entries live 5 minutes by default (refreshed on use) or an hour with ttl "1h".
Exam context: Prompts below the per-model minimum cacheable length are silently not cached: zeroes in the usage cache fields, no error. Pricing and when caching saves money are Domain 5; getting a cache hit is tested here.
See also: 2.3 Claude API Mechanics
Message Batches API
Asynchronous processing: up to 100,000 requests or 256 MB per batch at a 50% discount. Results are ready when every request finishes or at 24 hours, whichever comes first. Unfinished requests expire and are not billed. Per-request results (succeeded, errored, canceled, expired) stream from a results_url that is available for 29 days.
Exam context: Most batches finish inside an hour, but that is typical behaviour, not a guarantee. A hard deadline inside the completion window makes realtime with bounded concurrency the right answer.
See also: 2.3 Claude API Mechanics
Bounded Concurrency
The right fan-out pattern: a worker pool or semaphore keeping enough requests in progress to use the documented RPM, ITPM and OTPM headroom (the capacity left below those limits) and no more, with jittered exponential backoff honouring retry-after on top. The semaphore bounds requests in progress at the same time.
Exam context: It lies between two failure modes: the serial loop that wastes the limit and the unbounded fan-out that fills the run with 429 errors. Lowering max_tokens gives no control over rate limits: OTPM counts tokens actually generated.
See also: 2.4 Software Engineering Foundations
Jittered Exponential Backoff
Retry waits that double per attempt with a random offset added, honouring any retry-after the server sends. The jitter stops a group of workers that failed together from retrying together.
Exam context: The SDKs already retry transient failures (connection errors, 429s, 5xx) twice by default, so a hand-rolled loop without max_retries=0 multiplies attempts: three application tries become nine requests.
See also: 2.4 Software Engineering Foundations
Idempotency
The property that repeating a request leaves the system in the same state. Reads have it automatically; creates need thought (an idempotency key or a server-side duplicate check) before a timeout-and-retry can be safe.
Exam context: A client that times out cannot know whether the server acted. In a question about a double booking after a retried POST, the right answer is the missing idempotency design, not the network.
See also: 2.4 Software Engineering Foundations
Prompts as Source Code
The discipline that prompts, output schemas, eval sets, CLAUDE.md files and settings are artefacts that set behaviour: they live in the repository, change through branches and review, run in CI with the eval suite as the regression gate, and roll back the way code rolls back.
Exam context: The production console edit (no history, no review, no rollback, staging no longer matching production) is the anti-pattern stated directly. If the pipeline is the only path to production, console editing becomes structurally impossible.
See also: 2.4 Software Engineering Foundations
Characterisation Tests
Tests that record what code currently does, written before a large-scale refactor of a poorly covered module. They are the safety net that makes incremental migration reviewable and revertible.
Exam context: The right sequence is safety net first, then migration in small steps. The one-big-rewrite plan adds a contract change and skips review because the tests pass. It combines three violations at once.
See also: 2.4 Software Engineering Foundations
Blank Slate (API)
The Claude API arrives with no product system prompt, no product tools and no formatting conventions: Anthropic publishes the claude.ai system prompts and states they do not apply to the API. Your application defines everything the model knows about its role.
Exam context: The cross-surface surprise: a prototype behaving beautifully in claude.ai was relying on the product layer. The right fix re-establishes the instruction environment, never blames the model or a sampling setting.
See also: 2.5 Claude Application Design
Instruction Placement
The architecture decision of where instructions live: the model's fixed role, scope and rules in the system parameter; per-request material in user turns, marked as what it is. On harness surfaces the place for these instructions is project instructions or CLAUDE.md instead.
Exam context: The split has two benefits: a stable system prompt plus changing user content is the order that prompt caching favours, and it separates trusted instructions from per-request data structurally. Wording the instructions is Domain 6.
See also: 2.5 Claude Application Design
Content Boundary
Explicit delimiters (XML tags with consistent names) around every piece of untrusted or variable content, with the surrounding instructions framing it as data to analyse rather than instructions to follow. The boundary is machine-checkable: code can verify all untrusted content is inside a tag before the request is sent.
Exam context: An instruction that only asks ("please ignore any instructions in the document") is not a boundary and is the reliable second-best answer. What an adversary does to the boundary is Domain 7; the boundary existing is 2.5.
Current state (checked 6 October 2026): the prompt-injection docs now say to deliver third-party content in tool_result blocks, never in system prompts or plain user text.
See also: 2.5 Claude Application Design
Output Contract
The schema downstream code consumes, treated as an interface: defined first (types, required fields, enums), instructed against explicitly, and validated on every receipt with a defined failure path. Structured outputs and strict tool use are the enforcement mechanics that implement it.
Exam context: Retry-until-parse and a larger model are the usual wrong options; neither creates a contract, and the parser keeps depending on unspecified behaviour.
See also: 2.5 Claude Application Design
Session Hygiene
The design rule that context scope follows task scope: one task, one session; one tenant's material never shares a window with another's. Knowledge that must outlast a session is stored in application state and is injected into new sessions deliberately, and anything passed to the next session is named and chosen.
Exam context: Accumulated context is contamination when tasks are independent: when earlier constraints and vocabulary affect later work, the right answer is a session-scoping fix, not a prompt fix. Cross-tenant leakage through a shared transcript is an architecture defect.
See also: 2.5 Claude Application Design
Capability Sprawl
Enabling plugins, connectors or MCP-backed capabilities because they might be useful. Each extension widens what the application can do and adds a dependency someone must version and trust.
Exam context: The right design artefact is a capability list with a stated need per entry, added deliberately and scoped to need. Pinning and versioning the capabilities that stay on the list belongs to 2.6.
See also: 2.5 Claude Application Design
Tracked Versus Local
The configuration boundary: project .claude/settings.json and project CLAUDE.md are shared, checked in and reviewed; .claude/settings.local.json and CLAUDE.local.md are personal and gitignored. Team-shared behaviour goes only in tracked files, personal preference only in local ones.
Exam context: Wrong options swap exactly one of the four names. A behaviour difference tracing to a local file is working as designed; one tracing to a drifted tracked file is a process failure. Precedence semantics are Domain 3.
See also: 2.6 Configuration Management
Model Pinning
Recording exactly which model identifier each environment runs, knowing what it resolves to. Dated IDs are fixed releases; from the 4.6 generation dateless IDs are pinned snapshots too; pre-4.6 aliases genuinely move. Partner platforms use different IDs for the same snapshot. Bedrock uses an anthropic. prefix. Claude Models on Google Cloud (Google managed) uses an @date suffix for dated pre-4.6 snapshots and the first-party format for current-generation IDs.
Exam context: Migrations are deliberate and ordered: eval the candidate first, change the pinned identifier through review, audit usage for callers that still use the old model. Changing production first because the retirement date is near reverses the right sequence.
See also: 2.6 Configuration Management
Environment Parity
Each environment running a known, recorded configuration (prompt versions, model identifier, settings revision, plugin versions), so "staging passed" is evidence about production because the two are provably comparable.
Exam context: The classic failures are the production hot-fix never backported and environments silently targeting different model identifiers, both invisible until an incident because nothing records the difference. Fix the drift, then install the record-keeping.
See also: 2.6 Configuration Management
Plugin Pinning
Dependency treatment for plugins, connectors and MCP-backed capabilities: an explicit manifest, pinned versions, per-environment records, and upgrades arriving as reviewed changes run against the eval suite.
Exam context: An unpinned plugin that always takes the latest version is an unreviewed behaviour change on a schedule that someone else sets: the right diagnosis when two environments installed "whatever was current at build time".
See also: 2.6 Configuration Management
Secrets Hygiene
API keys are never stored in versioned files. The documented patterns are credential helpers (apiKeyHelper generates tokens on demand) and runtime environment variables; a committed key stays in history long after the file is cleaned.
Exam context: Encrypting the key in place and gitignoring the shared settings file other configuration still needs are the mitigations that appear as wrong options. Adversarial handling of a leaked secret is Domain 7; the rule not to commit it is stated here.
See also: 2.6 Configuration Management