Eight people on our team booked the Claude Certified Architect – Foundations exam in the same window. Eight people passed. None of them had a spare afternoon to give it, and none of them had a guide written by someone who'd actually sat the exam, because at the time nobody had published one.
So we're writing the guide we wished existed. Not a syllabus copy-paste. The version with the parts that would've saved us time, told in plain terms, from people who did this on top of client hours rather than instead of them.
We've laid it out as the questions candidates actually ask, because that's closer to how you'll use it than a straight narrative would be. Skip to what you need.
What does the exam actually cover, and how is it weighted?
Five domains, and they're not weighted evenly, which matters more than it sounds like it should.
Domain 1: Agentic Architecture & Orchestration (27%). Designing agentic systems with the Claude API: the agent loop and how it terminates, choosing between single-agent, hub-and-spoke, and multi-agent handoff patterns, guardrails, and knowing when to reach for the SDK versus writing the loop yourself.
Domain 2: Claude Code Configuration & Workflows (20%). Structuring
CLAUDE.mdfiles across a repo, settings, hooks, permissions, and CI/CD integration. Less about writing code, more about setting the defaults that keep a team's behaviour consistent and safe.Domain 3: Prompt Engineering & Structured Output (20%). Prompts that hold up in production: JSON schema enforcement, few-shot patterns, validation and retry mechanics.
Domain 4: Tool Design & MCP Integration (18%). Tool schemas Claude can use without confusion, building MCP servers and clients, connecting external services.
Domain 5: Context Management & Reliability (15%). Keeping long, multi-turn conversations coherent: context windows, prompt caching, handoffs between turns and sub-agents, and reliability over time.
The team's honest read: Domains 1 and 2 together are nearly half the exam and the hardest to compensate for if you're weak there, so that's where most study hours should go. More on Domain 5 below, because its low weighting is a trap.
How many questions, and what score do you need to pass?
Sixty multiple-choice questions, 120 minutes, scored on a scale from 100 to 1000. You need 720 to pass.
Worth saying plainly: 720 is a scaled score, not 72% of questions correct. Don't do the maths that way and second-guess yourself mid-exam.
Every question is scenario-based. There's no pure recall or definition-matching to fall back on, which changes how you should prepare (see below).
What scenarios come up, and what do they actually test?
Six scenarios exist in the question bank; only four appear on any given exam sitting, so you can't predict which ones you'll get.
Customer Support Resolution Agent. An agent handling high-ambiguity returns, billing, and account issues through custom MCP tools, aiming for 80%+ first-contact resolution while knowing when to escalate.
Code Generation with Claude Code. Integrating Claude Code into a team workflow with custom slash commands,
CLAUDE.mdconfiguration, and choosing plan mode versus direct execution.Multi-Agent Research System. A coordinator delegating to subagents for search, document analysis, synthesis, and cited report generation.
Developer Productivity with Claude. An agent helping engineers navigate unfamiliar codebases using built-in tools (Read, Write, Bash, Grep, Glob) alongside MCP servers.
Claude Code for CI/CD. Automated code review, test generation, and pull-request feedback, designed to minimise false positives.
Structured Data Extraction. Pulling information from unstructured documents, validating output against JSON schemas, and handling edge cases gracefully.
Here's the part that surprised the team more than the scenarios themselves: recognising the scenario barely helps with the question attached to it. More on that below, because it's the single biggest thing we'd tell a first-time candidate.
Which domain do people underestimate, and where should study time actually go?
Domain 5, Context Management & Reliability. It's the lightest-weighted domain at 15%, which is exactly why people deprioritise it, and exactly why that's a mistake. It turns up disproportionately inside scenario questions, and the content is judgement-heavy rather than something you can cram the night before.
A rough split the team would recommend:
Foundations, Domains 1 and 2, roughly 47% of the exam. Spend most of your time here.
Domain 1: know the agentic loop lifecycle and
stop_reasonhandling cold. It's a recurring trap. Know the orchestration patterns by instinct, including that subagents don't inherit context automatically.Domain 2: learn the settings and
CLAUDE.mdhierarchy, particularly which level wins when user, project, and team files conflict, plus path-specific rules. Know how hooks, permissions, and CI/CD integration are scoped.
Applied skills, Domains 3 and 4, where judgement beats memorisation. Expect scenario questions where several answers all technically work. The distractors are built to be plausible. Watch for the exam's "simplest fix that works" pattern: it rewards the least complex solution that satisfies the constraints and marks down over-engineering.
Domain 3: structured output end to end, JSON schema enforcement, few-shot patterns, validation-retry loops for malformed responses.
Domain 4: tool boundaries and schema design. Scoping tools too broadly is the fastest way to lose points here.
Context and reliability, Domain 5. Don't treat it as the easy 15%. Cover context-window management, prompt caching (eligibility versus cost), long-conversation handling, and human-in-the-loop escalation. Because scenarios cross domains, study for cross-domain thinking rather than single-domain recall.
Should you just do the courses, or build something alongside them?
Build something real. The team was unanimous on this one.
Courses give you the theory and the vocabulary, but they don't map cleanly onto how the exam actually functions. Every question asks you to pick the best architectural choice among several that are all technically correct, and that's a judgement call that only develops from shipping systems, not from watching lectures.
What worked, paired with the course material:
Build a small agent with a real loop. Learn proper termination with
stop_reason, real error handling, and a human escalation path.Stand up an MCP server with tightly scoped tools and clear schemas. This is where the team saw the most avoidable point loss.
Set up a
CLAUDE.mdhierarchy across local, project, and subdirectory levels, so the conflict rules stop being theoretical.Write a structured-extraction prompt that enforces a JSON schema with a validation-retry loop.
One or two of these builds, done properly, will teach you more than a second pass through the course material.
What's the one thing about this exam that no other guide mentions yet?
That recognising the scenario isn't the same as recognising the question.
You can work through every mock exam available and still meet a question you've never seen in that exact form, and that's not a gap in your preparation. It's the exam working as intended. Across the sittings the team went through, the real surprise wasn't how hard the questions were in the abstract. It was realising how little the scenario label actually told you about what was being tested.
A few things follow from that:
The six scenarios are costumes, not the concept. The same underlying idea (say, escalation logic, or context handoff between subagents) can show up dressed as customer support one question and as a research system the next.
A perfect mock score mostly proves you memorised that mock. Once you can recognise a mock's questions on sight, further grinding on it stops helping.
The exam tests understanding, not recall. Every question asks which of four workable options is best, and the wrong answers are built to look plausible on a skim.
If you take one piece of advice from a team that's already sat it: don't study to recognise the scenario. Study to recognise the concept underneath it, because that's what actually shows up on the page.
Where can Singapore-based candidates sit the exam?
The exam runs through Pearson VUE, so you've got two options: online-proctored from home or your office, or in person at a physical Pearson VUE test centre. Singapore has several. Appointments can be rescheduled up to 24 hours before the sitting through your Pearson account, and registration itself runs through the Anthropic Partner Academy.
Do the scenarios translate to a Singapore or APAC business context, or are they US-centric?
They translate cleanly. All six scenarios are architecture problems, not business-culture problems, so there's nothing US-specific to trip up a Singapore candidate.
If there's a bias in this exam, it's technical rather than geographic. It leans heavily engineering and CI/CD-oriented, so anyone who's only used Claude through the chat interface, regardless of where they're based, is likely to find the gap there rather than in the scenario framing.
How much study time should a working professional in Singapore realistically budget?
Depends honestly on where you're starting from.
If you already build with Claude regularly, budget 2 to 3 weeks at 5 to 6 hours a week, around 20 to 30 hours total. If you're thinner on hands-on agent, MCP, or Claude Code work, plan for 4 to 6 weeks instead. That extra time isn't for reading more; it's for building the applied judgement that only comes from doing the work, which is the gap most candidates underestimate.
Eight people on our team have now sat this exam and passed. If you're based in Singapore and want to talk through your own prep plan, or weighing up whether to put your team through it, get in touch at redairship.com/contact
Key Takeaways
Domains 1 and 2 are nearly half the exam. Start there.
Don't treat Domain 5 as the easy 15%. It shows up more than its weighting suggests.
Pair every course module with something you actually build.
Study the concept, not the scenario dressing.
Rate this insight
Was this article useful?
Click to rate




