I recently passed the Claude Certified Architect – Foundations exam. It's required for engineers at work, so taking it was never really optional, but I went in wanting more than a pass. I build with Claude every day, and I wanted to know how much of that everyday knowledge would hold up when someone else wrote the questions.
This post covers how I prepared, what caught me off guard on exam day, and what I'd focus on if I were starting again. If you're about to sit it, I hope it saves you some guessing.
What the exam actually is
The exam is 60 questions in 120 minutes, and you need a scaled score of 720 out of 1,000 to pass. Some questions have a single answer and some ask you to pick two or three, and each one tells you how many to choose. The fee is $125, and the credential is valid for 12 months.
What makes it interesting is that nothing is asked in the abstract. Every question sits inside a realistic scenario, like a customer support agent, a multi-agent research pipeline, Claude Code running in CI, or a system that pulls structured data out of messy documents. Your exam draws four of these scenarios from a bank of six, so you won't know in advance which ones you'll get.
The content is split across five domains. Agentic architecture and orchestration carries the most weight at 27%, followed by Claude Code configuration and prompt engineering with structured output at 20% each, tool design and MCP at 18%, and context management and reliability at 15%. The official exam guide lists every task statement under each domain, and I'd treat it as the syllabus, because it really is one.
How I prepared: patterns, not cramming
Years ago I prepared for coding interviews with the Grokking approach. Instead of memorising solutions to hundreds of problems, you learn a small set of patterns and train yourself to recognise which one a problem is asking for. Sliding window, two pointers, that kind of thing. Once you see the pattern, most of the problem solves itself.
I used the same idea here. Architecture questions follow patterns too, and the wording in a question usually gives the pattern away. If a question says a rule must always hold, or that a mistake has financial consequences, the answer is almost never a better prompt. It's enforcement in code, like a hook or a gate that blocks the action. If a question mentions subagents producing generic output, the issue is usually that subagents don't inherit the coordinator's context, so the information was never passed to them. Once I started reading questions this way, a lot of options fell away quickly.
To practise, I used Claude to build myself a small exam platform from the official guide. It had timed mock exams weighted the same way as the real blueprint, practice sets by domain with an explanation for every option, and a deck of pattern flashcards. Each card had three parts: the signal you see in the question, the move that wins, and the tell that gives away the wrong answers. There was also a round where you read a question and name the pattern before looking at the options, which turned out to be the most useful drill of all.
I also took practice tests from other sources, and once I was scoring comfortably I asked for a harder set built around the patterns I kept missing. Those questions were deliberately unfair, with traps where the familiar pattern was the wrong answer, and they did more for my confidence than the easy wins.
What surprised me on exam day
The topics I expected to be hard turned out to be some of the easiest. Questions about attention dilution, coordinator and subagent setups, or when to escalate to a human tend to have a clear signal in them, and once you've drilled the patterns you spot them almost immediately.
What actually slowed me down was Claude Code configuration, which surprised me, because I use Claude Code every day. The catch is that I almost always use it from my editor, and the exam goes much deeper into the command line and the configuration underneath it.
You need to know exactly which mechanism fits which kind of guidance: CLAUDE.md, .claude/rules/ with a glob pattern so it only loads for certain files, a Skill, a hook, or settings permissions. You also need to know when each one loads, how to set up Claude Code for automated code review with restricted tools and structured output, and what context: fork does in a Skill's frontmatter. None of it is difficult once you've seen it, but if you haven't set these things up by hand, the options all look plausible.
If you're starting today
Read the exam guide properly, end to end. It lists every task statement the exam covers, and almost everything I was asked traced back to one of them.
Then go and use the parts of Claude Code you normally don't. Run it from the terminal. Try claude -p for non-interactive runs, --output-format json with --json-schema for structured output, and --resume to pick up a named session. Write a CLAUDE.md, add a rules file with a paths glob, and create a Skill with context: fork so you can see what each one does and when it loads. If you work mostly from an editor like I do, this is the gap the exam will find.
Finally, practise recognising patterns rather than memorising answers. You won't see your practice questions on the real exam, but you will see the same ideas wearing different clothes. If you can read a question and name the pattern before you look at the options, you're ready.