# CCAR-P Course Overview

Claude Certified Architect – Professional. Blueprint, audience, study allocation, the relationship to CCAR-F, and how to use this course.

import { Card, CardGrid, Badge } from '@prosefly/astro-components';

<Badge color="accent" variant="soft">Exam code CCAR-P</Badge> <Badge color="info" variant="soft">63 items · 120 min</Badge> <Badge color="success" variant="soft">$175</Badge> <Badge color="warning" variant="soft">Pass 720/1000</Badge>

## What the credential validates

That you can **architect production Claude systems end to end** – translating ambiguous business problems into resilient, cost-aware, compliant solutions; selecting and routing between models; designing retrieval and integration layers; standing up evaluation and optimisation programmes; governing safety and regulatory risk; and communicating decisions across their full lifecycle to technical and non-technical stakeholders.

This is the **Professional-tier Architect** exam. It assumes you already operate at Foundations level and tests **senior-architect judgment**: trade-offs under constraint, decision matrices, cost models, ADR-style reasoning, and the ability to justify *why* a design is correct for a specific context rather than reciting features.

**Intended for:** solutions architects, staff/principal engineers, and technical leads who own Claude system design in an enterprise, including regulated industries.

**Not intended for:** first-time Claude users, or roles that only consume Claude as a productivity tool (see CCAO-F).

## Relationship to CCAR-F (read this first)

CCAR-P is **not a disjoint syllabus** from the Architect – Foundations exam. Every one of the five CCAR-F domains reappears inside CCAR-P **at higher altitude** – you are no longer asked *what* a pattern is, but *when to choose it under conflicting constraints and how to defend the choice*.

| CCAR-F domain | Reappears in CCAR-P as | Altitude shift |
| --- | --- | --- |
| Agentic Architecture & Orchestration (27%) | D1 Solution Design & Architecture; multi-agent parts of D3 | From "build a coordinator/subagent loop" to "choose workflow vs agentic vs augmented-LLM under SLA, cost and reliability constraints, and write the ADR" |
| Prompt Engineering & Structured Output (20%) | D2 Models, Prompting & Context Engineering | From "write a good prompt" to "govern prompts as versioned assets, route across a model portfolio, manage breaking changes and caching architecture" |
| Tool Design & MCP Integration (18%) | D3 Integration (incl. RAG) | From "define a tool schema" to "capability-bloat and least-privilege analysis, identity propagation, MCP vs API vs agent-to-agent selection" |
| Context Management & Reliability (15%) | D1 HA/fallback; D2 context engineering; D4 optimisation | From "manage the context window" to "capacity planning, rate-limit tiers, fallback design, observability at scale" |
| Claude Code Configuration & Workflows (20%) | D7 Developer Productivity & Operational Enablement | From "configure CLAUDE.md and settings" to "roll out managed policies and enablement programmes across teams" |

### The four deltas to study

Four areas are **new or substantially deeper** at Professional level. If you only have time to close gaps, close these:

1. **RAG architecture (D3, 19% – the biggest domain).** Chunking strategy by data shape, dense/sparse/hybrid retrieval, reranking, grounding/citations, retrieval evaluation, and the RAG vs long-context vs fine-tuning decision. Almost absent at Foundations.
2. **Evaluation frameworks and A/B testing (D4, 16%).** Golden sets, LLM-as-judge calibration, pairwise testing with statistical significance, offline vs online evals, regression suites in CI, and structured failure diagnosis.
3. **Regulated-industry compliance (D5, 14%).** GDPR/DPIA/residency, HIPAA/BAA/PHI, FedRAMP High via Bedrock/Vertex, SOC 2, EU AI Act, Zero Data Retention (and Fable 5.1's 30-day retention requirement).
4. **Stakeholder communication and lifecycle management (D6, 14%).** Discovery frameworks, ADRs and decision matrices, C4 documentation, lifecycle phases with exit criteria, and managing model deprecations as a lifecycle event.

## Blueprint (Exam Guide v1.0, effective July 2026)

| # | Domain | Weight | Items (approx.) | Course page |
| --- | --- | --- | --- | --- |
| 1 | Solution Design & Architecture | 17% | ~11 | [Domain 1](/ccar-p/domains/d1-solution-design-architecture/) |
| 2 | Claude Models, Prompting & Context Engineering | 13% | ~8 | [Domain 2](/ccar-p/domains/d2-models-prompting-context-engineering/) |
| 3 | Integration (incl. RAG) | **19%** | ~12 | [Domain 3](/ccar-p/domains/d3-integration-rag/) |
| 4 | Evaluation, Testing & Optimization | 16% | ~10 | [Domain 4](/ccar-p/domains/d4-evaluation-testing-optimization/) |
| 5 | Governance, Safety & Risk Management | 14% | ~9 | [Domain 5](/ccar-p/domains/d5-governance-safety-risk/) |
| 6 | Stakeholder Communication & Lifecycle Management | 14% | ~9 | [Domain 6](/ccar-p/domains/d6-stakeholder-communication-lifecycle/) |
| 7 | Developer Productivity & Operational Enablement | 7% | ~4 | [Domain 7](/ccar-p/domains/d7-developer-productivity-operational-enablement/) |

:::tip[Where the marks are]
Integration/RAG (19%), Solution Design (17%) and Evaluation (16%) together are **52%** of the exam. The two "soft" domains – Governance (14%) and Stakeholder/Lifecycle (14%) – are another **28%** and are where Foundations-level candidates lose points. Do not treat them as filler.
:::

## The Architect's mindset

The exam rewards one posture consistently: **an architect chooses under constraint and can defend the choice with evidence.** Correct answers tend to:

- Start from **business value pillars** (efficiency, cost, performance SLAs) and derive the design, not the reverse.
- Prefer **programmatic enforcement** (hooks, validation, `stop_reason`) over prompt-based enforcement for critical rules.
- Apply **least privilege** to tools – remove unneeded capabilities rather than logging or confirming them.
- Design for **failure**: fallback models, retries with backoff, idempotency, human gates on irreversible actions.
- Measure with **per-segment** metrics and independent evaluation, never aggregate-only or self-report.
- Match **cloud placement** and **retention** to data residency and compliance, not convenience.
- Treat prompts, models and tools as **versioned, governed assets** with rollout and rollback plans.

Wrong answers tend to: over-engineer (multi-agent where a workflow suffices), trust self-reported confidence, use arbitrary iteration caps or natural-language parsing for control flow, give agents 18 tools "just in case", optimise a single number while masking per-segment regressions, and skip the DPIA/BAA/human gate because "it is internal".

## Suggested time allocation (35-hour plan)

| Domain | Weight | Hours |
| --- | --- | --- |
| Integration (incl. RAG) | 19% | 8 |
| Solution Design & Architecture | 17% | 6.5 |
| Evaluation, Testing & Optimization | 16% | 6 |
| Governance, Safety & Risk Management | 14% | 5 |
| Stakeholder Communication & Lifecycle | 14% | 5 |
| Models, Prompting & Context Engineering | 13% | 3 |
| Developer Productivity & Operational Enablement | 7% | 1.5 |

## Hands-on preparation checklist

- [ ] Build a **RAG pipeline** end to end (ingest → chunk → embed → index → retrieve → rerank → ground) and instrument `recall@k` and faithfulness.
- [ ] Reproduce the **confident-but-wrong-after-refresh** failure: change a document, watch stale retrieval produce a wrong answer, and fix it at the index layer.
- [ ] Write an **ADR** for a workflow-vs-agentic decision with a decision matrix and rejected alternatives.
- [ ] Stand up an **LLM-as-judge** eval in a separate session/model and **calibrate** it against human labels.
- [ ] Run a **pairwise A/B test** of two prompts and compute whether the difference is statistically significant.
- [ ] Model the **cost** of routing Haiku 4.5 → Sonnet 5 → Opus 5 with prompt caching and Batch API on a realistic workload.
- [ ] Do a **capability-bloat / least-privilege** review of an agent's tool set and remove unneeded destructive tools.
- [ ] Draft a **DPIA** outline and a **BAA/PHI** handling note for a regulated deployment; decide Bedrock vs Vertex vs direct API on residency grounds.
- [ ] Produce a **C4 context + container** view and a **runbook** for one system.

## Course pages

<CardGrid>
  <Card title="D1 · Solution Design & Architecture" href="/ccar-p/domains/d1-solution-design-architecture/" icon="lucide:drafting-compass">17%</Card>
  <Card title="D2 · Models, Prompting & Context Engineering" href="/ccar-p/domains/d2-models-prompting-context-engineering/" icon="lucide:sliders-horizontal">13%</Card>
  <Card title="D3 · Integration (incl. RAG)" href="/ccar-p/domains/d3-integration-rag/" icon="lucide:database">19%</Card>
  <Card title="D4 · Evaluation, Testing & Optimization" href="/ccar-p/domains/d4-evaluation-testing-optimization/" icon="lucide:flask-conical">16%</Card>
  <Card title="D5 · Governance, Safety & Risk Management" href="/ccar-p/domains/d5-governance-safety-risk/" icon="lucide:shield-check">14%</Card>
  <Card title="D6 · Stakeholder Communication & Lifecycle" href="/ccar-p/domains/d6-stakeholder-communication-lifecycle/" icon="lucide:presentation">14%</Card>
  <Card title="D7 · Developer Productivity & Operational Enablement" href="/ccar-p/domains/d7-developer-productivity-operational-enablement/" icon="lucide:users">7%</Card>
  <Card title="Practice Exam" href="/ccar-p/practice-exam/" icon="lucide:clipboard-check">63 timed items</Card>
  <Card title="Practice Exam 2" href="/ccar-p/practice-exam-2/" icon="lucide:clipboard-check">63 new, harder items</Card>
</CardGrid>
