CCAR-P Exam Domains: Complete Breakdown of All 7 Domains [2026]

The Claude Certified Architect - Professional (CCAR-P) exam distributes 63 scored questions across seven domains, and each domain carries a published weight that determines how much of your final score it controls. Before you build a study schedule, you should know those weights cold, because they answer the most practical question in exam preparation: where do your points live?

This guide breaks down every CCAR-P domain: the exact weights, the approximate question counts they produce on a 63-question exam, the topics inside each domain, the judgment calls the exam actually tests, and the scenario patterns to expect. The exam runs 120 minutes, requires a scaled score of 720 out of 1000 to pass, and mixes single-answer multiple choice with multiple-response items. Roughly a quarter of the questions ask you to Select TWO or Select THREE, and those items appear in every domain.

If you are new to the certification itself, start with the complete CCAR-P certification guide or the shorter what is CCAR-P overview, then return here for the domain-level detail.

What this guide covers:

• The complete weight breakdown for all 7 domains with approximate question counts
• Every topic each domain tests, taken directly from the exam blueprint
• The judgment calls behind the questions, with scenario examples for each domain
• A deep treatment of Integration, the heaviest domain at 19%
• Cross-domain themes that show up in synthesis questions
• A weight-based study prioritization strategy with links to a full preparation plan

Domain Weight Overview

The weights below come straight from the exam blueprint. To convert a weight into a question count, multiply it by 63 and round. Integration at 19% works out to roughly 12 questions, Solution Design at 17% to roughly 11, and so on down to Developer Productivity at 7%, which produces only about 4 questions. Exact counts can shift by a question between exam forms, but the proportions hold.

The Numbers That Matter

Two domains sit at the top of the table. Integration (19%) and Solution Design & Architecture (17%) together control 36% of the exam, roughly 23 of your 63 questions, and they test the skills that define the architect role: choosing how systems connect and what shape those systems take. If your preparation time is limited, invest here first.

The middle band is unusually broad. Evaluation (16%), Governance (14%), and Stakeholder Communication & Lifecycle (14%) together control 44% of the exam, about 28 questions. This band separates CCAR-P from a builder-level exam: it tests whether you can prove a system works, keep it safe and compliant, and carry it through a full delivery lifecycle.

The light band still matters. Models, Prompting & Context Engineering (13%) contributes about 8 questions and Developer Productivity (7%) about 4. Four questions sounds small until you remember the 720-out-of-1000 passing bar; Domain 7 points are among the cheapest on the exam to earn.

Domain 1: Solution Design & Architecture (17%)

Approximate question count: ~11 of 63

Domain 1 tests the foundational architect skill: taking a messy business problem and turning it into a Claude-based system with the right shape. The blueprint names three pattern families you must distinguish. An augmented LLM design wraps a single model call with retrieval, tools, or structured output. A workflow design chains model calls through fixed steps that code controls. An agentic design hands the model control of its own loop, letting it decide which tools to call and when to stop.

This distinction drives cost, latency, debuggability, and failure behavior. A fixed workflow is cheaper to run, easier to test, and simpler to audit than an agent, so the professional default is to reach for autonomy only when the path through the problem genuinely cannot be predicted in advance. The exam builds scenarios around this judgment: an agentic design that sounds impressive when a simpler pattern is correct, or a rigid workflow that keeps breaking because the task requires dynamic decision-making.

Decomposition and orchestration form the second half of the domain: when to split a problem across specialized agents, how an orchestrator routes work and synthesizes results, and how feedback loops carry evaluation signals back into the system. The blueprint also ties every design to business value pillars, meaning efficiency gains, cost envelopes, and performance SLAs (service-level agreements, the response-time and availability targets you commit to).

Scenario angles to expect:

• The exam gives you a business process description (volume, variability, audit requirements, latency target) and asks which architectural pattern fits best.
• The exam gives you a proposed multi-agent architecture and asks you to identify the over-engineering, usually agents that could be merged or replaced with deterministic steps.
• The exam gives you two candidate designs and a hard cost ceiling, then asks which design aligns with the stated value pillar.

What to study: Anthropic's published guidance on building effective agents, the workflow versus agent decision framework, and orchestrator-worker patterns.

Domain 2: Claude Models, Prompting & Context Engineering (13%)

Approximate question count: ~8 of 63

Domain 2 covers the layer most candidates know best, and the exam tests it at architect altitude, where every choice carries a dollar figure and a latency number. Model selection questions give you a workload profile and ask you to balance capability against cost and speed. A nuanced legal analysis task and a high-volume ticket-routing task land on different model tiers, and the exam expects you to justify the choice through the trade-off.

The prompting content covers zero-shot prompting (instructions with no examples), few-shot prompting (a handful of worked examples that establish a pattern), and chain-of-thought (asking the model to reason step by step before answering). The professional twist is knowing when each technique earns its token cost: few-shot examples improve format compliance but consume context on every call, and chain-of-thought improves multi-step reasoning while adding latency and output tokens.

Context engineering rounds out the domain. Prompt caching lets you reuse a stable prompt prefix across requests at a fraction of the input cost, which transforms the economics of long system prompts and large reference documents. Modular prompt design and Claude Skills (packaged, reusable instruction sets) matter because architects design prompts that whole teams maintain.

Scenario angles to expect:

• The exam gives you a cost overrun on a service with a large static system prompt and asks which mechanism to apply first (prompt caching is the usual answer, and the distractors involve switching models prematurely).
• The exam gives you inconsistent output formats from a production prompt and asks which technique change fixes it with the least added cost.
• The exam gives you three workloads and asks you to map each to a model tier.

What to study: the model comparison tables on docs.anthropic.com, prompt caching mechanics, and the prompt engineering documentation with attention to when each technique is worth its token cost.

Domain 3: Integration (19%)

Approximate question count: ~12 of 63

Integration is the heaviest domain on the CCAR-P exam. Enterprise Claude deployments live or die on how they connect to the systems around them, and this domain tests every layer of that connection: the mechanism you choose, the capabilities you expose, the identities that flow through it, the data pipelines that feed it, and the observability that keeps it accountable. Give it your deepest preparation.

Selecting the Integration Mechanism: MCP, API/CLI, or Agent-to-Agent

The exam expects you to choose among three ways of connecting Claude to external capability, and to defend the choice.

The Model Context Protocol (MCP) is Anthropic's open standard for connecting models to tools and data sources through a uniform client-server interface. An MCP server publishes its tools in a standard format, and any MCP-aware client can discover and call them. Choose MCP when a capability will be shared across multiple applications, teams, or agents, because the standardization pays for itself in reuse and discoverability.

A direct API or CLI integration wires Claude to a specific service through purpose-built code. It carries less abstraction overhead and gives you full control over the request path, which makes it the right call for a single bespoke connection with a tight latency budget. A nightly batch job that calls one internal service gains nothing from a protocol layer.

An agent-to-agent integration delegates work to another agent with its own tools, context, and reasoning. Reach for it when the capability you need is itself judgment-heavy: a research subsystem, a code-review subsystem, or a domain specialist that must make its own decisions. Delegation buys context isolation and specialization at the price of latency and coordination complexity.

The exam gives you a connection requirement (who consumes it, how often, with what latency budget, shared or bespoke) and asks which mechanism fits. The wrong answers are usually real mechanisms applied at the wrong scale, such as standing up an MCP server for a one-off internal script.

Capability Bloat

Capability bloat is the accumulation of tools, permissions, and connectors that an agent can technically reach but rarely needs. It grows quietly, one integration at a time, until the agent carries dozens of capabilities for a job that uses five.

Bloat hurts on three axes at once. Tool selection accuracy degrades as the option count grows, because the model must discriminate among more overlapping choices. The security attack surface expands, since every unused permission is a standing liability. And context gets consumed by tool definitions the agent never invokes, raising cost and crowding out task-relevant information.

The exam gives you an agent configuration listing its tools and permissions alongside its actual job, and asks what to remove, how to regroup capabilities into specialized agents, or which principle the configuration violates. The governing principle is least privilege: expose exactly the capabilities the task requires and nothing beyond them.

Authentication and Authorization Gaps

This is the most security-focused topic on the exam, and it targets a specific class of real-world failure: agents that erase user identity. Authentication establishes who is making a request, and authorization determines what that identity may do.

The classic gap is the shared service account. Every user's requests flow through one broadly scoped credential, so a junior analyst and a system administrator get identical data access the moment they talk to the same agent. A related failure is the confused deputy, where an agent uses its own elevated privileges to perform an action on behalf of a user who lacks the privilege to perform it directly. A third is the audit gap, where every action logs as the service account, making attribution impossible after an incident.

The designs the exam rewards: propagate the end user's identity through to downstream systems, scope credentials per tool and per task, and enforce authorization at the tool boundary so the checking happens in code that the model cannot talk its way past. Prompt instructions are never an authorization mechanism.

The exam gives you an MCP or tool deployment description with a subtle identity flaw and asks you to name the gap or pick the remediation. Read these questions slowly, because the flaw is usually one clause in the setup ("the server authenticates using a shared API key").

RAG Pipeline Design: Chunking, Indexing, Retrieval

Retrieval-augmented generation (RAG) is the pattern of fetching relevant documents at query time and placing them in the model's context, so answers are grounded in your data instead of the model's training memory. The exam tests RAG as a three-stage pipeline and expects you to diagnose failures at the correct stage.

Chunking splits source documents into retrievable pieces. Chunks that are too small strip away the surrounding context a passage needs to be understood, while chunks that are too large dilute the embedding (the numeric representation used for similarity search) and waste context tokens. Structure-aware chunking, which splits along headings, sections, and table boundaries, outperforms fixed-size splitting on structured content, and overlap between chunks protects information that straddles a boundary.

Indexing determines how chunks are stored and matched. Pure vector search finds semantically similar text but can miss exact identifiers, part numbers, and rare terms, which is why hybrid indexing that combines vector similarity with keyword matching is the standard answer for enterprise corpora. Metadata attached at indexing time (document type, date, tenant, access level) enables filtering, recency weighting, and permission-aware retrieval.

Retrieval strategy covers what happens at query time: how many chunks to fetch, whether to rerank candidates with a second scoring pass, and whether to rewrite the user's query before searching. The architect-level insight the exam keeps returning to is that retrieval must be evaluated separately from generation. When the right chunk never reaches the context, no prompt improvement can fix the answer.

The exam gives you a RAG failure symptom (correct answers on prose, wrong answers on tables; missed policy clauses; stale results) and asks which stage to fix and how. Map the symptom to the stage before reading the options.

Progressive Discovery vs. Monolithic Context

This topic tests how you scale an agent's awareness of a large capability surface. A monolithic context strategy loads everything up front: every tool definition, every schema, every reference document sits in the context window from the first request. It is simple and predictable, and it works well for small catalogs. As the surface grows, it burns tokens on every call, inflates latency, and worsens tool selection by widening the option set.

Progressive discovery exposes a small entry surface instead, typically search or list operations, and lets the agent pull in specific tool definitions or documents on demand as the task requires them. Context stays lean and the approach scales to catalogs with hundreds of tools, at the cost of extra round trips and a more complex interaction pattern.

The exam gives you a catalog size, a call frequency, and a latency budget, and asks which strategy fits. A small stable toolset with tight latency points to monolithic loading, while a large or growing catalog points to progressive discovery.

Observability and the Accuracy-Latency Trade-off

Observability at scale means you can trace a single request across model calls, tool invocations, and retrieval hops, attribute token spend to features and tenants, and detect quality drift from production telemetry. The exam tests whether you design this in from the start, because retrofitting tracing onto a live agent system is painful and slow.

The accuracy-latency trade-off shows up whenever a pipeline step improves quality at the cost of response time: a reranking pass, a verification call, a second retrieval round. The exam gives you an SLA and a proposed pipeline and asks which step to cut, keep, or make conditional. The professional answer ties the decision to the stated latency budget instead of maximizing accuracy unconditionally.

What to study for Domain 3: the MCP documentation and architecture overview, the tool use section of docs.anthropic.com, and Anthropic's published RAG guidance. Build one small RAG pipeline and one MCP integration end to end before exam day, because this domain punishes purely theoretical preparation.

Domain 4: Evaluation, Testing & Optimization (16%)

Approximate question count: ~10 of 63

Domain 4 tests whether you can prove that a system works and keep proving it as the system changes. The blueprint starts with metrics across five dimensions: accuracy, latency, cost, safety, and security. Architect-level questions hinge on picking the dimensions a scenario actually cares about, because a fraud-detection assistant and a marketing-copy generator have different definitions of failure.

Evaluation datasets are the operational core of the domain. An eval set is a curated collection of inputs with known good outputs or grading criteria that you run against the system before and after every change. The exam expects you to know mixed-methodology frameworks: code-graded checks for anything with an objective answer, model-graded evaluation (using a model to judge outputs against a rubric) for open-ended quality, and human review where stakes or subjectivity demand it. A/B testing extends this into production, comparing variants on live traffic with predefined success metrics.

The diagnosis topics are where the exam gets scenario-heavy. You should be able to separate three root cause classes: prompt failure (the instructions are ambiguous or the technique is wrong), hallucination (the model generates unsupported content, often because grounding data never reached the context), and model mismatch (the selected tier lacks the capability for the task). Each class has a different fix, and the exam punishes candidates who jump to prompt tweaking for every symptom.

Scenario angles to expect:

• The exam gives you a quality regression that followed a prompt change and asks which process gap allowed it to ship (the answer involves running an eval set as a gate).
• The exam gives you hallucination reports from a RAG assistant and asks for the first diagnostic step, which is checking whether retrieval delivered the right chunks before touching the prompt.
• The exam gives you a latency and cost profile and asks which optimization lever to pull first among caching, model tier changes, and prompt slimming.

What to study: Anthropic's evaluation guidance and the differences between grading methodologies. Build an eval set for one of your own projects, because writing grading criteria teaches this domain faster than reading about it.

Domain 5: Governance, Safety & Risk Management (14%)

Approximate question count: ~9 of 63

Domain 5 tests safety as an architectural property. Guardrails are the layered controls that constrain what an LLM system can take in, emit, and do: input filtering that blocks prompt injection and out-of-scope requests, output validation that checks responses against policy before they reach users, and action gating that requires programmatic checks before consequential operations execute. The exam consistently rewards defense in depth over any single control, and it treats prompt instructions alone as insufficient protection for anything with real stakes.

Human-in-the-loop validation (routing specific outputs or actions to a person for approval before they take effect) is the domain's most tested judgment call. Review everything and the system delivers no efficiency, review nothing and a single failure can be catastrophic. The exam wants review gates placed where risk concentrates: irreversible actions, high-value transactions, and edge cases the system flags as uncertain.

The compliance topics require working recognition of each regime and its design implications. GDPR is the EU regulation governing personal data, bringing data minimization, purpose limitation, and deletion rights into your pipeline design. HIPAA is the US law governing protected health information, constraining what healthcare data can flow into prompts, logs, and retrieval indexes. FedRAMP is the US federal authorization program for cloud services, which determines what infrastructure a government deployment may run on. Ethical AI content covers bias and fairness testing across user groups plus transparency obligations, such as disclosing AI involvement and making decisions explainable.

Scenario angles to expect:

• The exam gives you an agent with authority over refunds or account changes and asks where the human approval gate belongs (at the high-impact action boundary, enforced in code).
• The exam gives you a healthcare or EU deployment description and asks which compliance obligations shape the design, from data residency to what may appear in logs.
• The exam gives you a hiring or lending use case and asks which fairness and transparency controls belong in the evaluation plan.

What to study: Anthropic's usage policies and safety guidance, guardrail layering patterns, and the one-paragraph version of each regulation: what data it covers, what it demands, and what that means for prompts, logs, and retrieval.

Domain 6: Stakeholder Communication & Lifecycle Management (14%)

Approximate question count: ~9 of 63

Domain 6 is the clearest signal that CCAR-P is a professional-tier exam. Nine questions test work that happens in meetings and documents: discovery, expectation setting, decision communication, and carrying a system through its lifecycle. Candidates who prepare only on technical material routinely lose points here, which makes this domain one of the best returns on study time for engineers.

Structured discovery means gathering requirements in a deliberate order: the business objective and its success metrics first, then constraints (data availability, compliance regime, latency and cost envelopes), then integration realities, and only then solution shape. The exam presents discovery scenarios and asks what to establish first, and the correct answer anchors on business outcomes before technology choices.

Communicating architectural decisions is tested through audience awareness: an executive needs the trade-off in terms of cost, risk, and time to value, while an engineering team needs interface contracts and failure behavior. SLA expectation alignment is the recurring theme. LLM systems are probabilistic, so an architect commits to measured accuracy targets with defined human-review backstops instead of promising perfection. The lifecycle model runs discovery, design, handoff, monitoring, and iteration, and the exam expects you to know what each phase produces. Handoff in particular requires documented architecture, implementation guidance, and operational runbooks, because a system the client team cannot run is a failed delivery regardless of its technical quality.

Scenario angles to expect:

• The exam gives you a sponsor demanding guaranteed perfect accuracy and asks how to respond (reframe to measured targets on an eval set, with human review covering the residual risk).
• The exam gives you a post-handoff failure and asks which lifecycle artifact or phase was skipped.
• The exam gives you a stakeholder conflict, such as legal blocking a data source mid-project, and asks which feedback mechanism should have surfaced it earlier.

What to study: the lifecycle phase definitions, architecture decision records as a documentation pattern, and practice translating one of your own technical decisions into a three-sentence executive summary.

Domain 7: Developer Productivity & Operational Enablement (7%)

Approximate question count: ~4 of 63

Domain 7 is the smallest domain, and its four questions are among the most concrete on the exam. It tests whether you can turn Claude into a team capability: configuring Claude Code and related tooling so an entire engineering organization gets consistent behavior, weaving AI assistance into development workflows, and applying the same tooling to debugging and operational issue resolution.

The team configuration theme centers on shared versus personal setup. Project-level configuration travels with the repository and gives every developer the same standards, while personal configuration stays on one machine. When the exam describes inconsistent behavior across a team, the cause is almost always team standards living in personal configuration. The workflow theme asks where AI assistance produces real leverage, with code review, test generation, documentation, and migration work as the high-yield stages. The operational theme covers using AI tooling during incidents: summarizing logs, tracing failures across services, and drafting remediation steps with a human approving each action.

Scenario angles to expect:

• The exam gives you a team with divergent Claude Code behavior and asks for the configuration fix (move shared standards into version-controlled project configuration).
• The exam gives you a debugging or incident scenario and asks where AI tooling helps while keeping a human in control of changes.

What to study: the Claude Code documentation sections on team configuration and workflow integration. If you hold the CCA-F, this domain overlaps heavily with material you already know; the CCA-F versus CCAR-P comparison maps the overlap in detail.

Cross-Domain Themes: How the Exam Thinks

CCAR-P questions rarely stay inside one domain, and the multiple-response items in particular love to span two or three. Three reasoning patterns run underneath the whole blueprint, and recognizing them lets you answer questions you never explicitly studied.

Trade-off Reasoning: Cost, Latency, Accuracy

Almost every architectural question resolves to a triangle of cost, latency, and accuracy, and the exam wants you to optimize for the dimension the scenario names. Model selection (Domain 2), reranking steps in RAG pipelines (Domain 3), evaluation thresholds (Domain 4), and SLA commitments (Domain 6) are all the same trade-off wearing different clothes. When a question states a constraint, treat it as the scoring key: the correct answer honors the stated budget even when a more accurate option sits in the list.

Lifecycle Thinking

The exam treats every system as something that gets discovered, designed, delivered, monitored, and iterated. Answers that skip a phase are usually wrong: shipping without an eval baseline (Domain 4), delivering without handoff documentation (Domain 6), or integrating without observability (Domain 3). When two options look technically equal, prefer the one that leaves the system measurable and operable after you walk away.

Safety by Design

Governance content leaks far beyond Domain 5. Authorization at the tool boundary is an Integration topic, safety metrics are an Evaluation topic, and human-in-the-loop gates appear inside Solution Design scenarios. The pattern the exam rewards is building controls into the architecture from the start and enforcing consequential constraints in code. Whenever an option relies on prompt instructions to prevent a high-stakes failure, treat it as a trap.

How to Prioritize Your Study Time

Weight is the starting point for prioritization, and experience is the adjustment. Here is a practical tiering for most candidates:

Start with Tier 1, because its concepts (integration mechanisms, architectural patterns, decomposition) are the vocabulary every other domain builds on. Give Tier 2 more time than its familiarity suggests, since evaluation methodology, compliance mapping, and lifecycle artifacts are the topics hands-on engineers most often meet for the first time on this exam. Tier 3 is where daily practitioners can move fastest, but run practice questions there early to confirm the assumption instead of trusting it.

The 6-week CCAR-P study plan turns this tiering into a week-by-week schedule, and the first-attempt guide covers exam-day tactics, including how to handle the multiple-response items that make up about a quarter of the exam. Candidates coming from the Foundations tier can also review the CCA-F pillar guide to see which builder-level topics carry forward.

Common Questions

Domain Mastery Checklist

Use this checklist to confirm coverage before you sit the exam. Every line maps to a topic the blueprint names explicitly.

Conclusion

The CCAR-P blueprint tells you exactly what Anthropic believes a professional Claude architect does: integrate systems securely (19%), design the right architecture (17%), prove it works (16%), keep it safe and compliant (14%), carry stakeholders through the lifecycle (14%), engineer prompts and context economically (13%), and make whole teams productive (7%). Study in that order of weight, adjust for your own gaps, and treat the middle band of evaluation, governance, and communication with the respect its 44% combined weight demands.

Three habits separate passing candidates on this exam. They read every scenario for its stated constraint and optimize for that dimension. They diagnose failures to a root cause class before selecting a fix. And they reject any option that guards a high-stakes action with prompt instructions alone.

Your recommended next steps:

1. Build your schedule from the 6-week CCAR-P study plan, which allocates weeks according to the domain weights above
2. Read the first-attempt pass guide for question tactics, including multiple-response strategy
3. Keep the CCAR-P cheat sheet nearby for rapid review of the highest-yield facts
4. Deciding between certifications? The CCA-F versus CCAR-P comparison settles which tier fits your experience

Ready to test yourself against the blueprint? Preporato's CCAR-P practice tests give you 6 full-length exams of 63 questions each, distributed across all 7 domains by weight, with an explanation for every answer. They are available through Preporato Pro and the practice bundle, and they are the fastest way to find out which domains still need your attention before you book the real thing.