CCAR-P cheat sheet: the decision rules for all seven domains on one page

This CCAR-P cheat sheet compresses the 63-item, 120-minute Claude Certified Architect Professional exam into decision rules by domain. Seven domains are weighted from 19 percent for Integration down to 7 percent for Developer Productivity and Operational Enablement; 720 of 1,000 passes; the fee is $175, the highest in the programme. Each domain below gets the CCAR-P decision rules that settle an item when two options both look defensible, then the traps, the terms and a final-week checklist.

How to use this CCAR-P cheat sheet

Read the weights first. Integration and Solution Design together are about 23 of 63 items, but the paper is flatter than that suggests: five of the seven domains sit between 13 and 17 percent, so no single domain carries the result the way one does on the developer paper. The guide lists 38 objectives, more than any other Claude exam, on a paper of 63 items. That is about 1.66 items per objective, which means depth on the heavy domains pays better here than coverage of every objective. Use each rule below as a test on your own practice misses rather than as text to memorise.

Checked against the official sources on 17 September 2026: the CCAR-P Exam Guide v1.0 (July 2026), the Anthropic Certification Exam Policy dated 25 June 2026, and the partner certification FAQ. Where this page states a fee, a count or a policy, that is where it comes from.

The item column is a whole-number reading of the published percentages, the same allocation the free timed mock at /practice/ccar-p uses. The guide promises approximate weights, not exact counts. One consequence worth knowing before you read a score report: Developer Productivity carries about four items, so the only per-domain percentage it can show at or above 80 is 100. Read that domain as pass or fail. The generic Claude exam cheat sheet covers the twelve judgements that repeat across all four tracks; this page is the CCAR-P layer beneath it, and the Claude certification study guide supplies the repair loop the checklist at the end assumes.

Domain 1: Solution Design and Architecture (17%)

About eleven items. Six objectives: translate business problems into Claude-based solutions, design end-to-end architectures with feedback loops, select the architectural pattern, design multi-agent systems, apply decomposition, and align the solution to business value. The stems describe a partner request or a production system and ask what an architect should do next, so the rules are about ownership and pattern before they are about anything technical. The deeper treatment is in solution design on CCAR-P.

1. 1.1 Decide what Claude owns before deciding how. Exact arithmetic, transactions and any fact that can change before the next refresh belong to the system of record through a tool call. An irreversible or high-stakes decision belongs behind a human gate. Claude owns the judgement and language step in between, and reading like a language task is not a reason to hand it more.
2. 1.2 Choose the pattern by predictability, then by the cost of an error. If every step can be written down in advance it is a workflow: chaining, routing, parallel sections or an evaluator loop. An agent is for a path that only becomes clear as tools return results, and it ships with scoped tools, turn limits and monitoring. One bounded step is a single augmented call, the cheapest pattern there is.
3. 1.3 An orchestrator delegates and combines; it does not do the work. Sub-tasks go to workers with a brief that carries the constraints, one level deep. Before any synthesis, compare what came back with what went out. Four dispatched and two returned is an incomplete result that reads as complete.
4. 1.4 Decompose at the boundaries where an error would spread. Split where a wrong intermediate result would poison everything after it, or where a person has to approve, and nowhere else. Every additional hop is latency, cost and a place to lose context, so tidiness is not a reason.
5. 1.5 Anchor the design to a named value pillar and a measurable target. The guide names efficiency, transformation, productivity, cost and performance SLAs. An option that cannot say which pillar it serves and how that would be measured cannot be compared against one that can, however capable it sounds.

Tie-breaker. Which option grants Claude the least autonomy and the fewest moving parts that still meet the stated requirement?

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

About eight items. Five objectives: select models on trade-offs, design system prompts and guardrails, apply prompting techniques, optimise context and token usage, and implement prompt reuse through caching, modular prompts and Skills. The official sample for this domain is the caching item: a long static prompt resent on every call, with latency and cost both a concern. Every distractor either throws away context or fails to create anything reusable. The domain post is models, prompting and context on CCAR-P.

1. 2.1 Start in the middle tier and move on evidence. Default to the balanced model. Move up when an eval set shows the quality bar missed, down when it shows headroom. Reaching for the largest model by reflex is the distractor in almost every model-selection item, and reaching for the smallest regardless of fit is its twin.
2. 2.2 A rule that must hold every time is not a prompt. System prompts steer behaviour; they do not enforce it. Schema validation, tool-call authorisation and deterministic checks enforce. When a stem says must never or must always, look for the option that puts the rule in code rather than in stronger wording.
3. 2.3 Climb the prompting ladder in order. Clear zero-shot instructions, then a few diverse examples, then structure such as tagged sections, then step-by-step reasoning for a step that is genuinely hard, then tools or retrieval for facts the model cannot know. Fine-tuning is the last rung, never the first.
4. 2.4 Name the binding constraint, then pull the matching lever. A quality floor points at the tier or a thinking budget on one hard step. A cost ceiling points at caching, batching or a smaller tier. A p95 latency target points at caching, a shorter context or a faster tier. Truncating a document the task needs is a loss, not an optimisation.
5. 2.5 Cache what is stable and put it first. In the official sample, an 8,000-token system prompt and policy document go out with every request. The key orders the static content ahead of the dynamic user message and turns caching on. A prefix only caches when it is identical across calls, and moving the policy into a few-shot block creates nothing reusable.

Tie-breaker. Which constraint is actually binding in the stem, quality, cost or latency, and which single lever addresses it without discarding anything the task needs?

Domain 3: Integration (19%)

About twelve items, the largest block on the paper. Eight objectives, the most of any domain: evaluate tool configuration for capability bloat, analyse authentication and authorisation for gaps, weigh accuracy against latency, select monitoring strategies at scale, design a RAG pipeline, match retrieval to the data and the queries, select the integration mechanism, and choose between progressive discovery and a monolithic context. Four of the eight objectives begin with the verb evaluate, which on this domain means choosing between named alternatives on a stated constraint. The official sample for this domain is the least-privilege item; the other two sit in the neighbouring domains. The full treatment is in the CCAR-P integration domain.

1. 3.1 Least privilege means removal. The official sample gives a support agent refund and delete tools that support staff never use. The key removes the two tools. Logging and confirmation prompts are compensating controls that leave the capability reachable, and a larger model has nothing to do with authorisation scope.
2. 3.2 Identity is established server-side and injected, never read from the message. The user cannot be trusted to state who they are or what they may do. Resolve role and tenant on the server, inject them into the context, and issue separate credentials per tenant so that an incident or an audit question has a single attributable owner.
3. 3.3 More tools cost accuracy, and so does more context. Configure to the leanest tool set and context that clears the eval bar and the p95 target. When a toolset is large or changes often, load definitions progressively as they are needed. When it is small and stable, a fixed context is simpler and cheaper. Tool count decides, not taste.
4. 3.4 RAG chunks follow the document, the index follows the query, and stale facts stay out. Chunk by the document structure rather than a default size, index for the way people actually ask, and keep anything that can change between refreshes behind a live tool call. The official sample, confident wrong answers right after a document refresh with model and latency unchanged, points at retrieval and indexing first.
5. 3.5 Choose the protocol by who needs the tools. Several clients needing one governed tool surface is MCP. One application owning one integration is a direct API or CLI call. A counterpart that is itself an autonomous agent with its own tools is agent-to-agent. Naming the protocol first and the consumer second is how this item is lost.
6. 3.6 Observability at scale is a design input, not an afterthought. One trace identifier across every sub-call, logs of inputs, outputs and outcomes rather than errors alone, and a sampling plan for review. A unit of work that is dropped silently is the failure this rule exists to make visible.

Tie-breaker. What is the leanest configuration that clears the eval bar, the p95 target and the governing constraint, and does the option remove risk or merely watch it?

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

About ten items. Six objectives: define metrics across accuracy, latency, cost, safety and security, design evaluation datasets with mixed methods, run A/B tests, diagnose system issues, optimise the cost-performance trade-off, and monitor with logging and observability. The official sample is a RAG system that starts returning confident wrong answers after a document refresh while the model and latency are unchanged, and the key looks at retrieval and indexing before anything else. The domain post is evaluation and testing on CCAR-P.

1. 4.1 Metrics cover all five families the objective names. Accuracy, latency, cost, safety and security. An eval suite that reports accuracy alone, however thorough, answers a fifth of the question the objective asks, and the item will offer it as the diligent-looking distractor.
2. 4.2 Set the threshold before the run and build the golden set before shipping. A pass mark chosen after the result describes the result. Grade in cost order: code-based checks first, a calibrated model judge that is not the model under test next, human review reserved for the high-stakes cases. Rebuild the golden set whenever the prompt changes.
3. 4.3 A/B means one variable, the same inputs and a criterion declared in advance. Three changes and one improvement gives no attribution, and every later version carries all three. The key changes one thing, reruns the identical cases and compares against a number written down beforehand.
4. 4.4 Diagnose by symptom before touching anything. Wrong facts point at retrieval or knowledge. Right facts and wrong reasoning point at the prompt or a model mismatch. Right content in the wrong shape points at the output contract. Gradual drift with no code change points at the corpus or a model swap that never re-cleared the eval gate.
5. 4.5 Cost and latency come from the tail of the token distribution. The average request does not breach the SLA or drive the bill; the slow, long tail does. Model from the real distribution, then pull levers in order: cache the stable prefix, batch what can wait, right-size the tier, tune the thinking budget.
6. 4.6 Monitor on every call and put a quality score on the dashboard. Error rate alone misses the most common production failure: a slow quality decline with nothing erroring. An eval score sampled from live traffic is the signal that catches it, and it needs an owner and a trigger, not just a chart.

Tie-breaker. Was the success criterion fixed before the run, and does the proposed change alter exactly one thing that the symptom actually implicates?

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

About nine items. Five objectives: implement guardrails and safety controls, identify risks and failure modes of LLM systems, apply human-in-the-loop validation, ensure compliance with regulations such as GDPR, HIPAA and FedRAMP, and address bias, fairness and transparency. The stems put a control in the wrong place or at the wrong strength and ask you to notice. The domain post is governance, safety and risk on CCAR-P.

1. 5.1 Three checkpoints, three different questions. Input screening asks what is coming in. Output screening asks what is going out. Tool-call authorisation asks what is about to happen, and it is deterministic and sits before the action. An output filter cannot undo a side effect that has already run.
2. 5.2 Fail closed wherever a wrong pass would cause harm. A guardrail that passes traffic when it errors is worse than no guardrail, because it looks like protection while providing none. Block and log on uncertainty; release only on a positive result.
3. 5.3 Trained safety does not know your policy. Claude reduces general harms without configuration. Your data-handling rules, authorisation model and domain policy are enforced nowhere unless you put them in a control. Injection arrives from two directions: the user, and content that rides in through retrieval or a tool result.
4. 5.4 Route human review by stakes, not by volume. Reversibility and the cost of a wrong answer outrank confidence. Consequential outputs in legal, health, financial, employment and similar categories need a qualified reviewer whatever the confidence score, and a disclaimer is not a review.
5. 5.5 Every regulation resolves to a control, an owner and an evidence artefact. GDPR wants a lawful basis and minimisation. HIPAA wants safeguards over protected health information under the right agreement. FedRAMP wants an authorised route at the required impact level. Residency covers logs and caches, not just the primary path. Choosing a route that could comply is a prerequisite, never proof.
6. 5.6 Bias enters through your corpus, your framing, your examples and your routing. None of those four is covered by a vendor evaluation of the model. Log decisions so they can be reconstructed, and check outcomes per subgroup, because an aggregate dashboard can look healthy while harm concentrates in one group.

Tie-breaker. On the run where the model gets it wrong, does this option stop the action or only describe it afterwards?

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

About nine items. Five objectives: conduct structured discovery, communicate architectural decisions and trade-offs, manage feedback loops and expectations including SLAs, document architectures with implementation guidance, and support the lifecycle from discovery through iteration. An engineering instinct does not protect you here: the technically best design is not the key when the stem asks how the decision was reached, explained and handed over. The domain post is stakeholder communication on CCAR-P.

1. 6.1 Discovery turns adjectives into constraints. Fast becomes a p95 in milliseconds. Accurate becomes an eval acceptance criterion. Must not becomes a named control. A preference you cannot measure is a discovery gap, and an option that builds to it is building to a guess.
2. 6.2 A trade-off has three parts, and the third is the one that moves decisions. What the choice gains, what it gives up, and what reversing it would cost once the system is built around it. Most presentations stop at two. In a regulated setting, add a fourth: what it does to the compliance posture.
3. 6.3 Recommend as a package, not a verdict. Options considered, the criteria weighed, the recommendation and the risks that remain. A stakeholder who is handed only a conclusion cannot defend it upward, and an item that offers the confident single answer is testing whether you know that.
4. 6.4 An SLA threshold traces to a source. A user expectation, a business criticality or an eval criterion. A round number that sounds reasonable is the distractor, and so is a threshold copied from a different system with a different user.
5. 6.5 Document for the person who was not in the room. Decisions with the alternatives rejected and why, labelled assumptions, and a register of controls. The handoff test is whether a competent architect who missed every design session could make a safe change from the documentation alone. A feedback loop assigns each signal a trigger, an owner and an action; dashboards alone are observability, not governance.

Tie-breaker. Has every preference, approval, signal and decision been translated into something measurable, owned and documented before anyone acts on it?

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

About four items. Three objectives: configure Claude tools and environments for teams, with Claude Code named as the example, improve developer workflows with AI-assisted tooling, and support debugging and operational issue resolution. It is the lightest domain on this paper, and it carries the one judgement that also appears on every other track: whether a rule lives in prose or in an enforced control. The configuration side is covered in Claude Code configuration for the exams.

1. 7.1 Prose configuration guides; hooks and permissions enforce. A line in a CLAUDE.md or rules file is context the model is steered by. A command that must never run, or a check that must always pass before a merge, belongs in a permission rule or a hook that the client enforces regardless of what the model decides.
2. 7.2 Roll out through a champion and one real workflow, then widen. An all-hands switch-on is the distractor. Shared assets need an owner and a rollback path, and each mechanism has a job: a Skill for a reusable procedure, a subagent for isolated or verbose work with its own tool allowlist, a hook for a step that must run deterministically.
3. 7.3 AI-generated changes pass the same gates as human ones. Correctness, security, maintainability, and whether the person merging can explain what the change does and why. Automate every check that can become a regression test or a blocking hook, and keep the human on the ones that cannot.
4. 7.4 Match the operational symptom to its architecture cause, with evidence, before acting. Gradual quality decline points at a corpus or model change. A latency spike points at context growth, a slow tool or a cache miss. Intermittent tool failures point at authorisation, rate limits or an unhandled error path. A cost rise with flat usage points at tier creep or a caching regression. Write the fix into a runbook.

Tie-breaker. Is this enforced by the client no matter what the model decides, or is it a suggestion the model usually follows?

The CCAR-P traps: wrong-answer patterns and why they tempt

The distractors on this paper describe things competent engineers do every week, which is what makes them distractors. Twelve recur. Three are taken directly from the official sample rationales and the other nine follow the same construction: the option adds a component, a control or a capability where the key removes, reorders or restructures one.

CCAR-P quick reference: the terminology

Eighteen terms the stems use without defining. An architect who works with Claude daily knows all of them, but several carry a narrower meaning on the paper than in conversation, and the distractors are written against the loose meaning.

Final-week checklist and CCAR-P exam tips

Six steps, in order. They assume the studying is done and you are now converting it into marks. The two-week CCAR-P study plan is the version of this that starts a week earlier and front-loads the two domains that appear on no other blueprint. If you hold CCAR-F already, the post on moving from CCAR-F to CCAR-P covers what carries over and what does not.

Policy facts worth carrying in: a failed attempt can be retaken after 14 days, then 30 after a second failure and 90 after a third, with four attempts per rolling twelve months at the full $175 each time (your partner-tier discount still applies), and the credential is valid for 12 months with a free, non-proctored renewal if completed on time. Registration requires a work email on a recognised Claude Partner Network company domain; Select, Preferred and Global Premier partners pay half, and Global Premier pays nothing through 31 December 2026. Confirm all of it against the guide and the Pearson VUE Anthropic page before booking. Our guide to Claude certification practice exams sets out what official practice material exists, which for this exam is the three sample items and nothing else.

Key takeaways

• The paper is flat and the blueprint is wide. Five domains between 13 and 17 percent, 38 objectives on 63 items; depth on Integration and Design beats coverage.
• Predictability gates the pattern. Enumerable steps mean a workflow, and the cost and flexibility arguments never get to speak.
• Least privilege is removal. Logs and confirmations watch a risk; the key takes the capability away.
• Enforce in code, steer in prose. A rule that must hold every time is not a system prompt line, a CLAUDE.md line or a firmer instruction.
• The key subtracts. All three official sample keys remove, reorder or narrow; every distractor adds.
• Developer Productivity is pass or fail. Four items means the only domain percentage at or above 80 is 100, so read that line of the score report accordingly.