Capability Bloat
A tool surface larger than the role's task list justifies. The excess has two costs. The first is attack surface, because a connected tool is a capability that can be reached, whatever the system prompt says. The second is context weight, because every definition occupies the window on every request, and near-duplicate tools degrade selection accuracy.
Exam context: This is what the whole objective is about. Configurations are evaluated by starting from the role's task list, never from the platform's capability list, and "more tools so it can handle anything" is the wrong option that reverses this rule.
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 the wrong options by a fixed procedure. In the guide's own Domain 3 sample question, removal is the right answer, and logging, a confirmation prompt, and a larger model are the wrong options. So learn the ranking well enough to apply it at once.
See also: 3.1 Capability Bloat
Tool Consolidation
Combining overlapping tools, or tools with a vague purpose, into fewer tools. Each remaining tool is clearly described and scoped to a task. Related tools are namespaced under a common name prefix. The half of least privilege that removes tools shrinks the surface. Consolidation improves the tools that remain.
Exam context: Least privilege is not only removal. A large number of narrow, near-duplicate tools 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. The credential is broader than any individual user's rights, so the agent 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. Questions describe an agent reading every record through a shared service credential, and the right 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 as a side effect, the audit trail records each invocation and the user it was for.
Exam context: The structural fix. The detective and instruction-level wrong options only look like this fix. 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: A common wrong option ignores which hop has the gap: it secures the client-to-agent link while the gap in the question is at the tool-to-database link. Scoping the agent has no real effect 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 (the check that a token was issued to this server), corrupts attribution in downstream logs, bypasses controls tied to the token, and lets a stolen token be forwarded to other systems.
Exam context: It appears as a practical shortcut ("just forward the user's token"), and it is the wrong answer. 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 of any term except the largest one loses accuracy and gives no visible gain. Traces supply the decomposition, which is why this objective depends 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 always a wrong option. 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. The rest of the traffic takes a fast path. Spending only where it is needed, rather than applying it to everything or removing it from everything.
Exam context: The recurring right answer whenever a question names both a latency SLA and a quality threshold, because it is the only option that meets both. Verification on everything and deletion of all verification each fail 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 wrong options. "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 links pipeline stages or loop iterations into one record that you can follow.
Exam context: A failure you cannot trace is a failure you cannot diagnose. Options that log single calls in a multi-stage pipeline are wrong, because without correlation ids the failing stage cannot be found.
See also: 3.4 Observability at Scale
Two-Tier Monitoring
The design that high request volume requires. 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. The scoring is calibrated against the formal eval set. Answer quality then becomes a monitored signal that can raise alerts between eval runs.
Exam context: The gap in the typical question where support reports bad answers and engineering sees dashboards that show no problem. A hallucinating system is "up", so more uptime alerting adds more of the type of metric that already shows no problem.
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 wrong option: it uses the same idea, but the average hides the bad results.
See also: 3.4 Observability at Scale
Chunk
The unit that a retrieval pipeline finds. 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 irrelevant text. When the document structure is reliable, structure-aware splitting with modest overlap works better than splitting by fixed character counts, because document structure carries the meaning.
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 guessing that looks like diagnosis.
See also: 3.5 RAG Pipeline Design
Contextual Retrieval
Prepending a brief, chunk-specific explanation to each chunk before embedding and indexing it. The explanation states the chunk's place in its document. This makes passages that lost their context at the chunk boundary findable again. Anthropic's published benchmark reports large reductions in top-20 retrieval failure rates, with further reductions when keyword search and reranking are added.
Exam context: The highest-leverage upgrade to a standard pipeline, and the one whose reasoning stays true when its numbers change: 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 question makes hybrid plus reranking the right answer.
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 sample question about confident but stale answers, 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 deciding step in retrieval selection: after naming the data's shape and the query pattern, name which failure would hurt most here (staleness, missed recall (a relevant document that retrieval does not find), wrong precision, latency), then choose the cheapest strategy whose failure mode is acceptable.
Exam context: What turns a preference into a reasoned choice. Sacrificing the failure mode the question explicitly names is the only trade that is never acceptable, and it eliminates most wrong options 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 get 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: It can be the right or the wrong answer. It is the impressive wrong option on a simple lookup with a latency budget. It is the right answer on a genuinely multi-hop comparison, where single-query retrieval is the wrong option 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 scenario (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. When there is no reuse, the answer is the opposite: a server for a single consumer that will never share it adds permanent infrastructure and more authentication to secure, for no benefit.
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. Streamable HTTP is remote, shared and multi-client, and the OAuth authorisation model applies to it.
Exam context: "We need HTTP so we cannot use MCP" is a deliberate confusion that the exam includes. 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 features (streaming, chat surfaces) to a script consumer add cost and benefit nobody.
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 an agent-to-agent setup adds tokens, latency, and a new point of failure 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 large catalogue sizes.
Exam context: "The window is big enough, load everything" is the tempting wrong option. Context rot, degraded tool selection, and per-request cost all arrive before the window limit does, so a big enough window does not decide the 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 components, and discovery logic that must itself be reliable.
Exam context: The trade-off has two sides and questions name both. A tight interactive budget tolerates fewer hops (discovery round trips), so pure discovery for a hot core adds latency with no benefit.
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 still works, 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 practice that the documentation recommends keeps the handful of most-used tools loaded and defers the rest, which is exactly why "defer everything" is a wrong option.
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 keeps changing the cache and belongs behind discovery instead.
Exam context: The hybrid partition, and the usual right answer when a question supplies all four decision cues. Questions include pure strategies on either side of it as wrong options.
See also: 3.8 Progressive Discovery