The CCAR-P blueprint: 7 domains, 38 objectives, and where the marks are

The seven domains, by weight

The first thing to notice is how flat that is. There is no 35% domain to specialise in and no 3% domain to ignore. Six of the seven land within six percentage points of each other, which tells you the examiners were building a breadth test on purpose. They want someone who can hold a whole delivery in their head.

The second is the arithmetic on the tail. D7 is four questions. Getting all four right is worth less than half of what integration is worth, and the gap between four out of four and two out of four comes to roughly three points of scaled score. If you spend an evening on developer productivity while you are still shaky on retrieval strategy, you have spent the evening badly.

One caveat on reading the table this way. Weight tells you how many questions a domain contributes, not how hard they are, and nobody publishes per-domain difficulty. Granted, the two are probably correlated for most candidates. But if governance is the part you find genuinely difficult, its 14% will cost you more than integration's 19%.

What each domain actually asks

D3 · Integration — 19%

Eight objectives, twelve questions, and the widest span on the exam. Retrieval pipeline design sits here, along with chunking and indexing, matching a retrieval strategy to the shape of the data, choosing between MCP and a direct API integration, authentication and authorisation across a system that acts on a user's behalf, observability at scale, tool bloat, and progressive discovery. If you budget your revision by weight, about a third of it belongs to this domain.

D1 · Solution Design & Architecture — 17%

You are given a business problem and asked to turn it into a system, then defend the shape you chose. Workflow, augmented model or agentic loop. Multi-agent orchestration. Decomposition. Aligning the whole thing to a value pillar somebody named in the stem.

The recurring failure is over-reach. Three of the four options will usually be more capable than the one that gets the mark, and the mark goes to the simplest design that satisfies the constraint in front of you.

D4 · Evaluation, Testing & Optimization — 16%

This domain is about proving the thing works and then keeping it working. Defining metrics that are both meaningful and observable. Building eval datasets that include the cases you would rather not think about. Running experiments whose results can actually be attributed to something. Diagnosing a failure to the right layer before touching anything. Optimising cost and latency after measuring, never before.

It rewards a discipline more than it rewards a fact, and the discipline is measure first.

D5 · Governance, Safety & Risk — 14%

One heuristic gets you a surprising distance through this domain: a prompt instruction is not a security control. Anything that has to hold up under adversarial input has to be enforced outside the model, and options that defend against prompt injection by asking the model not to comply are reliably wrong.

Around that sit the failure modes a given architecture creates, where a human belongs in the loop, and compliance. GDPR, HIPAA and FedRAMP appear as architectural constraints rather than as checkboxes: what they change is where data may live and what you have to be able to delete.

D6 · Stakeholder Communication & Lifecycle — 14%

This is the domain technical candidates lose marks to, and it carries the same weight as governance and more than prompting. Structured discovery. Explaining a trade-off to whichever audience the stem names. Committing to an SLA on a probabilistic system without lying about it. Documentation and handoff. Knowing which lifecycle phase a described situation is really in.

It looks like common sense until you meet it under a clock, at which point it turns out to be graded on specifics. Which discovery question would change the design? What can an SLA honestly promise about output quality? Nine questions ride on answers like those.

D2 · Models, Prompting & Context Engineering — 13%

Everything that happens before a request reaches the model. Which model to send it to and why. What belongs in a system prompt and what belongs in the user turn. When few-shot or chain-of-thought earns its tokens. Context-window management. Prompt caching, including the ordering detail that decides whether a cache helps at all: the stable part has to come first.

The theme is restraint. A cheaper model and a clearer instruction are the right answer more often than instinct suggests.

D7 · Developer Productivity & Enablement — 7%

Team tooling and environments, AI-assisted developer workflows, and debugging systems that have a non-deterministic component in them. Three objectives and four questions. One focused pass is enough.

Turning the weights into a timetable

A blunt allocation works well enough to start with. Give each domain the share of your revision that matches its share of the exam, then adjust once: upward for anything a practice mock says you are weak on, downward for anything you already do daily at work.

The adjustment matters more than the starting split, which is the argument for putting a mock sat cold at the front of any plan. Allocating by weight is what you do when you know nothing about yourself. Allocating by weight and measured weakness together is strictly better, and it costs two hours to earn.

Why objective-level detail is worth caring about

Most certification score reports stop at the domain. This one goes down to the objective, and that changes what a failure costs you. Being told you were weak on integration spans authentication gaps, chunking strategy, protocol choice and observability, which is four unrelated evenings of work. Being told you were weak on 3.5 is one topic, and the retake window is 14 days.

Every question in this bank is tagged to an objective for that reason, and there is a card for each of the 38 with its own drill behind it. If you are planning a retake, the weak rows on your report are already the study plan. You do not need to re-cover the domain around them.

Common questions