Claude Certified Architect Foundations.

How this exam thinks

Before any domain content, internalize the disposition the exam is testing. Almost every "best answer" question rewards the same handful of judgments. If you can recognize them, you can answer questions on topics you only half-remember.

The five judgments the exam keeps testing

1. Deterministic over probabilistic when business logic depends on it. If a rule must hold (verify identity before refund, block refunds over $500, force a tool to run first), the right answer is a programmatic mechanism: a hook, a prerequisite gate, a forced tool_choice. The wrong answers are "improve the system prompt" and "add few-shot examples." Prompt-based compliance is probabilistic; financial and identity workflows can't tolerate that.
2. Model-driven decisions over hand-rolled control flow. Loops should branch on stop_reason. Coordinators should decide which subagents to invoke. Don't parse natural-language signals to decide "is the agent done." Don't pre-route requests with a regex classifier when a tool description fix gets you 80% of the way there.
3. Match the proportionate first response. When the question describes a problem and offers four fixes, the right answer is usually the smallest mechanism that addresses the root cause. Tool descriptions are minimal? Fix the descriptions. Escalation is wrong? Add explicit criteria with few-shot examples. Don't reach for a separate classifier model, ML pipeline, or higher-tier model when the cheap fix hasn't been tried.
4. Subagents have isolated context. Always. Subagents do not inherit the coordinator's history. The coordinator must pass complete findings, structured metadata, and quality criteria explicitly in the subagent's prompt. Whenever an answer hinges on "the subagent will know X," verify X was passed in.
5. Structure beats summary. When in doubt, the right answer is "preserve structured data": claim-source mappings, error categories with retryable flags, dates and provenance, conflicting values both annotated. The wrong answer is "summarize and pick one" or "return generic status."

The anti-patterns that are always wrong

The exam is generous: a handful of distractors are designed to be obviously wrong once you know the pattern. Burn these into memory:

• Self-reported model confidence as a routing signal. The model is already overconfident on the cases it's getting wrong. Confidence scores from the model itself are not calibrated. (You can use field-level confidence calibrated against a labeled validation set; that's different.)
• Sentiment analysis as a complexity signal. A frustrated customer with a simple problem and a calm customer with a complex one both exist. Sentiment doesn't predict case complexity.
• "A bigger model / larger context window will fix it." Almost always wrong. Attention dilution, decomposition errors, and unclear criteria don't yield to more tokens.
• "Suppress the error and return success." Catching a timeout and returning empty results as a successful query is always wrong. The coordinator loses the context it needs to recover.
• "Terminate the entire workflow on any failure." Equally wrong from the other direction. Local recovery in subagents, structured propagation to the coordinator, partial results with coverage annotations.
• Iteration caps and natural-language loop termination. An agentic loop terminates on stop_reason == "end_turn". Not when the assistant says "Done!" Not after N iterations as the primary stopping mechanism.

The six scenarios

Every form draws four scenarios at random from the same six. Knowing them in advance is a real edge: when a question lands, you already have the system in your head and can focus on the specific judgment being tested.

Memorize these six setups

1. Customer support resolution agent. Agent SDK. MCP tools: get_customer, lookup_order, process_refund, escalate_to_human. Target: 80%+ first-contact resolution. Domains: D1, D2, D5.
2. Code generation with Claude Code. Custom slash commands, CLAUDE.md, plan mode vs direct execution. Domains: D3, D5.
3. Multi-agent research system. Coordinator delegates to web search, document analysis, synthesis, and report generator subagents. Domains: D1, D2, D5.
4. Developer productivity tools. Built-in Read/Write/Bash/Grep/Glob plus MCP. Domains: D2, D3, D1.
5. Claude Code in CI/CD. Automated reviews, test generation, PR feedback. Non-interactive flag, JSON output. Domains: D3, D4.
6. Structured data extraction. JSON schemas, validation, edge cases. Domains: D4, D5.

When a scenario opens, read the setup once and then go straight to the question. The setup is rarely a trick; the question is where the points live.

Domain 1 · Agentic architecture & orchestration 27%

The biggest single block of the exam. Seven task statements, all about how an agent loop runs and how multi-agent systems coordinate. If you only have time to deeply prepare for one domain, prepare for this one.

The agentic loop, in one paragraph

You send a request to Claude. The response has a stop_reason. If it's "tool_use", you execute the requested tool, append the result to the conversation history, and send the next request. If it's "end_turn", you stop. That's the whole loop. The model decides when it's done, not your code.

Coordinator–subagent: the rules you must know

• Hub-and-spoke architecture. All inter-subagent communication routes through the coordinator. This isn't aesthetic; it's where observability and consistent error handling live.
• Subagents have isolated context. They do not inherit the coordinator's conversation history. The coordinator must pass complete findings (including structured metadata like source URLs, document names, and dates) directly in the subagent's prompt.
• Spawn parallel subagents in a single response. The coordinator emits multiple Task tool calls in one turn, not across separate turns. This is how you get the latency win.
• allowedTools must include "Task" for a coordinator to spawn subagents. If the question describes "the coordinator can't delegate," check this first.
• Coordinator decomposition is the most common failure mode. If subagents complete successfully but the final report misses topic areas, the coordinator's task decomposition was too narrow. Don't blame downstream agents.
• Coordinator prompts specify goals and quality criteria, not procedural steps. "Find comprehensive coverage of X" beats "First do A, then do B, then do C." Subagents need room to adapt.

Hooks vs prompts: the deterministic line

This is the single most-tested distinction in Domain 1. Memorize it cold:

Session management: resume vs fork vs fresh start

• --resume <session-name> picks up a named session. Use when prior context is mostly still valid and you're continuing the same line of work.
• fork_session creates an independent branch from a shared baseline. Use to explore divergent approaches (testing strategy A vs B, refactor approach 1 vs 2) from the same analysis.
• Fresh start with an injected summary beats resuming when prior tool results are stale. After significant code modifications, telling a resumed session "by the way, file X changed in these specific ways" is better than expecting it to figure that out.

Decomposition strategy

• Prompt chaining (fixed sequential pipeline) for predictable multi-aspect work. Example: per-file local review pass plus a cross-file integration pass.
• Dynamic adaptive decomposition for open-ended investigation. Example: "add comprehensive tests to a legacy codebase" should map structure first, then prioritize, then expand subtasks as dependencies surface.
• Multi-concern messages get decomposed in parallel. A customer with three issues becomes three concurrent investigations sharing context, not three sequential conversations.

Domain 2 · Tool design & MCP integration 18%

Five task statements. The headline lesson: tool descriptions are the primary mechanism the model uses for tool selection. When two tools have minimal, similar descriptions, the model chooses badly. Half of Domain 2's right answers begin with "improve the descriptions."

What a good tool description contains

• Purpose: what the tool does, in one sentence that distinguishes it from neighbors
• Input format, including examples of valid inputs
• Example queries that should call this tool
• Edge cases and boundaries: when to use this tool vs a similar alternative
• What the output looks like, so the model knows what to do with the result

If the question describes "agent picks the wrong tool" and the answer choices include "expand descriptions to include input formats, example queries, edge cases, and boundaries," that's the answer. Few-shot examples and routing classifiers are over-engineered for this problem.

Splitting vs consolidating tools

A generic analyze_document with overloaded behavior is a smell. Split it into extract_data_points, summarize_content, and verify_claim_against_source. Each gets a defined input/output contract. The exam consistently rewards splitting.

The opposite move (consolidating two tools into one polymorphic lookup_entity) is sometimes architecturally valid but is rarely the correct "first step" answer. The proportionate-response rule applies.

Structured error responses

Every MCP tool failure should return:

• isError: true (the MCP flag)
• errorCategory: transient / validation / business / permission
• isRetryable: boolean
• Human-readable description for the agent (and end-user via the agent)

Generic "Operation failed" responses are always wrong. They prevent the agent from making appropriate recovery decisions. A business-rule violation (refund exceeds policy) should be marked non-retryable with a customer-friendly explanation; a transient timeout should be marked retryable.

Tool distribution across agents

• Tool count matters. Giving an agent 18 tools when 4–5 would do degrades selection reliability. Scope each agent's toolset to its role.
• Cross-role tools are okay for high-frequency needs. A synthesis agent that constantly needs simple fact-checks gets a scoped verify_fact tool while complex verifications still route through the coordinator.
• Replace generic with constrained. fetch_url becomes load_document with URL validation; the constrained version prevents misuse.

tool_choice: three modes, one common mistake

• "auto": model chooses whether to call a tool or return text. The default.
• "any": model must call some tool but picks which. Use to guarantee structured output when multiple extraction schemas exist.
• {"type": "tool", "name": "..."}: forced selection of a specific tool. Use to ensure a particular extraction (like extract_metadata) runs before downstream enrichment.

The trap: people reach for forced selection when "any" would do. Forced selection is for ordering; "any" is for guaranteeing a structured response.

MCP server scoping

• Project-scoped .mcp.json: shared team tooling, version-controlled, with ${ENV_VAR} expansion for credentials.
• User-scoped ~/.claude.json: personal experiments that don't belong in the team config.
• Both load simultaneously; their tools are all available to the agent at once.
• MCP resources (not tools) are for content catalogs (issue summaries, schemas, doc hierarchies) that reduce exploratory tool calls.

Built-in Claude Code tools

Know what each one is for:

• Grep: content search. Finding callers, error strings, imports.
• Glob: path pattern matching. **/*.test.tsx, file-by-extension.
• Read: load full file contents.
• Write: full file write. The fallback when Edit can't find unique anchor text.
• Edit: targeted modification by unique text match. Fast but fails on ambiguous anchors.
• Bash: shell execution.

The exam-relevant move: build understanding incrementally with Grep first, then follow imports with Read. Don't read every file upfront.

Domain 3 · Claude Code configuration & workflows 20%

Six task statements. The headline lesson: configuration hierarchy and scoping decisions are the difference between "works on my machine" and "works for the team."

The configuration hierarchy

The exam pattern: a question describes a "team member doesn't have the rules" symptom. The answer is "they're in user-scope; move to project-scope." Or: "test files are spread throughout the codebase and need consistent conventions." The answer is path-scoped rules with glob patterns, not a CLAUDE.md per directory.

Slash commands vs skills

• Slash commands in .claude/commands/ (project) or ~/.claude/commands/ (user). For team-wide, version-controlled commands, project scope.
• Skills in .claude/skills//SKILL.md with frontmatter:
  • context: fork: runs in an isolated sub-agent context, output doesn't pollute main conversation. Use for verbose discovery or brainstorming.
  • allowed-tools: restrict tool access during the skill (e.g., disallow destructive Bash).
  • argument-hint: prompt the developer for required parameters when the skill is invoked without args.
• Skills vs CLAUDE.md. Skills are on-demand, task-specific. CLAUDE.md is always-loaded universal standards. Don't put skills' contents in CLAUDE.md, and don't put always-on rules in a skill.

Plan mode vs direct execution

The Explore subagent isolates verbose discovery and returns summaries to preserve main context. Use it when an exploration phase will dump pages of file contents the main agent doesn't need to keep around.

Iterative refinement: when to do what

• Concrete input/output examples. The most effective fix when prose descriptions are interpreted inconsistently. Two or three example pairs.
• Test-driven iteration. Write the test suite first, then iterate by sharing test failures.
• Interview pattern. Have Claude ask clarifying questions before implementing in unfamiliar domains. Surfaces considerations you'd miss.
• Single message vs sequential. When fixes interact (e.g., changing one schema affects three call-sites), put all issues in one message. When they're independent, sequential is fine.

Claude Code in CI/CD

• -p (or --print): non-interactive mode. The fix when the CI job hangs waiting for input. Don't reach for CLAUDE_HEADLESS=true or --batch; those are not real flags.
• --output-format json --json-schema: structured findings parseable for automated PR comments.
• Independent review instances beat self-review. The same session that generated code is biased toward defending its decisions. A second instance without the generator's reasoning context catches more.
• Per-file passes plus a cross-file integration pass. This is the fix for "single-pass review of 14 files gives shallow, inconsistent feedback." Attention dilution is the root cause; bigger context windows don't help.
• Including prior review findings when re-running on new commits prevents duplicate comments. Instruct Claude to report only new or still-unaddressed issues.
• CLAUDE.md is how CI gets project context: testing standards, fixture conventions, valuable-test criteria. Without it, generated tests are shallow.

Domain 4 · Prompt engineering & structured output 20%

Six task statements. The headline lesson: specific criteria and few-shot examples beat vague guidance every time, and tool_use with JSON schemas is the only reliable path to structured output.

Explicit criteria over vague instructions

"Be conservative" and "only report high-confidence findings" do nothing for precision. The right shape is explicit categorical criteria with concrete code examples for each severity level. "Flag a comment only when the claimed behavior contradicts the actual code behavior" is the form the exam rewards.

Corollary: when false-positive rates are high in one category, you can temporarily disable that category to restore developer trust while you improve the prompt for it. Don't let one noisy category undermine confidence in the accurate ones.

Few-shot examples: when and how many

• 2–4 targeted examples for ambiguous scenarios (not 10+).
• Show the reasoning for why one action was chosen over plausible alternatives. Don't just show input → output; show the judgment.
• Include examples that distinguish acceptable patterns from genuine issues. This is how you reduce false positives while keeping generalization.
• Examples are most effective for: ambiguous tool selection, format consistency, varied document structures (inline citations vs bibliographies), and edge cases like null fields.

tool_use with JSON schemas: the only reliable path

Schema-compliant structured output requires tool_use. Free-form "respond in JSON format" prompts produce syntax errors. tool_use eliminates them.

• Strict schemas eliminate syntax errors but not semantic errors (line items that don't sum to the total, values placed in the wrong field). Build separate validation for the semantic layer.
• Required vs optional (nullable) fields matter. If a source document may not contain a piece of information, mark the field nullable. A required field tells the model to fabricate a value to satisfy the schema.
• Enum + "other" + detail string is the right pattern for extensible categorization. Adding "unclear" as an enum value is the right pattern for ambiguous cases.
• Format normalization rules live in the prompt alongside the strict schema. The schema doesn't normalize; the prompt does.

Validation, retry, feedback loops

• Retry with the specific validation error appended to the prompt. The model corrects format/structural errors well when told what failed.
• Retries don't help when the information is absent from the source. If a required field can't be filled because the source doc didn't include it, no amount of retrying creates the data. Mark the field nullable instead.
• detected_pattern field. A structured-output trick. Tag each finding with the code construct that triggered it, so when developers dismiss findings you can analyze the dismissal patterns systematically.
• Self-correction validators. Extract calculated_total alongside stated_total to flag discrepancies. Add conflict_detected booleans to mark inconsistent source data.

Batch processing: when it's right and when it's wrong

The Message Batches API gives 50% cost savings and a processing window up to 24 hours with no latency SLA. It does not support multi-turn tool calling. Use custom_id to correlate request/response pairs and to identify failed documents for resubmission.

Multi-instance and multi-pass review

• Self-review is biased. A model that just generated code retains reasoning context that makes it less likely to question its own decisions. Use a second instance.
• Per-file passes + cross-file integration pass beats a single pass over many files.
• Verification passes with self-reported confidence per finding enable calibrated review routing. The calibration belongs in the routing logic, not in trusting the score.

Domain 5 · Context management & reliability 15%

Six task statements. The smallest domain by weight, but the one with the highest density of "anti-patterns that are always wrong" gotchas.

Context management for long interactions

• Progressive summarization loses numbers. Amounts, dates, percentages, customer-stated expectations get vague-ified. Extract them into a persistent "case facts" block included in every prompt outside the summarized history.
• Lost-in-the-middle. Models reliably process input at the start and end. Put key findings summaries at the top of aggregated inputs; use explicit section headers for detailed results.
• Trim verbose tool outputs. An order lookup with 40+ fields, of which only 5 are relevant to the current task, should be trimmed before accumulating in context.
• Pass complete history. Subsequent API requests need the full conversation to maintain coherence. There's no server-side session.
• Restructure upstream agents to return structured data (key facts, citations, relevance scores) instead of verbose content when downstream agents have limited context budgets.

Escalation: the rules

• Honor explicit customer requests for a human immediately. Don't first try to investigate. Don't "see if I can help with that." Just escalate.
• Acknowledge frustration, then offer resolution if the issue is in scope. Escalate only if the customer reiterates the preference. (This is the nuanced case: explicit demand → escalate; implicit frustration with an in-scope issue → offer to help, then escalate if pushed.)
• Escalate when policy is silent on the customer's specific situation (competitor price-matching when policy only addresses own-site adjustments).
• Multiple matches → ask for more identifiers. Don't pick by heuristic.
• Escalation criteria belong in the system prompt with few-shot examples. Not in a separate classifier model. Not in self-reported confidence. Not in sentiment analysis.

Error propagation in multi-agent systems

• Structured error context (failure type, attempted query, partial results, alternative approaches) enables intelligent coordinator recovery.
• Distinguish access failures from valid empty results.
• Local recovery in subagents for transient failures. Only propagate what can't be resolved locally, with what was attempted and any partial results.
• Coverage-annotated synthesis output. Mark which findings are well-supported and which topic areas have gaps due to unavailable sources. Don't paper over gaps.

Large-codebase exploration

• Context degrades in long sessions. The model starts referencing "typical patterns" instead of the specific classes it found earlier. Counter with scratchpad files.
• Subagent delegation isolates verbose discovery from the main coordination context.
• Structured state exports (manifests) for crash recovery. Each agent dumps state to a known location; the coordinator loads the manifest on resume.
• /compact reduces context usage when extended exploration has filled it.

Human review and confidence calibration

• Aggregate accuracy hides per-segment failure. 97% overall can mask 60% on one document type. Stratify by document type and field before automating.
• Stratified random sampling of high-confidence extractions catches novel error patterns over time.
• Field-level confidence calibrated against a labeled validation set is the right routing signal. Raw model self-reports are not.
• Route low-confidence and ambiguous-source extractions to human review. Reviewer capacity is finite; spend it on uncertainty.

Multi-source synthesis: provenance and conflicts

• Claim-source mappings travel with findings through every stage of synthesis. Source URLs, document names, excerpts, dates.
• Conflicting statistics: annotate with attribution. Don't pick one. Distinguish well-established findings from contested ones in the report.
• Publication and collection dates are mandatory in structured outputs. Without them, temporal differences look like contradictions.
• Render content types appropriately. Financial data as tables, news as prose, technical findings as structured lists. Don't force everything into one shape.

Question patterns the exam rewards

After working through the sample questions, a few grammars repeat. If you can recognize them, you can answer in 30 seconds instead of two minutes.

Pattern A · "Production data shows X is happening N% of the time. What change would most effectively address this?"

The right answer is the smallest mechanism that addresses the root cause. Read the cause carefully. Is it a missing prerequisite (programmatic hook), a tool-selection ambiguity (better descriptions), or an unclear decision boundary (explicit criteria with few-shot)? The wrong answers will be (a) heavier infrastructure than needed, (b) prompt-only fixes for problems that need determinism, or (c) addressing the wrong layer (tool availability when the problem is tool ordering).

Pattern B · "All subagents complete successfully but the output is wrong. Root cause?"

Almost always the coordinator's task decomposition was too narrow. Don't blame downstream agents that worked correctly within their assigned scope. Read the coordinator's logs in the question; they reveal the answer directly.

Pattern C · "Latency is too high; how do we reduce overhead?"

Look for the principle of least privilege. Give the agent that needs frequent simple lookups a scoped tool for the common case; keep complex cases routing through the coordinator. Don't over-provision (give it all the web search tools), don't speculatively cache, don't batch in a way that creates blocking dependencies.

Pattern D · "How should this failure flow back?"

Structured error context with failure type, attempted query, partial results, and alternatives. Generic statuses, suppressed errors marked as success, and workflow-terminating exceptions are all anti-patterns.

Pattern E · "Where should this configuration live?"

If it should reach every developer via git: project-scope (.claude/...). If it's personal: user-scope (~/.claude/...). If it applies to files spread across directories: path-scoped rules with glob patterns. If it should run on demand and not pollute context: a skill with context: fork.

Pattern F · "Single-pass review of N files is inconsistent."

Per-file passes for local issues + a separate cross-file integration pass. Not a bigger model, not consensus voting, not pushing the burden to developers.

Pattern G · "Use Message Batches API for both workflows?"

Match each workflow to the API. Batch for non-blocking, latency-tolerant. Synchronous for blocking. Never both with a "fallback if too slow." That's added complexity for no gain.

The 10-hour lab plan

Reading the exam guide gets you maybe 60% of the way. The other 40% is the muscle memory that comes from actually building the things. This lab plan is structured to give you concrete reps on every domain in roughly ten hours of build time. It's organized as four labs that compose into one realistic system.

Fast pass for all three labs: the working scaffolds live at github.com/darindeters/claude-architect-labs. Clone the repo, pick a lab, run the boot command. Each lab boots in 30 seconds and the TODO blocks map exactly to the numbered steps below.

Lab 1: A customer support agent with a hook-enforced prerequisite

≈ 3 hours · domains 1, 2, 5

Goal: Build the customer support agent from Scenario 1. By the end, you will have written code that demonstrates every Domain 1 distinction the exam tests.

Lab 2: Multi-agent research with parallel subagents and provenance

≈ 3 hours · domains 1, 2, 5

Goal: Build the research system from Scenario 3. By the end, you will have lived through the coordinator-decomposition failure mode, the parallel-spawn latency win, and the provenance-loss anti-pattern.

Lab 3: Claude Code for a real team workflow

≈ 2 hours · domains 2, 3

Goal: Configure a project the way Domain 3 questions assume it's configured. Pick any repo you have write access to.

Lab 4: Structured extraction with validation and batch

≈ 2 hours · domains 4, 5

Goal: Build the extraction system from Scenario 6. By the end, you will have practiced every Domain 4 schema-design decision the exam tests.

Optional Lab 5: A CI/CD review pipeline

≈ 1 hour · domains 3, 4

If you have the appetite: wire Claude Code into a GitHub Actions workflow with claude -p --output-format json --json-schema, post structured findings as inline PR comments, and re-run on subsequent commits while passing prior findings to avoid duplicates. This makes the Scenario 5 questions feel familiar instead of theoretical.

What is NOT on the exam

The exam guide is explicit about what's out of scope. Don't waste prep time on these:

• Fine-tuning, training, or model weights
• Authentication, billing, account management, OAuth flows, API key rotation
• Deploying or hosting MCP servers (infrastructure, networking, container orchestration)
• Constitutional AI, RLHF, safety-training methodology
• Embedding models or vector database internals
• Computer use (browser automation, desktop interaction)
• Vision and image analysis
• Streaming API implementation, server-sent events
• Rate limiting, quotas, pricing math
• Specific cloud provider configs (AWS, GCP, Azure)
• Performance benchmarking, model comparison metrics
• Prompt caching internals (beyond knowing it exists)
• Token counting algorithms or tokenization specifics

This list is generous. If a prep resource is heavy on any of the above, it isn't aligned with this exam.

Day-of strategy

Reading the question

• The scenario is one of six. Recognize it in the first sentence. Then go to the question.
• Identify which domain is being tested. Each scenario maps to a primary set of domains; the question will be in one of them.
• Look for the "production data shows…" or "logs show…" framing. The setup usually contains the root cause if you read carefully. The right answer addresses what the logs say happened, not what you'd guess.
• Ask the five judgments from the opening section: deterministic-when-required, model-driven-decisions, proportionate-first-response, isolated-subagent-context, structure-beats-summary.

Reading the answers

• Eliminate the always-wrong distractors first. Sentiment routing, self-reported confidence as a routing signal, "use a bigger model," "suppress the error and return success," "terminate the workflow." If any of those appear, scratch them.
• Eliminate over-engineered answers. Separate classifier model, ML pipeline, custom routing layer: these are usually wrong when a smaller mechanism would do. Unless the question explicitly says "we've tried the simple thing and it didn't work."
• Eliminate "addresses the wrong layer" answers. If the problem is tool ordering, an answer about tool availability is wrong. If the problem is decomposition, an answer about the synthesis agent is wrong.
• Of the remaining one or two, pick the smallest mechanism that fixes the root cause.

Time and pacing

• There's no penalty for guessing. Answer everything. An unanswered question is scored as incorrect.
• If a question is taking more than two minutes, mark and move on. Come back with fresh eyes.
• Trust your first read on the pattern questions (Patterns A–G). Second-guessing usually moves you toward over-engineered distractors.

The week before

• Re-read the six scenarios until you can recall each one cold.
• Re-read the sample questions and explanations. The explanations teach the test's grammar.
• Run through your Lab 1 and Lab 2 code one more time. The pattern questions become trivial when the code is fresh.
• Take the practice exam if you have access. It's the highest-leverage hour you can spend.

Closing

This exam tests one thing more than any other: do you have the disposition of someone who has shipped agentic systems to production? The candidate who has lived through a misrouted refund, a coordinator that decomposed too narrowly, or an extraction schema that hallucinated to satisfy a required field: that candidate already knows most of the answers.

The exam is generous to the practitioner and unforgiving to the memorizer. Build the labs. The questions will look like things you've already debugged. — TWD

If you internalize the five judgments, recognize the seven question patterns, and complete the four labs, the rest is reading the question carefully and matching the answer to the smallest mechanism that fixes the root cause. That's the test. Good luck.

Companion reading on the same site: Best Practices covers the model-agnostic disposition this exam tests. Claude Code covers the tool you'll use in Domain 3.