Free lesson · Claude Certified Architect - Professional (CCAR-P)
The Seven-Domain Blueprint and 38 Objectives
The Map You Study Against
The blueprint is the single most useful document in your preparation. It tells you what is tested, how much each part is worth, and - because the score report grades against it - where you went wrong afterwards.
Seven domains, 38 objectives, 63 items.
The Seven Domains by Weight
Ordered by weight rather than by number, because weight is what should order your time.
| Domain | Weight | ~Items |
|---|---|---|
| D3 - Integration | 19% | ~12 |
| D1 - Solution Design & Architecture | 17% | ~11 |
| D4 - Evaluation, Testing & Optimisation | 16% | ~10 |
| D5 - Governance, Safety & Risk Management | 14% | ~9 |
| D6 - Stakeholder Communication & Lifecycle Management | 14% | ~9 |
| D2 - Claude Models, Prompting & Context Engineering | 13% | ~8 |
| D7 - Developer Productivity & Operational Enablement | 7% | ~4 |
graph TD
A["63 items"] --> B["D3 Integration 19%"]
A --> C["D1 Solution Design 17%"]
A --> D["D4 Evaluation 16%"]
A --> E["D5 Governance 14%"]
A --> F["D6 Stakeholder 14%"]
A --> G["D2 Models & Context 13%"]
A --> H["D7 Dev Productivity 7%"]
This diagram shows how sixty-three items distribute across seven domains. Integration takes nineteen percent, solution design seventeen, evaluation sixteen, governance fourteen, stakeholder communication fourteen, models and context thirteen, and developer productivity seven.
Warning: Verified 3 September 2026 against public material describing Exam Guide v1.0. Weights and objectives are Anthropic's and change without notice. Check the current guide before sitting.
Three Domains Are Over Half the Exam
Interactive animation: Integration, solution design and evaluation total 52 percent of the exam - 33 of the 63 items.
Integration, solution design, and evaluation total 52%. That is thirty-three of sixty-three items.
The other four domains share the remaining 48% between them, and one of those - developer productivity - is a single-figure percentage.
Important: Study by weight, not by curiosity. The domains people find most interesting are rarely the heaviest, and a preparation plan that follows interest produces strength where the marks are thin. Integration alone is worth more than governance and developer productivity combined.
What Each Domain Actually Asks
D3 - Integration (19%). Connecting Claude to real systems. Tools and their scoping, retrieval architecture, MCP and interoperability, authentication, and the messy reality of integrating with infrastructure that already exists. The heaviest domain and the broadest.
D1 - Solution Design & Architecture (17%). Turning a business problem into a system. Pattern selection between workflow, agentic, and augmented-LLM approaches. Multi-agent orchestration. Decomposition. End-to-end design including feedback loops.
D4 - Evaluation, Testing & Optimisation (16%). Knowing whether it works and making it better. Metrics, evaluation datasets, grading methods, diagnosis when something underperforms, A/B testing, and optimising cost and latency without losing quality.
D5 - Governance, Safety & Risk Management (14%). Keeping it safe and lawful. Guardrails, output screening, failure modes, human oversight, and the regulatory frames - GDPR, HIPAA, FedRAMP - plus bias, fairness, and explainability.
D6 - Stakeholder Communication & Lifecycle Management (14%). Everything human and everything after launch. Requirements discovery, framing trade-offs for executives, architecture review, service levels, decision records, handoff, and eventual deprecation.
D2 - Claude Models, Prompting & Context Engineering (13%). The Claude-specific craft. Model selection and routing, system prompt design, prompting technique, extended thinking, context as a finite resource, caching, and reusable prompt architecture.
D7 - Developer Productivity & Operational Enablement (7%). Claude Code across a team. Rollout, shared configuration, permission policy, and using Claude for debugging and operational work.
The 38 Objectives
Each domain breaks into objectives, and the objectives are what the score report grades you against. Domain 1 illustrates the shape.
| Objective | |
|---|---|
| 1.1 | Translate business problems into Claude-based AI solutions |
| 1.2 | Design end-to-end architectures (input → processing → output → feedback loops) |
| 1.3 | Select appropriate architectural patterns (workflow, agentic, augmented LLM) |
| 1.4 | Design multi-agent systems and orchestration strategies |
| 1.5 | Apply decomposition techniques for complex problem solving |
| 1.6 | Align solution design with business and operational requirements |
Six objectives for a 17% domain - so roughly two items each, and some objectives will get one.
Important: Read the objective verbs. "Translate", "design", "select", "apply", "align" - every one is a doing verb, not a knowing verb. No objective says "describe" or "list". That is the clearest signal available about how the exam is written: it tests decisions, not definitions.
Get the full list from the official guide. The exam guide enumerates all 38 with their wording, and it is worth reading once end to end. This course maps every topic to an objective in its frontmatter, but the authoritative list is Anthropic's.
Tip: Print the objective list and mark each one as confident, shaky, or unknown before you start studying. That takes twenty minutes and gives you a preparation plan more precise than any course structure - including this one.
Why the Objective Level Matters
Here is the detail that should change how you prepare.
The score report grades you objective by objective, not just domain by domain.
That means a failure tells you something specific. Not "you were weak on Integration" - which is nine or twelve items and covers tools, retrieval, MCP, and enterprise systems - but which of those objectives cost you.
graph LR
A["Overall score"] --> B["Pass or fail"]
C["Domain breakdown"] --> D["Where to spend time"]
E["Objective breakdown"] --> F["What to actually study"]
This diagram shows three levels of score analysis. The overall score tells you whether you passed. The domain breakdown tells you where to spend time. The objective breakdown tells you what to actually study.
Important: An objective-level report is the most actionable feedback a certification gives you. "Improve Integration" is not a study plan. "Objective 3.4, retrieval strategy selection" is. If you resit, that report is worth more than any amount of general revision.
Turning Weights Into a Plan
Weight alone is not the ranking. Weight multiplied by your gap is.
Algorithm: Building a study plan from the blueprint
- Rate yourself 1–5 on each of the seven domains.
- Convert each rating to a gap - a 2 is a large gap, a 4 is small.
- Multiply gap by weight.
- Rank by that product. That is your order.
- Within the top domains, rate yourself per objective.
- Study the objectives, not the domains.
- Re-rate after each domain and re-rank.
Step 3 is what stops two common mistakes. Studying your weakest domain first even when it is worth 7%. And skipping a domain you feel adequate at when it is worth 19%.
Example: Two candidates, same total study time:
Domain Weight Candidate A gap A priority Candidate B gap B priority D3 Integration 19% Small Low Large Highest D7 Dev Productivity 7% Large Low-ish Small Lowest D6 Stakeholder 14% Medium Highest Medium Medium Candidate A's largest gap is in the smallest domain. Following instinct - fix the weakest thing - would send them to a domain worth four items. The multiplication sends them to stakeholder communication instead, which is worth nine.
The Shape of a Breadth Exam
One structural consequence of 38 objectives across 63 items.
Most objectives get one or two questions. A handful get three.
That has two implications and they pull in opposite directions.
You cannot afford a blind spot. An objective you skipped is not a risk you might dodge - it is one or two items lost with near certainty, and there are 38 chances to have skipped something.
You cannot master everything to depth. With 63 items across 38 objectives, no single objective rewards deep specialisation. Broad competence beats narrow excellence on this paper.
Warning: The failure mode this creates is a candidate who prepares three domains thoroughly and skims four. On a scenario-clustered exam that can work, because a whole scenario might be in your strong area. On a breadth exam with standalone items it cannot, because the skimmed domains are distributed evenly through the paper.
Interactive animation: Two implications that pull opposite ways - no blind spots across 38 objectives, and no reward for deep specialisation.
What the Blueprint Does Not Tell You
Two honest limits.
It does not say how items are distributed within a domain. A 19% domain with five objectives does not guarantee equal coverage of all five. Some objectives may get one item, some three.
It does not indicate difficulty. Two objectives with equal item counts can differ considerably in how hard those items are.
Neither changes the plan. Weight remains the best available proxy for where to spend time, and it is far better than instinct.
Tip: Do not over-model the blueprint. Ranking domains by gap times weight is the useful precision; predicting exactly how many items objective 3.4 will get is not. The numbers guide allocation, not scheduling to the hour.
Using This Course Against the Blueprint
Every topic in this course carries an objective mapping in its frontmatter. That means you can work in either direction.
From a weakness to content. Know an objective is shaky, find the topics mapped to it.
From content to coverage. Read a module, know which objectives it addressed.
The course is organised by domain and weighted to match - modules per domain follow the blueprint percentages rather than the amount of material available on each subject.
Important: That weighting is deliberate and it means some domains get less space than the subject deserves in general. Developer productivity is one module, not four, because it is 7% of the exam. This is a preparation course, not a reference work, and the allocation follows the marks.
In Short
Seven domains, 38 objectives, 63 items. Integration is heaviest at 19%, developer productivity lightest at 7%, and three domains - integration, solution design, evaluation - are 52% between them.
Every objective is phrased with a doing verb. Translate, design, select, apply, align. That tells you the exam tests decisions rather than definitions.
The score report grades objective by objective, which makes it the most actionable feedback available. Prepare at that level too: rate yourself per objective, not per domain.
Rank by gap multiplied by weight rather than by weakness alone, or you will spend your best hours on the smallest domain. And with most objectives getting one or two items, a blind spot is a near-certain loss while deep specialisation earns little.
Interview: The blueprint itself is not examined. What matters is the habit it should produce - studying by weight, working at objective level, and refusing to let a domain go unprepared because it looks less interesting. On a breadth exam that discipline is worth more than any individual topic.
Exercise: Starter. Name the three heaviest domains and their combined weight. Then say why the score report's objective-level grading matters more than the domain level.
Intermediate. Rate yourself 1–5 across the seven domains, multiply gap by weight, and rank. Note whether the ranking differs from your instinct - for most people it does.
Advanced. Obtain the official exam guide and mark all 38 objectives as confident, shaky, or unknown. That list is your actual study plan, and it is more precise than any course's module order.
Quiz: Quick check: A candidate rates themselves weakest in Developer Productivity (7%) and moderately weak in Integration (19%). They plan to fix the weakest domain first. What is wrong?
A) Nothing - addressing the weakest area first is sound B) Ranking should use gap multiplied by weight; a moderate gap in a 19% domain costs more marks than a large gap in a 7% one C) Developer Productivity should be skipped entirely D) They should study domains in blueprint order
Answer: B - the largest gap is not automatically the highest priority. Roughly four items are available in Developer Productivity against twelve in Integration, so a moderate weakness in the larger domain is worth more marks than a severe one in the smaller.