Domain 3 — Integration (19%)

19% of the exam and the heaviest domain, roughly 12 questions. The exam's judgement is that real difficulty lives in the connections, not the pattern.

3.1 Choosing an integration mechanism

The deployment-surface question is a compliance question in disguise. Choosing Bedrock, Vertex or Foundry lets an enterprise authenticate through existing IAM rather than distributing API keys, bill through an existing commitment, log invocations into its own audit pipeline, and — the decisive one — pin inference to a named geography where a regulator requires it. The trade-off is that the direct API generally gets new capability first.

3.2 Authentication and authorisation

Two distinct problems that the exam expects you to separate:

• Authenticating to Claude. Keys in a secret manager, never in source or a client bundle; separate credentials per environment; rotation on suspicion; or federated identity where a cloud deployment surface allows it.
• Authorising what the system may reach on a user's behalf. This is where enterprise designs go wrong. An agent that queries a database with one privileged service account can return any user any row. The correct pattern propagates the caller's identity and enforces authorisation at the data layer, so the agent inherits the user's permissions rather than the application's.

The same reasoning applies to MCP servers and tools: each holds credentials of its own, and its reach is bounded by what it was granted. Grant narrowly, and treat an over-privileged tool as an architectural defect rather than a configuration detail.

3.3 Retrieval pipeline design

RAG is examinable at component level here. The canonical pipeline and the failure at each stage:

Two numbers worth carrying: contextual enrichment combined with hybrid retrieval cuts retrieval failure substantially over naive embedding search, and adding reranking on top cuts it further — Anthropic's published figures are a 49% and then a 67% reduction in top-20 retrieval failures. Prompt caching is what makes the enrichment step economic, because the source document is cached once rather than re-sent per chunk.

Citations are the professional answer to grounding. Enabling them on documents returns the exact supporting passage with each claim, as a structured pointer rather than model-generated prose: cited_text, document_index and a character, page or block location. They are more reliable than asking for citations in the prompt, and cited_text does not count toward output tokens. Note one constraint that appears in questions: citations are not compatible with strict structured output, because interleaved citation blocks conflict with a rigid JSON schema.

3.4 Accuracy, latency and cost as a three-way trade

Every integration decision moves at least two of these. Retrieval breadth raises accuracy and cost; reranking raises accuracy and latency but can lower cost by shrinking the final prompt; a heavier model raises accuracy, latency and cost together; caching lowers cost and latency and does nothing for accuracy.

Latency levers in the order they apply: choose the lightest adequate tier; shorten the prompt and bound the output; stream so that time-to-first-token rather than total time governs the experience; and parallelise what is independent. The documented caution is worth remembering — engineer for quality first, then reduce latency, because optimising early hides what good looks like.

3.5 Observability

An LLM system that logs only errors is unobservable, because its characteristic failure is a successful-looking response with wrong content. A professional integration captures, per request:

• request_id, model and version, and the prompt or prompt template version
• stop_reason and full usage, including cache creation and read tokens
• Latency split into time-to-first-token and total
• Tool calls attempted, their results and their errors
• Retrieval: what was retrieved and what was actually cited
• Validation outcomes, guardrail triggers and escalations to human review
• Cost attributed to a tenant, feature or team

That set is what makes the difference between "quality seems worse this week" and a diagnosis. It is also what an auditor asks for, which is why observability sits in an integration domain and a governance domain simultaneously.

← Previous: Domain 2 — Claude Models, Prompting and Context Engineering  |  Next: Domain 4 — Evaluation, Testing and Optimisation →