Mastering Claude Certified Architect Professional.

What a near miss taught me

I walked into CCAR-P feeling good about architecture, retrieval, evaluation and safety, the topics that fill most study material. I came out a few questions short of 720. The score report breaks your result down by objective, and it told a story I hadn't predicted: the expensive misses weren't in the hard, abstract topics. They were in the concrete, operational ones.

• Configuring Claude Code for a team. Which settings file wins, what a managed policy can lock down, where a shared MCP server is defined. These questions have exactly one right answer and no partial credit for being "basically right."
• Guardrails as mechanisms. I knew guardrails mattered. I hadn't drilled which control goes where: preventative versus detective, before the tool runs versus after.
• Developer workflow and debugging. Domain 7 is only 7% of the blueprint, so I under-studied it. Every one of those questions still counts, and they're some of the most learnable on the exam.
• SLAs and the lifecycle. Turning "it should be fast and accurate" into numbers a sponsor signs, and knowing what happens at handoff, monitoring and iteration.

Two question styles cost me more than any topic. Multiple-response items ("select two") where I was confident about one answer and talked myself into the wrong partner. And a question about running a check before versus after a tool call, where I knew both mechanisms existed but hadn't internalized that only one of them can stop the action. Part 05 and Part 06 exist because of those two.

How this exam thinks

CCAR-P questions are scenarios with four plausible answers. You're rarely choosing between right and wrong; you're choosing between good and best. The best answer almost always reflects one of eight reflexes. Learn to see them and you'll answer faster than you can reason from first principles.

The eight reflexes

The decoder: question cue → winning pattern → the trap

When a question stem contains one of these cues, the right answer usually has the shape in the middle column. The right-hand column is the distractor built to catch you.

When two answers both look right, pick the one that fixes the root cause with the smallest mechanism you can measure or enforce. The distractor adds capacity, adds instructions, or hopes. — TWD

Words that hide simple ideas

Outside this exam I had never used the word "adversarial" in a sentence. Inside it, it shows up constantly, and it just means "coming from an attacker." Read it as "attack" and those questions get simple. Several other terms work the same way: intimidating label, plain idea.

Domain playbooks

Each domain below lists its score-report objectives with the one idea that answers most questions about it. When your practice results flag an objective, come back to its line and then do the lab it points to.

D1 · Solution Design & Architecture (17%)

• Translate business problems into Claude-based solutions. Start from the outcome and the user, not the technology. The best answer often reframes the request ("a chatbot") into the real job (deflect tier-1 tickets with cited answers).
• Design end-to-end architectures. Input → processing → output → feedback loop. The answer that includes how quality is captured and fed back usually beats the one that stops at output.
• Select architectural patterns. The ladder from reflex 1. Routing for distinct request types, chaining for fixed sequences, parallelization for independent sub-tasks or voting, an agent when the path is unknown.
• Design multi-agent systems. Orchestrator-workers when sub-tasks are dynamic; a supervisor when you need ordering, an audit trail and a kill switch. Subagents get their context passed in explicitly; they don't inherit it.
• Apply decomposition. Long or many-item tasks fail by omission. Split by item or section, process independently, aggregate with structure preserved.
• Align to business value. Efficiency, transformation, productivity, cost, SLAs: the right answer names the pillar the sponsor cares about and a metric for it. → Lab 10

D2 · Models, Prompting & Context Engineering (13%)

• Select models on trade-offs. The smallest model that meets the quality bar on your eval, within latency and cost. Route easy cases to a small model and hard ones to a large one. → Lab 4
• Design system prompts, templates and guardrails. Role, task, constraints, output format with an example; critical rules at the edges; untrusted content delimited. Prompt guardrails are a layer, never the only layer.
• Apply prompting techniques. Few-shot for format and edge cases; chain-of-thought (or extended thinking) for multi-step reasoning; zero-shot when the task is simple. Fix ambiguous instructions before adding examples.
• Implement prompt reuse. Prompt caching rewards a stable prefix: system prompt, tools, reference documents first; anything per-request (timestamps, user text) last. Modular prompts and templates keep teams consistent. → Lab 5

D3 · Integration (19%, the biggest domain)

• Evaluate tool/agent configuration for capability bloat. Fewer, non-overlapping tools with crisp descriptions; least privilege per agent; split when selection accuracy drops. → Lab 7
• Analyze authentication and authorization gaps. Look for shared credentials, agents with more access than the user, secrets in prompts or logs, and authorization done by instruction. Fix with delegated, scoped, per-user auth and server-side checks. → Lab 8
• Evaluate accuracy-latency trade-offs. Justify with numbers: which percentile, which accuracy metric, which cost. Streaming improves perceived latency; caching, smaller models and parallel calls improve real latency.
• Analyze observability at scale. Trace every step (prompt, retrieval, tool calls, tokens, latency) with a request ID; sample for quality review; alert on SLO burn, not single errors. → Lab 9
• Select connection protocols and integration mechanisms. MCP for reusable tool and data access across clients (stdio locally, streamable HTTP remotely); direct API tools for one app; batch APIs for large, non-urgent jobs; webhooks or queues for asynchronous work.

D4 · Evaluation, Testing & Optimization (16%)

• Define evaluation metrics. Accuracy (task-specific), latency (percentiles), cost per task, safety (violation and over-refusal rates), security (attack success rate). Every metric gets a threshold someone agreed to.
• Design eval datasets and frameworks. Real queries plus deliberate edge cases plus adversarial cases; code-based checks where possible, a calibrated judge for the subjective rest, humans for spot checks. → Lab 4
• A/B testing and iteration. Offline eval first; then a controlled online test with a primary metric chosen before the test; change one variable at a time.
• Diagnose prompt failures, hallucinations and model mismatch. Hallucination with good retrieval → ground and require citations; with bad retrieval → fix retrieval. Inconsistent format → examples or structured outputs. Can't reason through it → model or thinking budget.
• Optimize tokens, latency and cost. Measure where tokens go; cache stable prefixes; trim retrieved context; route by difficulty; batch what isn't interactive.
• Monitor with logging and observability tools. Dashboards for the SLIs, traces for debugging, alerts tied to SLOs, and a feedback signal (thumbs, escalations) joined to the trace.

D5 · Governance, Safety & Risk Management (14%)

• Implement guardrails and safety controls. Layers: input screening, constrained tools and permissions, output checks, human gates for consequential actions, monitoring. Put each control where it can actually stop the failure. → Lab 3
• Identify risks, limitations and failure modes. Hallucination, injection, data leakage, bias, over-reliance, drift, runaway agent loops and cost. Name the failure mode, then the control that addresses that specific one.
• Apply human-in-the-loop validation. Approval before irreversible or high-impact actions; confidence- or rule-based escalation; sampled review to calibrate automation. Design the reviewer's experience too: show the evidence, not just the answer.

D6 · Stakeholder Communication & Lifecycle (14%)

• Structured discovery and requirements. Users, current process, pain, volume, data, constraints, success metrics, risks, before any design. The "build a prototype first" answer is a trap unless discovery is done.
• Communicate decisions and trade-offs. In the audience's terms: an executive hears cost, risk and time to value; an engineer hears latency, failure modes and interfaces. Write decisions down (an ADR) with the options you rejected.
• Manage feedback loops and expectations, including SLAs. Agree measurable targets up front, report against them on a cadence, and renegotiate with data rather than absorbing scope.
• Document architectures and implementation guidance. Diagrams, data flows, prompts and their versions, eval results, runbooks for known failures, and who owns what after handoff.
• Support lifecycle phases. Discovery → design → build → handoff → monitoring → iteration, and model deprecation is part of it: pin versions, re-run evals on the new model, canary, then switch. → Lab 10

D7 · Developer Productivity & Operational Enablement (7%, don't skip it)

• Configure Claude tools and environments for teams. Shared project settings and CLAUDE.md in git; personal overrides in local files; organization policy in managed settings; shared MCP servers in .mcp.json. Part 05 has the details. → Lab 1
• Improve developer workflows. Plan before editing on large changes, give the agent a way to verify its work (tests, linters), use subagents for isolated investigation, run headless in CI for review and triage, and turn repeated procedures into commands or skills. → Lab 11
• Support debugging and operational issue resolution. Reproduce, read the trace, isolate the step (retrieval, prompt, tool, model), fix there, add the case to the regression set. → Lab 9

Claude Code for teams

This is the material that cost me the most, and it's pure recall: learn it once, bank the marks. It's also the fastest to verify yourself (Lab 1 and Lab 2 take under an hour together). Details move between releases, so confirm against the current Claude Code documentation before exam day.

Settings precedence: who wins a conflict

When the same setting is defined in several places, the higher row wins. Memorize the order top to bottom.

Mnemonic: Managed, Command line, Local, Project, User: "My Cat Likes Purring Upstairs." The more specific and more authoritative, the higher it ranks, and policy beats everything.

Permissions

• Rules come in three lists, allow, ask and deny, with patterns such as Bash(npm run test:*), Read(./.env) or Edit(src/**).
• Deny wins. A deny rule beats an allow rule for the same action, wherever each is defined. That's how a managed policy blocks something a project tries to allow.
• Permission modes change the default prompting behavior (normal prompting, auto-accepting edits, plan mode for read-only exploration, and a bypass mode that organizations can disable through managed settings).

Hooks: before versus after

Hooks are shell commands Claude Code runs at fixed points. They're deterministic: unlike an instruction in CLAUDE.md, they run every time. The question is always which event.

Other events worth knowing: UserPromptSubmit (inspect or add context to a prompt before Claude sees it), Stop and SubagentStop (when Claude finishes; can ask it to keep going, for example until tests pass), SessionStart (load context or set up the environment), PreCompact and Notification. Hooks are configured in the same settings files, so the precedence table applies, and a managed policy can require them.

Memory: CLAUDE.md files stack

• Organization-wide instructions from a managed policy location, the project's CLAUDE.md (committed, team conventions), and your user-level ~/.claude/CLAUDE.md (personal preferences) are all loaded. They add up rather than replace each other.
• CLAUDE.md is guidance the model reads; it isn't enforcement. Anything that must hold goes in permissions or hooks.
• Keep it short and specific: build and test commands, conventions, gotchas. Files can import others with @path.

MCP server scopes

"Share this server with the whole team" → project scope in .mcp.json, with secrets supplied through environment variables, never committed. "Only approved servers company-wide" → managed settings.

Subagents, commands, skills and CI

• Subagents (.claude/agents/ in the project, or your user directory): their own context window, their own tool allow-list and optionally their own model. Use them to keep exploratory noise out of the main context and to restrict a reviewer to read-only tools.
• Custom commands and skills (.claude/commands/, .claude/skills/): repeatable procedures checked into the repo. Skills load their full instructions only when relevant, which keeps context lean.
• Headless mode (claude -p "…" with JSON output and an explicit tool allow-list) runs Claude Code in scripts and CI: PR review, issue triage, fixing lint. In CI, scope tools and permissions tightly; there's no human to approve a prompt.

Question craft

Multiple response ("select two")

1. Judge each option on its own, true or false, before pairing. Don't hunt for a "pair that goes together." The correct options are usually independent good practices, and the distractor is often a near-copy of a right answer with one fatal word.
2. Watch for the half-right option. "Add a PostToolUse hook to block…" pairs a real mechanism with the wrong timing. One wrong clause makes the whole option wrong.
3. If you're sure of one, re-read the stem before picking the second. Ask which remaining option addresses a different part of the requirement. Two options that do the same thing rarely both score.
4. There's no partial credit. Don't spend four minutes on one; flag it and come back.

Scenario matching

• Options can repeat. Don't assume a one-to-one mapping or use elimination across rows.
• Classify each scenario by its single strongest cue (irreversible? → human gate; must never happen? → preventative control; trend? → monitoring).

Qualifiers decide the answer

Pacing

• About 1:54 per question. Answer everything on the first pass, flag anything over two minutes, and come back. A guess costs nothing; a blank does.
• Long scenarios: read the last sentence (the actual question) first, then the scenario looking for the facts it needs.
• Don't change an answer on review unless you can name the specific fact you misread.

Study with Claude

The fastest learning I did was arguing with a model, not re-reading notes. Paste these into Claude (any plan). Replace the bracketed parts.

The distractor autopsy

Here is a practice question I got wrong, the option I chose, and the
correct option: [paste]. Don't just explain the right answer. Tell me
what reasoning would lead someone to my choice, the exact word or
assumption that makes it wrong, and a one-line rule I can apply to
spot this trap next time.

The objective drill

Act as an examiner for an AI solution-architect certification. Write
one scenario question for the objective "[objective from the score
report]" with four options where every option is plausible to a
practitioner. Don't show the answer. After I answer, grade my reasoning,
not just my letter, then write a harder variant on the same idea.

The teach-back

I'm going to explain [prompt caching / PreToolUse vs PostToolUse /
canary vs A/B] in my own words. Interrupt me with a pointed question
whenever I'm vague or wrong, the way a skeptical principal engineer
would. Finish with the two things I'd most likely get wrong on an exam.

The stakeholder role-play (Domain 6)

Play a VP of Customer Support who wants "an AI agent that's 100%
accurate, live next month." Push back the way a real sponsor would.
I'll run discovery and turn your demands into measurable acceptance
criteria and an SLA. At the end, score me on discovery, expectation
setting and how I communicated trade-offs.

The jargon flip

Give me 10 one-sentence scenarios. For each I'll say whether it calls
for regression testing, adversarial testing, an A/B test, a canary, or
monitoring. Mix them up and include two that are deliberately close
calls, then explain those two.

The three-week plan

Readiness checklist

Tick these off as you go. They're saved in this browser.

• Two timed practice exams at 75% or better overall, three or more days apart
• No domain under 75% on either of them
• I can write the settings precedence order from memory and say what each file is for
• I can say which hook event can block an action and which can't, and I've built one of each
• I know which MCP scope shares a server with the team and where its secrets should live
• Given a scenario, I can tell regression, adversarial, A/B, canary and monitoring apart instantly
• I've attacked my own RAG app with an indirect injection and stopped it with something other than a prompt line
• I've built an eval set, run a regression after a change, and calibrated an LLM judge against my own ratings
• I've measured a prompt-cache hit and know what breaks one
• I can turn "fast and accurate" into an SLA with percentiles and thresholds
• I can describe a model upgrade end to end: pin, eval, canary, switch, monitor
• I judge each "select two" option on its own before pairing

Practice-material hygiene

I worked through several third-party question sets. Some were genuinely useful; one cost me hours. What I'd tell anyone picking practice material:

• Check that the format survived. A PDF that's been exported and re-exported can shift text between options, merge words, or show a "select two" question with radio-button styling. If the options don't read cleanly, you're memorizing noise. Fix it or drop the question.
• Map every question to an objective. A set that's 40% prompt-writing and 0% Claude Code configuration will flatter you. Tag questions to the 32 objectives and look at the coverage before trusting your score.
• Learn the reasoning, never the letter. If you recognize a question by its answer position, it has stopped teaching you. Shuffle, and read the explanation for every option.
• Know where it came from. If a source ever presents questions as actual exam items, stop using it. Live content is covered by the candidate agreement, and leaked items are often wrong anyway.
• Prefer building to drilling. Every hour in the labs paid back more than an hour of questions, because the exam asks what you'd do.

The exam isn't testing whether you've read about Claude. It's testing whether you've shipped with it, and whether you'd make the safe, measurable, proportionate call under pressure. — TWD