Capability Bloat
A tool surface larger than the role's task list justifies. The excess costs twice over: attack surface, because a wired tool is a reachable capability whatever the system prompt says, and context weight, because every definition occupies the window on every request and near-duplicate tools degrade selection accuracy.
Exam context: The objective's whole shape. Configurations are evaluated from the role's task list forward, never from the platform's capability list backward, and "more tools so it can handle anything" is the planted inversion.
See also: 3.1 Capability Bloat
Control Categories
The taxonomy that ranks the four mitigations the exam offers for an over-privileged tool. Elimination removes or scopes the capability. A compensating control (a confirmation prompt) guards a capability that should not exist. A detective control (audit logging) finds abuse after the damage. An instruction (a system-prompt prohibition) constrains behaviour, not capability.
Exam context: Naming the category eliminates distractors mechanically. The guide's own Domain 3 sample plants logging, a confirmation prompt, and a larger model against a keyed removal, so the ranking is worth knowing cold.
See also: 3.1 Capability Bloat
Tool Consolidation
Collapsing overlapping or vaguely-purposed tools into fewer, clearly-described, task-scoped ones, with related tools namespaced under common prefixes. The subtractive half of least privilege shrinks the surface; consolidation improves what remains.
Exam context: Least privilege is not only removal. A long tail of granular near-duplicates confuses selection and wastes context even when every tool is individually justified.
See also: 3.1 Capability Bloat
Confused Deputy
An agent that serves many users through one service credential broader than any individual user's rights, so it exercises its privilege on behalf of users who should have less. Any user can then potentially reach anything the account can. The MCP security guidance names the same attack class for proxy servers and mandates per-client consent.
Exam context: The recurring authorisation gap. Stems describe an agent reading every record through a shared service credential, and the keyed answer is identity propagation with per-user scoping, not stronger login and not logging.
See also: 3.2 Authentication and Authorisation Gaps
Identity Propagation
Carrying the authenticated user's identity onto the agent's tool calls so every read and write is scoped to what that user may legitimately reach. Done properly the agent can never exceed the rights of the user it acts for, and each invocation lands in the audit trail with attribution as a side effect.
Exam context: The structural fix that the detective and instruction-level distractors only pretend to be. It answers both halves of the security question at once: what is possible, and who did it.
See also: 3.2 Authentication and Authorisation Gaps
Effective Privilege
What an identity can actually reach at a given hop, as opposed to what the design intended. Measured hop by hop across the chain (user to client, client to agent, agent to each tool, each tool to its downstream system), because the widest credential anywhere on the chain sets the real blast radius.
Exam context: Hop-blindness is a favourite distractor: an option secures the client-to-agent link while the stem's gap sits at the tool-to-database link. Scoping the agent is cosmetic while a tool it calls still holds an admin credential.
See also: 3.2 Authentication and Authorisation Gaps
Token Passthrough
Accepting a token from a client and forwarding it to a downstream API without validating that it was issued to you. The MCP authorisation specification forbids it: servers accept only tokens valid for their own resources and must not accept or transit any others. It breaks audience validation, corrupts attribution in downstream logs, bypasses controls keyed to the token, and lets a stolen token travel.
Exam context: Planted as pragmatic simplicity ("just forward the user's token") and keyed as wrong. Each hop authenticates for itself with its own scoped credential.
See also: 3.2 Authentication and Authorisation Gaps
Latency Budget
The decomposition of end-to-end response time into its terms: time-to-first-token and generation length per model call (thinking included), each retrieval and reranking stage, each serial tool round-trip, each agent-loop iteration. Only genuinely independent calls parallelise; a step that consumes another step's output keeps its serial cost however it is scheduled.
Exam context: Optimisation aimed anywhere but the dominant term spends accuracy for no visible gain. Traces supply the decomposition, which is why this objective leans on 3.4.
See also: 3.3 Accuracy–Latency Trade-offs
Perceived Latency
What streaming improves: tokens arrive as they generate, so a human sees progress immediately while total generation time is unchanged.
Exam context: Streaming offered to a machine consumer is a distractor by construction. A parser or batch job waits for the complete response, so its p95 does not move.
See also: 3.3 Accuracy–Latency Trade-offs
Risk-Based Routing
Splitting traffic so the expensive accuracy path (reranking, a verification pass, a larger tier) runs only on the subset whose stakes justify it, while the bulk takes a fast path. Selective spending rather than blanket application or blanket removal.
Exam context: The recurring keyed answer whenever a stem names both a latency SLA and a quality bar, because it is the only option that holds both. Blanket verification and blanket deletion each sacrifice one named requirement.
See also: 3.3 Accuracy–Latency Trade-offs
Two-Sided Justification
A configuration argument that cites the latency requirement and the quality requirement together, each with its measurement source: "meets the stated p95 in traces while holding the measured error rate at or below the eval bar".
Exam context: Options justified on one side only are planted. "Faster is better" and "more accurate is better" are preferences, not justifications, and the exam can tell the difference.
See also: 3.3 Accuracy–Latency Trade-offs
Trace
The unit of observability for a Claude system: a per-request record carrying prompt version, model id, retrieved context, tool calls and their results, token usage, cost, latency, and the response. A correlation id stitches pipeline stages or loop iterations into one navigable whole.
Exam context: A failure you cannot trace is a failure you cannot diagnose. Options that log single calls in a multi-stage pipeline are distractors, because without correlation ids the failing stage cannot be found.
See also: 3.4 Observability at Scale
Two-Tier Monitoring
The design that volume forces. Cheap aggregate metrics run on every request (latency percentiles, token spend, error and refusal rates, tool-failure rates), while expensive full payloads are kept for a sample plus every detected failure.
Exam context: "Log everything forever" fails twice, on cost and on privacy, because full prompts and outputs capture user data. Sampling rates, retention windows, and redaction are design decisions made up front.
See also: 3.4 Observability at Scale
Quality Instrumentation
Automated scoring of sampled production traffic against a rubric or an LLM judge, calibrated against the formal eval set, so answer quality becomes a monitored, alertable signal between eval runs.
Exam context: The gap in the signature stem where support reports bad answers and engineering sees green dashboards. A hallucinating system is "up", so more uptime alerting is more of the metric class that is already green.
See also: 3.4 Observability at Scale
Drift Signal
A cheap metric that moves before quality complaints arrive: token spend per request, refusal rate, tool-failure rate, input-length distribution. Alerted on tail percentiles rather than means, because a stable mean conceals a doubled p99.
Exam context: How a broken document refresh, a prompt regression, or changed user behaviour gets caught early. Alerting on averages is the planted version of the same idea with the pain averaged out of it.
See also: 3.4 Observability at Scale
Chunk
The unit of findability in a retrieval pipeline. Too small strips the context a passage needs to be understood (a table split from its caption, a clause split from its heading); too large dilutes relevance and spends tokens on padding. Structure-aware splitting with modest overlap beats fixed character counts, because document structure is where meaning lives.
Exam context: Chunking is a trade-off named in both directions, never a setting. Tuning chunk size in response to quality complaints, without retrieval metrics on a labelled set, is guesswork dressed as diagnosis.
See also: 3.5 RAG Pipeline Design
Contextual Retrieval
Prepending a brief, chunk-specific explanation situating each chunk in its document before embedding and indexing it, so passages that lost their context at the chunk boundary become findable again. Anthropic's published benchmark reports large reductions in top-20 retrieval failure rates, stacking further with keyword search and reranking.
Exam context: The highest-leverage upgrade to a standard pipeline, and the one whose reasoning survives its numbers: restore each chunk's lost context before indexing it. The benchmark figures are a dated snapshot and belong in the quick reference.
See also: 3.5 RAG Pipeline Design
Hybrid Indexing
Combining embedding search for meaning with keyword or BM25 search for exact strings, plus metadata filters that narrow the candidate set before similarity ranks it. Corpora containing part numbers, error codes, or clause references need all three.
Exam context: Pure vector search over an identifier-heavy corpus returns thematically similar but wrong passages, and no amount of chunk tuning fixes it. Recall-critical language in a stem keys hybrid plus reranking.
See also: 3.5 RAG Pipeline Design
Embedding-Version Pinning
Fixing one embedding-model version for both the indexed corpus and the incoming queries. A corpus embedded with one model and queried with another degrades silently: no errors thrown, retrieval quietly wrong.
Exam context: One of the two operational causes behind the guide's own confident-stale-answers sample, alongside a refresh that never triggered a re-index. Both are fixed by process, not by a bigger model.
See also: 3.5 RAG Pipeline Design
Failure-That-Matters Test
The tiebreaker in retrieval selection: after naming the data's shape and the query pattern, name which failure would hurt most here (staleness, missed recall, wrong precision, latency), then choose the cheapest strategy whose failure mode is acceptable.
Exam context: What converts preference into argument. Sacrificing the failure mode the stem explicitly names is the one unforgivable trade, and it eliminates most distractors before their other properties are examined.
See also: 3.6 Retrieval Strategy Matching
Agentic Retrieval
Iterative retrieval in which the model searches, reads, refines, and searches again, spending latency and tokens to buy precision on questions no single query can answer. Anthropic's context-engineering guidance frames it as just-in-time retrieval: keep lightweight identifiers and load content as questions arise.
Exam context: Cuts both ways. It is the prestige distractor on a simple latency-budgeted lookup, and the keyed answer on a genuinely multi-hop comparison where single-query retrieval is planted instead.
See also: 3.6 Retrieval Strategy Matching
System of Record
The authoritative source for live structured data, queried through its own interface (text-to-SQL, an API tool) rather than copied into a vector index. The database already answers precisely and currently; embedded rows are stale from the moment of indexing and stripped of the structure that made queries exact.
Exam context: Live operational data in a stem (stock levels, balances, account records) signals a query tool. Any option that embeds it is wrong on staleness alone, before precision is even considered.
See also: 3.6 Retrieval Strategy Matching
M+N Economics
The reuse argument for MCP. Without a shared protocol, M applications each need their own integration to N systems, so the build-out is M×N. With one server per system and one client per application it becomes M+N. The protocol's own analogy is a USB-C port.
Exam context: The selection cue is reuse across surfaces, teams, or clients. Inverted, it inverts the answer: a server for a single consumer that will never share it is standing infrastructure and auth surface bought for nothing.
See also: 3.7 Integration Mechanisms
Transport (MCP)
The binding that carries MCP messages, chosen by deployment topology rather than protocol preference. stdio runs the server as a client-launched subprocess over its standard streams: local, single-client, same machine. Streamable HTTP posts each message to one HTTP endpoint and returns a JSON object or a request-scoped event stream: remote, shared, multi-client, and the topology the OAuth authorisation model applies to.
Exam context: "We need HTTP so we cannot use MCP" is planted confusion. Protocol semantics are identical on every transport, and Streamable HTTP is an MCP transport.
See also: 3.7 Integration Mechanisms
Headless Run
An agent embedded in automation rather than a conversation: the SDK running the agent loop as a library, or the CLI running non-interactively as a subprocess with parsed output. The consumer is a script, there is no human in the loop, and the output must be machine-readable.
Exam context: Cued by "runs nightly", "in CI", "unattended". Options that add interactive machinery (streaming, chat surfaces) to a script consumer are cost without a beneficiary.
See also: 3.7 Integration Mechanisms
Decide-Versus-Execute Test
The question that separates agent-to-agent delegation from a plain tool call: does the counterpart reason and choose for itself, or does it execute a fixed, fully-specified operation? Reasoning counterparts justify delegation; executing ones are tools.
Exam context: It eliminates the most expensive wrong answer in one question. Wrapping a deterministic operation in agent-to-agent machinery adds tokens, latency, and a new failure surface over the call that does the same work.
See also: 3.7 Integration Mechanisms
Monolithic Context
Loading the whole capability surface upfront on every request: all tool definitions, all reference material. Simplest to build, one round trip, and a stable prefix the cache makes nearly free, which makes it the right answer for small stable surfaces and the wrong one at estate scale.
Exam context: "The window is big enough, load everything" is the seductive distractor. Rot, degraded tool selection, and per-request cost all arrive before the window limit does, so capacity is not a strategy.
See also: 3.8 Progressive Discovery
Progressive Discovery
Loading capability on demand instead of upfront. Several mechanisms serve the one principle: Skills load metadata always and their instruction body only when triggered, deferred tool loading puts the catalogue behind search, and retrieval keeps identifiers and fetches content as questions arise. The price is extra round trips, more moving parts, and discovery logic that must itself be reliable.
Exam context: The trade-off has two sides and stems name both. A tight interactive budget tolerates fewer hops, so pure discovery for a hot core spends latency on nothing.
See also: 3.8 Progressive Discovery
Deferred Tool Loading
Marking tools to load only when discovered through search, so their schemas stay out of context until needed while the full catalogue remains available. Deferred definitions are excluded from the system-prompt prefix, so prompt caching survives, and at least one tool must stay non-deferred for search to start from.
Exam context: The mechanism that lets a capability surface grow without every request paying for it. The documented posture keeps the handful of most-used tools loaded and defers the rest, which is exactly why "defer everything" is planted.
See also: 3.8 Progressive Discovery
Hot Core
The small, stable set of tools and instructions nearly every request uses, kept loaded and cached while the long tail sits behind discovery. Core membership needs both frequency and stability: a hot but volatile component churns the cache and belongs behind discovery instead.
Exam context: The hybrid partition, and the usual keyed answer when a stem supplies all four decision cues. Pure strategies are planted on either side of it.
See also: 3.8 Progressive Discovery