The Capstone: Architecting the Whole Platform

Twenty chapters, seven domains, one system. This capstone assembles them into the bookshop’s enterprise customer knowledge-and-support platform. We design and defend it the way an architect actually delivers one: from the business problem down to the running, monitored, governed system. Then we work the exam guide’s three sample questions. The point of the credential is recognizing each item as a decision you’ve now made in context.

The platform, domain by domain

The system from chapter 0: a customer-facing assistant answers questions and resolves issues, backed by retrieval over a private corpus, holding customer PII, meeting cost and latency SLAs, evaluated continuously, observable, and governed. Every domain of the exam is a real decision in building it.

Solution design (D1). It starts before any code. You discover the real problem behind “help customers faster”: the deflection rate the business actually needs, the value pillar it optimizes (cost per contact), and whether Claude is even the right tool. For the templated 40%, a cheaper path might win. You choose the architecture pattern per part — an augmented-LLM retrieval answer for the common question, an agentic loop for the open-ended case. Then you decompose the system into a support coordinator over a knowledge-retrieval component and an order-actions component, complete and disjoint.

Models, prompting, context (D2). You route by model tier — Haiku for retrieval-answers and intent routing, a stronger model for refund reasoning — pinned to snapshots. The system prompt carries the role, the output contract, and the trusted-instruction layer, with few-shot examples where consistency matters. The large, stable policy prefix is cached while the live user turn stays uncached. Measured: ~4,777 tokens written once, then read at a tenth of the price.

Integration & RAG (D3). Shared capabilities live behind MCP servers; app-local logic stays a custom tool; capability bloat is resisted. The RAG pipeline chunks, embeds, indexes, and retrieves over the policy/catalog/help corpus, and retrieval is targeted. Verified live: a doc_type metadata filter turned a wrong-chunk refusal into a correct, cited answer. Tools run under least privilege, authorization enforced in code. The whole thing is observable, with the usage object as the cost-and-latency meter.

Evaluation & optimization (D4). Nothing ships on vibes. An eval harness scored the assistant 7/7 on a representative dataset with an LLM-as-judge you validated. A/B testing proved grounding’s worth: an ungrounded variant scored 2/7 and confidently claimed the shop ships to the UK when it doesn’t. It also gave you a diagnosis discipline for when a number regresses. Then you optimize against the SLA: cache the prefix, route by task, trim tokens, never blind.

Governance & risk (D5). Guardrails enforce what the model can’t be trusted to — a PreToolUse deny on destructive actions, human approval on refunds over a threshold. The design meets its data obligations: PII minimized, encrypted, retained to a limit, audited, with a GDPR deletion path. It’s built to detect and mitigate bias, cite its sources, and disclose that it’s AI.

Stakeholders & lifecycle (D6), and enablement (D7). You communicate the tradeoffs so a business owner can choose quality against cost against latency, and set the SLA. You document the decisions and their rationale and run the lifecycle as a loop. The Arc 4 evals feed the iteration that a never-”done” system needs. And you enable the team with shared Claude Code conventions and an AI-assisted review pipeline.

That’s the whole blueprint, and it’s one coherent system — no domain is decoration.

The sample questions, worked

The guide publishes three sample items. Worked with their rationale, they show the reasoning the whole exam rewards.

Sample 1 (Domain 3 — Integration). A support agent has read-tickets, draft-replies, issue-refunds, and delete-accounts tools; staff only ever need read and draft. Applying least privilege, which change best reduces risk? → Remove the refund and delete tools from the agent’s configuration entirely. Least privilege means eliminating a capability the role doesn’t need. That removes the attack surface — an injection can’t invoke a tool that isn’t there. Logging (a detective control) and a confirmation prompt (a compensating control) leave the dangerous capability present. A bigger model doesn’t change authorization scope at all. This is chapter 10 exactly: remove, don’t guard.

Sample 2 (Domain 2 — Models, Prompting & Context). An 8,000-token system prompt and policy document ship on every request, followed by a short varying user message; latency and cost are both concerns. Which optimization addresses both? → Place the static system prompt and policy before the dynamic content and enable prompt caching. A stable prefix cached is reused on every subsequent call, cutting both time-to-first-token and per-request cost without discarding any needed context. Verified: a ~7,957-token static prefix served from cache. Truncation loses policy the assistant needs. Blindly downsizing the model risks quality. Moving the policy into a few-shot block creates no cacheable prefix. Chapter 14.

Sample 3 (Domain 4 — Evaluation & Optimization). A RAG system suddenly returns confident but incorrect answers after a document refresh, while latency and model version are unchanged. Where do you look first? → The retrieval/indexing step is returning irrelevant or stale chunks. The trigger is the document refresh, and model and latency are constant. So the change is in what retrieval feeds the model — a broken re-index or mismatched embeddings. Verified in chapter 13: holding the model and prompt fixed, a bad refresh flipped a correct “30 days” into a wrong “14 days.” The model was innocent; the context was poisoned.

The instinct behind the answers

Read the three together and the same architect’s reasoning recurs — and it’s the exam’s real content:

• Reduce the surface, don’t monitor it. Security is removing the unneeded capability, not logging its misuse. The strongest control is the one that makes the failure impossible, not observable.
• Match the fix to the actual constraint. Caching addresses latency and cost because it reuses a real prefix; truncation and downsizing attack the wrong thing. The question always contains the constraint that selects the answer.
• Isolate the variable that changed. A regression after a document refresh, with everything else constant, points at retrieval — not the model. Diagnosis is subtraction: hold constant what didn’t move, and look where it did.

When an exam item offers a capability-removing control against a monitoring one, a constraint-matched optimization against a plausible-but-mismatched one, or an isolate-the-change diagnosis against a guess, the first is almost always right. That instinct is what CCA-Professional is built to reward: architecture as the disciplined reduction of a problem to the decision that actually moves it.

Final thoughts

The credential asks whether you can design, integrate, evaluate, and govern a production Claude system and defend the choices. This series answered it by architecting one — a support platform that retrieves and grounds, routes and caches, evaluates and optimizes, guards and complies, and is handed off to a team to run and iterate. Where the work was code, it ran against a real pipeline. Where it was judgment, it was reasoned in the open and labelled as such. Go design the system your own blueprint describes — a real one, end to end. Then the exam stops being questions and becomes a description of decisions you’ve already defended. That’s the whole point of the credential, and of this series.

Back to the exam overview, or start designing — the best preparation is a production system you architected yourself.