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
| 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.