AI Knowledge Center 🧠 Concepts
The exam is scenario-grounded

The 6 production scenarios

Every CCA-F question lives inside one of six production settings. If you can recognize the setting and recall its failure modes, half the work is done. For each: the setup, the task statements it leans on, the high-yield traps, and worked mini-cases (click to reveal the reasoning). Reviewed 2026-06-05.

Why these six — and not, say, e-commerce? These aren’t our picks. They are the six production scenarios the real Claude Certified Architect — Foundations exam is built on (Anthropic launched it 2026-03-12). Each sitting draws 4 of the 6 at random. Customer support is on the official list; e-commerce is not — and swapping it in would make this prep stop matching the exam (e-commerce concerns like orders, refunds, and invoices already live inside the support and data-extraction scenarios). The six are a fixed external spec: don’t add or remove them.
The exam itself is confirmed by multiple independent write-ups; the fine-grained blueprint (exact domain weights, the “4-of-6” rule) is community-reconstructed and verified against code.claude.com/docs — not an official Anthropic publication, and not affiliated with or endorsed by Anthropic.
How to use this · the drill Read the failure modes until the “situation → fix” mapping is automatic. Then work each mini-case top-down: read the Situation, notice the Tempting answer it’s steering you toward, commit to your pick, then reveal. The exam rewards knowing why the other three options are wrong — so every case names the trap and ends in a one-line Principle you can carry to any question in that domain. Cross-reference the quiz (filter by domain) and the cram sheet.

1 · Customer Support Resolution Agent

An agent resolves returns, billing disputes, and account issues through MCP tools (get_customer, lookup_order, process_refund, escalate_to_human).

emphasizes D1D2D5

High-yield failure modes

▸
Tool-ordering / verification skipped → programmatic prerequisite gate or PreToolUse hook (deterministic, not a prompt).
▸
Monetary rule (approval over $500) → PreToolUse hook intercepts and blocks; never trust prompt wording.
▸
Ambiguous identity (multiple name matches) → ask for one more identifier before acting.
▸
Explicit human request → escalate immediately, no investigation first. (Sentiment alone is not a trigger.)
▸
Specific facts lost over many turns → persistent “case facts” block re-injected every turn.
▸
Genuine policy gap (e.g. competitor price-match not in policy) → escalate for interpretation; don’t invent policy.
Mini-case: the double refund

Situation. Retries on transient API failures occasionally double-charge a customer — the server processed the first process_refund before the client timed out and retried. Which fix is complete?

Tempting
Pick one — “just add idempotency keys” or “just classify errors and don’t retry the bad ones.” Each sounds sufficient on its own.
Answer
Both, together. Idempotency keys (hash of operation + customer + amount) make a re-sent request a no-op; error classification stops you retrying something that did arrive. Idempotency alone still won’t recover a request that never landed; classification alone can’t undo a duplicate that already processed.

Principle When a failure has two independent causes (already-applied vs never-arrived), no single fix covers both — make the side-effect idempotent and the retry conditional.

Mini-case: which escalation is justified?

Situation. After looking up the customer and order, which case most justifies firing escalate_to_human?

Tempting
Escalate the hardest-sounding or angriest request — a combined billing-plus-return question, or a customer who’s clearly upset.
Answer
A competitor price-match request when policy allows own-site matching within 14 days but is silent on competitors. That’s a genuine policy gap — the agent must not invent a rule. A “change my mind” cancel and a combined billing+return question are both within the agent’s competence, complexity and sentiment notwithstanding.

Principle Escalate on policy silence, not on difficulty or sentiment. If the rules don’t cover the case, a human decides; if they do, the agent acts — even when the request is complex or the customer is angry.

2 · Code Generation with Claude Code

Generating, refactoring, debugging, and documenting code in Claude Code — using slash commands/skills, CLAUDE.md, plan mode, and built-in tools.

emphasizes D3D5

High-yield failure modes

▸
Teammate doesn’t see your standards → they were in ~/.claude/CLAUDE.md (user scope, not committed). Move to project CLAUDE.md.
▸
Bloated 400-line CLAUDE.md → keep always-on standards in CLAUDE.md; move workflow-specific guidance to skills.
▸
Conventions only when editing certain files → .claude/rules/ with a paths: glob.
▸
Large restructure / many files → plan mode. Trivial change → direct execution (don’t over-ceremony).
▸
Verbose skill floods context → context: fork frontmatter.
▸
Stale prior-session findings → new session + injected structured summary; note what changed.
Mini-case: the unfamiliar caching task

Situation. A developer who doesn’t know cache-invalidation or stampede prevention asks Claude to “implement Redis caching, now.” What surfaces the design concerns they can’t even name yet?

Tempting
Reach for plan mode or TDD — they feel like the rigorous choices. But plan mode plans a known spec, and TDD assumes you already know the edge cases to test.
Answer
The interview pattern: have Claude ask targeted questions first (TTL? invalidation strategy? stampede protection?), surfacing requirements the developer didn’t know to specify — then build.

Principle When the gap is unknown requirements, make the model ask before it builds. Plan mode and TDD refine a spec you already have; the interview pattern discovers one.

Mini-case: personalize a shared command

Situation. A dev wants to tweak the team’s shared, committed /commit skill — but only for their own machine.

Tempting
Edit the project’s .claude/skills/commit/SKILL.md directly — it’s right there. (Now everyone gets your personal tweak, and your change fights the next teammate’s.)
Answer
Create a personal ~/.claude/skills/commit/SKILL.md with the same name. User-scope skills shadow same-named project skills, so the team’s committed version is untouched and only you get the tweak.

Principle Personalize by shadowing, not editing: a same-named user-scope file overrides the project one for you alone. Never edit shared/committed config to get a personal change.

3 · Multi-Agent Research System

A coordinator delegates to web-search, document-analysis, and synthesis subagents, producing a cited report.

emphasizes D1D2D5

High-yield failure modes

▸
Narrow/incomplete coverage → the coordinator’s decomposition was too narrow (not a synthesis or search bug).
▸
Duplicate work, 2× tokens → partition scope in the coordinator before delegating.
▸
Keep the coordinator as hub → observability, consistent error handling, controlled context flow. Don’t let subagents talk directly.
▸
Context bloat at synthesis → subagents return structured facts/citations, not verbose prose.
▸
Partial results (some sources failed) → coverage annotations (well-supported vs gap), not discard-or-halt.
▸
Conflicting sources → present both with attribution, annotate the conflict; never average. Preserve claim→source mappings.
Mini-case: parallel vs sequential

Situation. The coordinator needs the web-search and document-analysis subagents to run at the same time. How do you get true concurrency?

Tempting
Call one subagent, then the next (feels parallel because it’s “both”), or reach for fork_session because it has “fork” in the name.
Answer
Emit multiple Agent/Task calls within a single response. Separate turns run sequentially by definition; fork_session branches your own exploration, it doesn’t fan out worker types.

Principle Concurrency comes from one response with many calls, not many responses. One call per turn is sequential no matter how it’s phrased.

Mini-case: three search outcomes

Situation. One search subagent gets three results: academic = 15 papers; industry = “0 results”; patent = “connection timeout.” How should it report back to the coordinator?

Tempting
Treat “0 results” and “timeout” the same — both “found nothing” — or silently retry the timeout and hide it.
Answer
Report all three distinctly: academic = success; industry = a valid empty result (isError:false); patent = isError:true with structured error context. Each warrants a different coordinator move — accept / accept / consider-retry.

Principle “No results” and “couldn’t check” are different facts — never collapse them. Preserve the empty-vs-error distinction so the caller can choose accept vs retry.

4 · Developer Productivity with Claude

An agent explores unfamiliar/legacy codebases, generates boilerplate, and automates tasks with built-in tools and MCP.

emphasizes D1D2D3

High-yield failure modes

▸
Discovery floods context → use the read-only Explore subagent (or a forked skill) to map and summarize.
▸
Over-broad tool abused (general fetch_url doing ad-hoc search) → replace with a constrained, validating tool (least privilege).
▸
Too many tools on one agent → ~4–5 per agent; split across subagents.
▸
Shared MCP server, per-dev secrets → project .mcp.json with ${ENV} expansion.
▸
Heterogeneous tool output formats → a PostToolUse hook normalizes results before the model sees them (works even for unmodifiable third-party MCP tools).
Mini-case: normalizing third-party output

Situation. Tools return timestamps in Unix, ISO 8601, and numeric status codes; some are third-party MCP servers you can’t modify. What’s the most maintainable way to normalize them?

Tempting
Tell the model in the prompt to “handle the different formats” (probabilistic, doesn’t scale), or hand-wrap each tool (impossible for servers you don’t own).
Answer
A PostToolUse hook — one deterministic interception point that transforms every tool’s output in code before the model sees it, including data from third-party tools you can’t touch.

Principle Normalize once, deterministically, at the boundary — a hook — not per-tool and not in the prompt. Hooks reach even tools you don’t own; prompts are probabilistic and don’t scale.

5 · Claude Code for Continuous Integration (CI/CD)

Automated code review, test generation, and PR feedback inside a pipeline.

emphasizes D3D4

High-yield failure modes

▸
CI hangs on input → the -p / --print headless flag.
▸
Prose output, need structured → --output-format json + --json-schema, then post via API.
▸
Duplicate comments on re-review → include prior findings in context; report only new/unresolved.
▸
14-file PR, inconsistent depth → attention dilution; per-file passes + a separate integration pass.
▸
Noisy false positives → explicit categorical criteria; temporarily disable a contaminating category.
▸
Batch API choice → batch the non-blocking job (nightly), keep blocking checks synchronous; resubmit only failures via custom_id.
Mini-case: subtle bugs slip through

Situation. Subtle bugs are caught only in human review; the generator’s own reasoning shows it considered and dismissed them. Adding a same-session self-review didn’t help. What architecture catches them?

Tempting
“Ask the model to review its own work more carefully” — a self-review in the same session. It re-reads its own rationalizations and clears them again.
Answer
A separate, independent review instance with no access to the generator’s reasoning — fresh eyes don’t inherit the author’s blind spots. (CCA-F task 4.6: multi-instance review.)

Principle A reviewer that can see the author’s reasoning inherits its blind spots. For real scrutiny, withhold the rationale and use a fresh instance — in-session self-review catches little.

6 · Structured Data Extraction

Extracting from unstructured documents, validating against JSON schemas, maintaining high accuracy at scale.

emphasizes D4D5

High-yield failure modes

▸
JSON syntax errors under load → tool use with a JSON schema (forces syntax).
▸
Sums/dates wrong despite schema → schema = syntax, not semantics; add validation + retry.
▸
“Required” field often absent → fabrication factory; make it optional/nullable.
▸
Inline content missed (no header) → 2–4 few-shot examples covering inline vs headered forms.
▸
Format-only error (e.g. date format) → targeted validate-and-retry with the specific error, not a full re-run.
▸
96% aggregate accuracy → stratify by type/field before trusting it; calibrate any confidence score against labeled data.
Mini-case: the tax_id trap

Situation. 40% of invoices carry a tax_id, 60% don’t. You mark it a required string in the schema. What happens on the 60% that lack one?

Tempting
Assume “required” just enforces good data — so the model will skip it or error when it’s missing. It does neither.
Answer
The model fabricates a value to satisfy the constraint. Fix: make the field optional/nullable so the model can honestly return null for “not present.”

Principle Required fields are fabrication factories: a “required” field the source often lacks forces invention. Make genuinely-optional data nullable so “not present” is expressible.

Mini-case: removing human review

Situation. The pipeline reports 96% accuracy over 10,000 invoices and the team wants to drop the human reviewer. What’s the first validation step?

Tempting
Take 96% at face value — “that’s well above our bar, ship it.” The aggregate is exactly what hides the risk.
Answer
Stratify accuracy by document type and field. A blended 96% can mask a catastrophe — 99.9% on digital PDFs and 40% on handwritten scans still averages ~96%. Confirm per-segment consistency before removing the human.

Principle An aggregate metric is a ceiling on what you know, not a floor on what you ship. Stratify before trusting it — a high average can hide a segment failing wholesale.

Next Now run the practice quiz in exam mode and watch the per-domain breakdown — your weak scenario will show up as a weak domain.