Claude Certified Architect — Foundations

• What it tests
• Who it’s for
• The format
• The five domains
• Retakes and cost
• How to prepare
• Common mistakes

What this exam actually tests

CCAR-F is an architecture exam that happens to be about Claude. That distinction matters more than it sounds, because it changes what studying looks like. The exam is not checking whether you can recall parameter names or quote documentation. It is checking whether, given a situation with competing constraints, you would choose a defensible design — and whether you understand what that design costs.

The five published domains describe a single arc: you decide how an agentic system should be structured, you configure the environment it runs in, you get reliable output out of the model, you connect it to the outside world through tools, and you keep the whole thing stable as context accumulates. That is the job of a solution architect working with Claude, and the blueprint follows it closely enough that the domain names are a usable syllabus on their own.

The single most useful reframe: most questions have more than one answer that works. You are picking the one that works given the stated constraints — latency budget, cost ceiling, failure tolerance, who maintains it. Candidates who study by memorising capabilities tend to struggle here, because the exam rarely asks what Claude can do. It asks what you should do.

Who it’s for, and what to have done first

Anthropic positions this at solution architects with roughly six months of hands-on work. In practice the useful test is whether you have built something with Claude that other people depended on — an internal tool, a pipeline, an assistant with real users. Six months of reading is not the same preparation as six weeks of shipping.

Two capability gaps are worth closing before you book. First, if you have never written a tool definition and watched Claude call it badly, the tool-design domain will be abstract to you in a way that costs marks. Second, if you have only ever used Claude through a chat interface, the configuration and orchestration domains — nearly half the exam between them — will feel like trivia rather than experience. Both gaps close in a weekend of building.

CCAR-F sits below CCAR-P, the Professional architect exam, which returns to standalone items across seven domains and adds governance, stakeholder communication and operational enablement. If you are choosing between them, the Foundations exam is the right entry point unless you have several years of systems architecture behind you.

The format, and why it is unusual

This is the part most candidates under-prepare for. CCAR-F is scenario-based: rather than sixty unrelated questions, you work through four scenarios drawn from a pool of six possible situations, each carrying a cluster of related items. The sixty items and the hundred and twenty minutes are the same numbers you would see on a standalone exam. How they feel is not.

Three consequences follow, and all three are worth rehearsing:

• Misreading a scenario is expensive. On a standalone exam a misunderstanding costs you one item. Here it can cost you a cluster, because every item in the group inherits the same premise. Read the setup twice before answering anything in it.
• Time is lumpy. Two minutes per item is the average, not the shape. The first item in a scenario costs you the reading; the rest are quicker. Plan around thirty minutes per scenario and treat that as a hard checkpoint rather than a guideline.
• Constraints carry forward. A latency ceiling or a compliance requirement stated in the setup usually applies to every item beneath it. The answer that would be right in isolation is often wrong under the scenario’s constraint, and that is precisely what is being tested.

Items are multiple-choice and multiple-response, and each one tells you how many responses to select — so a question asking for two answers is not a trick, it is labelled.

Scoring is scaled, 100 to 1,000, with 720 to pass — the same bar across all four Claude certifications. Your score report also gives percent-correct by domain, and Anthropic is explicit that those section percentages are informational: the pass decision rests on the total scaled score alone. Do not read that as licence to skip a domain, though. At 27% of the paper, Agentic Architecture & Orchestration is large enough that abandoning it makes the arithmetic uncomfortable.

The six scenarios are published

This is the detail most candidates miss, and it is in the exam guide. The bank of six is listed in full, along with the domains each one draws on. Four of them appear on your sitting:

• Customer support resolution agent — Agent SDK, high-ambiguity requests, MCP tools for backend systems, knowing when to escalate
• Code generation with Claude Code — custom slash commands, CLAUDE.md configuration, plan mode versus direct execution
• Multi-agent research system — a coordinator delegating to search, analysis, synthesis and reporting subagents
• Developer productivity tooling — exploring unfamiliar codebases with built-in tools and MCP servers
• Claude Code for continuous integration — automated review, test generation, minimising false positives on pull requests
• Structured data extraction — JSON schema validation, edge cases, integration with downstream systems

Read all six before you sit. Not to memorise them — the items are what you have not seen — but because arriving with the production context already familiar means the reading time on each scenario buys you constraints rather than orientation.

The five domains, and what each is really asking

The weightings below are Anthropic’s own, shown in full in the table above this section. What follows is an interpretation of what each domain covers in practice — useful for planning study time, but not a claim about the item pool.

Agentic Architecture & Orchestration — 27%

The largest domain, and the one that most rewards having built something. It is about structure: when a single well-prompted call beats a multi-step agent, when to decompose work across subagents, how control flows between them, and where state lives. Expect to weigh autonomy against predictability — a loop that can retry indefinitely is powerful and is also how you get an unbounded bill.

Study by designing, not reading. Take a workflow you know and sketch it three ways: one call, a fixed pipeline, and an agent with tools. Write down what each costs, how each fails, and which you would defend to someone paying for it. That exercise is close to what the exam asks.

Claude Code Configuration & Workflows — 20%

Roughly twelve items on how Claude Code is set up and used in a real project — the configuration surface, how instructions and context are supplied to it, how it fits into an existing engineering workflow, and what changes when more than one person relies on it.

This is the domain most often skipped by architects who do not use the tool daily, and the cheapest to fix. A week of genuinely working in it, including the configuration you would normally leave at defaults, covers most of the ground.

Prompt Engineering & Structured Output — 20%

Another twelve or so items, and easy to misjudge. The framing is architectural: how you get output a downstream system can rely on, what you do when it does not conform, and how much of reliability belongs in the prompt versus in validation around it.

The reliability angle is the one to prepare. A design that assumes well-formed output and has no answer for the day it is not is the wrong answer, regardless of how good the prompt is.

Tool Design & MCP Integration — 18%

Around eleven items on connecting Claude to systems it does not contain: how a tool should be described so it is called correctly and at the right moment, what belongs in a tool versus in the prompt, error and permission boundaries, and where MCP fits as the integration layer.

The recurring theme is that tool design is interface design. A tool with a vague description and overlapping responsibilities gets called wrongly, and the fix is almost always in the definition rather than in more instructions.

Context Management & Reliability — 15%

The smallest domain and, for people who have only built demos, often the least familiar. It covers what happens as context accumulates: what to keep, what to summarise, what to retrieve on demand, and how a system behaves at the edges rather than in the happy path.

Nine items is not many, but this domain is disproportionately about judgement, and it is where production experience is most visible. If you have ever had something degrade over a long session, you already know most of it.

Retakes, validity and what it costs

The retake ladder is steep and worth knowing before you book rather than after: fourteen days after a first failed attempt, thirty after a second, ninety after a third, with a maximum of four attempts in any rolling twelve months. Retakes are full price. A rushed first attempt can therefore cost you a fortnight of momentum on top of the fee.

The certification is valid for twelve months — short compared with most cloud credentials, which run two or three years. Renewal is a free non-proctored assessment, but letting it lapse means a full-price retake of the proctored exam. Put the expiry in a calendar the day you pass.

One thing that changes the maths for a lot of candidates: partner-tier discounts run to 50%, and Global Premier partners have had the exam free through the end of 2026. If your employer is an Anthropic partner, check before you pay. It is a common reason people discover the exam cost them nothing.

A four-week preparation plan

This assumes six to eight hours a week and some existing hands-on experience. Compress it if you build with Claude daily; extend it if the tool-design or Claude Code domains are new to you.

• Week 1 — close the build gap. Ship one small agentic system end to end: at least two tools, real error handling, and something that persists between calls. The point is not the artefact, it is that four of the five domains stop being abstract.
• Week 2 — the two large domains. Orchestration and Claude Code are 47% of the paper between them. Work through configuration deliberately, and do the three-designs exercise from the orchestration section above on two different workflows.
• Week 3 — structured output, tools, context. Concentrate on failure modes: malformed output, a tool called at the wrong time, a session that degrades as it grows. Being able to name the failure is most of being able to answer the question.
• Week 4 — rehearse the format. Practise reading a dense scenario and extracting its constraints before looking at any question. Then sit a full timed run. Pacing is a real risk on this exam and it is the cheapest thing to fix.

Three things candidates get wrong

Studying capabilities instead of trade-offs. Knowing what Claude can do is the entry ticket, not the exam. Almost every question has a technically workable answer that is wrong for the constraints given. If your preparation never involves rejecting a design that would work, you are preparing for a different exam.

Treating it as sixty separate questions. It is four scenarios. Candidates who answer item by item without holding the scenario’s constraints in mind lose marks in clusters, and usually cannot tell afterwards which cluster it was.

Trusting a free question bank without checking it. There is a large supply of free CCAR-F practice questions, generated in bulk, with no stated review process and no source for any answer. Practising against a confidently wrong explanation is worse than not practising, because you will defend the wrong answer in the exam with conviction. Whatever you use — including this site when its mock exams exist — check that each answer cites something you can go and read.

What Rubric will have for this exam

Mock exams built to the five published weightings, in the scenario format rather than as standalone items, with every answer citing the documentation it rests on and carrying the date it was last checked against the blueprint. Results report per domain, so a score tells you what to study next rather than just how you did.

None of that exists yet — this page is the blueprint, published early because it is useful on its own. The exams follow.