Claude Certified Architect - Professional course
8 modules, one per exam domain. 54 lessons, each opening with its key concepts; 6 timed practice tests.
One purchase covers the lessons and the tests.
What does the CCAR‑P course cover?
Every module is one of the 8 exam domains Anthropic publishes, in exam order, with the domain's share of the exam as its bar. Integration and Solution Design and Architecture carry the most at 19% and 17%. The exam runs 120 minutes for 63 questions (all scored). Open a module for its lessons; the practice tests close the course.
Find the decision a business request is really asking for, choose the shape and the mechanism that fit it, and record the choice so it survives the next review.
17% of the exam · Exam domain: Solution Design & Architecture
Framing the Problem
A request names a solution somebody already picked. Walk it back to the work, the population and the cost of being wrong.
- 1.1
Find the Decision the Business Actually Needs
A problem statement carries a population, a target and a constraint · The cost of a wrong answer sets the review design
25 minHigh priority
- 1.2
Recognise the Problems Claude Should Not Own
Determinism, not difficulty, decides whether a model belongs · Most problems split into a rule half and a judgement half
25 minHigh priority
- 1.3
Size the First Version So It Can Ship
Scope to a measured share of volume, not to features · The escape path ships in version one, not version two
25 minHigh priority
Choosing a Shape
One call, a fixed workflow or an agent. Then decide how knowledge reaches the model and where a person can still change the outcome.
- 1.4
Choose Between a Call, a Workflow and an Agent
Autonomy costs predictability and bounded spend · An unknown step count is what justifies an agent
25 minHigh priority
- 1.5
Decide How Knowledge Reaches the Model
Load what is stable, fetch what is live · Retrieval is for corpora that will not fit, not for large-sounding ones
25 minHigh priority
- 1.6
Place the Human Where the Review Actually Works
Design the review, not just the reviewer · High-risk domains require a qualified professional whatever the accuracy
25 minHigh priority
Recording the Decision
Write the record that answers why not the other option, and do the cost arithmetic before anybody writes code.
- 1.7
Write a Decision Record That Survives Review
The rejected options are the section people come back for · One record per decision, each dated and cross-referenced
25 minCore topic
- 1.8
Cost a Design Before Anybody Builds It
Four numbers give you the bill within about twenty percent · Fix multipliers before trimming tokens
25 minHigh priority
Module assessment
Drawn from the lessons above, a different set each attempt.
Pick a tier from graded evidence, reach for effort before you reach for a bigger model, and treat caching, window size and delivery mode as parts of the architecture.
13% of the exam · Exam domain: Claude Models, Prompting & Context
Selecting and Tuning a Model
Start cheap and climb or start capable and descend, then use effort as the first control and add a second model only when it earns its place.
- 2.1
Start Cheap and Climb, or Start Capable and Descend
Grade the task, not the benchmark · Task class predicts the tier better than volume does
25 minHigh priority
- 2.2
Reach for Effort Before You Change the Model
Five effort levels, with high as the API default · Manual budget_tokens is rejected on Claude 4.7 and later
25 minHigh priority
- 2.3
Build Multi-Model Designs That Actually Save Money
A cascade pays only at a high cheap-tier pass rate · Grade with a different model from the one that answered
25 minCore topic
Context Economics
Caching decides prompt order, the window is a ceiling rather than a target, and delivery mode follows who is waiting.
- 2.4
Treat Prompt Caching as an Architectural Decision
A breakpoint on variable content caches nothing · Invalidation cascades through tools, system, then messages
25 minHigh priority
- 2.5
Work Out What a Million Token Window Really Changes
Fitting is not the same as working · Grade at the input size you intend to deploy
25 minHigh priority
- 2.6
Spend the Latency Budget Where Somebody Is Waiting
Streaming changes perception, batch changes cost · Batch results at completion or 24 hours, whichever comes first
25 minCore topic
Module assessment
Drawn from the lessons above, a different set each attempt.
Pick the platform and the routing before the design hardens, put MCP and scoped credentials at the boundary, and run the thing under real limits and real failures.
19% of the exam
Choosing Where Claude Runs
Five platforms, two operator models, and a set of consequences for features, residency, retention and who sets the retirement date.
- 3.1
Choose the Platform Before You Choose Anything Else
Anthropic-operated against partner-operated · Feature availability is not uniform across platforms
25 minHigh priority
- 3.2
Route Requests Where the Rules Say They May Go
Global routing is an availability feature, not a residency promise · Rate limits pool across inference_geo values
25 minHigh priority
- 3.3
Know Who Processes the Data and What Survives the Request
Covered Models require 30-day retention · HIPAA readiness is organisation level and permanent
25 minHigh priority
Connecting Systems
MCP as the place you decide what Claude may reach, credentials as the place you decide what it can touch, and citations as the way an answer becomes checkable.
- 3.4
Use MCP as the Boundary Between Claude and Your Systems
Remote HTTPS servers only, over Streamable HTTP or SSE · Allowlist fails closed when a tool is added later
25 minHigh priority
- 3.5
Give the Integration the Smallest Identity That Works
The model is not a permission boundary · Scope from the credential, not from a tool argument
25 minHigh priority
- 3.6
Ground Answers So Somebody Can Check Them
Document type decides citation granularity · A scan with no text layer cannot be cited
25 minCore topic
Running It in Production
The limits that cap your throughput, the failures that happen where Claude meets another system, and the interface that turns a migration into a configuration change.
- 3.7
Design for the Limits Before Traffic Finds Them
Cache reads do not count toward input tokens per minute · The spend cap 429 carries no retry-after
25 minHigh priority
- 3.8
Plan for the Failures That Happen at the Seam
An empty result is not the same as no data · Write the partial-result rule down
25 minHigh priority
- 3.9
Put a Stable Interface Between Your Product and the Model
Resolve the model identifier in one place · Sweep effort again on every migration
25 minCore topic
Module assessment
Drawn from the lessons above, a different set each attempt.
Write criteria a grader can score, build a set that looks like production, gate on it in the pipeline, and optimise cost and latency from measurement rather than intuition.
16% of the exam · Exam domain: Evaluation, Testing & Optimization
Building the Eval Set
Criteria before cases, a distribution that matches the traffic, and the cheapest grading method each criterion allows.
- 4.1
Write the Success Criteria Before the Test Cases
Specific, measurable, achievable, relevant, with a threshold · One score per dimension, never blended
25 minHigh priority
- 4.2
Build a Set That Looks Like the Traffic You Will Get
Volume with automated grading beats a small hand-graded set · Keep the regression suite out of the sampled distribution
25 minHigh priority
- 4.3
Pick the Cheapest Grading Method the Criterion Allows
Decompose a fuzzy criterion before reaching for a model grader · Calibrate any model grader against human labels
25 minHigh priority
Running Evals That Mean Something
The systematic errors a model grader introduces, the gate that gives a suite teeth, and what to do when online behaviour disagrees with the score.
- 4.4
Know How a Model Grader Misleads You
Verbosity, position, self-preference and scale drift · Pin the grader and re-baseline after any change
25 minHigh priority
- 4.5
Put the Eval Suite in the Pipeline, With Teeth
Gate on the delta as well as the floor · Design the override before somebody needs it
25 minHigh priority
- 4.6
Reconcile What the Suite Says With What Users Do
A divergence is a finding about your criteria or your sample · Shadow rather than stage when the decision matters
25 minCore topic
Optimising Afterwards
Attribute the spend before touching a prompt, and allocate a latency budget across components rather than letting one absorb it.
- 4.7
Measure Where the Money Goes Before You Optimise
Tag every request with a workload label · Count attempts rather than successes
25 minHigh priority
- 4.8
Spend the Latency Budget on Purpose
Budget the ninety-fifth percentile · Parallelise independent tool calls before changing tier
25 minCore topic
Module assessment
Drawn from the lessons above, a different set each attempt.
Classify what reaches the prompt, count every party that touches it, size the blast radius before granting a permission, and write risks somebody can act on.
14% of the exam · Exam domain: Governance, Safety & Risk
Data Handling
What may enter a prompt, who else touches it on the way, and which boundary crossings need a name against them.
- 5.1
Decide What May Enter a Prompt Before Anything Does
Free text defeats field-level classification · Tool results carry a class too
25 minHigh priority
- 5.2
Count Every Party That Touches the Data
A verified connector is not an audited one · Your own audit trail is a party
25 minHigh priority
- 5.3
Record Which Boundary the Data Crosses, and Who Agreed
An approval needs a name, a date and a scope · Every approval carries a review date
25 minCore topic
Safety in the Design
Controls that hold when the model is wrong, and a trail that answers the question an incident actually asks.
- 5.4
Size the Blast Radius Before You Grant the Permission
Reversible at scale is not reversible · Volume caps bound tools nobody has added yet
25 minHigh priority
- 5.5
Build the Trail Somebody Will Read at Two in the Morning
Log the control decision, not only the outcome · Log arguments in full and sample the payloads
25 minCore topic
Risk You Can Name
A register that steers engineering, and the usage policy read as a constraint on what you may build at all.
- 5.6
Name the Risks in Language Somebody Can Act On
Every residual risk needs a named owner · Score before and after the control
25 minHigh priority
- 5.7
Read the Usage Policy as an Architecture Constraint
High-risk obligations do not scale with accuracy · Disclosure at the start of the session
25 minHigh priority
Module assessment
Drawn from the lessons above, a different set each attempt.
Write requirements somebody signs, set expectations a demo cannot undo, report progress on work that has no percent complete, and hand the system over so another team can change it.
14% of the exam · Exam domain: Stakeholder Communication & Lifecycle
Before the Build
Requirements with exclusions in them, a demo that shows the failure path, and a pilot designed to answer one question.
- 6.1
Turn the Request Into Requirements Somebody Will Sign
Write down what you will not do · Commit to outcomes, never to an implementation
25 minHigh priority
- 6.2
Set Expectations That Survive the Demo
Demo the failure path in the same session · A demo shows behaviour and never a rate
25 minHigh priority
- 6.3
Design the Pilot to Answer a Question
Write the decision rule before the data · A pilot that concludes no is a success
25 minCore topic
Through the Build
A status report that says where the project stands, and a way to answer the sponsor who has just seen something impressive.
- 6.4
Report Progress on a System That Has No Percent Complete
Report against the bar, not the baseline · Name the blocker and who can clear it
25 minHigh priority
- 6.5
Answer the Executive Who Saw Something Impressive
Convert enthusiasm into a bounded test · Commit to the outcome, keep the mechanism
25 minHigh priority
After the Build
Transfer the ability to change the system rather than only to run it, and turn a retirement notice into a plan before anybody needs to approve anything.
- 6.6
Hand Over So the Team Can Run It Without You
Handover is a rehearsal, not a document · Transfer eval ownership and the change process
25 minHigh priority
- 6.7
Turn a Retirement Notice Into a Plan Nobody Panics About
Tell stakeholders before you need anything from them · Plan backwards from the retirement date
25 minCore topic
Module assessment
Drawn from the lessons above, a different set each attempt.
Put security policy where engineers cannot move it and conventions where the team can, write guardrails precise enough to survive, and instrument the rollout before you have opinions about it.
7% of the exam · Exam domain: Developer Productivity & Operational Enablement
Enabling the Team
Settings precedence across an organisation, permission rules that stay in force because nobody needs to route around them, and the telemetry that tells you which is which.
- 7.1
Standardise the Configuration Without Freezing the Team
Managed settings for policy, project settings for convention · Permission lists merge across scopes by default
25 minHigh priority
- 7.2
Write Guardrails Engineers Do Not Route Around
Deny and ask apply immediately, allow waits for trust · A generous allow list protects attention for the rare prompt
25 minHigh priority
- 7.3
Instrument the Rollout and Write the Runbook
Content logging is off until you turn it on · Managed settings lock the telemetry destination
25 minCore topic
Module assessment
Drawn from the lessons above, a different set each attempt.
Six worked situations in the shape the exam uses: a brief that hides its own requirement, a bill nobody attributed, a security review that removes a capability, a suite that disagrees with production, a regulated workload in the wrong place, and a sponsor who left without a handover.
0% of the exam · Exam domain: Cross-domain
Worked Exam Scenarios
One scenario per domain cluster, each running from the situation through the reasoning to the decision the exam asks for, and each ending on why the plausible alternatives fail.
- 8.1
Scenario: The Agent Nobody Needed
The shape follows the work, not the funded idea · Deterministic steps stay in code
25 minHigh priority
- 8.2
Scenario: The Bill That Arrived Before the Users
Attribution before optimisation · Batch, cache and structured output ahead of a tier move
25 minHigh priority
- 8.3
Scenario: The Security Review Two Weeks Before Launch
The approved processor decides which capabilities exist · Start with the finding that removes options
25 minHigh priority
- 8.4
Scenario: The Suite Says Ship
Offline high and online low points at the population · A rubric that never asks cannot fail
25 minHigh priority
- 8.5
Scenario: The Workload in the Wrong Organisation
Stop the exposure growing before restructuring · Qualified human review is the control that already worked
25 minHigh priority
- 8.6
Scenario: The Sponsor Who Left
A baseline you never recorded may still exist as data · Ownership follows value and accountability
25 minHigh priority
Module assessment
Drawn from the lessons above, a different set each attempt.
Each test mirrors the real exam: 120 minutes, 63 questions, all domains in proportion. Learning mode shows the explanation after each answer; exam mode runs the clock and scores at the end. The study plan below schedules them across the weeks.
- 1
Practice test 1
Full CCAR-P exam simulation #1 covering all seven domains at their real blueprint weights: solution design, models and context engineering, integration, evaluation, governance, stakeholder communication, and developer enablement. Scenario-based, applied-reasoning items in the style of the live exam.
63 questions · 120 min
- 2
Practice test 2
Full CCAR-P exam simulation #2 with proportional coverage of all seven domains. Emphasizes solution decomposition, architectural pattern selection (workflow vs. agentic vs. augmented LLM), and integration mechanism trade-offs across MCP, API/CLI, and agent-to-agent.
63 questions · 120 min
- 3
Practice test 3
Full CCAR-P exam simulation #3 with proportional domain coverage. Emphasizes model selection under cost and latency SLAs, prompt and context engineering with caching and Skills, and RAG pipeline design with chunking, indexing, and retrieval strategy.
63 questions · 120 min
- 4
Practice test 4
Full CCAR-P exam simulation #4 with proportional domain coverage. Emphasizes evaluation and optimization: defining metrics, designing test frameworks, A/B testing, and diagnosing prompt failure, hallucination, and model-mismatch issues in production.
63 questions · 120 min
- 5
Practice test 5
Advanced CCAR-P exam simulation #5 with proportional domain coverage. Emphasizes governance, safety, and risk: guardrails, human-in-the-loop validation, regulatory compliance (GDPR, HIPAA, FedRAMP), ethical AI, and stakeholder lifecycle management.
63 questions · 120 min
- 6
Practice test 6
Advanced CCAR-P exam simulation #6 with the hardest cross-domain scenarios. Multi-layered production trade-offs spanning architecture, integration, evaluation, and governance, with nuanced distractors that reward deep architectural judgment.
63 questions · 120 min
Try 15 free questions on the certificate page before you buy.
How long does it take to prepare with this course?
About 23 hours of lessons, 54 of them at roughly 25 minutes each. With the 6 practice tests and review, plan on about 25 hours. The modules run in exam order, so the heaviest domains come first. Pick a pace and the plan lays itself out.
- Week 1Solution Design and Architecture3h 20m of lessons3h 20m
- Week 2Claude Models, Prompting and Context · IntegrationPractice tests 1 and 26h 15m of lessons6h 15m
- Week 3Evaluation, Testing and OptimizationPractice test 33h 20m of lessons3h 20m
- Week 4Governance, Safety and Risk · Stakeholder Communication and LifecyclePractice tests 4 and 55h 50m of lessons5h 50m
- Week 5Developer Productivity and Operational Enablement · Exam ScenariosPractice test 6 · Schedule the exam once you clear 75% on a fresh test3h 45m of lessons3h 45m
Ready to start the CCAR-P course?
The course and the practice tests come together in one purchase, or go Pro to add 19 build-and-submit projects for this cert plus every other track on Preporato.
Course + practice tests
Lifetime access: pay once, study forever
- 54 interactive lessons with checkpoints
- 6 full-length practice tests
- 378+ exam-style questions
- Detailed explanations for every answer
- Exam mode & learning mode
- ×No hands-on labs
Preporato Pro
Billed monthly, cancel anytime
- 19 build-and-submit projects for CCAR-P, graded instantly
- Every course and practice test across every certification
- GPU sandboxes and hosted environments
- Flashcards, study guides and articles
- Cancel anytime, no contract
CCAR-P course + practice tests
from$19.99course + tests