What this CCAR-P guide is sure about
A verification ledger for this course: which claims come from the official CCAR-P exam guide, which this guide refuses to make, and what to re-check yourself.
On this page
What you will be able to do
- Separate the exam facts taken from the official CCAR-P exam guide from the technical material checked against product documentation
- Explain why this guide publishes no raw pass percentage and no per-domain item counts
- Recognise that this guide states no out-of-scope list, and know where to look for one
- Name the topics in this course that are version-sensitive and know what to re-check for each
- Use the exam guide and the official documentation as the authorities this guide defers to
A study guide that never says where its confidence runs out is asking to be trusted uniformly, and no guide has earned that. You are about to pay a fee, book a proctored slot and spend several weeks on this material, so it is reasonable to want the ledger: what was checked and against what, what has been left unstated on purpose, and what has probably moved since it was written. This is the least interesting lesson in the course and the one most worth reading before you lean on the rest of it.
It matters more at Professional than at Foundations. This exam asks which design you would defend, and a defence rests on specifics: a field name, a default, a price, a limit. Specifics are exactly what goes stale.
What is verified, and from where
Two kinds of claim run through this course, and they have different provenance.
- Primary source
The document a claim originates from, rather than a restatement of it. For the exam facts here that is the official CCAR-P exam guide; for the technical material it is the product documentation. A blog post, a conference talk or another study guide is a secondary source, however confident it sounds.
The exam facts come from the official CCAR-P exam guide published by the Claude Certification Program. That covers the exam code, the 63 items, the format of multiple-choice and multiple-response with every item stating how many responses to select, the 120-minute limit, proctored delivery online or at a test centre, the pass mark of a scaled 720 on a 100-1,000 scale, the 175 USD fee, the 12-month validity, reporting as pass or fail with a scaled score plus percent-correct by domain, the seven domain weights of 17, 13, 19, 16, 14, 14 and 7 per cent, the absence of prerequisites, the retake waiting periods and the renewal path. None of that is inferred, and all of it is subject to change without notice, which the exam guide says of itself.
The technical material was checked against the official documentation at docs.claude.com and code.claude.com, covering the Claude Application Programming Interface (API), the Claude Agent SDK, Claude Code, Managed Agents and Model Context Protocol. Parameter names, response fields, beta identifiers, configuration paths and command flags were verified there rather than written from memory or carried across from third-party material.
What this guide deliberately does not claim
Four things a reader reasonably wants are missing from this course on purpose. Each absence is a decision rather than an oversight, and the fourth is a gap rather than a policy, which is why it is listed here with the others.
The raw percentage needed to pass
Lesson 1 says that 720 is a scaled score rather than a percentage, and then stops. That is the whole honest answer. Scaling exists so that a score means the same thing on every form of the exam, which requires equating: a form that happens to be harder needs slightly fewer correct answers to reach 720 than an easier one does. There is therefore no single raw percentage to publish, and the programme does not publish a range either. Anyone stating the number is guessing, and the guess is unfalsifiable, because candidates never see their raw count.
How many items each domain carries
The blueprint publishes weights, not counts. Nineteen per cent of a 63-item paper is around twelve items if the weights map evenly onto items, but nothing states that they do, and some items sit plausibly in two domains at once. Where this course does that arithmetic, in the study-time allocation in lesson 1 and in the reading of a per-domain score report, it says out loud that it is arithmetic on a published weight. Treat every item count in this guide as an estimate carrying that caveat.
Which items appear on the exam
This guide contains no real exam questions. Every practice item in it was written for it from the published objectives. That is partly an integrity position, since the confidentiality agreement you accept before the session begins covers all exam content, and partly a practical one: a bank assembled from other people's memories of a rotating pool trains you to recognise phrasings that will not be in front of you.
A list of what is out of scope
The Foundations exam guide closes with an explicit out-of-scope list, and the Foundations course in this library reproduces it, because knowing what to stop studying is the most useful planning fact in that document. This course states no equivalent list, and the honest reason is that none was available to the people who wrote it. That is a gap in this guide rather than a claim about the exam.
The consequence for you is practical. Where the Foundations reader can rule a topic out on paper, you have to rule it out from the objective statements, and the objective statements are the safer authority anyway. If your revision plan holds an evening on something no task statement mentions, that evening is speculative whatever any study guide says. Open the current exam guide's appendices yourself before you plan around an exclusion.
What is version-sensitive, and what to re-check
This is the section to come back to. The Claude API, the Agent SDK, Claude Code, Managed Agents and Model Context Protocol (MCP) all ship frequently, and several things this course describes have already changed at least once. Each is hedged where it appears in the lessons. Collecting them here means you can check them in one sitting rather than meeting one of them mid-design.
| Topic | Why it moves | What to verify |
|---|---|---|
| Model identifiers and aliases (models and prompting, lesson 1; integration, lesson 3) | New generations arrive and old ones are retired, and a retired id returns a 404 rather than a warning | That every id in your configuration still resolves, before an upgrade window rather than during one |
| Prices, context windows and benchmark figures (models and prompting, lessons 1 and 4) | Everything numeric about a model moves, and it moves in both directions | The current pricing and models pages on the day you put a figure into a design document |
The effort value set (models and prompting, lessons 1 and 3; evaluation, lesson 5) | Values have been added across releases, and not every model accepts every one | The current list for the model you are on, before you size a cost or latency budget around a step between two values |
| Thinking defaults and when it may be disabled (models and prompting, lessons 3 and 4; evaluation, lesson 4) | The default flipped: thinking is on unless disabled on the current flagship, and disabling it is only accepted under some effort settings | Whether a route that sized max_tokens tightly still fits once thinking is counted against it |
| Beta headers (models and prompting, lessons 4 and 5; evaluation, lesson 5) | A beta either graduates and stops needing its header, or is superseded and stops accepting it | Whether the header a lesson names is still required, still accepted, or now an error |
| Date-stamped strategy and tool identifiers (models and prompting, lesson 4; integration, lesson 1) | The names carry a release date by construction, so a newer one exists the moment the behaviour changes | The identifier your account is entitled to, rather than the dated one in a lesson |
| Prompt cache constants (models and prompting, lesson 5; integration, lesson 3) | Breakpoint counts, minimum cacheable prefixes and time to live have all moved, and the minimum is not monotonic across generations | That your prefix still caches after a model change, read from the usage fields rather than assumed |
| Which tiers a cache change invalidates (models and prompting, lesson 5) | Whether the tools and system tiers survive a change of thinking or effort depends on where the model renders that configuration | The published invalidation table for your model, before planning a strategy around toggling either per request |
| MCP protocol revision and client capabilities (integration, lesson 7) | Revisions are dated and negotiated per request, and capabilities are deprecated through numbered proposals while staying in the specification | The revision your client and your server actually speak, and whether a capability you rely on is live or retained only for compatibility |
| The MCP authorisation stack (integration, lesson 2) | It is bound to specifications that revise on their own schedule, and which transports are in scope has changed | The current specification before you design a token audience, a scope failure path or a consent step |
| Claude Code settings paths and precedence (developer productivity, lesson 1) | The distribution mechanism has been stable and the installation ergonomics have not | The managed settings path for every operating system your team runs, before you promise an automatic rollout |
| Claude Code flags and slash commands (developer productivity, lessons 2 and 3) | Flags, permission modes and diagnostic commands are added and renamed with the release train | claude --help on the version your team has installed, rather than a memorised list |
| Managed Agents event and field names (integration, lessons 2 and 4; evaluation, lessons 5 and 6) | A product surface with its own release cycle, and its telemetry names are part of that surface | The current event names before you build a dashboard or an alert on one |
stop_reason and stop_details values (models and prompting, lesson 2; evaluation, lessons 1, 4 and 6) | Values are added as behaviours are added, and some fields are null for some categories | That your handler has a default branch for a reason it has never seen, and does not key on a field that can be null |
| SDK retry and timeout defaults (evaluation, lessons 1 and 6; integration, lesson 3) | Defaults differ between SDKs and change between versions of one | Your client's configured timeout and retry count, because the wall-clock ceiling is their product rather than the timeout alone |
| Inference geography and retention controls (governance and risk, lesson 4) | Availability varies by model and by deployment platform, and organisation-level settings change what you are entitled to | The provider's current documentation, in writing, before you promise a regulator or a customer anything |
Where the authority actually lives
This is an independent study guide. It was fact-checked against primary sources, that check produced findings, and the corrections are in. What it cannot do is keep pace with a set of products that ship faster than any study guide is revised, which is also why the credential itself is valid for twelve months rather than three years.
So the order of authority is worth stating plainly. The official CCAR-P exam guide is authoritative for anything about the exam: the fee, the format, the time limit, the pass mark, the weights, the retake rules. The official documentation at docs.claude.com and code.claude.com is authoritative for anything about the products. This guide organises both into something you can reason with at the end of a working day, and it is worth what a good study aid is worth, which is a lot until the moment you need the final word on a fee, a field name or a default.