Integration

Integration is the biggest single domain on CCAR-P — 19% of the blueprint, about 12 of the 63 questions. It is also the widest, spanning eight distinct objectives: evaluating tool and agent configuration for capability bloat, analysing authentication and authorisation for security gaps, weighing accuracy against latency, choosing monitoring strategies at scale, designing RAG pipelines with chunking and indexing strategies, matching retrieval strategy to data shape and query pattern, evaluating connection protocols including MCP, and choosing between progressive discovery and monolithic context.

The unifying idea is the boundary. Everything in this domain is about what crosses between the model and the systems around it — which capabilities it can reach, under whose authority, carrying what data, over which protocol, and what record that leaves behind. Get the boundary wrong and no amount of prompting recovers it, because the model is on the wrong side of the control.

That is why this domain punishes people who reason from the model outward. The exam's own published sample here is a least-privilege question whose correct answer is to delete two tools — no knowledge of Claude required, only the discipline to apply a security principle when a more interesting option is on the page. Expect the same shape repeatedly: ordinary distributed-systems judgement, applied to a component that happens to be probabilistic.

What the exam actually tests

• —Least privilege on the tool surface: removing capability versus gating it
• —Where authorisation is enforced, why a system prompt is not that place, and where credentials may live
• —MCP mechanics — transports, discovery, invocation — and when MCP beats a direct integration
• —Chunking and retrieval strategy chosen from data shape and query pattern, not from habit
• —Diagnosing where latency actually accrues in a multi-stage pipeline
• —What a trace must contain for an incident to be reconstructable after the fact

Tool surface: capability bloat and progressive discovery

Every tool you expose is two liabilities: an action the system can be induced to take, and a candidate the model must consider on every request. Least privilege addresses the first — a capability the role never needs should not be configured, because removing it eliminates the attack surface rather than monitoring it.

The second is a selection problem. Past a few dozen tools, always loading every schema costs context on every request and degrades tool choice. Progressive discovery is the alternative: defer loading and let the model search the catalogue, or move rarely-needed procedure into a Skill. The trade-off is a round trip plus a new failure mode — the right tool never gets found — so it is a scale decision, not a default. One nuance worth carrying: discovery that appends schemas preserves a cached prefix, whereas mutating the tool list between turns invalidates the whole cache.

Authorisation, authentication and secrets at the boundary

The agent's identity is not the user's identity. If an agent holds a credential that can read every customer's records, per-user scoping enforced anywhere the model can see it is not enforcement — it is a request. The scope has to be applied where the model cannot reach: in the tool implementation, in the query the tool builds, or in a proxy that rewrites the call.

Credentials must not enter the context window. Anything placed in a system prompt or a message persists in conversation history, is replayed on later turns, and surfaces in logs and summaries. The sound patterns are to keep the authenticated call host-side behind a tool the orchestrator executes, or to inject the secret at egress from a store the model never sees. Audit the reverse direction too: what a tool returns lands in context and in your logs, so an over-broad response is a disclosure.

MCP and choosing a connection protocol

MCP is a protocol, not a library: JSON-RPC 2.0 messages over one of two standard transports. With stdio the client launches the server as a subprocess and exchanges newline-delimited messages over its stdin and stdout. With Streamable HTTP the server exposes a single endpoint handling POST and GET, may issue a session identifier at initialisation that the client returns on later requests, and can stream responses as server-sent events. The older HTTP-plus-SSE arrangement is its deprecated predecessor.

After initialisation and capability negotiation, clients discover tools by listing them and invoke them by name with arguments. Servers may declare behavioural annotations on a tool, and the specification is explicit that clients must treat those as untrusted unless the server itself is trusted — an annotation is a hint, never a permission. Choose MCP when a capability is shared across several applications and maintained independently of any one of them; an app-specific action is a direct tool.

RAG: chunking, retrieval strategy, and the accuracy–latency trade

Retrieval failures present as confident wrong answers, which is why the blueprint pairs them with diagnosis. The exam's published sample is exactly this: a document refresh, unchanged model and latency, answers that got worse — the index, not the model.

Chunking is where most quality is won or lost. Boundaries that separate a clause from its definition, a figure from its caption, or a row from its header produce chunks that retrieve well and answer badly. Retrieval strategy follows the query pattern: exact-identifier lookup wants lexical or keyed retrieval, similarity questions want vectors, mixed traffic usually wants both plus a re-ranking pass.

Every accuracy improvement here costs latency — more candidates, a reranker, a second hop — so decide against a measured budget, and treat a re-index as a deploy needing staging and a rollback path, because it can change every answer at once.

Observability when the unit of work is non-deterministic

You cannot reproduce an incident by re-running the request, so the trace has to carry everything needed to explain the outcome afterwards: which tools were called with which arguments and what they returned, which documents were retrieved and from which index version, the model and configuration in force, token counts and cache hit rates, and how the turn ended.

That last field matters more than it looks. A turn that stopped at an output limit, one that ended normally, and one the model declined look similar downstream and have completely different fixes.

At scale, sampling full traces plus aggregate counters is the workable compromise — capturing every request in full becomes its own cost and its own retention problem. Decide sampling and retention deliberately, because traces contain user data and inherit its obligations.

Where candidates go wrong

How to study this domain

Integration is 19% and broad, so allocate proportionally — about one part in five of your preparation — and split it deliberately rather than reading around what you already know.

Spend the first block on MCP, the only part of this domain with crisp, checkable facts: the two standard transports and how each carries messages, what happens at initialisation, how tools are discovered and invoked, and the specification's position that tool annotations are untrusted. Small, finite, and it converts directly into points.

Spend the second on retrieval, working from failures rather than architecture diagrams. For a corpus you know, write down what a bad chunk boundary does to a specific question, and what a stale index looks like from outside. Confidently-wrong-after-a-refresh is a signature the exam reuses, and recognising signatures beats reasoning from first principles under time pressure.

Spend the third on security, as a habit rather than a topic: for any design in front of you, ask what the agent can do that its user could not, and where the rule preventing it is enforced. If the answer is anywhere the model can read, you have found the flaw.

Common questions