CCA-Professional: Architecting Claude Systems That Ship

There are two Architect credentials. The Foundations exam (CCAR-F) checks that you understand the building blocks — the agentic loop, tools, prompt and context engineering. The Professional exam (CCAR-P), the subject of this series, checks something harder and more valuable. It asks whether you can design, integrate, evaluate, and govern a production Claude system end to end, and defend the architectural decisions to the people who pay for it. It assumes the Foundations material and builds a full storey on top of it.

This is a study guide for CCAR-P, written as a book and organized the way an architect actually works — from a business problem to a shipped, monitored, governed system. It teaches each subject first and maps to the exam blueprint second. And where a claim is about code, it’s run against a real pipeline rather than asserted from memory.

The exam at a glance

Credential	Claude Certified Architect – Professional
Code	CCAR-P
Items	63
Format	Multiple-choice and multiple-response (each item says how many to pick)
Time	120 minutes
Passing score	720 on a 100–1,000 scale
Fee	$175 USD
Validity	12 months

Two format notes shape how you study. It’s 63 items in 120 minutes — a shade under two minutes each, so the pressure is depth of judgment, not clock. And many items are multiple-response (“select two/three”), which punishes shallow familiarity. On an architecture exam, the second-best answer is often also plausible, and only real understanding separates it from the best one. The score report gives percent-correct per domain, but you pass on the total. So a weak domain can be carried, and neglecting the 19% giant to perfect the 7% corner is a bad trade.

What “architect” means here — and how it differs from Foundations

The Foundations exams reward knowing how a piece works. The Professional exam rewards knowing which pieces to combine, at what cost, under what constraints, and how to prove it works and keep it working. The blueprint reflects that. It’s dominated by integration (including RAG), solution design, evaluation, governance, and stakeholder lifecycle — the concerns that only appear once a system meets real data, real users, real regulators, and a real budget.

#	Domain	Weight
3	Integration (RAG, protocols, observability)	19%
1	Solution Design & Architecture	17%
4	Evaluation, Testing & Optimization	16%
5	Governance, Safety & Risk Management	14%
6	Stakeholder Communication & Lifecycle	14%
2	Claude Models, Prompting & Context Engineering	13%
7	Developer Productivity & Operational Enablement	7%

Notice what’s large: not the API mechanics (that’s the Developer exam), but integration and design and evaluation and governance — the architect’s work. If you’ve shipped and operated one real Claude system, you’re the audience. If you haven’t, the fastest preparation is to design one — and this series designs a full one as it goes.

The system we design

A study guide that only lists concepts teaches an architect nothing, because architecture is about how the pieces fit this problem. So this series designs one system throughout — the same bookshop from this blog’s other series, scaled up to what an enterprise actually runs: a customer knowledge-and-support platform.

Picture it. A customer-facing assistant answers questions and resolves issues. Behind it, a RAG layer retrieves from a corpus of policies, catalog data, and help articles, and tools look up orders and process refunds. The whole thing handles customer PII under GDPR and meets latency and cost SLAs. It’s evaluated continuously, observable in production, and governed with guardrails and human-in-the-loop where the stakes demand it. Every domain of the exam is a real decision in building that platform, and we make each decision in context rather than in the abstract.

The run-verified-where-it-is-code convention

This blog’s rule is that a technical claim is either run against a pinned version or flagged as unrun. An architecture series has two kinds of content, and it’s honest about the line between them:

• Code claims are run. The RAG pipeline (chunking, embeddings, indexing, retrieval) and the evaluation harness (metrics, LLM-as-judge, A/B) are stood up and executed. You’ll see real retrieved chunks, real grounded answers, and real eval scores — not descriptions of what they’d do. Prompt caching, token and latency optimization, and model-selection measurements are likewise run. Pinned: anthropic 0.120.2, claude-agent-sdk 0.2.128, mcp 1.29.0, and for RAG langchain-core 1.5.2 with a local nomic-embed-text embedding model; verification runs on claude-haiku-4-5. Production embeddings would use a service like Voyage AI; the mechanics are identical.
• Design and governance is grounded judgment, and labelled as such. Compliance (GDPR, HIPAA, FedRAMP), risk, ethics, stakeholder communication, and lifecycle are architecture practice, not code. Those chapters give concrete, defensible guidance. They treat compliance at the architect’s-decision level — what the architecture must provide: data residency, audit trails, encryption, least privilege, human review. They don’t pose as legal authority. Where something is a design recommendation rather than a run result, the text says so.

The line is about trust. When a chapter shows you a RAG answer or an eval score, it happened. When it recommends an approval gate before an irreversible action, that’s reasoned architecture. You’ll know which is which.

The map

Seven arcs, following the arc of the work itself, plus this orientation and a capstone:

• Arc 1 — Solution design & architecture (D1): business problem to system, the pattern choice (workflow / agentic / augmented-LLM), and multi-agent decomposition at scale.
• Arc 2 — Models, prompting & context at scale (D2): choosing a model as an architect, system prompts and guardrails, and context, caching, and prompt reuse.
• Arc 3 — Integration & RAG (D3): integration protocols, the RAG pipeline (chunking, indexing, retrieval), security and authorization, and observability at scale.
• Arc 4 — Evaluation, testing & optimization (D4): metrics and eval datasets, A/B testing and failure diagnosis, and cost/latency optimization.
• Arc 5 — Governance, safety & risk (D5): guardrails and failure modes, compliance and data handling, and ethical AI.
• Arc 6 — Stakeholders & lifecycle (D6): discovery and communicating tradeoffs, and documentation and the lifecycle.
• Arc 7 — Developer productivity (D7): enabling teams with Claude Code and operational support.

Each chapter teaches its subject, makes its decisions against the platform above, and points at the next. The goal isn’t to memorize the blueprint — it’s to be able to architect the system it describes, and to defend every choice.

Next: from business problem to Claude solution — how an architect turns a vague business ask into a system worth building.