Claude Certified Architect - Professional

CCAR-P — Claude Certified Architect – Professional — is a $175, 63-item, 120-minute proctored exam, scored 100–1000 with 720 to pass. You sit it through Pearson, either at a test centre or remotely with OnVUE. Items are multiple-choice and multiple-response, and every multiple-response item states how many options to select. The credential is valid 12 months and is renewed by a free open-book assessment. There are no prerequisites — Foundations is not required, and it is not a stepping stone you must earn first.

It is written for mid-to-senior solution architects, AI/ML engineers and technical leads with 3+ years in systems architecture or platform engineering who design production Claude solutions at enterprise scale. Expect long enterprise scenarios with a named constraint, not API trivia.

About half of CCAR-P has no Foundations counterpart: RAG and retrieval, authN/authZ, observability, A/B testing, compliance, and an entire 14% domain on stakeholder communication and lifecycle management. Foundations asks whether you can build it. Professional asks whether you can defend it to an auditor, a CFO and the team that inherits it.

The blueprint:

• Integration — 19%

• Solution Design & Architecture — 17%

• Evaluation, Testing & Optimization — 16%

• Governance, Safety & Risk Management — 14%

• Stakeholder Communication & Lifecycle Management — 14%

• Claude Models, Prompting & Context Engineering — 13%

• Developer Productivity & Operational Enablement — 7%

Plan study time by weight, because weight is items. Across 63 items, one point of weight is roughly two-thirds of an item: Integration is about twelve items, Developer Productivity about four. The top three domains carry 52% and the top five carry 80% — your pass is earned there. Give each domain hours in proportion to its weight, then spend the surplus on the Professional-only material above, because retrieval, identity, observability, experimentation and compliance surface inside every domain rather than sitting in one. The classic failure is a strong engineer who spends a weekend on the 7% domain because it is the most familiar.

Ten minutes out, stop reading notes and read this. Say each word aloud, expand it from memory, then check yourself against the line. Whatever you cannot expand cold is the one thing left to rehearse. In the exam, walk the letters in order and answer at the earliest one the scenario has not yet resolved.

• Integration · 19% — BRIDGE: Boundary · Retrieve · Identity · Deliver context · Gauge · Evidence — name the system of record and trust boundary, choose the retrieval strategy, propagate the end user's identity and filter by ACL at query time, budget the context window, hit the accuracy · latency · cost target, then trace and cite everything.

• Solution Design & Architecture · 17% — SCOPE: Sponsor's metric · Constraints · Options · Pattern · Evidence — name the business outcome and its baseline, list the hard limits, weigh build/buy/extend, stop at the first pattern that satisfies the metric under those constraints, and prove it with an eval set and pilot thresholds.

• Evaluation, Testing & Optimization · 16% — PROVE: Pin the objective · Representative set · Objective scorers first · Validate the judge · Experiment online — name the decision the score drives, stratify real traffic and hold out a clean split, run deterministic checks before any LLM judge, prove the judge agrees with humans, then shadow, canary, A/B with a stopping rule.

• Governance, Safety & Risk Management · 14% — GRAIL: Gauge blast radius · Restrain in code · Approve at the irreversible step · Isolate untrusted input and regulated data · Log for audit — classify the action, turn each risk into a deterministic control, put one gate in front of what cannot be undone, strip authority from retrieved and third-party content, keep append-only provenance.

• Stakeholder Communication & Lifecycle Management · 14% — PILOTS: Problem not product · Identify the binding constraint · Limits declared up front · Options on the record · Thresholds to promote · Steward and sunset — name the decision the output changes, find the one constraint that decides the architecture, declare non-determinism and cost envelope early, write the ADR with alternatives, agree the numbers that exit the pilot, hand it to a named owner with a review date.

• Claude Models, Prompting & Context Engineering · 13% — TIERS: Task profile · Instructions · Evidence · Reuse · Spend — profile volume, latency SLO and the cost of a wrong answer before any tier talk, write the system prompt as a contract, decide per fact whether it is resident, retrieved or tool-fetched, version the prompt as an owned asset, then order for cache hits and measure cost per resolved task.

• Developer Productivity & Operational Enablement · 7% — ADOPT: Anchor · Declare · Onboard · Protect · Track — capture the baseline first, declare shared configuration as code in the repo, onboard one willing cohort clone-and-go, protect with tool allow-lists, approvals and team-level cost attribution, then report outcomes against the baseline and say what you cannot attribute.

Every CCAR-P item is a scenario with one constraint that decides the answer. Find it before you read the options.

Read the stem for the ask, not the story. The final sentence usually carries both the question and the binding constraint — a latency SLO, a cost ceiling, a residency rule, an audit obligation, a team that cannot maintain what you build. Then reread the body only for facts that touch it. Industry colour, headcount and the incumbent stack are scenery; a number never is.

Place the question in a domain before you judge options, because the domain is what best means:

• Integration — correct data, correct permissions, cheapest context that still survives an audit.

• Solution Design — the simplest pattern that clears the business bar.

• Evaluation — the move that produces trustworthy evidence, in the right order.

• Governance — the deterministic control in front of the irreversible step.

• Stakeholder & Lifecycle — the missing conversation, decision record or owner.

• Models & Context — the tier and context strategy the stated budget or SLO permits.

• Developer Productivity — what still works after the author leaves the team.

Working the options:

• Multiple-response items tell you how many to select. Select exactly that many — no credit for hedging with an extra good idea, none for stopping short.

• Judge each option on its own merits — true or false — rather than ranking them against each other.

• Eliminate the technically correct. Two or three options usually work in the abstract; one respects the constraint the stem named. An option that adds latency to a scenario with a latency SLO is wrong even though it improves accuracy.

• Distrust the most sophisticated answer. Multi-agent where a chain suffices, fine-tuning where a prompt and an eval suffice, a vector store for a document that fits in context: over-engineering is the most common wrong answer. Under-engineering exists too, and always looks like a missing control, eval or owner.

Time: 63 items in 120 minutes is 1 minute 54 seconds each. Budget 1:40 and bank the difference. Check the clock at item 21 (40 minutes) and item 42 (80 minutes). Flag and move rather than argue with an item — a long stem you have already parsed is far quicker on the second pass, and twenty minutes of buffer beats any single question.