After passing the Claude Certified Architect – Foundations exam, the natural next step is the Professional level. The Professional exam is a different kind of test. Foundations asks: can you identify the correct mechanism? Professional asks: given these business constraints, compliance requirements, cost envelope, and latency targets — which architecture would you choose and why?
This guide covers everything that matters for the Professional exam: the 7 domains and their weights, the one mental model that unlocks every question, a domain-by-domain breakdown of what to master, the 12 trap patterns the exam uses to catch you, and a 4-phase study approach that works whether you're already comfortable with Claude or brand new to the Professional-level material.
Exam snapshot: 63 questions, 120-minute time limit, target 75%+ per domain. 5 modules totalling 733 minutes of official course content. Online proctored. My Foundations badge: Claude Certified Architect – Foundations — Professional is next.
The 7 Exam Domains
Anthropic · CCA Professional — Domain Weights
| Domain | Weight | Core focus |
|---|---|---|
| 1. Solution Design & Architecture | 17% | Architecture patterns, multi-agent orchestration, feasibility assessment |
| 2. Claude Models, Prompting & Context Engineering | 13% | Model tier selection, prompt caching, CoT, positional attention |
| 3. Integration | 19% | MCP, RAG, tool design, agent-to-agent, authorization, observability |
| 4. Evaluation, Testing & Optimization | 16% | Eval grading ladder, A/B testing, model rollout, cost optimisation |
| 5. Governance, Safety & Risk Management | 14% | Safety stack, HITL, prompt injection, compliance controls |
| 6. Stakeholder Communication & Lifecycle | 14% | Discovery, tradeoff framing, handoff artefacts, scope management |
| 7. Developer Productivity & Ops Enablement | 7% | Shared config, code review independence, operational diagnosis |
Domain 3 (Integration) carries the most weight at 19%. Domains 6 and 7 test skills that Foundations barely touched — the stakeholder and operational layers of being an architect, not just a builder.
The Master Pattern
Before diving into domains, there is one idea that drives the correct answer on every question in every module:
A thing that looks handled and a thing that has been verified to be handled are different claims.
This sounds abstract. Here is what it means across the five modules:
| Claim | Reality |
|---|---|
| "The demo ran clean five times" | ≠ the system is deterministic |
| "A control is named in the design doc" | ≠ a control with a named owner and evidence artifact |
| "We use a compliant model provider" | ≠ the full data path meets compliance obligations |
| "The model gave a confident answer" | ≠ the answer is correct |
| "Here is the architecture diagram" | ≠ here is the rationale for every decision |
| "Cost per call is $0.002" | ≠ the monthly bill at production scale |
Apply this to every question: look at each answer option and ask whether it is verified/owned/evidenced or merely assumed/named/claimed. The right answer almost always closes the gap between claim and verification. The wrong answers almost always leave it open.
Domain 1: Solution Design & Architecture (17%)
What it tests
Given a real scenario with real constraints, which of the four architectural patterns is correct — and why do the other three fail for this specific case?
The four architecture patterns
The Professional exam forces you to justify your pattern choice. Know the decision rule for each:
| Pattern | Choose when |
|---|---|
| Single augmented LLM call | The task is a single transformation with supplied context (e.g. translate this document using this glossary) |
| Fixed workflow | The steps are known in advance, identical per request, and auditability of each step matters |
| Autonomous agent | The path to the answer only becomes clear as each step reveals new information |
| Multi-agent system | Sub-tasks require genuinely different specialisations, tools, or context that would overload a single agent — and sub-tasks are independent enough to run in parallel |
The Professional exam pairs each pattern with its failure mode in that scenario. "A fixed workflow with extra steps to cover most cases" fails open-ended research tasks because the path can't be pre-enumerated. "An autonomous agent" fails a stable 5-step compliance report because it adds planning overhead the problem doesn't need.
The four AI properties and their design consequences
Every architectural decision traces back to one of four inherent properties of language models:
| Property | What it means | Design consequence |
|---|---|---|
| Non-determinism | Same input → different outputs | Need evals, not manual spot-checks |
| Knowledge boundary | Training data has a cutoff | Need retrieval for live or proprietary data |
| Finite context | Context window is fixed | Need a context management strategy |
| Confidence ≠ correctness | High confidence doesn't mean high accuracy | Need human review or output validation for high-stakes decisions |
The trap for this domain
Right tradeoff word, wrong conclusion. The wrong answers often use the correct vocabulary — "auditability," "scalability," "reliability" — but apply it to the wrong pattern for the given scenario. Read the constraints in the question carefully. A scenario that requires ordered, auditable, exception-halting steps is solved by a supervisor orchestrator, not by peer-to-peer handoffs where each agent decides what to call next.
For architecture pattern questions: first identify what the scenario cannot accommodate (no known steps in advance → rule out fixed workflow; no sub-task independence → rule out multi-agent). The correct answer is often the only one that doesn't break any stated constraint.
Domain 2: Claude Models, Prompting & Context Engineering (13%)
What it tests
How to build prompts that are reliable, cost-efficient, and use the right model for each workload — not prompt tips, but the engineering discipline of prompt design.
Model tier selection
The principle: use the smallest model that clears the accuracy bar, validated by ongoing evaluation. At 400,000 requests per day, "comparable accuracy" across the model family means the cheapest model wins — provided you confirm it keeps winning with real evals. Using a larger model "because errors are more expensive than compute" is a substitution of assumption for measurement.
Prompt caching mechanics
Four things to know cold:
- Caching matches on the prompt prefix — everything before the first dynamic token
- If dynamic values (timestamp, request ID) appear at position zero, the cache hit rate will be near zero regardless of cache settings
- First-time writes cost more; subsequent reads are cheaper — cache the stable prefix
- Dynamic values must come after the static block, never before it
Positional attention
Critical rules buried in the middle of a long system prompt are followed inconsistently. This is not a model failure — it is a prompt structure failure. Rules that must always apply go at the start or end of the prompt, clearly separated from reference content.
The trap for this domain
Applying techniques universally. Chain-of-thought prompting improves multi-step reasoning but adds cost and latency to simple extraction tasks for no benefit. Prompt caching everywhere doesn't help if the prompt structure defeats it. Techniques earn their tokens only when applied to the workloads where they produce measurable improvement.
Domain 3: Integration (19% — the highest weight)
What it tests
How Claude-based systems connect to the world — tool design, retrieval architecture, observability, authorization, and the boundaries between integration patterns.
MCP vs. direct API vs. agent-to-agent
| Pattern | Use when |
|---|---|
| MCP server | Many AI applications need standardised, reusable, discoverable access to the same system — each team maintains their server once |
| Direct API integration | A single, tightly scoped call inside an owned, controlled pipeline with no reuse requirement |
| Agent-to-agent protocol | Two autonomous agents owned by different organisations must coordinate without exposing internal systems to each other |
Authorization: the structural mistake
The most tested trap in Domain 3: authorisation enforced by a system prompt instruction is not a security boundary.
A service account with organisation-wide access plus a prompt saying "only return data for the requesting employee" leaves every employee's data retrievable through a prompt injection or prompt failure. The fix is enforcing access control at the infrastructure layer — per-user scoped credentials or pass-through authentication — so the model simply cannot retrieve what it has not been granted access to.
RAG: when to use structure-aware chunking
Fixed-size chunking (300 tokens, 500 tokens) severs clauses from the definitions and cross-references that give them meaning. For document types where meaning depends on structure — contracts, legal documents, engineering standards — use structure-aware chunking aligned to clauses and sections, with metadata linking cross-references.
For exact identifiers (part numbers, order IDs, SKUs), pure semantic retrieval fails because embeddings blur similar strings. Use hybrid retrieval: keyword/exact matching for identifiers, semantic search for natural-language queries.
Observability at scale
At tens of thousands of sessions per day:
- Log structured traces + correlation IDs for every session
- Capture key metrics (latency, tool selection, retrieval relevance) for every session
- Reserve full payload capture for sampled sessions and error-triggered capture
Logging every full prompt and response at scale is both expensive and counterproductive — when everything is logged, nothing is findable.
The trap for this domain
Authorization via instruction. The exam reliably presents scenarios where prompt instructions are doing security's job. The correct answer always moves authorization to the access-control layer.
Domain 4: Evaluation, Testing & Optimization (16%)
What it tests
How to know whether a system is working, how to improve it safely, and how to detect problems before users do.
The eval grading ladder
| Tier | When to use |
|---|---|
| Code-based (exact match, regex, schema validation) | Output is deterministic and structure is checkable |
| Model-based (LLM-as-judge) | Output is subjective, complex, or high-volume |
| Human review | Ground-truth labelling, judge calibration, high-stakes decisions |
LLM-as-judge design requirements: constrained verdicts (avoid open-ended scoring), a different model from the one being evaluated, and periodic calibration against human expert ratings. An uncalibrated judge is worse than no automated evaluation — it creates false confidence.
Golden dataset composition
The most trustworthy evaluation dataset combines:
- Anonymised real queries from production-like channels (the actual input distribution)
- Deliberately constructed edge cases and failure-prone scenarios (the failure surface)
Synthetic-only datasets inherit the documentation's blind spots. Prompt examples only prove the assistant memorised its own instructions.
A/B testing rigor
The Professional-level requirement:
- Pre-commit hypothesis before the test starts
- Power calculation to determine minimum sample size
- One primary metric (not ten)
- Monitor guardrail metrics alongside the primary metric
Offline evaluation gains do not automatically transfer to the production distribution. Run an A/B test on a fraction of production traffic before full rollout.
The trap for this domain
Uncalibrated judge. A model judge that has never been checked against human labels can silently drift — reporting high scores while quality degrades. The fix is periodic human calibration of the judge itself, not just the system under evaluation.
Domain 5: Governance, Safety & Risk Management (14%)
What it tests
How safety is architecturally constructed — which layer prevents what, where human oversight belongs, and what a compliance control actually requires.
The four-layer safety stack
| Layer | Who sets it | Blind spot |
|---|---|---|
| Trained behavior | Anthropic | Cannot be overridden, but covers general harms only |
| System prompt | You (the builder) | Only as strong as the instructions — prompt injection can defeat it |
| Runtime screening | You (runtime layer) | Adds latency; covers use-case-specific rules |
| Authorization | You (infrastructure layer) | Most reliable — the model can't do what it can't access |
The critical insight: each layer catches the blind spot of the layer above it. Authorization at the infrastructure layer is the only control that holds even if all higher layers fail.
HITL placement rule
Human-in-the-loop approval belongs before actions that are irreversible or high-impact. Low-risk internal steps (drafting, internal record updates) flow automatically. External commitments (issuing purchase orders, sending customer communications) get the gate.
Indirect prompt injection
Retrieved content from external sources can contain adversarial instructions embedded in documents. The defence is structural: retrieved content must be explicitly delimited as untrusted data and denied instruction-level authority. The model must treat it as reference material, not as instructions.
Compliance controls
A named control in a design document is not a compliance control. A compliance control requires:
- The control itself (what is being enforced)
- A named owner (the person accountable for it)
- An evidence artifact (the thing a regulator can inspect)
Any control missing an owner or evidence artifact is functionally the same as no control.
The trap for this domain
Authorization enforced by instruction. Same pattern as Domain 3 — but in Domain 5, the emphasis is on the compliance and safety failure that results when an instruction does what an access layer should.
Domain 6: Stakeholder Communication & Lifecycle (14%)
What it tests
The human side of being an architect — discovery discipline, tradeoff communication, project lifecycle management, and what good handoff looks like.
Discovery: four question categories
Before proposing any architecture, the discovery process must cover all four categories:
| Category | What it captures |
|---|---|
| Must do | The core capability the business needs |
| Must NOT do | Constraints and prohibitions — often the hardest to surface |
| Must cost | The cost envelope (per request, per month, total) that makes the business case work |
| Must prove | The evidence standard required before stakeholders will trust and scale the system |
A confident design sketch produced before all four categories are exhausted is built on assumptions, not requirements.
Tradeoff framing
Three elements — not two. Most stakeholders hear gain and give-up. The element that matters most is the third:
- What you gain (accuracy, capability, speed)
- What you give up (cost, latency, complexity)
- What it costs to reverse (migration effort, data implications, vendor lock-in)
The reversal cost is what separates a recoverable decision from a costly one. Including it in tradeoff communication is what separates an architect from a vendor.
The outcome document: six required fields
An outcome document (the agreement before design begins) needs all six to be complete:
- Use case + scope
- Metric before (baseline — unrecoverable if not captured at the start)
- Metric after (using the same definition and measurement method as the before)
- Auditable control
- Measurement owner (a named person, not a team)
- Reuse potential (what other teams could benefit from this)
The before-metric is the field most often missing. Once the system is live, the baseline is gone.
The trap for this domain
Starting design before discovery is complete. The exam presents scenarios where a stakeholder has expressed a preference ("we need a chatbot") and tests whether you anchor to the stated solution or treat it as a starting point for structured discovery.
Domain 7: Developer Productivity & Ops Enablement (7%)
What it tests
How to scale AI-assisted development across a team or organisation without introducing operational chaos.
Shared configuration over personal configuration
Team-scale productivity comes from configuration shared through version control — CLAUDE.md files, MCP server definitions, permissions, approved command lists — that every team member's tooling inherits. Personal configuration is layered on top for preferences, not standards.
Skills distribution
| Type | Reach | Rollback |
|---|---|---|
| Org-provisioned | Entire organisation | No rollback capability |
| Plugin (versioned) | Configurable | Versioned rollback |
| Project Skill | Repo-scoped | Repo-scoped |
| API Skill | Per-call | Pinned |
Org-provisioned skills reach everyone but cannot be rolled back — test carefully before provisioning.
Diagnosing before rewriting
When a production agent starts taking unexpected actions, the instinct is to rewrite the system prompt. The right move is to inspect the traces of affected sessions first — inputs, retrieved context, tool calls, and outputs — to identify where in the pipeline the failure actually originates. Changing the prompt before diagnosis risks masking the real cause and destabilising working behaviour.
Code review independence
AI-authored code reviewed by the same AI session that wrote it inherits the session's blind spots. Independent review — a fresh context, a separate session or agent — is what restores genuine scrutiny. Humans retain merge authority.
The trap for this domain
Same session reviewing what it wrote. The exam explicitly tests the anchoring problem: a reviewer anchored to the reasoning that produced the code cannot spot the gaps it created.
The 12 Trap Pattern Library
The Professional exam uses recurring wrong-answer shapes across all domains. Recognising the shape lets you eliminate the wrong answer before fully analysing it.
| # | Trap name | Shape |
|---|---|---|
| 1 | Instruction-as-control | Enforcing security/auth by prompt instruction instead of the infrastructure layer |
| 2 | Right word, wrong conclusion | Uses correct vocabulary (auditability, reliability) but applies it to the wrong pattern |
| 3 | Assume before measure | Proposing a model change, cost cut, or switch without first analysing production traces |
| 4 | Uncalibrated judge | Running an LLM-as-judge without periodic human calibration |
| 5 | Synthetic-only dataset | Evaluating with synthetic examples only — misses the real distribution |
| 6 | Blanket technique application | Applying CoT or caching to every workload regardless of measurable benefit |
| 7 | Name without owner | Listing a compliance control without a named owner and evidence artifact |
| 8 | Solution before discovery | Anchoring to the stated solution ("we need a chatbot") before completing discovery |
| 9 | Missing before-metric | Designing an outcome document without capturing the baseline before launch |
| 10 | Log everything or nothing | Either logging every full payload (costly, unfindable) or logging nothing (blind) |
| 11 | Reversal cost omitted | Presenting a tradeoff with gain and give-up but no reversal cost |
| 12 | Same session review | Having the authoring session or agent review what it created |
What Separates Professional from Foundations
The Foundations exam tests recognition: can you identify the correct mechanism from a description?
The Professional exam tests reasoning under trade-offs: given a concrete business scenario with multiple competing constraints — cost, latency, compliance, auditability, reversibility — which architectural choice best satisfies all of them, and why do the alternatives fail?
Three specific shifts:
Longer scenario context. Professional questions set up scenarios with 4–6 sentences of business context before the actual question. Read everything — the constraints buried in the setup determine which options are eliminated.
More plausible wrong answers. At Foundations level, wrong answers are often clearly wrong. At Professional level, wrong answers often use correct terminology and describe something that would work in a different scenario. The failure is in the fit to this specific scenario.
Stakeholder and lifecycle domains. Foundations doesn't test discovery methodology, tradeoff framing, or handoff artefacts. Domains 6 and 7 of the Professional exam are entirely new territory for Foundations candidates.
The 5 Modules
| Module | Content | Official runtime |
|---|---|---|
| M1 | Platform & Solution Design | 238 min |
| M2 | Enterprise Integration & Production | 158 min |
| M3 | Responsible AI, Safety & Risk | 114 min |
| M4 | Stakeholder Engagement & GTM | 178 min |
| M5 | Team Enablement & Ops | 45 min |
Read them in order. Each module builds on the previous. M4 (Stakeholder) appears disproportionately in Domain 6 questions, and the outcome document six-field structure tested in M4 appears verbatim on the exam.
Study Approach: 4 Phases
Phase 1 — Read all 5 modules for understanding, not memorisation (2 weeks)
The goal in Phase 1 is to build the mental model, not create flashcards. Read each module asking: what problem does this solve, and what goes wrong when you ignore it?
The master pattern applies here: for every concept, identify what "looks handled" vs. what "has been verified to be handled."
Phase 2 — Write one real architectural decision (1 week)
Take any system you've built or are planning to build and write a genuine architectural decision record: the problem, the options considered, the constraints that eliminated each alternative, the chosen approach, the reversal cost. Include a tradeoff framing with all three elements (gain, give-up, reversal cost).
Writing one real decision record does more than reading ten. The Professional exam tests whether you can think like an architect, not whether you can recall like a student.
Phase 3 — Practice questions by domain, drill weak spots (1 week)
Use the CCA Professional practice quiz on this site to work through questions by domain. For every question you get wrong, stop — identify which of the 12 trap patterns caught you, re-read the relevant module section, and move on.
Also available: the Foundations quiz and Foundations domain quiz for the underlying patterns that Professional questions build on.
Phase 4 — Trap patterns + master pattern, one session before the exam
The day before the exam, run through the 12 trap patterns once. Then re-read the master pattern statement:
A thing that looks handled and a thing that has been verified to be handled are different claims.
Apply it to whatever question type is hardest for you. Then rest.
Study Timeline
If you hold the Foundations cert already: 3–4 weeks is enough if you're actively building with Claude APIs.
| Week | Focus |
|---|---|
| Week 1–2 | Read all 5 modules. Write your architectural decision record. |
| Week 3 | Practice questions per domain. Identify weak domains. Re-read those modules. |
| Week 4 | Full-domain practice on weak areas. Trap pattern review. Rest before exam. |
If you're new to the Professional-level material: 5–7 weeks. Spend extra time in Phase 2 — the writing phase — because the Professional exam tests reasoning, and reasoning requires building it, not reading about it.
Key Resources
| Resource | What it covers |
|---|---|
| Anthropic learning portal (all 5 modules) | Primary source — covers all 7 domains |
| Anthropic Model Spec | Domain 5 alignment boundary |
| Claude Code docs | Domain 1 entry points + Domain 7 |
| MCP specification | Domain 3 integration |
| CCA Professional Practice Quiz | 7-domain quiz with Practice + Exam modes |
| CCA Foundations prep guide | The foundational mental models |
| Foundations quiz | 35-question Foundations practice |
FAQ
How much harder is Professional than Foundations? Significantly. Foundations tests whether you know what a mechanism is. Professional tests whether you can apply it correctly under multiple constraints simultaneously. The scenario questions are longer, the wrong answers are more plausible, and two entire domains (stakeholder and operational) have no Foundations equivalent.
Is there a published passing mark? The official material targets 75%+ per domain. A specific overall passing score has not been publicly announced in the same way Foundations published 72%.
How many questions and how long? 63 questions, 120 minutes. That's about 1 minute 54 seconds per question — enough time, but not leisurely. Longer scenario questions will need more time; shorter scenario-matching questions will need less.
Do I need to build something to pass? Not technically required. But the Professional exam tests reasoning under constraints, and reasoning about architectural trade-offs is much harder without the operational intuition that comes from having built something that failed in an interesting way. The Phase 2 architectural decision record is the minimum viable substitute.
When should I take it after Foundations? If you're actively building with Claude APIs: 3–4 weeks of preparation is enough. If you're coming from a more theoretical background: 5–7 weeks. Don't rush Phase 2 — that's where the understanding forms.
Can I use Claude to study for the Claude exam? Yes, and it's effective. Give Claude a scenario and ask it to explain which architectural pattern fits and why the others fail. Then argue with it — challenge the answer and see if the reasoning holds. The disagreement is where the learning happens.
The Professional exam is a genuine test of architectural judgment. It rewards people who build things and think carefully about why architectural choices fail, not people who memorise patterns. Prepare by writing and reasoning, not just by reading.
Practice quiz → CCA Professional Practice Quiz
Foundations prep → Claude Certified Architect – Foundations Prep Guide
Deploying Claude in your organisation and need an architect who's already navigated the Foundations exam and is deep in Professional preparation? Let's talk.