What is out of scope on the CCAR-F exam
The exam guide publishes a list of topics that will not appear. Reading it is the cheapest way to save several hours of misdirected preparation.
Most exam guides tell you what is covered. This one also publishes what is not, and that list is worth more than it looks — it is the difference between twenty focused hours and thirty scattered ones.
Here is the list, with a note on why each exclusion makes sense once you see what the exam is actually testing.
The published exclusions
Fine-tuning Claude models or training custom models. The exam is about architecting systems with the models as they are. Not a gap in your knowledge if you have never fine-tuned anything.
Claude API authentication, billing, or account management. Getting a key and paying for it is not an architectural decision.
Detailed implementation in specific languages or frameworks, beyond what tool and schema configuration requires. You need to read a JSON schema and a config file. You do not need to write idiomatic anything.
Deploying or hosting MCP servers — infrastructure, networking, container orchestration. This one surprises people, because MCP is 18% of the exam. The distinction is design versus operations: how you shape a tool interface and configure server scope is in scope; where the process runs is not.
Claude's internal architecture, training process, or model weights. Nothing about transformers.
Constitutional AI, RLHF, or safety training methodology. Interesting, not tested.
Embedding models or vector database implementation. Notable given how much production RAG work involves both. The exam's context questions are about managing a context window, not about retrieval.
Computer use — browser automation, desktop interaction.
Vision and image analysis.
Streaming API implementation or server-sent events. You should know structured output through tool use; you do not need to know how tokens arrive.
Rate limiting, quotas, or API pricing calculations.
Token counting algorithms or tokenization specifics. Context management is tested. Counting tokens is not.
Prompt caching implementation details, beyond knowing it exists. Knowing it exists is enough.
OAuth, API key rotation, or authentication protocol details.
Specific cloud provider configurations — AWS, GCP, Azure.
Performance benchmarking or model comparison metrics.
What the list tells you about the exam
Read together, the exclusions describe a boundary rather than a set of arbitrary cuts. Everything on the far side of it is either infrastructure (hosting, cloud config, networking), model internals (training, weights, tokenization, safety methodology), or adjacent capability areas (vision, computer use, embeddings).
What is left is the layer in between: how you compose Claude's existing capabilities into a system that behaves reliably in production. That is what "architect" means in this credential, and the exclusions are what makes the definition precise.
It also explains why the exam feels different from a cloud certification. There is no service catalogue to memorise. The questions are about design decisions, and design decisions are exactly what remains once infrastructure and internals are ruled out.
Where people lose time anyway
Three of these catch experienced people out.
Embeddings and vector databases. If your production Claude work is mostly RAG, this is most of your day job and none of the exam. The context questions ask about token budgets, progressive summarisation, lost-in-the-middle effects and structured fact extraction — not about retrieval quality.
MCP server deployment. Having built and hosted a server, it is natural to prepare for questions about transports and process management. The exam asks about tool and resource design, description quality, server scope (project versus user), and environment variable expansion. Configuration, not operations.
Prompt caching. It is genuinely important in production, and the guide is explicit that knowing it exists is the whole requirement.
The other direction
The guide also publishes an in-scope list, and it is worth reading in the same sitting. A few items on it are more specific than the domain titles suggest — control flow driven by stop_reason, crash recovery from manifests, context: fork and allowed-tools frontmatter, nullable fields to prevent hallucinated values, failure handling by custom_id, stratified sampling for error-rate measurement.
Those are the kind of details that distinguish someone who has read about a topic from someone who has used it, which is precisely what the exam is trying to distinguish. The exam guide summary has both lists in full, and each domain page breaks the in-scope items down by task statement.