The 6 concepts of cert prep

Tap any concept to jump to its 5-card cluster.

• 1Cert Domain Coverage MapThe 5 domains, their weights, and where they live in the course
• 2Anti-Patterns Master ReferenceThe exam's most-tested wrong answers
• 3Validation-Retry PatternThe cert's preferred resilience pattern
• 4Information ProvenanceClaim → source mapping for multi-agent systems
• 5Exam Scenario WalkthroughsWorked examples of cert-style questions
• 6Mock Exam PracticePacing, elimination, and exam-day strategy

The 5 domains, weighted

Anthropic's official Claude Certified Architect — Foundations blueprint splits the exam into 5 domains. Each domain owns a set of "task statements" (28 total), and each task statement maps to one or more course modules. If your practice score is weak in a domain, jump to that row instead of re-reading the whole course.

Weights are not equal. D1 Agentic Architecture is the heaviest at 27%. D5 Context & Reliability is the lightest at 15% but punches above its weight on judgment questions. Budget your study time to the weights, not your comfort zones.

The blueprint is a syllabus

BEFORE: You're prepping for a final and your instinct is to re-read the whole textbook front-to-back. Equal time on every chapter, every page. It feels thorough — you're "covering everything."

PAIN: But the professor publishes a syllabus showing chapter weights, and chapter 3 is worth 27% of the final while chapter 9 is worth 5%. Reading them equally means you under-prepare for the heavy chapter and over-prepare for the light one. Same hours in, worse score out.

MAPPING: The cert blueprint is your syllabus. The 5 domains and their weights tell you exactly where points come from. Study to the weights: D1 (27%) gets the most hours, D5 (15%) gets the least — unless your practice scores reveal a weak spot, in which case the weak domain wins regardless of weight.

From blueprint to study plan

1. Read the official blueprint firstAnthropic publishes a Foundations exam guide listing all 5 domains and their 28 task statements. That's the source of truth for what's tested. Anything not on it is out of scope.
2. Map every task statement to a moduleEach task statement points to a "primary" module (taught from scratch) plus "cert tip" callouts in related modules. The map below shows them all.
3. Diagnose with practice scoresTake one full mock early. The per-domain breakdown reveals which row to drill, regardless of weight.
4. Target the row, not the whole moduleYou don't re-read M14. You re-read the cert tip in M14 plus the primary module that owns that exact task statement.
5. Skip the out-of-scope listFine-tuning, OAuth, billing, embedding internals, vector DB internals — not tested. Don't waste hours on them.

5 domains at a glance

Out of scope: fine-tuning, OAuth, billing, MCP server hosting, embedding/vector DB internals, computer use, vision, streaming, rate limits, prompt-caching internals, token-counting algos.

Misconceptions

Wrong answers ARE the anti-patterns

Every cert question has the same shape: 1 correct pattern + 3 plausible-wrong distractors. The distractors are not random nonsense — they're real anti-patterns developers actually ship. If you can recognize the wrong answers as named anti-patterns, half the question is already eliminated.

The cert tests roughly 18 anti-patterns across all 5 domains. They cluster around five themes: parsing natural language to control flow, using prompts where hooks belong, trusting self-reported model output, letting one agent hold too many tools, and aggregating metrics that hide failures.

Medical board impostors

BEFORE: You're studying for medical boards. You know the textbook diagnoses cold — heart attack, pneumonia, appendicitis. The right answers are crisp.

PAIN: The boards don't ask "what's the textbook diagnosis." They show you a patient with chest pain and offer four options: heart attack, acid reflux, pulled muscle, panic attack. Three are plausible impostors. If you only memorized the right answer, you can't tell which option is the real impostor and which is correct.

MAPPING: The cert is the same test. Anti-patterns are the impostors — "use the system prompt for refund limits," "trust Claude's confidence score," "give one agent 18 tools." Each is plausible if you've never been told it's wrong. Memorizing the anti-pattern catalog is how you spot the impostors instantly.

How to use the catalog

1. Read each anti-pattern in BOTH directionsThe wrong move ("parse 'I'm done' to stop the loop") AND the correct move ("check stop_reason"). Two-sided memory.
2. Tag each anti-pattern with its domainD1 anti-patterns show up in agent-loop questions; D2 in tool questions; D5 in metrics questions. Tags speed elimination.
3. Practice naming the anti-pattern out loudWhen you see option D in a question, you should be able to say "AP #2: iteration cap as control" before you even read option C.
4. Watch for combosSome questions stack two anti-patterns: a system-prompt rule (AP #3) inside a same-session review (AP #12). Catching one isn't enough.

10 anti-patterns to know cold

10 of ~18. Desktop has the full set with flip cards.

Misconceptions

Specific feedback fixes specific bugs

The validation-retry loop is the cert's most-tested Domain 4 pattern. Claude returns structurally valid JSON via tool_use — the schema guarantees that. But the values inside may still be wrong. A CPT code field might contain "knee surgery" instead of "27447". Schemas guarantee shape, not meaning.

The trick: when validation fails, do not say "try again." Append specific field-level errors to the conversation — which field, what was expected, what was actually returned. Self-correction accuracy jumps from ~30–40% (generic retry) to 80%+ (specific feedback). Cap at 3 retries per field; after that, flag for human review.

The teacher who writes feedback

BEFORE: A student turns in an essay. The teacher hands it back marked "WRONG, redo." The student rereads it, can't tell what's wrong, and produces a similar essay with similar mistakes.

PAIN: Generic feedback fails because the student doesn't know which sentence to fix. They retry blindly. Multiple cycles burn time and produce only marginal improvement — or no improvement at all.

MAPPING: Generic "try again" is the same useless feedback for Claude. Replace it with surgical comments: "Paragraph 3, sentence 2: cite a source for this claim." That's "Field 'cpt_code': expected 5-digit numeric, got 'knee surgery'." Claude self-corrects the next round because it knows exactly what to fix.

The 4-step loop

1. Extract with tool_useForce the specific extraction tool with tool_choice: {type: "tool", name: "..."} on the first attempt. Schema guarantees structure.
2. Validate against business rulesRun domain checks: regex on CPT codes, format on ICD-10, positivity on units. Schema = structure; validator = meaning.
3. On failure: append SPECIFIC errorsEach error names the field, the expected format, and the actual value. Add as a tool_result with is_error: true.
4. Cap retries per field at 3If the same field fails three times, the source document probably doesn't contain the data — flag for human review instead of looping forever.

Pseudocode

# Validate-retry with per-field failure caps
FUNCTION extract_with_retry(document, max_retries=3):
  field_failures = {}
  messages = [{"role": "user", "content": document}]

  FOR attempt IN 0..max_retries:
    response = CALL Claude(
      tools=[extract_tool],
      tool_choice=force_tool IF attempt==0 ELSE auto,
      messages=messages
    )
    extracted = response.tool_use.input
    errors = validate(extracted)         # business rules

    IF errors is empty:
      RETURN {success: true, data: extracted}

    # Stuck-field check: same field, 3rd failure = data issue
    FOR err IN errors:
      field_failures[err.field] += 1
      IF field_failures[err.field] >= 3:
        RETURN flag_for_human(err.field)

    # THE KEY: append SPECIFIC errors, not "try again"
    detail = JOIN("field 'X': expected Y, got Z" FOR err)
    messages.append(tool_result(detail, is_error=true))

  RETURN {success: false, reason: "max retries"}

Generic "try again": ~35% self-correction. Specific errors: ~80%+. The wording of the feedback is the entire pattern.

Misconceptions

Every claim carries its source

In multi-agent systems, three subagents can return three different answers to the same question. Provenance is the metadata that lets the coordinator decide which to trust — without delegating the decision to Claude. Every claim travels with: source, confidence, timestamp, and agent ID.

This is the cert's signature Domain 5 pattern (task statement 5.6). The exam tests it as Scenario 3 (Multi-Agent Research). Conflict resolution follows a fixed priority chain: trust official sources over aggregators; if reliability ties, trust fresher data; if still tied, flag as "contested" and route to human review.

The journalist's source notes

BEFORE: A reporter writes "sources say the company is bankrupt" without attribution. Maybe it was the CEO; maybe a disgruntled intern; maybe Twitter rumor. The reader can't tell.

PAIN: When two reporters publish opposite claims about the same company, the editor has no basis for deciding which to print. Without source notes, the newsroom is just guessing — and reputations get destroyed by the wrong guess.

MAPPING: Subagent reports without provenance are unsourced reporting. Subagent A says "Acme has a lien" (state filing DB). Subagent B says "no liens" (third-party aggregator). The coordinator is the editor — and provenance is the source notes that let the editor decide official-DB beats aggregator, every time.

Four metadata fields, one priority chain

1. SourceWhich agent/tool/API produced the claim. Direct DB query? Third-party scraper? Critical for reliability ranking.
2. ConfidenceReliability tier of the source. Official state DB = high. Aggregator = medium. User-submitted = low. Hardcoded, not Claude-judged.
3. TimestampWhen was the data retrieved? UCC filings can update daily. Stale "high confidence" data may already be wrong.
4. Agent IDWhich subagent in the pipeline produced the claim. Required for audit-trace when something goes wrong.
5. Resolution chainHighest confidence wins. If tied, freshest wins. If still tied, flag "contested" and emit BOTH sources for human review.

Pseudocode

# Every claim carries provenance metadata
STRUCT Claim:
  text          # the actual claim
  source        # e.g., "ny_state_filing_db"
  confidence    # "high" | "medium" | "low"
  timestamp     # ISO-8601 retrieval time
  agent_id      # which subagent produced it

# Coordinator resolves conflicts deterministically
FUNCTION resolve(claims_for_same_question):
  IF claims.length == 1:
    RETURN {status: "single-source", claim: claims[0]}

  # Step 1: highest source-confidence wins
  ranked = sort_by(claims, key=confidence_rank, desc=true)
  top = ranked[0]
  rivals = [c FOR c IN ranked IF c.confidence == top.confidence]

  # Step 2: tie-break by freshness
  IF rivals.length > 1:
    rivals = sort_by(rivals, key=timestamp, desc=true)

  # Step 3: still disagreeing? mark contested, send to human
  IF rivals[0].text != rivals[-1].text:
    RETURN {status: "contested", sources: rivals, escalate: true}

  RETURN {status: "well-established", claim: rivals[0]}

Reliability ranking is hardcoded. Never delegate "which source is more trustworthy" to Claude — that turns a deterministic decision into a non-deterministic guess.

Misconceptions

Six recurring scenarios power the exam

The cert reuses six scenario backdrops across the entire exam. Each scenario is a 2–3 sentence setup describing a real production system; each gets 3–4 questions hung off it, testing different domain concepts. Recognize the scenario, recall its canonical architecture, and you've already framed the answer.

The scenarios: S1 Customer Support (refunds, escalation), S2 Code Generation (Claude Code, plan mode), S3 Multi-Agent Research (provenance, conflict), S4 Developer Productivity (Agent SDK + MCP), S5 CI/CD (non-interactive, session isolation), S6 Data Extraction (validation-retry, schemas).

Case studies in business school

BEFORE: An MBA student walks into a strategy exam expecting random questions about supply chains, marketing, and finance.

PAIN: Instead, the professor spends the first 5 minutes describing one company — "Acme Corp, $500M revenue, struggling with X" — and then asks four questions all set in that same company. If you didn't recognize it as the case from week 6, you waste minutes re-deriving the situation for each question.

MAPPING: Cert scenarios work identically. "Customer support agent processing refund requests..." — that's S1, and the next three questions will all be about S1 too. Recognize the scenario in the first sentence, recall its canonical architecture, and the question is half-answered before you read the options.

Each scenario's signature decision

1. S1 Customer SupportHook-based refund limits + escalate on policy gaps (NOT sentiment). Watch for prompt-based enforcement distractors.
2. S2 Code GenerationPlan mode for complex tasks + directory-level CLAUDE.md + iterative TDD. Watch for "skip planning" distractors.
3. S3 Multi-Agent ResearchProvenance tracking + context isolation + fork_session. Watch for "average the answers" distractors.
4. S4 Developer ProductivityAgent SDK + built-in tools (Read/Write/Bash/Grep/Glob) + MCP for external data. Watch for "give one agent everything" distractors.
5. S5 CI/CDNon-interactive -p + --output-format json + separate sessions for generate vs review. Watch for same-session reuse distractors.
6. S6 Data ExtractionSchema design + tool_choice forced + validation-retry with specific errors. Watch for "increase max_tokens" distractors.

Parsing an exam question

# Read every question through this filter
FUNCTION parse_question(q):
  # Step 1: identify the scenario
  scenario = match(q.context, [S1..S6])
  IF scenario found:
    canonical_arch = recall_architecture(scenario)
    # now you know what GOOD looks like

  # Step 2: identify the domain being tested
  domain = classify(q.stem) # D1..D5
  expected_patterns = patterns_for(domain)
  expected_anti_patterns = anti_patterns_for(domain)

  # Step 3: scan the 4 options against the catalogs
  FOR option IN q.options:
    IF matches(option, expected_anti_patterns):
      eliminate(option)
    ELIF matches(option, canonical_arch):
      mark_likely(option)

  # Step 4: between remaining options, pick most specific
  RETURN most_specific(remaining)

Scenario → domain → anti-pattern scan → pick. Four passes, ~60 seconds total. Practice until it's reflex.

Misconceptions

Mocks reveal the gap, not just the score

A mock exam isn't a verdict; it's a diagnostic. The single most valuable output is the per-domain breakdown — not the overall score. A 78% overall that's actually D1 92% / D5 60% means D5 is your study target, regardless of weight.

Aim for 800+ on full mocks (passing is 720/1000, so 800 is a comfortable margin). Run at least 2 full-length timed mocks in the final week, under exam conditions: 90-minute timer, 90 seconds per question, no notes. Review every wrong answer to identify which anti-pattern fooled you.

Marathon training, not race day

BEFORE: You're training for a marathon. Your instinct is to run a full 26.2 every weekend to "prove you can do it."

PAIN: Running max distance every week burns you out. You arrive at race day exhausted, with no headroom for the unexpected. The full distance reveals your weak spots, but only if you run it sparingly and rest in between.

MAPPING: Full mock exams are like full marathons. Run 2 in the final week, max. Use the per-domain breakdown the way a runner uses heart-rate data — to find weak spots and rest before race day. The exam morning rewards a rested brain, not a fried one.

The 4-week prep arc

1. Week 1: domain coverageWalk all 5 domains. Map task statements to modules. Skim the cert tip in each module. No mocks yet.
2. Week 2: scenario libraryBuild the 6 scenario architectures + 18 anti-patterns into recall. One short timed quiz at week-end — diagnostic only.
3. Week 3: drilling weak rowsFocus on whichever domain scored lowest. Re-read primary module + cert tip. One full mock; review every wrong answer with anti-pattern names.
4. Week 4: full mocks + sleepTwo full-length timed mocks. Light review only. Sleep more than you study. Walk in calm.

The 90-second loop

# For every question, run this loop
FUNCTION answer_question(q):
  start_timer(seconds=90)
  scenario = identify_scenario(q.context) # S1..S6
  domain = classify(q.stem)               # D1..D5

  # Pass 1: kill the obvious anti-pattern (always 1 exists)
  options = q.options
  options.remove(match_first(options, anti_patterns_for(domain)))

  # Pass 2: check remaining 3 against canonical_arch[scenario]
  best = match_best(options, canonical_arch[scenario])

  IF timer.elapsed > 90:
    flag(q)                # come back later
    pick_best_guess(options) # NEVER leave blank
    CONTINUE
  RETURN best

# Save 10 min at end for flagged questions; review fresh
# Eliminate-first odds: 50-66% (vs 25% pure guessing)

Pacing: ~60 questions in 90 minutes → 90 seconds each, with 10 min reserve. Never leave a question blank — eliminate-first guesses are positive expected value.

Misconceptions

One question per concept

Tap a card to reveal the answer.