What this guide is sure about
A verification ledger for this course: which claims come from the official exam guide, which claims this guide deliberately refuses to make, and which topics move with the products and need re-checking against your own installed version.
On this page
On this page
- What is verified, and from where
- What the exam guide rules out
- What this course did about it, after the fact
- What this guide deliberately does not claim
- The raw percentage needed to pass
- How many items each domain carries
- Which items appear on the exam
- What is version-sensitive, and what to re-check
- Where the authority actually lives
What you will be able to do
- Separate the exam facts taken from the official 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
- Recall what the exam guide's published out-of-scope list rules out, and why exclusion is not the same as irrelevance
- 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 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.
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-F exam guide; for the technical material it is the product documentation. A blog post, a forum thread or another study guide is a secondary source, however confident it sounds.
The exam facts come from the official CCAR-F exam guide published by the Claude Certification Program. That covers the exam code, the 60 items, the format of multiple-choice and multiple-response with every item stating how many responses to select, the structure of 4 scenarios drawn from a bank of 6, the 120-minute limit, proctored delivery, the pass mark of a scaled 720 on a 100-1,000 scale, the 125 USD fee, the 12-month validity, reporting as pass or fail with a scaled score plus percent-correct by domain, the five domain weights of 27, 18, 20, 20 and 15 per cent, and the published primary-domain mapping for each of the six scenarios reproduced in lesson 2. 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 and Model Context Protocol. Tool names, hook events, configuration fields, flags and file locations were verified there rather than written from memory or carried across from third-party material.
What the exam guide rules out
Most blueprints tell you what is on the exam and leave the boundary to inference. This one does not. The exam guide closes with an explicit out-of-scope list: topics stated as not appearing on the paper. It is the most useful planning fact in the document, because every other page tells you what to study and this one tells you what to stop studying.
Grouped by the kind of thing being excluded, rather than left as a wall of items:
| Kind | Excluded, as published |
|---|---|
| How the model is made | Claude's internal architecture, training process and weights; Constitutional Artificial Intelligence (AI), Reinforcement Learning from Human Feedback (RLHF) and safety training methodology; fine-tuning or training custom models |
| Modalities and transport | Computer use; vision and image analysis; streaming and server-sent events |
| Accounts and platform plumbing | Claude API authentication, billing and account management; OAuth, API key rotation and authentication protocol details; rate limiting, quotas and pricing calculations; specific cloud provider configuration; deploying or hosting Model Context Protocol (MCP) servers |
| Measurement and internals | Performance benchmarking and model comparison metrics; token counting algorithms and tokenisation specifics; prompt caching implementation details beyond knowing it exists |
| Retrieval machinery | Embedding models and vector database implementation details |
| Language and framework detail | Detailed implementation of specific programming languages or frameworks, beyond tool and schema configuration |
Several of those entries exclude a depth rather than a subject, and the difference is worth reading carefully. MCP servers are squarely in scope: integrating one into Claude Code, scoping it and configuring it is most of Domain 2. What is excluded is deploying and hosting one. Tool and schema configuration is in scope whatever language you write it in, and what is excluded is the framework-specific implementation underneath. Prompt caching carries its own boundary in the guide's wording, which permits knowing that it exists and excludes the mechanics.
The practical consequence is direct. If your revision plan holds an evening on cache lifetimes and breakpoints, an evening on how a tokeniser splits a string, an afternoon on cosine similarity and chunk overlap, an hour of authentication flow diagrams, or a table of benchmark figures by model, that time is buying you nothing an item is allowed to ask for. The 33 task statements are where it should go instead.
What this course did about it, after the fact
This lesson is the ledger, so the sequence should be on the record. The course was written before the appendix carrying that list was recovered, and the whole build therefore proceeded without it. Once it surfaced, every lesson, practice item and card was audited against it. The finding was small: the course had crossed the boundary in a handful of places, all of them prompt caching mechanics mentioned in passing, and that detail has been trimmed. A closing note on batch processing lost its cache durations, and a note on which cached blocks a change of tool choice invalidates has gone from a lesson and from a card that was drilling it on repeat. No answer key changed, and nothing in scope was removed to make room.
What this guide deliberately does not claim
Three numbers that a reader reasonably wants are missing from this course on purpose. Each absence is a decision rather than an oversight.
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. Twenty-seven per cent of a 60-item paper is around sixteen items if the weights map evenly, but nothing states that they do, and the scenario structure gives an obvious reason they might not: drawing four scenarios from six means the domain mix of your particular paper depends on which four you are given.
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 weight rather than a published count. 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. That is partly an integrity position, since reconstructing live items from candidate recall breaches the agreement you sign before you sit, 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.
What is version-sensitive, and what to re-check
This is the section to come back to. Claude Code, the Agent SDK and MCP ship frequently, and several things this course describes have already changed at least once. Each of these 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-question.
| Topic | Why it moves | What to verify |
|---|---|---|
| Subagent-spawning tool name (agentic architecture, lesson 3) | Renamed from Task to Agent in Claude Code v2.1.63, and some surfaces still report the older name | What your version emits. If you match the name in code, match both |
| Post-tool hook output (agentic architecture, lesson 5) | The SDK returns hook decisions in hookSpecificOutput, where updatedToolOutput replaces a result and additionalContext appends to it. An older MCP-only replacement field is deprecated, and the events each surface exposes differ by SDK and version | Whether your surface can replace tool output at all, and under which field name, before designing a normalisation layer around it |
| Permission-mode values (Claude Code workflows lesson 4, agentic architecture lesson 3) | The set of modes has grown across releases and the labels have moved. plan has been stable; the mode that denies outright rather than prompting has not | claude --help on your installed version instead of a memorised list |
| Read before edit (tool design, lesson 5) | Enforcement relaxed recently and now depends on the model as well as the version. Newer models can edit an unread file where reading it would not have prompted, and a plain cat or grep can count as the read | Whether the strict form still applies to the model and version you run |
| MCP tool search (tool design, lessons 3 and 4) | Claude Code now defers MCP tool definitions behind tool search by default, so an extra server costs little context at session start. It can be switched off, and some configurations do not support it | Whether deferral is active before you reason about what one more server costs. What remains is selection pressure, not context |
| Subagent state (agentic architecture, lesson 3) | Recent SDK versions let a subagent be resumed inside a session, keeping its history, and let an agent definition name a memory source. Prompt-only isolation is the default, not a hard limit | What your version offers, before designing either around the isolation or against it |
| Subagent execution default (agentic architecture, lesson 3) | Recent versions run subagents in the background by default and mark an invocation foreground when the result is needed first. Earlier versions ran them synchronously | Which your version does, if ordering matters to your orchestration |
| Built-in tool names outside Claude Code (tool design, lesson 5) | Managed Agents exposes an equivalent prebuilt toolset under a dated type identifier, with lower-case tool names | The current type string rather than a dated suffix from memory |
| Context controls (context and reliability, lesson 2) | /compact, /autocompact and /context have gained options over time | The exact flags in your installed build |
| Skill and command frontmatter (Claude Code workflows, lesson 2) | The field set grows with releases | The frontmatter reference for your version rather than assuming a published list is complete |
The Workflow tool (agentic architecture, lesson 6) | Present in recent TypeScript Agent SDK versions | Availability in your SDK before designing orchestration around it |
| Fork isolation and checkpointing (agentic architecture, lesson 7) | The mechanism for snapshotting and reverting an agent's file changes has moved between releases | Which mechanism your version offers, before trusting it to make a writing fork safe |
| CLAUDE.md locations and command names (Claude Code workflows, lesson 1) | Claude Code ships often, and paths and command names change with it | /memory and your version's documentation rather than a path you memorised |
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 four products that ship faster than any study guide is revised.
So the order of authority is worth stating plainly. The official CCAR-F exam guide is authoritative for anything about the exam: the fee, the format, the time limit, the pass mark, the weights. The official documentation at docs.claude.com and code.claude.com is authoritative for anything about the products. This guide is a study aid that 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 flag or a field name.