Claude Certified Architect – Foundations (CCAR-F): the full prep pack

You are sitting Claude Certified Architect – Foundations, exam code CCAR-F, governed by Exam Guide Version 1.0, effective July 2026⁴. That is the only guide that matters for this pack. It is not the same credential as Claude Certified Architect – Professional (CCAR-P), a separate Version 1.0 guide, also published July 2026, with seven broader domains and Integration as the largest at 19%⁶. If a study resource mixes the two blueprints, it is wrong for your exam. This module gives you the blueprint, the delivery mechanics, and — deliberately — the boundary between what Anthropic has actually published and what third-party prep sites are reporting on Anthropic's behalf.

Delivery: every CCAR-F exam is proctored and delivered through Pearson Professional Assessments, via OnVUE for remote proctoring¹². Registration runs through the Anthropic Partner Academy on Skilljar; passing candidates receive a digital badge through Credly by Pearson¹². Eligibility is gated: exams are available only to members of the Claude Partner Network, and firms join for free at claude.com/partners¹. If your organization has not joined the network, you cannot register regardless of how well you know the material — confirm partner-network membership before you plan a study schedule around a fixed date.

Retakes, per Pearson VUE's program page: a failed attempt gets a 14-day wait before attempt two, a 30-day wait before attempt three, a 90-day wait before attempt four, with a hard cap of 4 attempts per exam in any rolling 12-month period². Plan around this: if you fail close to your deadline, the 14-day minimum wait may push you past it. Register early enough that a first failure still leaves room for one retake before any hard deadline your employer has set.

Domain 1, Agentic Architecture & Orchestration, is worth 27% of the CCAR-F exam — the largest single domain⁴. The published exam guide gives that 27% as a single weight with no internal breakdown between mechanics and orchestration⁴. This pack splits Domain 1 into two modules as a teaching device: this module covers the mechanics — can you trace what happens, in order, inside one turn of a Claude agent loop, and can you name precisely what makes it stop. The next module (Domain 1b) covers the judgment side — orchestration patterns and subagents. Get the mechanics wrong here and every scenario question that builds on them — tool design, context management, escalation — collapses with it.

The single fact the exam leans on hardest: Claude decides, your code executes. Claude's output is a request — a tool_use block naming a tool and its input — never an executed side effect¹¹¹². Whether that tool call actually happens client-side (in your app process) or server-side (via a hosted connector such as the MCP connector¹³) is an architecture decision you make, not something the model controls. That means every failure mode candidates think of as 'the model's problem' — a timeout, a retry storm, a hung external call, a malformed error message — is actually a decision your system made about how to execute and how to report back. A scenario that describes 'the agent kept calling the same tool forever' is not a model bug; it is a missing terminal condition in your loop code.

This module covers the second half of Domain 1, Agentic Architecture & Orchestration, the single largest domain at 27% of the Foundations exam⁴. The exam guide names multi-agent orchestration, coordinator/subagent patterns, and explicit context passing as in-scope task statements⁴. The claim to internalize: the exam rewards the smallest architecture that satisfies the requirement, not the most impressive one. A scenario stem that can be solved with a deterministic chain and gets solved with a five-agent swarm is a wrong answer waiting to be picked, and the exam is built to tempt exactly that choice.

Anthropic's own engineering guide, Building Effective AI Agents (19 Dec 2024), is the spine for this material¹⁰. It draws a hard line between workflows, where the LLM and tools are orchestrated through predefined code paths, and agents, where the LLM directs its own process and tool use. Five patterns recur on the exam: prompt chaining (sequential steps, each checked before the next), routing (classify then dispatch to a specialized path), parallelization in its two forms — sectioning (split independent subtasks) and voting (run the same task multiple times and aggregate) — orchestrator-workers, and evaluator-optimizer (one model generates, another critiques and sends back for revision). The orchestrator-workers pattern is the one most often confused with a general multi-agent system: 'a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results'¹⁰. The distinguishing feature is that the orchestrator decides the subtasks at runtime, unlike parallelization where subtasks are fixed in advance.

The load-bearing idea for this module is a design principle from Anthropic's context-engineering guidance: subagent architectures do their work in a separate context and return distilled results rather than full transcripts¹⁹. The pattern is that the coordinator constructs and passes a curated brief — the subtask goal, the relevant constraints, and the expected output shape — and the subagent hands back a condensed result, not its complete working transcript¹⁹. This is why subagent architectures protect the parent's context budget: work that would otherwise fill the coordinator's window with intermediate tool calls, retries, and scratch reasoning instead happens in a separate side context, and only the distilled output crosses back. The exam guide names this explicitly as a tested objective — explicit context passing between coordinator and subagents⁴ — so a correct answer about subagent design almost always names both halves of the exchange: what goes in (curated brief) and what comes out (condensed result). A wrong answer either assumes shared memory between coordinator and subagent, or has the subagent return its raw transcript, both of which defeat the purpose of delegating in the first place.

Claude Code Configuration & Workflows is 20% of the CCAR-F blueprint⁴ — tied with Prompt Engineering as the second-largest domain, just behind Agentic Architecture at 27%. Plinth Prep, writing 27 July 2026, calls this "the weighting that most surprises people and the one most often left out of study plans built from general Claude API knowledge"⁷. The reason is simple: candidates who learn Claude through the Messages API treat Claude Code as a developer convenience tool, not an architecture surface. That instinct is expensive⁷. This module treats Claude Code configuration as a design decision — where a rule lives, who inherits it, and how a session becomes a scripted CI/CD step.

Anthropic's own documentation states that CLAUDE.md files "can live in several locations, each with a different scope"¹⁴: managed, user, project, local, directory-level, imported, and path-scoped instructions. The exam does not test the list — it tests whether you can place a given rule in the scope that gets it to the right audience, and no further. That is the design question underneath every Domain 3 scenario: who must inherit this, and who must not.

The CLI reference documents -p/--print as printing a response without interactive mode¹⁵ — the mechanism that turns Claude Code from an interactive assistant into a scripted step. Combined with a structured output format, this is the pattern the exam expects for CI/CD: a headless invocation, a machine-parseable result, and a pass/fail gate downstream. The exam guide names Claude Code configuration and CI/CD explicitly as in-scope objectives⁴, so expect scenarios framed as "a team wants Claude to run as part of the build" rather than "a developer wants to chat with Claude." Skills configuration and plan mode are also named in-scope topics⁴: skills package reusable capability into something Claude can invoke deliberately, and plan mode forces a proposed plan before any action executes — useful when a scenario calls for review before changes land, as opposed to full autonomy.

Domain 4 is 20% of the CCAR-F blueprint⁴ and it is not a writing test. The exam is scoring whether you can force output that a downstream system, a tool call, or a human can rely on without a second pass. That means the real skill is choosing the right mechanism — plain instructions, a JSON schema constraint, or strict tool use — for a stated consumer, and knowing when a batch run beats an interactive one. Get the mechanism wrong and no amount of prompt polish saves the answer.

The instruction-and-example layer still matters, because most of what Claude produces — reasoning traces, draft content, tool-triggering language — is read by a person or feeds a prompt-only pipeline, not a schema. Anthropic's guidance is specific: give explicit instructions rather than implying what you want, and use few-shot examples because they are 'one of the most reliable ways to steer Claude's output format, tone, and structure'¹⁶. For long-context prompts, structure matters as much as content — organize with XML tags to separate instructions, reference material, and examples, and place long documents before the final instruction so the model reads context before task. This placement discipline is exam-relevant because Domain 4 questions describe long prompts with buried instructions and ask what is wrong with them.

Structured outputs move the contract from language to schema. They 'constrain Claude's responses to follow a specific schema, ensuring valid, parseable output for downstream processing'¹⁷, and the SDK can validate and parse the result directly rather than the caller writing a brittle JSON.parse-and-hope layer. Strict tool use is the same idea applied to tool calls: when an agent must invoke a function, the tool's parameter schema — not a prompt reminder — is what should guarantee valid arguments. Domain 2 covers tool schema design; Domain 4 tests whether you know to use schema enforcement over prompt instruction when the exam scenario says a system, not a person, consumes the result.

Batch processing is explicitly in scope⁴ as an execution-mode decision, not a formatting technique. The signal to pick batch over a normal interactive call is: the work is non-interactive (no user is waiting on a live response), volume is high, and latency per item does not matter — for example, scoring thousands of stored support tickets overnight versus answering one live chat message. The exam question shape is usually 'which of these workloads should run as batch,' testing recognition of throughput-over-latency workloads, not batch mechanics.

Domain 2 is 18% of the CCAR-F blueprint⁴, and almost every question in it reduces to one sentence from Anthropic's own docs: "Claude determines when to call a tool based on the user's request and the tool's description"¹². There is no hidden classifier deciding which tool fires. The model reads the tool's name, description, and parameter schema at inference time and reasons about fit, exactly the way it reasons about a sentence in your prompt. That means a badly written tool description is not a cosmetic problem — it is a routing bug. If two tools plausibly cover the same request, or a description is vague about scope, the model will sometimes pick wrong, and no amount of system-prompt scolding fixes a tool interface that does not disambiguate itself.

The practical discipline: one tool, one clear responsibility. get_weather should not also handle unit conversion and travel alerts. Names should be unambiguous verbs plus nouns (search_orders, not handle_request). Descriptions should state not just what the tool does but when it applies and, often, when it does not — "use this only for orders placed in the last 90 days; for older orders use search_archive" removes an entire class of misselection. Parameters should mark what is required versus optional explicitly, and any parameter with a small fixed set of legal values should be an enum, not free text — an enum for priority: ["low","medium","high"] cannot be misspelled or invented by the model the way a free-text string can.

Description and schema quality is the first control. tool_choice and strict tool use are the second, and they are enforcement rather than persuasion¹². tool_choice lets you force Claude to use a specific tool, any tool, or none, instead of leaving the decision purely to the description — useful when a workflow step must always call a tool (e.g., logging) regardless of how the request reads. Strict tool use constrains the model's output to validate against the schema before you ever try to execute it, which matters for exam scenarios about reliability: a malformed tool call caught at the schema boundary is cheaper to handle than one that fails deep inside your business logic. Expect the exam to test whether you'd reach for a better description, a tighter schema, tool_choice, or a workflow redesign, given a described misselection symptom — description and schema come first because they are also what MCP tool consumers see, and mistakes there propagate across every agent using that server.

The Professional exam guide names the trade-off explicitly as capability bloat⁶, and Foundations tests the same idea without the label. Every additional tool definition placed in the context window costs tokens and raises misselection risk: with ten similar-looking tools available, the model has ten more ways to guess wrong versus a scenario with two. This is why "connect the MCP server" is rarely the complete correct answer on its own — connecting an MCP server that exposes twenty tools when the agent's task needs two is functionally the same mistake as writing one bloated tool that tries to do everything. The correct pattern pairs the connector's allowlist/denylist mechanism¹³ with the same one-tool-one-responsibility discipline used for custom tools: scope exposure to exactly what the task requires, and use per-tool configs to adjust behavior for a specific agent without touching the shared server²⁰.

Context Management & Reliability is 15% of the CCAR-F blueprint, the smallest domain⁴. Treat that number as a scheduling weight, not a difficulty rating. Plinth Prep's guidance is blunt about this: 'abandoning Context & Reliability... costs you more than the margin between a comfortable pass and a fail,' and 'weight is not difficulty'⁷. This domain rewards mechanical precision — knowing exactly what accumulates in a context window, in what order you fix it, and who signs off when the agent can't decide alone. Get the sequencing wrong on a scenario question and you'll pick a plausible-sounding wrong answer even if you know all the vocabulary.

The mechanical detail the exam wants: what accumulates. Tool-result accumulation is the usual culprit — every tool call appends its full result back into the conversation, and in a long agentic loop those results compound fast¹⁸. Thinking-token accounting matters too: extended thinking consumes budget that counts against the same context, so an architect has to plan for it rather than treat it as free¹⁸. Anthropic's documentation also names context editing and overflow behavior as things to design for explicitly, not react to after the fact¹⁸. Two topics the guide places inside this domain rather than treating as their own scored areas deserve a clear statement: human review and information provenance are both explicitly in-scope⁴. In practice that means an architect must design where a human checkpoint sits — before an irreversible action, after a low-confidence output, or on escalation — and must be able to say where a claim in the agent's output came from and who is accountable for approving it. Provenance is not a compliance afterthought here; it is tested as part of designing a reliable system.

Anthropic's own scope statement says the exam validates whether a candidate can make "informed decisions about tradeoffs when implementing real-world solutions with Claude"⁵. That is not a knowledge test, it is a judgment test dressed as multiple choice. Plinth Prep's July 27, 2026 guidance is blunt about the mechanics behind that: "the questions are scenario-based, so a single question routinely sits across two or three domains"⁷. A stem about a customer-support agent might simultaneously test Domain 1 (does it need a coordinator or a single loop), Domain 2 (are the tool schemas tight enough), and Domain 5 (what happens when the transcript grows past the window). If your last two weeks of study are still organized as five separate binders, you will know each fact and still miss the question, because the question is asking which fact governs given a stated constraint. This module is about the last third of preparation: not learning more, but learning to read the stem, locate the constraint, and answer inside the published scope⁴.

A repeatable four-step read for any scenario stem:

1. Find the constraint. Every stem names one: a latency budget, a cost ceiling, an audit requirement, a team-scale problem, a schema requirement downstream. Underline it mentally before reading the options.
2. Assign the owning domain. Use the constraint-to-domain map above as a first pass. Most constraints map cleanly to one domain even when the scenario touches three.
3. Eliminate out-of-scope options. Cross out anything that requires fine-tuning, model internals, billing mechanics, or infrastructure hosting — those are excluded by the guide⁴, so they cannot be the intended answer regardless of how plausible they sound.
4. Choose the smallest architecture that satisfies the constraint. The exam rewards minimalism: a single agentic loop over a multi-agent system if the loop meets the requirement, a tightened tool schema over a new orchestration layer, compaction over a wholesale redesign. This mirrors the "tradeoffs" framing Anthropic uses to describe the certification⁵.

From 7 September 2026 to 5 October 2026 you have 28 days. At 45 minutes a day that is 21 hours. That is enough to cover all five CCAR-F domains once at working depth and rehearse mixed timed scenarios twice. It is not enough to read every Anthropic documentation page linked in this pack end to end. So the plan below spends minutes in proportion to the published domain weights and treats reading as a means to answering, not an end. The sessions scheduled in this pack structure only part of that 21-hour budget; the remainder is your own reading of the linked documentation and your own timed mixed-practice runs, done on the schedule below.

The weights are the allocation key: Agentic Architecture & Orchestration 27%, Claude Code Configuration & Workflows 20%, Prompt Engineering & Structured Output 20%, Tool Design & MCP Integration 18%, Context Management & Reliability 15%⁴. Convert those to minutes and the argument about "what should I study tonight" disappears.

The 30% carved out for mixed practice is the part people delete first and regret. Plinth Prep's July 2026 guidance is blunt: studying domain by domain organises coverage but rehearses the wrong thing, because the paper is scenario-based and one stem routinely sits across two or three domains⁷. If you only ever answer questions immediately after reading the matching page, you are practising retrieval with the domain label already given to you. The exam does not give you the label.

Second allocation rule: weight is not difficulty⁷. Context Management & Reliability is the smallest domain at 15%⁴, but its content is mechanical — context rot, tool-result accumulation, compaction, just-in-time retrieval¹⁸¹⁹ — and mechanical detail is cheap to learn and expensive to guess. Do not zero it out. Equally, do not assume the 27% domain needs 27% of your effort; if you already build agent loops for a living, buy time back there and spend it on Claude Code.

What to cut when you fall behind, in this order. First, deep reading of Building Effective AI Agents beyond the named patterns. You need to recognise prompt chaining, routing, parallelisation, orchestrator-workers and evaluator-optimizer, and to say when a workflow beats an agent — the orchestrator-workers definition (a central model decomposes, delegates to workers, synthesises results) is the load-bearing sentence¹⁰. The essay's longer discussion of agent economics is worth your time as an architect and not worth your last week as a candidate.

Second, anything on the guide's out-of-scope list: fine-tuning and custom-model training, API authentication/billing/account management, MCP-server hosting infrastructure, model internals and weights, Constitutional AI and RLHF training methods, embeddings and vector-database implementation, computer use, vision, streaming implementation, and rate limits/quotas/pricing calculations⁴. Every minute spent there is a minute stolen from a scored domain — and, usefully, recognising these topics inside an answer option is a fast way to eliminate a distractor.

Third, do not build a study track for retrieval-augmented generation or responsible AI as if they were CCAR-F domains. On the Foundations blueprint retrieval lives inside context management and safety lives inside agent design constraints; there is no separate RAG domain and no separate responsible-AI domain⁷. Those enterprise concerns belong to the separate Professional exam (CCAR-P), whose Version 1.0 guide became effective in July 2026 with Integration at 19% and a dedicated Governance, Safety & Risk Management domain at 14%⁶. Studying CCAR-P material for a CCAR-F sitting is a common and costly category error.

What never to cut. The 30% mixed-practice reserve, and the final two days of error-log review. Coverage without rehearsal is how well-read candidates fail scenario papers⁷.

This 50-question set mirrors the CCAR-F Version 1.0 blueprint proportions (effective July 2026): Agentic Architecture & Orchestration 27% (14 questions here), Claude Code Configuration & Workflows 20% (10), Prompt Engineering & Structured Output 20% (10), Tool Design & MCP Integration 18% (9), Context Management & Reliability 15% (7)⁴. The real exam is 60 scenario-based questions in 120 minutes with a reported passing score around 720/1000 per third-party prep guidance, not an Anthropic-published figure⁷. Score yourself by domain, not just overall: a domain-level miss rate above 30% means that domain needs another study pass before you schedule, regardless of your total. Treat every wrong answer as a diagnostic — re-read the relevant objective in the official guide⁴, not just the explanation here, before moving on.

Read this in the lobby. Everything here is in the modules with its source; this is the version you can hold in your head.

22 sources back this pack. Grades: Live (checked this week, unchanged), Current-ish (checked within a month), Dated (older or unchecked), Frozen (pinned filing or PDF), Dead (two failed checks).