# Claude Certified Architect — Foundations Exam Wiki

> Community study-material repository for the Claude Certified Architect — Foundations certification. Grounded in the multilingual study guide, scenario question banks, practical exercises, and interactive HTML practice tests aligned with the official five exam domains.

## Context Links

- [Agent index](https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9/llms.txt)
- [Human interactive wiki](https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9)
- [GitHub repository](https://github.com/paullarionov/claude-certified-architect)

## Repository Metadata

- Repository: paullarionov/claude-certified-architect

- Generated: 2026-06-08T18:27:47.540Z
- Updated: 2026-06-08T18:28:04.927Z
- Runtime: Grok CLI
- Format: Custom
- Pages: 3

## Page Index

- 01. [Certification Opening Brief](https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9/pages/01-certification-opening-brief.md) - Orients Claude Certified Architect — Foundations candidates to the exam blueprint: 720 passing score, five weighted domains, eight scenario families, target candidate profile, and how to navigate this repository's guides, PDFs, and practice assets as a structured study path with clear decision points before deep technical review.
- 02. [Agent Orchestration & MCP Integration Walkthrough](https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9/pages/02-agent-orchestration-mcp-integration-walkthrough.md) - Exam-style deep dive on Domains 1–2 (45% combined weight): agentic loops and stop_reason, AgentDefinition and hub-and-spoke subagents, Task spawning with explicit context passing, SDK hooks, MCP server configuration, tool descriptions, isError handling, and tool_choice — with step-by-step walkthroughs mirroring Customer Support Agent and Multi-Agent Research System scenarios, including common pitfalls like missing coordinator context and unstructured subagent errors.
- 03. [Exam Rehearsal, Practice Tests & Certification Pitfalls](https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9/pages/03-exam-rehearsal-practice-tests-certification-pitfalls.md) - Closing certification page synthesizing Domains 3–5 (Claude Code workflows, prompt engineering with JSON schemas, context management and reliability): four hands-on practical exercises with domain mappings, worked example and practice-test question patterns, interactive HTML rehearsal workflow, out-of-scope topic traps, and the final preparation checklist — giving candidates a deliberate finish before sitting the exam.

## Source File Index

- `.github/workflows/markdown-to-pdf.yml`
- `.github/workflows/pdf-style.css`
- `guide_en.MD`
- `guide_es.md`
- `guide_it.md`
- `guide_ru.MD`
- `guide_zh.md`
- `image-1.png`
- `image.png`
- `pdf/guide_en.pdf`
- `practical_test_en.html`
- `practical_test_ja.html`
- `practical_test_ko.html`
- `practical_test_ru.html`
- `practical_test_zh.html`
- `README.md`
- `utils/build_practical_test_html.py`

---

## 01. Certification Opening Brief

> Orients Claude Certified Architect — Foundations candidates to the exam blueprint: 720 passing score, five weighted domains, eight scenario families, target candidate profile, and how to navigate this repository's guides, PDFs, and practice assets as a structured study path with clear decision points before deep technical review.

- Page Markdown: https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9/pages/01-certification-opening-brief.md
- Generated: 2026-06-08T18:27:46.843Z

### Source Files

- `README.md`
- `guide_en.MD`
- `guide_es.md`
- `guide_ru.MD`
- `guide_zh.md`
- `pdf/guide_en.pdf`
- `image.png`
- `image-1.png`

<details>
<summary>Relevant source files</summary>
The following files were used as context for generating this wiki page:
- [README.md](README.md)
- [guide_en.MD](guide_en.MD)
- [guide_es.md](guide_es.md)
- [guide_ru.MD](guide_ru.MD)
- [guide_zh.md](guide_zh.md)
- [pdf/guide_en.pdf](pdf/guide_en.pdf)
- [practical_test_en.html](practical_test_en.html)
- [utils/build_practical_test_html.py](utils/build_practical_test_html.py)
- [image.png](image.png)
- [image-1.png](image-1.png)
</details>

# Certification Opening Brief

The **Claude Certified Architect — Foundations** (CCA-F) exam tests whether you can make sound trade-off decisions when building production Claude applications. This page orients you to the official blueprint—passing score, weighted domains, scenario families, and target candidate profile—and maps how this repository's guides, PDFs, and practice assets form a structured study path with clear decision points before you dive into deep technical review.

If you treat certification prep as a single long read-through, you will miss the exam's actual shape: 60 multiple-choice questions drawn from four randomly selected scenario families, scored on a 100–1000 scale where **720** is the passing threshold. This brief helps you decide *where to start*, *what to prioritize by weight*, and *when you are ready* for scenario drills and the timed practice exam.

---

## Exam Blueprint at a Glance

The official exam is a **120-minute proctored session** with **60 multiple-choice questions** (one correct answer out of four). Results arrive within two business days with section breakdowns. There is **no guessing penalty**—answer every question.

Sources: [guide_en.MD:29-36](), [image.png]()

| Parameter | Value |
|---|---|
| Question format | Multiple choice (1 of 4) |
| Scoring scale | 100–1000 |
| **Passing score** | **720** |
| Guessing penalty | None |
| Scenarios per exam | **4 of 8** (randomly selected) |
| Session length | 120 minutes, no external resources |

### Five Weighted Domains

Domain weighting tells you where to invest study time. Agent architecture carries the largest share; context management is smallest but still decisive at the margin.

Sources: [guide_en.MD:40-48]()

| # | Domain | Weight | Primary technologies |
|---|---|---|---|
| 1 | Agent architecture and orchestration | **27%** | Claude Agent SDK, coordinator/subagent patterns, hooks |
| 2 | Tool design and MCP integration | **18%** | MCP tools, `isError`, tool descriptions |
| 3 | Claude Code configuration and workflows | **20%** | CLAUDE.md, Skills, planning mode, CI integration |
| 4 | Prompt engineering and structured output | **20%** | JSON schemas, few-shot, `tool_use`, Batch API |
| 5 | Context management and reliability | **15%** | Escalation, error propagation, provenance, confidence |

**Study implication:** A candidate strong in Claude Code but weak in multi-agent orchestration is under-prepared for roughly half the exam (Domains 1 + 5 overlap heavily with scenario design). Weight domains, not just technologies.

---

## Target Candidate Profile

The ideal candidate is a **solution architect** with at least **six months** of hands-on experience shipping production Claude applications. The exam assumes you already work with:

- **Claude Agent SDK** — multi-agent orchestration, subagent delegation, tool integration, lifecycle hooks
- **Claude Code** — CLAUDE.md, MCP servers, Agent Skills, planning mode
- **Model Context Protocol (MCP)** — tools and resources for backend integration
- **Prompt engineering** — JSON schemas, few-shot examples, extraction templates
- **Context windows** — long documents, multi-agent context passing
- **CI/CD pipelines** — automated code review, test generation
- **Escalation and reliability** — error handling, human-in-the-loop

Sources: [guide_en.MD:15-25]()

### Self-Assessment Decision Point

Before opening Part I theory, honestly score yourself 1–5 on each bullet above. If three or more areas are below 3, complete the free Anthropic Academy courses listed in [README.md:49-65]() *before* scenario drills. The repository guide assumes practitioner familiarity; it teaches exam trade-offs, not beginner API syntax.

---

## Eight Scenario Families

The exam frames every question inside a realistic industry scenario. You will face **four of these eight** on test day. Each scenario stresses different domain combinations.

Sources: [guide_en.MD:52-76]()

| # | Scenario family | What you are architecting |
|---|---|---|
| 1 | Customer Support Agent | Returns, billing, account issues via Agent SDK + MCP tools (`get_customer`, `lookup_order`, `process_refund`, `escalate_to_human`); 80%+ first-contact resolution |
| 2 | Code Generation with Claude Code | Generation, refactoring, debugging, documentation; slash commands, CLAUDE.md, planning mode |
| 3 | Multi-Agent Research System | Coordinator delegates to web research, document analysis, synthesis, report generation with citations |
| 4 | Developer Productivity Tools | Codebase exploration, boilerplate, automation via built-in tools (Read, Write, Bash, Grep, Glob) + MCP |
| 5 | Claude Code for Continuous Integration | CI/CD code review, test generation, PR feedback; minimize false positives |
| 6 | Structured Data Extraction | Unstructured → structured via JSON schemas, edge cases, validation loops |
| 7 | Conversational AI Architecture Patterns | Multi-turn context, memory, safe tool execution, ambiguous inputs |
| 8 | Agentic AI Tools | **Content gap** — reported by candidates but not yet documented in this guide |

Scenario 8 is an explicit community gap. If you encounter it on the real exam, contribute details via [GitHub Issues](https://github.com/paullarionov/claude-certified-architect/issues) so the guide can close the coverage hole.

Sources: [guide_en.MD:75-76]()

### Scenario-to-Domain Mapping (Mental Model)

```text
┌─────────────────────────────────────────────────────────────────┐
│                     EXAM SESSION (4 of 8)                       │
├──────────────┬──────────────┬──────────────┬────────────────────┤
│  Scenario    │  Dominant    │  Secondary   │  Repo practice     │
│  family      │  domains     │  domains     │  coverage          │
├──────────────┼──────────────┼──────────────┼────────────────────┤
│ 1 Support    │ D1, D2       │ D5           │ Guide Qs + HTML ✓  │
│ 2 Code Gen   │ D3           │ D4           │ Guide Qs + HTML ✓  │
│ 3 Research   │ D1           │ D2, D5       │ Guide Qs + HTML ✓  │
│ 4 Dev Tools  │ D3, D2       │ D5           │ Guide only         │
│ 5 CI/CD      │ D3, D4       │ D5           │ Guide Qs + HTML ✓  │
│ 6 Extraction │ D4           │ D5           │ Guide + Exercise 3 │
│ 7 Conv. AI   │ D5, D4       │ D1           │ Guide theory       │
│ 8 Agentic    │ Unknown      │ Unknown      │ **Gap**            │
└──────────────┴──────────────┴──────────────┴────────────────────┘
```

The interactive `practical_test_en.html` currently drills **four** scenario families (15 questions each, 60 total): Customer Support, Multi-agent Research, Code Generation, and CI/CD. Scenarios 4, 6, 7, and 8 rely on guide content and practical exercises instead.

Sources: [practical_test_en.html:242](), [utils/build_practical_test_html.py:1-4]()

---

## Repository Study Path

This repository is a community study companion—not the official exam portal. Use it as a layered curriculum with explicit decision gates.

Sources: [README.md:1-47]()

```mermaid
flowchart TD
    subgraph entry [Entry]
        README[README.md]
        LANG{Preferred language?}
    end

    subgraph core [Core Guide — guide_*.md / pdf/]
        BLUEPRINT[Blueprint: domains + scenarios]
        PART1[PART I: Theory Foundations<br/>Chapters 1–9]
        PART2[PART II: Exam Domain Notes<br/>Domains 1–5]
        QUESTIONS[60 Worked Exam Questions]
        EXERCISES[Practical Exercises 1–4]
        APPENDIX[Appendix + Out-of-Scope]
    end

    subgraph practice [Practice Assets]
        HTML[practical_test_*.html]
        PDF[pdf/guide_*.pdf]
    end

    subgraph official [Official Access]
        PORTAL[anthropic.skilljar.com]
    end

    README --> LANG
    LANG -->|en, es, ru, zh, ja, …| BLUEPRINT
    BLUEPRINT --> PART1
    PART1 --> GATE1{6+ months<br/>hands-on?}
    GATE1 -->|No| ACADEMY[Anthropic Academy courses]
    GATE1 -->|Yes| PART2
    PART2 --> QUESTIONS
    QUESTIONS --> HTML
    EXERCISES --> HTML
    HTML --> GATE2{≥85% on<br/>practice test?}
    GATE2 -->|No| PART2
    GATE2 -->|Yes| PORTAL
    BLUEPRINT -.-> PDF
```

### Asset Guide

| Asset | Location | Best use |
|---|---|---|
| Language guides | `guide_en.MD`, `guide_es.md`, `guide_ru.MD`, `guide_zh.md`, + 6 more | Primary study text; identical blueprint across translations |
| Offline PDFs | `pdf/guide_*.pdf` | Auto-generated on merge; same content, portable reading |
| Interactive practice | `practical_test_en.html` (+ `ru`, `zh`, `ja`, `ko`) | Timed drill; scores wrong answers **by scenario** |
| Certificate reference | `image-1.png` | Visual example of earned credential |
| Official portal | [Skilljar access request](https://anthropic.skilljar.com/claude-certified-architect-foundations-access-request) | Exam registration (partner network required) |

Sources: [README.md:17-47](), [.github/workflows/markdown-to-pdf.yml]()

### Recommended Reading Order

**Phase 0 — Orient (this page + blueprint).** Read the Introduction, Target Candidate, Exam Format, Domains, and Scenarios sections at the top of your language guide. Skim the Official Documentation table for bookmarking.

**Phase 1 — Theory Foundations (Part I).** Nine chapters organized by technology (Claude API, tools, Agent SDK, MCP, Claude Code, prompt engineering, batches, decomposition, escalation)—*not* by exam domain. This builds the mental models Part II assumes.

Sources: [guide_en.MD:110-114]()

**Phase 2 — Domain Notes (Part II).** Re-read the same material through the exam's five-domain lens. Focus on **Key knowledge** and **Key skills** subsections—these mirror what section breakdowns likely measure.

Sources: [guide_en.MD:1511-1515]()

**Phase 3 — Scenario Questions.** Work through all 60 explained questions. Read *why* the correct answer wins and why each distractor fails—exam questions test trade-off reasoning, not trivia recall.

Sources: [guide_en.MD:1938]()

**Phase 4 — Practical Exercises.** Hands-on labs mapping to domains:

| Exercise | Focus | Domains |
|---|---|---|
| 1 — Multi-tool agent with escalation | Agent loop, MCP errors, hooks | 1, 2, 5 |
| 2 — Claude Code team config | CLAUDE.md, rules, skills, MCP | 3, 2 |
| 3 — Structured extraction pipeline | Schemas, validation, Batch API | 4, 5 |
| 4 — Multi-agent research pipeline | Coordinator, parallel Task, provenance | 1, 2, 5 |

Sources: [guide_en.MD:3283-3341]()

**Phase 5 — Timed Practice Exam.** Open `practical_test_en.html` in a browser. Complete all 60 questions in one sitting (mirrors the 120-minute official constraint). Review the per-scenario incorrect-answer summary to target weak families.

Sources: [README.md:45-47](), [guide_en.MD:3405]()

---

## Decision Points Before Deep Technical Review

Use these gates to avoid studying the wrong material at the wrong depth.

### Gate 1: Eligibility and Access

Certification is currently restricted to **Anthropic Partner Network** members with a verified partner company email. Free for the first 5,000 partner employees; general availability will be $99.

Sources: [README.md:11-15]()

**Decision:** If you lack partner access, you can still study from this repository, but you cannot schedule the proctored exam until approved. Apply via [claude.com/partners](https://claude.com/partners) if needed.

### Gate 2: Experience Baseline

**If < 6 months hands-on:** Start with Anthropic Academy courses (especially Agent Skills, MCP intro, Claude Code in Action, Building with the Claude API) before Part I chapters.

**If ≥ 6 months hands-on:** Skim Part I for gaps only; prioritize Part II domain notes weighted 27% and 20% domains.

Sources: [guide_en.MD:17](), [README.md:49-65]()

### Gate 3: Scenario Coverage Gap

Because only four scenarios appear per exam and the HTML practice test covers four families, you must **not** treat a high practice score as full readiness. Explicitly study guide questions for **Developer Productivity Tools**, **Structured Data Extraction**, and **Conversational AI Architecture Patterns** even though they are absent from the interactive test.

### Gate 4: Out-of-Scope Filter

Do not waste time on topics the guide explicitly excludes: fine-tuning, API billing, cloud-provider configs, streaming, computer use, vision, tokenization internals, and similar.

Sources: [guide_en.MD:3366-3385]()

### Gate 5: Exam-Day Strategy

| Situation | Recommended action |
|---|---|
| Unsure between two answers | Pick the best trade-off; no penalty for guessing |
| Question involves tool ordering | Prefer programmatic enforcement (hooks, preconditions) over prompt-only fixes |
| Multi-agent error handling | Return structured context to coordinator; never silently swallow failures |
| Conflicting source data | Preserve both values with attribution; escalate reconciliation to coordinator |
| Claude Code in CI | Use `-p` / `--print` for non-interactive mode; isolate review from generation session |

Sources: [guide_en.MD:34-35](), [guide_en.MD:1558-1566](), [guide_en.MD:1881-1891]()

---

## Worked Example: Exam-Style Reasoning Walkthrough

This walkthrough mirrors Scenario 3 (Multi-Agent Research System)—a family that appears in both the guide and the interactive practice test.

**Situation:** A document analysis agent discovers that two credible sources contain directly contradictory statistics for a key metric: a government report states 40% growth, while an industry analysis states 12%. Both sources look credible, and the discrepancy could materially affect the research conclusions.

**Question:** How should the document analysis agent handle this situation most effectively?

| Option | Approach | Verdict |
|---|---|---|
| A | Apply credibility heuristics; pick one number; footnote the discrepancy | ✗ Agent arbitrarily resolves conflict outside its scope |
| B | Include both numbers without marking conflict; let synthesis decide silently | ✗ Hides uncertainty; provenance lost |
| C | Stop analysis; immediately escalate to coordinator | ✗ Blocks core work; over-escalation |
| **D** | **Complete analysis with both numbers, explicit conflict annotation and source attribution; let coordinator reconcile before synthesis** | **✓ Correct** |

**Step-by-step reasoning:**

1. **Identify the agent's role boundary.** The document analysis agent extracts and reports; it does not adjudicate which government or industry source is authoritative.
2. **Apply the responsibility-separation pattern.** Complete core work without blocking; do not guess which statistic is correct.
3. **Preserve provenance.** Both values stay attached to their sources—critical for Domain 5 synthesis requirements.
4. **Route reconciliation upward.** The coordinator has broader context (other agents' findings, user goals) to resolve or present uncertainty.
5. **Reject distractors systematically.** A uses unreliable heuristics; B conceals conflict; C sacrifices throughput for a decision that belongs at coordination level.

Sources: [practical_test_en.html:242](), [guide_en.MD:1921-1934]()

This pattern—**complete locally, annotate uncertainty, delegate reconciliation**—recurs across scenarios. Recognizing it quickly is high-value exam prep.

---

## Domain Quick Reference: What Examiners Test

### Domain 1 — Agent Architecture (27%)

The highest-weight domain. Expect questions on agent loop lifecycle (`stop_reason` of `"tool_use"` vs `"end_turn"`), hub-and-spoke coordinator patterns, explicit subagent context passing via the `Task` tool, hooks for deterministic enforcement, and fixed vs adaptive task decomposition.

Sources: [guide_en.MD:1515-1603]()

### Domain 2 — Tool Design & MCP (18%)

Tool descriptions are the primary selection mechanism. Study `isError` semantics, structured error categories, renaming tools to eliminate overlap, and least-privilege tool interfaces.

Sources: [guide_en.MD:1607-1676]()

### Domain 3 — Claude Code (20%)

CLAUDE.md hierarchy, `.claude/rules/` path globs, Skills with `context: fork`, planning mode vs direct execution, and headless CI usage (`-p`, `--output-format json`).

Sources: [guide_en.MD:1678-1761]()

### Domain 4 — Prompt Engineering (20%)

Explicit criteria beat vague instructions; few-shot for ambiguous cases; `tool_use` + JSON Schema for guaranteed structure; Batch API economics; multi-pass review architectures.

Sources: [guide_en.MD:1764-1845]()

### Domain 5 — Context & Reliability (15%)

Escalation triggers (explicit human request, policy gaps, no progress), structured error propagation in multi-agent systems, scratchpad files, confidence calibration, and provenance preservation during synthesis.

Sources: [guide_en.MD:1849-1934]()

---

## Preparation Recommendations (From the Guide)

The guide's authors suggest eight concrete activities before exam day:

1. Build a full Agent SDK loop with tool calling, error handling, and session management
2. Configure Claude Code on a real project (CLAUDE.md hierarchy, rules, skills, MCP)
3. Design and test MCP tools with differentiated descriptions and structured errors
4. Build a data extraction pipeline with schemas, validation/retry, and Batch API
5. Practice few-shot prompting for ambiguous scenarios
6. Study context management (fact extraction, scratchpads, subagent delegation)
7. Understand escalation and human-in-the-loop patterns
8. **Take the practice exam** — same scenarios and format as the real test

Sources: [guide_en.MD:3389-3405]()

---

## Summary

The CCA-F exam rewards practitioners who make architecture trade-offs under realistic scenario pressure: **720** on a 100–1000 scale, **five weighted domains** (led by 27% agent architecture), and **four randomly drawn scenario families** from a pool of eight. This repository organizes prep into blueprint orientation, Part I theory, Part II domain notes, 60 worked questions, four hands-on exercises, multilingual PDFs, and an interactive 60-question practice test—use the decision gates above to sequence them efficiently.

Start with the blueprint sections of your preferred `guide_*.md`, validate your experience baseline, study all eight scenario families (not only the four in the HTML test), drill domain-weighted weak spots, then sit the timed practice exam. When you consistently score well and can articulate *why* each correct answer wins, you are ready to register through the official Skilljar portal and sit the 120-minute proctored session.

Sources: [README.md:43-47](), [guide_en.MD:29-48](), [guide_en.MD:3389-3405]()

---

## 02. Agent Orchestration & MCP Integration Walkthrough

> Exam-style deep dive on Domains 1–2 (45% combined weight): agentic loops and stop_reason, AgentDefinition and hub-and-spoke subagents, Task spawning with explicit context passing, SDK hooks, MCP server configuration, tool descriptions, isError handling, and tool_choice — with step-by-step walkthroughs mirroring Customer Support Agent and Multi-Agent Research System scenarios, including common pitfalls like missing coordinator context and unstructured subagent errors.

- Page Markdown: https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9/pages/02-agent-orchestration-mcp-integration-walkthrough.md
- Generated: 2026-06-08T18:27:29.527Z

### Source Files

- `guide_en.MD`
- `README.md`
- `practical_test_en.html`
- `practical_test_ru.html`
- `practical_test_ja.html`
- `practical_test_zh.html`
- `practical_test_ko.html`

<details>
<summary>Relevant source files</summary>

The following files were used as context for generating this wiki page:

- [guide_en.MD](guide_en.MD)
- [README.md](README.md)
- [practical_test_en.html](practical_test_en.html)
- [practical_test_ru.html](practical_test_ru.html)
- [practical_test_ja.html](practical_test_ja.html)
- [practical_test_zh.html](practical_test_zh.html)
- [practical_test_ko.html](practical_test_ko.html)

</details>

# Agent Orchestration & MCP Integration Walkthrough

Domains 1 and 2 together account for **45%** of the Claude Certified Architect — Foundations exam (27% agent architecture and orchestration, 18% tool design and MCP integration). This page is an exam-style deep dive: it walks through the agentic loop, coordinator–subagent patterns, MCP integration, and the decision points that appear repeatedly in the **Customer Support Agent** and **Multi-Agent Research System** scenarios. Every pattern below is grounded in the study guide and practice questions—not in hypothetical APIs.

---

## Why These Topics Matter on the Exam

The certification tests whether you can make sound trade-off decisions in production agent systems. Exam questions rarely ask you to recite definitions; they present a log pattern, a metric regression, or an architectural proposal and ask which fix is *most effective*. Domains 1–2 reward candidates who understand:

1. **When the model drives the loop** (`stop_reason`) vs when **your code must enforce guarantees** (hooks, preconditions).
2. **How context flows** in hub-and-spoke multi-agent systems—and what breaks when it does not.
3. **How tools are selected and scoped** (descriptions, `tool_choice`, least-privilege `allowed_tools`).
4. **How MCP errors are surfaced** so agents can recover intelligently.

Sources: [guide_en.MD:40-48](guide_en.MD), [guide_en.MD:54-61](guide_en.MD)

---

## Domain Map: What You Must Know

| Topic | Domain | Exam weight | Typical scenario |
|---|---|---|---|
| Agentic loop & `stop_reason` | 1 | 27% | Any autonomous agent |
| `AgentDefinition`, hub-and-spoke, `Task` spawning | 1 | 27% | Multi-Agent Research System |
| SDK hooks (PreToolUse, PostToolUse) | 1 | 27% | Customer Support Agent |
| Tool descriptions & `tool_choice` | 2 | 18% | Customer Support, data extraction |
| MCP config, `isError`, resources | 2 | 18% | Customer Support Agent |
| Structured subagent errors | 1 + 2 | 45% | Multi-Agent Research System |

---

## Part 1: The Agentic Loop and `stop_reason`

### How the loop works

An agentic system is not a single API call. It is a **model-driven loop** where Claude decides which tool to call next based on accumulated context:

```text
Send request with tools
    │
    ▼
Receive response → check stop_reason
    │
    ├─ "tool_use"  → execute tool(s), append results, loop
    └─ "end_turn"  → task complete, return to user
```

Sources: [guide_en.MD:310-321](guide_en.MD)

### `stop_reason` values that control flow

| Value | Meaning | Your action |
|---|---|---|
| `"tool_use"` | Model wants to call a tool | Execute tool(s), append `tool_result` to history, send another request |
| `"end_turn"` | Model finished | Stop the loop; show result to user |
| `"max_tokens"` | Response truncated | Increase limit or handle partial output |
| `"stop_sequence"` | Hit a stop sequence | Application-specific handling |

For agentic systems, `"tool_use"` and `"end_turn"` are the control signals. The **only reliable completion signal** is `stop_reason == "end_turn"`.

Sources: [guide_en.MD:156-167](guide_en.MD), [guide_en.MD:325-330](guide_en.MD)

### Anti-patterns the exam penalizes

| Anti-pattern | Why it fails |
|---|---|
| Parsing assistant text for "Task completed" | Model wording is unreliable |
| Using `max_iterations=5` as primary stop condition | Arbitrary limit, not completion |
| Treating any text response as "done" | Model may still need tools |

**Exam takeaway:** Continue the loop on `"tool_use"`; stop on `"end_turn"`. Full conversation history must be sent on every request—the model does not persist state between calls.

Sources: [guide_en.MD:1519-1527](guide_en.MD), [guide_en.MD:154-154](guide_en.MD)

### Worked example: reducing loop count (Customer Support)

**Situation:** The agent averages 4+ API loops per resolution because `get_customer` and `lookup_order` are requested in separate sequential turns.

**Decision point:** Should you add composite tools, speculative execution, or prompt bundling?

**Correct approach:** Instruct Claude in the prompt to **bundle related tool requests into one turn**. Claude can request multiple tools in a single response; prompting for bundling fixes the sequential pattern with minimal architectural change.

**Why not the others:** Speculative execution wastes calls; composite tools add maintenance; increasing `max_tokens` does not change tool-call behavior.

Sources: [practical_test_en.html](practical_test_en.html) (Q53), [guide_en.MD:1519-1521](guide_en.MD)

---

## Part 2: `AgentDefinition` and Hub-and-Spoke Orchestration

### `AgentDefinition` — the agent configuration object

`AgentDefinition` configures each agent's identity, instructions, and tool access:

```python
agent = AgentDefinition(
    name="customer_support",
    description="Handles customer requests for returns and order issues",
    system_prompt="You are a customer support agent...",
    allowed_tools=["get_customer", "lookup_order", "process_refund", "escalate_to_human"],
    # Coordinator also needs:
    # allowed_tools=["Task", "get_customer", ...]
)
```

| Parameter | Purpose |
|---|---|
| `name` / `description` | Agent identification; helps coordinator select subagents |
| `system_prompt` | Behavioral rules and constraints |
| `allowed_tools` | Least-privilege tool scoping |

**Exam rule:** Too many tools per agent (e.g., 18 instead of 4–5) **reduces** tool selection reliability. Scope tools to each agent's role.

Sources: [guide_en.MD:332-350](guide_en.MD), [guide_en.MD:1638-1646](guide_en.MD)

### Hub-and-spoke topology

Multi-agent systems use a **coordinator at the center** with specialized subagents on the spokes:

```mermaid
flowchart TB
    subgraph coordinator_layer [Coordinator Layer]
        C[Coordinator Agent]
    end
    subgraph subagent_layer [Subagent Layer]
        WS[Web Search Subagent]
        DA[Document Analysis Subagent]
        SY[Synthesis Subagent]
    end
    User([User Request]) --> C
    C -->|Task spawn + context| WS
    C -->|Task spawn + context| DA
    WS -->|structured results| C
    DA -->|structured results| C
    C -->|both result sets| SY
    SY -->|integrated report| C
    C --> User
```

**Coordinator responsibilities:**
- Task decomposition and dynamic subagent selection
- Delegation via the `Task` tool
- Result aggregation and validation
- Error handling, retries, and routing
- All inter-agent communication (observability)

**Critical principle:** Subagents have **isolated context**. They do not automatically inherit the coordinator's conversation history. All required context must be **explicitly passed** in the subagent prompt.

Sources: [guide_en.MD:352-375](guide_en.MD), [guide_en.MD:1529-1540](guide_en.MD)

### Pitfall: missing coordinator context

**Wrong mental model:** "The document analysis subagent already knows what the web search found because they're in the same system."

**Reality:** Each `Task` spawn starts with only what you put in its prompt. If you omit prior search results, the subagent works blind.

```text
# Bad — subagent has no context
Task: "Analyze the document"

# Good — full context in the prompt
Task: "Analyze the following document.
Document: [full document text]
Prior search results: [web search results]
Output format requirements: [schema]"
```

Sources: [guide_en.MD:388-398](guide_en.MD), [guide_en.MD:1544-1552](guide_en.MD)

---

## Part 3: `Task` Spawning and Parallel Subagents

### Spawning mechanics

Subagents are spawned through the **`Task` tool**. The coordinator's `allowed_tools` **must include `"Task"`**.

A coordinator can issue **multiple `Task` calls in one response**—subagents then run **in parallel**:

```text
# One coordinator response:
Task 1: "Search for articles about X"
Task 2: "Analyze document Y"
Task 3: "Search for articles about Z"
# All three run concurrently
```

Sources: [guide_en.MD:377-408](guide_en.MD), [guide_en.MD:1544-1553](guide_en.MD)

### Walkthrough: Multi-Agent Research System — conflicting data

**Situation (Practice Q1):** A document analysis agent finds two credible sources with contradictory statistics: government report says 40% growth, industry analysis says 12%.

| Option | Verdict | Why |
|---|---|---|
| A) Pick one number via heuristics | Wrong | Analysis agent should not unilaterally resolve conflicts |
| B) Include both without marking conflict | Wrong | Synthesis agent cannot reconcile what it cannot see |
| C) Stop and escalate immediately to coordinator | Wrong | Blocks core work unnecessarily |
| **D) Complete analysis with both numbers, annotate conflict with attribution, let coordinator reconcile** | **Correct** | Preserves separation of duties; coordinator has broader context |

**Step-by-step reasoning:**
1. Document analysis agent **completes its core job** (extract and attribute data).
2. Output includes **both values**, source names, and an explicit `conflict_detected` flag.
3. Coordinator—not the subagent—decides reconciliation strategy before synthesis.
4. Synthesis agent receives reconciled or annotated inputs.

This mirrors the provenance pattern in Chapter 12: do not arbitrarily choose one value; preserve both with attribution.

Sources: [guide_en.MD:2130-2141](guide_en.MD), [guide_en.MD:1430-1456](guide_en.MD), [practical_test_en.html](practical_test_en.html) (Q1)

### Walkthrough: Multi-Agent Research System — next step after subagents return

**Situation (Practice Q2):** Web-search and document-analysis agents have returned results to the coordinator.

**Correct next step:** Coordinator passes **both result sets** to the synthesis agent for unified integration.

**Why not bypass the coordinator:** Direct agent-to-agent communication breaks centralized error handling, observability, and routing control.

Sources: [guide_en.MD:2145-2156](guide_en.MD), [practical_test_en.html](practical_test_en.html) (Q2, Q8)

### Pitfall: narrow coordinator decomposition

**Situation (Practice Q4):** Research on "AI impact on creative industries" covers only visual art. Coordinator logs show decomposition into "AI in digital art," "AI in graphic design," "AI in photography."

**Root cause:** Coordinator decomposition was **too narrow**—not subagent execution failure.

**Fix direction:** Coordinator prompts should express **goals and coverage criteria**, not overly specific subtopics that omit entire domains (music, literature, film).

Sources: [guide_en.MD:2030-2041](guide_en.MD), [practical_test_en.html](practical_test_en.html) (Q4)

---

## Part 4: SDK Hooks — Deterministic Enforcement

Hooks intercept agent lifecycle events. They provide **deterministic guarantees** where prompts provide only **probabilistic compliance** (>90%, not 100%).

| Hook type | Use case | Example |
|---|---|---|
| `PostToolUse` | Normalize or trim tool results before model sees them | Convert Unix timestamps to ISO 8601; trim 40+ order fields to 5 |
| `PreToolUse` (outgoing interception) | Block policy-violating actions | Block `process_refund` when amount > $500 |

```python
# PostToolUse: normalize date formats from different MCP tools
@hook("PostToolUse")
def normalize_dates(tool_result):
    # Convert Unix timestamp -> ISO 8601
    return normalized_result

# PreToolUse: block refunds above threshold
@hook("PreToolUse")
def enforce_refund_limit(tool_call):
    if tool_call.name == "process_refund" and tool_call.args.amount > 500:
        return redirect_to_escalation(tool_call)
```

| Attribute | Hooks | Prompt instructions |
|---|---|---|
| Guarantee | Deterministic (100%) | Probabilistic |
| Best for | Financial ops, compliance, safety | Preferences, formatting, general guidance |

**Exam rule:** When failure has financial, legal, or safety consequences—use hooks, not prompts.

Sources: [guide_en.MD:411-444](guide_en.MD), [guide_en.MD:1568-1578](guide_en.MD)

### Walkthrough: Customer Support — skipping `get_customer`

**Situation (Exam Q1 / Practice Q51):** In 12% of cases the agent skips `get_customer` and calls `lookup_order` with only a customer name, causing misidentified accounts and incorrect refunds.

| Option | Verdict |
|---|---|
| A) Few-shot examples | Insufficient—probabilistic |
| B) Routing classifier | Overengineering for sequencing |
| C) **Programmatic precondition blocking `lookup_order`/`process_refund` until verified ID** | **Correct** |
| D) Stronger system prompt | Probabilistic |

**Implementation pattern:** PreToolUse hook or precondition that blocks downstream financial tools until `get_customer` returns a verified identifier. This is **programmatic enforcement** of a multi-step workflow.

Sources: [guide_en.MD:1940-1951](guide_en.MD), [guide_en.MD:1556-1566](guide_en.MD), [practical_test_en.html](practical_test_en.html) (Q51)

---

## Part 5: Tool Descriptions — The Primary Selection Mechanism

Tool descriptions are how the LLM **chooses** which tool to call. Minimal or overlapping descriptions cause misrouting.

### What a strong description includes

The study guide's `get_customer` example demonstrates the pattern:

```json
{
  "name": "get_customer",
  "description": "Finds a customer by email or ID. Returns the customer profile, including name, email, order history, and account status. Use this tool BEFORE lookup_order to verify the customer's identity. Accepts an email (format: user@domain.com) or a numeric customer_id.",
  "input_schema": { ... }
}
```

Include in every description:
- What the tool does and returns
- Input formats and example values
- Edge cases and constraints
- **When to use this tool vs similar alternatives**

Sources: [guide_en.MD:209-236](guide_en.MD), [guide_en.MD:1609-1620](guide_en.MD)

### Walkthrough: Customer Support — wrong tool for order status

**Situation (Practice Q46):** Agent calls `get_customer` when `lookup_order` is more appropriate for order-status questions.

**First diagnostic step:** Check tool descriptions—ensure they clearly differentiate purpose and usage boundaries.

**Why not first:** Few-shot examples (adds tokens, doesn't fix root cause), reducing tool count (may remove needed tools), preprocessing classifier (overengineering).

Sources: [guide_en.MD:1955-1966](guide_en.MD), [practical_test_en.html](practical_test_en.html) (Q46)

### Walkthrough: Multi-Agent Research — tool name collision

**Situation (Practice Q7):** Requests like "analyze the uploaded quarterly report" route to the web-search agent instead of document analysis.

**Fix:** Rename `analyze_content` → `extract_web_results` (or similar) and update descriptions to explicitly state scope (web results only, not uploaded documents).

Sources: [practical_test_en.html](practical_test_en.html) (Q7), [guide_en.MD:1617-1620](guide_en.MD)

### Built-in tools vs MCP tools

Agents may prefer built-in tools (Read, Grep) over functionally similar MCP tools. Strengthen MCP descriptions by highlighting **unique data or capabilities** built-in tools cannot provide.

Sources: [guide_en.MD:236](guide_en.MD)

---

## Part 6: `tool_choice` — Controlling Tool Selection

`tool_choice` controls whether and which tools the model must call:

| Value | Behavior | When to use |
|---|---|---|
| `{"type": "auto"}` | Model may call a tool or answer in text | Default for conversational agents |
| `{"type": "any"}` | Model **must** call some tool | Guaranteed structured output |
| `{"type": "tool", "name": "extract_metadata"}` | Model **must** call a specific tool | Forced first step / execution order |

**Key distinctions for the exam:**
- `"auto"` → model can return plain text instead of calling a tool
- `"any"` → guarantees a tool call (useful when multiple extraction schemas exist)
- Forced selection → guarantees a specific first action (e.g., `extract_metadata` before enrichment)

Sources: [guide_en.MD:238-250](guide_en.MD), [guide_en.MD:1636-1648](guide_en.MD)

### Allocating tools across agents

| Principle | Rationale |
|---|---|
| 4–5 tools per agent | Reliability drops with 15+ tools |
| Role-scoped `allowed_tools` | Prevents synthesis agent from running full web searches |
| Constrained alternatives | `fetch_url` → `load_document` for document-only agents |
| Limited cross-role utilities | e.g., synthesis gets `verify_fact` for simple checks only |

**Walkthrough (Exam Q9):** Synthesis agent needs simple fact checks (85% of cases) but complex verification should route through coordinator. Give synthesis a **limited `verify_fact` tool**; keep full web-search tools on the search subagent.

Sources: [guide_en.MD:2060-2071](guide_en.MD)

---

## Part 7: MCP Integration

### What MCP provides

The Model Context Protocol connects external systems to Claude through three resource types:

| Type | Purpose | Example |
|---|---|---|
| **Tools** | Actions (CRUD, API calls) | `get_customer`, `process_refund` |
| **Resources** | Read-only context | DB schemas, task catalogs, docs |
| **Prompts** | Reusable prompt templates | Common task patterns |

When connected, all MCP server tools are **discovered automatically** and available simultaneously. Tool descriptions drive how the model uses them.

Sources: [guide_en.MD:450-463](guide_en.MD), [guide_en.MD:1650-1656](guide_en.MD)

### MCP server configuration

**Project scope (`.mcp.json`)** — team-shared, version-controlled:

```json
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}
```

| Config location | Scope | Secrets |
|---|---|---|
| `.mcp.json` (project root) | Whole team via VCS | `${GITHUB_TOKEN}` env substitution |
| `~/.claude.json` | Personal experiments | Not shared |

**Exam guidance:** Prefer community MCP servers for standard integrations (Jira, GitHub, Slack). Build custom servers only for unique workflows.

Sources: [guide_en.MD:465-502](guide_en.MD), [guide_en.MD:1650-1661](guide_en.MD)

### MCP resources reduce exploratory calls

Resources act as a "content catalog"—the agent sees what data exists without trial-and-error tool calls. Example: a task-summary resource listing all project issues hierarchically.

Sources: [guide_en.MD:534-543](guide_en.MD)

---

## Part 8: `isError` and Structured Error Responses

When an MCP tool fails, it sets **`isError: true`** in the response. This tells the agent the call failed—not that it succeeded with empty data.

### Structured error (good)

```json
{
  "isError": true,
  "content": {
    "errorCategory": "transient",
    "isRetryable": true,
    "message": "The service is temporarily unavailable. Timeout while calling the orders API.",
    "attempted_query": "order_id=12345",
    "partial_results": null
  }
}
```

### Generic error (anti-pattern)

```json
{
  "isError": true,
  "content": "Operation failed"
}
```

A generic message gives the coordinator no basis to decide: retry? modify query? escalate? continue with partial results?

Sources: [guide_en.MD:504-532](guide_en.MD), [guide_en.MD:1622-1634](guide_en.MD)

### Error categories

| Category | Examples | Retryable | Agent action |
|---|---|---|---|
| **Transient** | Timeout, 503, network | Yes | Retry with backoff |
| **Validation** | Bad input format | No (fix input) | Modify and retry |
| **Business** | Policy violation | No | Explain; propose alternative |
| **Permission** | Access denied | No | Escalate |

Sources: [guide_en.MD:1232-1239](guide_en.MD)

### Pitfall: unstructured subagent errors

**Anti-patterns the exam tests:**

| Anti-pattern | Problem |
|---|---|
| Generic "search unavailable" status | Coordinator cannot recover intelligently |
| Empty result marked as success | Masks failure as "no matches" |
| Abort entire workflow on one failure | Loses all partial results |
| Infinite retries inside subagent | Wastes latency; coordinator should decide |

**Correct pattern — structured subagent error:**

```json
{
  "status": "partial_failure",
  "failure_type": "timeout",
  "attempted_query": "AI impact on music industry 2024",
  "partial_results": [
    {"title": "AI Music Generation Report", "url": "...", "relevance": 0.8}
  ],
  "alternative_approaches": [
    "Try a narrower query: 'AI music composition tools'",
    "Use an alternative data source"
  ],
  "coverage_impact": "Not covered: AI impact on music production"
}
```

The coordinator can then: retry with modified query, use partial results, delegate to another subagent, or continue with **coverage annotations** in the final synthesis.

Sources: [guide_en.MD:1241-1288](guide_en.MD), [guide_en.MD:2045-2056](guide_en.MD), [practical_test_en.html](practical_test_en.html) (Q5, Q6, Q8)

### Local recovery vs coordinator escalation

**Situation (Practice Q3):** PDF parsing fails on corrupted sections, password-protected files, and large-file hangs. Every exception currently terminates the subagent and burdens the coordinator.

**Best fix:** Implement **local recovery in the subagent** for transient failures; escalate to coordinator only for errors the subagent cannot resolve, including attempted steps and partial results.

**Principle:** Handle errors at the **lowest level capable of resolving them**.

Sources: [guide_en.MD:2160-2171](guide_en.MD), [practical_test_en.html](practical_test_en.html) (Q3)

---

## Part 9: End-to-End Scenario Walkthroughs

### Scenario A: Customer Support Agent (single-agent + MCP tools)

**Architecture:** One `AgentDefinition` with MCP tools: `get_customer`, `lookup_order`, `process_refund`, `escalate_to_human`. Target: 80%+ first-contact resolution.

```mermaid
sequenceDiagram
    participant User
    participant Loop as Agentic Loop
    participant Claude
    participant MCP as MCP Tools
    participant Hook as PreToolUse Hook

    User->>Loop: "Refund for order #1234"
    Loop->>Claude: messages + tools
    Claude-->>Loop: stop_reason=tool_use, get_customer
    Loop->>MCP: get_customer(email)
    MCP-->>Loop: customer profile
    Loop->>Claude: append tool_result
    Claude-->>Loop: stop_reason=tool_use, lookup_order
    Loop->>MCP: lookup_order(order_id)
    MCP-->>Loop: order details
    Loop->>Claude: append tool_result
    Claude-->>Loop: stop_reason=tool_use, process_refund
    Loop->>Hook: intercept process_refund
    alt amount > $500
        Hook-->>Loop: redirect to escalate_to_human
    else within policy
        Hook-->>Loop: allow
        Loop->>MCP: process_refund
    end
    Claude-->>Loop: stop_reason=end_turn
    Loop->>User: resolution
```

**Decision checklist for this scenario:**

| Problem observed | First check | Enforcement level |
|---|---|---|
| Wrong tool selected | Tool descriptions | Prompt + description fix |
| Skips `get_customer` | Precondition hook | Programmatic (hooks) |
| Escalates too much / too little | Escalation criteria + few-shot | Prompt |
| Refund above threshold | PreToolUse hook | Programmatic (hooks) |
| Too many API loops | Prompt to bundle tool calls | Prompt |
| Policy gap (competitor price match) | `escalate_to_human` | Business rule → escalate |

Sources: [guide_en.MD:54-55](guide_en.MD), [guide_en.MD:1129-1209](guide_en.MD), [practical_test_en.html](practical_test_en.html) (Q46–Q53)

### Scenario B: Multi-Agent Research System (coordinator + subagents)

**Architecture:** Coordinator with `Task` in `allowed_tools`; subagents for web search, document analysis, synthesis, report generation.

**Happy-path flow:**
1. Coordinator decomposes topic with **broad coverage criteria** (not overly narrow subtopics).
2. Coordinator spawns parallel `Task` calls with **explicit context** in each prompt.
3. Subagents return **structured results** (not raw dumps).
4. Coordinator forwards combined results to synthesis agent.
5. Synthesis produces report with **coverage annotations** where inputs were partial.

**Error-path flow:**
1. Subagent encounters transient failure → local retry (1–2 attempts).
2. Unrecoverable failure → structured error with `partial_results`, `alternative_approaches`, `coverage_impact`.
3. Coordinator decides: retry, alternate source, or proceed with annotated gaps.
4. Final report marks sections `FULL COVERAGE` vs `PARTIAL COVERAGE`.

Sources: [guide_en.MD:60-61](guide_en.MD), [guide_en.MD:1274-1288](guide_en.MD), [guide_en.MD:2126-2203](guide_en.MD)

---

## Part 10: Common Pitfalls Summary

| Pitfall | Symptom | Correct approach |
|---|---|---|
| Missing coordinator context | Subagent produces irrelevant output | Pass full prior results in `Task` prompt |
| Unstructured subagent errors | Coordinator cannot decide recovery | Return `failure_type`, query, partial results, alternatives |
| Narrow decomposition | All subagents succeed but report has gaps | Coordinator goals + coverage criteria, not narrow subtopics |
| Bypassing coordinator | Proposed direct agent-to-agent routing | Reject—breaks observability and error control |
| Prompt-only enforcement for money | 12% skip verification rate | PreToolUse precondition hooks |
| Generic MCP errors | Agent retries blindly or gives up | `isError` + `errorCategory` + `isRetryable` metadata |
| Silent failure as empty success | "No results" when search actually failed | Distinguish zero results from tool failure |
| Parsing text for completion | Premature or infinite loops | Trust `stop_reason` only |

Sources: [guide_en.MD:1241-1248](guide_en.MD), [guide_en.MD:1371-1380](guide_en.MD)

---

## Exam Decision Framework

When facing a Domain 1–2 question, apply this sequence:

```text
1. Is this about LOOP CONTROL?
   → stop_reason: tool_use = continue, end_turn = stop

2. Is this about MULTI-AGENT FLOW?
   → Hub-and-spoke: all traffic through coordinator
   → Explicit context in Task prompts
   → Structured errors back to coordinator

3. Is this about RELIABILITY / COMPLIANCE?
   → Financial/legal/safety → hooks (deterministic)
   → Preferences/formatting → prompts (probabilistic)

4. Is this about TOOL SELECTION?
   → Descriptions first
   → Scope allowed_tools per role
   → tool_choice: any for forced structure, forced name for order

5. Is this about MCP ERRORS?
   → isError: true + structured metadata
   → Local recovery in subagent, escalate what you cannot fix
```

---

## Practice Resources

The repository includes interactive practical tests covering both scenarios in multiple languages. Work through the **Multi-agent Research System** and **Customer Support Agent** question sets in [practical_test_en.html](practical_test_en.html) after reading Domains 1–2 in [guide_en.MD](guide_en.MD). The README points to Anthropic's free MCP and Agent SDK courses for hands-on depth.

Sources: [README.md:43-47](README.md), [README.md:57-59](README.md)

---

## Summary

Agent orchestration and MCP integration are the exam's largest combined weight (45%) because they test production judgment, not API memorization. Master the agentic loop controlled by `stop_reason`, configure agents with scoped `AgentDefinition` objects, and orchestrate multi-agent work through a hub-and-spoke coordinator that spawns subagents via `Task` with explicit context. Use SDK hooks when business rules demand certainty; use tool descriptions and `tool_choice` when you need correct selection and structured output. Configure MCP servers in `.mcp.json` with env-var secrets, and return structured `isError` responses so coordinators—not guesswork—drive recovery. The Customer Support scenario teaches enforcement and tool scoping; the Multi-Agent Research scenario teaches context passing, decomposition breadth, and structured error propagation. Avoid the traps: missing context in `Task` prompts, generic errors, bypassing the coordinator, and prompt-only guarantees for financial operations.

---

## 03. Exam Rehearsal, Practice Tests & Certification Pitfalls

> Closing certification page synthesizing Domains 3–5 (Claude Code workflows, prompt engineering with JSON schemas, context management and reliability): four hands-on practical exercises with domain mappings, worked example and practice-test question patterns, interactive HTML rehearsal workflow, out-of-scope topic traps, and the final preparation checklist — giving candidates a deliberate finish before sitting the exam.

- Page Markdown: https://grok-wiki.com/public/wiki/paullarionov-claude-certified-architect-1b20f95d81b9/pages/03-exam-rehearsal-practice-tests-certification-pitfalls.md
- Generated: 2026-06-08T18:27:47.537Z

### Source Files

- `guide_en.MD`
- `practical_test_en.html`
- `utils/build_practical_test_html.py`
- `.github/workflows/markdown-to-pdf.yml`
- `.github/workflows/pdf-style.css`
- `pdf/guide_en.pdf`
- `guide_it.md`

<details>
<summary>Relevant source files</summary>

The following files were used as context for generating this wiki page:

- [guide_en.MD](guide_en.MD)
- [practical_test_en.html](practical_test_en.html)
- [utils/build_practical_test_html.py](utils/build_practical_test_html.py)
- [.github/workflows/markdown-to-pdf.yml](.github/workflows/markdown-to-pdf.yml)
- [.github/workflows/pdf-style.css](.github/workflows/pdf-style.css)
- [pdf/guide_en.pdf](pdf/guide_en.pdf)
- [guide_it.md](guide_it.md)

</details>

# Exam Rehearsal, Practice Tests & Certification Pitfalls

This page is the **closing certification rehearsal** for Domains 3–5: Claude Code configuration and workflows (20%), prompt engineering and structured output (20%), and context management and reliability (15%). Together these three domains account for **55%** of the exam. The real test draws four scenarios from eight possibilities, uses multiple-choice format with no guessing penalty, and requires a scaled score of **720** to pass — so every unanswered question is a missed opportunity.

Use this page after you have read Part I theory and Part II domain notes in the study guide. It ties together hands-on exercises, worked exam patterns, the interactive HTML practice test, out-of-scope traps, and a final checklist so you finish preparation deliberately rather than by rereading chapters at random.

---

## How Domains 3–5 Connect on the Exam

The exam does not test these domains in isolation. A single scenario often spans all three:

| Domain | Weight | What the exam tests | Typical scenario hook |
|---|---|---|---|
| **3 — Claude Code** | 20% | `CLAUDE.md` hierarchy, skills/commands, path rules, planning mode, CI integration | Code Generation, Claude Code for CI |
| **4 — Prompt engineering** | 20% | Explicit criteria, few-shot, JSON schemas, validation/retry, batch vs sync API | Structured Data Extraction, CI review quality |
| **5 — Context & reliability** | 15% | Context trimming, escalation, error propagation, provenance, human oversight | Multi-agent Research, Customer Support |

```text
  Scenario prompt
        │
        ├─► Domain 3: WHERE does config live? (project vs user, rules vs skills)
        ├─► Domain 4: HOW do you shape output? (few-shot, schema, retry loop)
        └─► Domain 5: WHAT happens when context fails? (escalate, propagate, preserve attribution)
```

Sources: [guide_en.MD:42-48](), [guide_en.MD:1678-1935]()

---

## Domain 3 Rehearsal: Claude Code Configuration & Workflows

### Decision framework

When a question mentions team-shared configuration, slash commands, or CI pipelines, walk through this sequence:

1. **Scope** — Is the setting for one developer or the whole team?
2. **Load behavior** — Always loaded (`CLAUDE.md`) or on-demand (Skills)?
3. **File targeting** — Cross-cutting globs (`.claude/rules/`) or directory-local `CLAUDE.md`?
4. **Execution mode** — Planning (explore first) or direct execution (clear, small change)?
5. **CI mode** — Non-interactive (`-p` / `--print`) with optional `--output-format json` + `--json-schema`?

### CLAUDE.md hierarchy — the #1 team pitfall

Three levels exist: user (`~/.claude/CLAUDE.md`), project (`.claude/CLAUDE.md` or root `CLAUDE.md`), and directory-level. User-level settings are **not** shared via version control. The classic exam trap: original developers put guidance in their personal config; a new hire sees different behavior despite working in the same repo.

**Fix:** Move team-wide standards to project-level `CLAUDE.md`.

Sources: [guide_en.MD:551-571](), [guide_en.MD:1680-1691](), [guide_en.MD:2680-2689]()

### Skills vs rules vs CLAUDE.md

| Mechanism | Loads when | Best for | Exam trap |
|---|---|---|---|
| **Project `CLAUDE.md`** | Every session | Universal coding/testing standards | Putting 400+ lines of workflow-specific guidance here |
| **`.claude/rules/` + `paths`** | Editing matching files | Cross-directory conventions (`**/*.test.tsx`) | Using directory `CLAUDE.md` when tests are scattered |
| **Skills (`SKILL.md`)** | On demand / trigger keywords | PR review, migrations, deep analysis | Verbose skill output polluting main session |
| **`.claude/commands/`** | Slash invocation | Team-shared `/review` command | Putting commands in `~/.claude/commands/` when team needs them |

**Skill frontmatter triad** (appears repeatedly on practice tests):

- `context: fork` — isolate verbose output in a subagent
- `allowed-tools` — restrict destructive operations
- `argument-hint` — reduce missing-argument failures

Sources: [guide_en.MD:665-690](), [guide_en.MD:1693-1705](), [guide_en.MD:2618-2629](), [guide_en.MD:2708-2719]()

### Planning mode vs direct execution

| Signal in the stem | Choose |
|---|---|
| Monolith → microservices, dozens of files, ambiguous integration options | **Planning mode** |
| Single-file fix, clear stack trace, one validation | **Direct execution** |
| "Add Slack support" with webhooks vs bot tokens vs Slack Apps | **Planning mode** (multiple valid architectures) |

Reactive switching ("start direct, plan when stuck") is consistently marked wrong. Plan first when architectural consequences are large.

Sources: [guide_en.MD:695-718](), [guide_en.MD:1719-1731](), [guide_en.MD:2000-2011](), [guide_en.MD:2602-2614]()

### CI/CD integration checklist

| Requirement | Correct approach | Wrong distractor |
|---|---|---|
| Pipeline hangs waiting for input | `claude -p "..."` | `CLAUDE_HEADLESS=true` (non-existent) |
| Inline PR comments need structured fields | `--output-format json` + `--json-schema` | Narrative format + manual parsing |
| Blocking pre-merge check | Synchronous API | Message Batches API (up to 24h, no SLA) |
| Overnight tech-debt report | Message Batches API (50% savings) | Same synchronous call as pre-merge |
| Self-review misses subtle bugs | Second **independent** review instance | Self-critique in same session |

**Session isolation pitfall:** The same session that generated code is less effective at reviewing it. Fresh-instance review mirrors human peer review.

Sources: [guide_en.MD:1747-1760](), [guide_en.MD:2075-2101](), [guide_en.MD:2359-2386]()

---

## Domain 4 Rehearsal: Prompt Engineering & Structured Output

### Syntax vs semantic errors

JSON schemas via `tool_use` eliminate **syntax** errors (malformed JSON, wrong types). They do **not** eliminate **semantic** errors (totals that don't reconcile, values in wrong fields, fabricated required fields).

| Error class | Example | Primary mitigation |
|---|---|---|
| Syntax | Trailing comma, missing brace | `tool_use` + JSON Schema |
| Semantic | `stated_total` ≠ sum of line items | Validation loop + retry with specific error feedback |

Sources: [guide_en.MD:252-302](), [guide_en.MD:1793-1819]()

### `tool_choice` decision table

| Setting | Behavior | When to use |
|---|---|---|
| `"auto"` | Model may return text or call a tool | General chat |
| `"any"` | Must call a tool (picks among defined tools) | Guaranteed structured output when multiple schemas exist |
| `{"type":"tool","name":"..."}` | Forces a specific tool | Pipelines requiring a fixed first step |

Sources: [guide_en.MD:238-250](), [guide_en.MD:1793-1805]()

### Schema design rules (exam favorites)

1. Mark fields **required** only when always present — otherwise the model fabricates values.
2. Use **nullable** types (`"type": ["string", "null"]`) when source may lack data.
3. Add enum values `"unclear"` and `"other"` plus a detail string for extensibility.
4. Pair strict schema with **normalization rules** in the prompt for messy real-world inputs.

### Few-shot beats vague instructions

When stems say "developers find feedback inconsistent" or "output structure still doesn't match after prose descriptions," the correct answer is usually **2–4 concrete input/output examples** showing location, issue, severity, and fix — not more abstract wording.

For CI false-positive crises: **temporarily disable** noisy categories (style, naming, documentation) while keeping high-precision categories (security, correctness). Uniform strictness reduction or pre-filtering findings before developers see them are common wrong answers when stakeholders rejected filtering.

Sources: [guide_en.MD:1766-1790](), [guide_en.MD:2419-2430](), [guide_en.MD:2541-2565](), [guide_en.MD:2588-2599]()

### Batch processing — match latency to workflow

```text
  Blocking pre-merge check ──► Synchronous API (developer waiting)
  Overnight audit/report   ──► Message Batches API (50% cost, ≤24h window)
  Multi-turn tool loop     ──► NOT batch-compatible (no mid-request tool execution)
```

Sources: [guide_en.MD:1821-1833](), [guide_en.MD:2389-2415]()

---

## Domain 5 Rehearsal: Context Management & Reliability

### Context preservation patterns

| Problem | Symptom | Correct mitigation |
|---|---|---|
| Progressive summarization | Numbers/dates become "about", "roughly" | Persistent "case facts" block outside summarized history |
| Lost-in-the-middle | Middle findings ignored in long inputs | Key findings at start/end with explicit headings |
| Verbose tool output | 40 fields returned, 5 needed | Trim to relevant fields before next turn |
| Long codebase session | Model cites "typical patterns" not actual classes | Subagents, scratchpad files, `/compact` |

Sources: [guide_en.MD:179-194](), [guide_en.MD:1851-1905]()

### Escalation calibration

**Escalate immediately when:**
- Customer explicitly requests a human
- Policy is silent or ambiguous for the specific request (e.g., competitor price matching)

**Do not escalate on:**
- First expression of dissatisfaction (unless they ask for a manager)
- Model self-rated confidence scores (unreliable)
- Sentiment analysis thresholds

**Deterministic guarantees beat prompts** when business logic requires tool sequencing (e.g., block `process_refund` until `get_customer` returns a verified ID).

Sources: [guide_en.MD:1865-1877](), [guide_en.MD:1940-1981](), [guide_en.MD:2878-2905]()

### Multi-agent error propagation

When a subagent times out, return **structured error context**: failure type, query attempted, partial results, alternatives. Wrong patterns:

- Generic "search unavailable" (hides recovery options)
- Empty success result (masks failure)
- Abort entire workflow on single subagent failure

For **conflicting sources**, preserve both values with attribution and pass reconciliation to the coordinator — do not pick one heuristically or hide the conflict.

Sources: [guide_en.MD:1879-1934](), [guide_en.MD:2045-2056](), [guide_en.MD:2130-2141]()

### Human oversight and provenance

- Aggregate accuracy (97%) can mask poor performance on specific document types — stratify sampling by type and field.
- Require subagents to output **claim → source** mappings (URL, quote, publication date).
- Separate confirmed findings from disputed ones in synthesis reports.

Sources: [guide_en.MD:1907-1934]()

---

## Four Hands-On Practical Exercises (Domain-Mapped)

The study guide ships four exercises designed to rehearse exam patterns hands-on. Two map primarily to Domains 3–5; two reinforce cross-domain skills you will still see in Domains 3–5 scenarios.

### Exercise 1: Multi-tool Agent with Escalation Logic

**Domains:** 1, 2, **5**

| Step | Action | Exam skill tested |
|---|---|---|
| 1 | Define 3–4 MCP tools with differentiated descriptions | Tool selection (Domain 2, appears in Domain 5 scenarios) |
| 2 | Agent loop on `stop_reason` (`tool_use` / `end_turn`) | Agent architecture fundamentals |
| 3 | Structured errors: `errorCategory`, `isRetryable` | Error propagation (Domain 5.3) |
| 4 | Interceptor hook blocking high-threshold operations → escalation | Deterministic policy enforcement |
| 5 | Test multi-aspect requests | Escalation calibration |

Sources: [guide_en.MD:3285-3296]()

### Exercise 2: Configuring Claude Code for Team Development

**Domains:** **3**, 2

| Step | Action | Exam skill tested |
|---|---|---|
| 1 | Project-level `CLAUDE.md` with universal standards | Hierarchy scope (3.1) |
| 2 | `.claude/rules/` with `paths: ["src/api/**/*"]`, `paths: ["**/*.test.*"]` | Path-specific loading (3.3) |
| 3 | Skill with `context: fork` + `allowed-tools` | Skill isolation (3.2) |
| 4 | MCP in `.mcp.json` + personal override in `~/.claude.json` | MCP config layering |
| 5 | Compare planning mode vs direct execution | Execution mode (3.4) |

Sources: [guide_en.MD:3300-3311]()

### Exercise 3: Structured Data Extraction Pipeline

**Domains:** **4**, **5**

| Step | Action | Exam skill tested |
|---|---|---|
| 1 | Extraction tool with JSON schema (required/optional, enums, nullable) | Schema design (4.3) |
| 2 | Validation/retry loop with specific error feedback | Semantic error handling (4.4) |
| 3 | Few-shot examples for varied document structures | Few-shot prompting (4.2) |
| 4 | Message Batches API: 100 docs, retry failures via `custom_id` | Batch strategy (4.5) |
| 5 | Field-level confidence + document-type routing to humans | Human oversight (5.5) |

Sources: [guide_en.MD:3315-3326]()

### Exercise 4: Multi-agent Research Pipeline

**Domains:** 1, 2, **5**

| Step | Action | Exam skill tested |
|---|---|---|
| 1 | Coordinator + subagents with explicit context in prompts | Context passing |
| 2 | Parallel `Task` calls in single response | Orchestration efficiency |
| 3 | Structured output: claim, quote, source URL, date | Provenance (5.6) |
| 4 | Simulate timeout → structured error to coordinator | Error propagation (5.3) |
| 5 | Conflicting data: preserve both with attribution | Reconciliation pattern |

Sources: [guide_en.MD:3330-3341]()

---

## Worked Example: End-to-End Scenario Walkthrough

**Exam-style stem (Domain 3 + 4 + 5):** Your CI pipeline runs `claude -p` with `CLAUDE.md` for PR review. Reviews are substantive but narrative. You need automatic inline GitHub comments with `file`, `line`, `severity`, and `suggested_fix`. After enabling structured output, developers still spend too long triaging a 40% false-positive rate across categories, and the same Claude session that generated a fix missed a regression another reviewer caught.

### Step-by-step reasoning

| Step | Question to ask yourself | Answer |
|---|---|---|
| 1 | Non-interactive CI? | Already using `-p` — correct |
| 2 | Need guaranteed JSON fields? | `--output-format json` + `--json-schema`, not CLAUDE.md prose templates |
| 3 | False positives eroding trust? | Temporarily disable noisy categories; keep security/correctness |
| 4 | Investigation time too high? | Include rationale + confidence **in each finding** (not pre-filter) |
| 5 | Generator missed its own bug? | Second independent review instance without generation context |
| 6 | Multi-file PR inconsistent depth? | Per-file passes + separate cross-file integration pass |

This single narrative chains Domains 3 (CI flags, `CLAUDE.md` context), 4 (schema, few-shot, category tuning), and 5 (session isolation, multi-pass review architecture).

Sources: [guide_en.MD:2359-2370](), [guide_en.MD:2374-2386](), [guide_en.MD:2541-2565](), [guide_en.MD:2105-2116](), [guide_en.MD:1836-1845]()

---

## Practice Test Question Patterns

The guide includes **60 questions across 4 scenarios** matching real exam format and difficulty. An interactive HTML version is generated for multiple languages.

### Scenario coverage in the practice test

| Scenario | Question range | Primary domains |
|---|---|---|
| Multi-agent Research System | Q1–Q15 | 5 (provenance, error propagation, synthesis) |
| Claude Code for Continuous Integration | Q16–Q30 | 3 + 4 (CI, few-shot, batch, structured output) |
| Code Generation with Claude Code | Q31–Q45 | 3 (hierarchy, skills, planning, rules) |
| Customer Support Agent | Q46–Q60 | 5 (escalation, tool sequencing, multi-issue handling) |

Sources: [guide_en.MD:2120-2124](), [guide_en.MD:2126](), [guide_en.MD:2355](), [guide_en.MD:2584](), [guide_en.MD:2813]()

### Recurring answer patterns (memorize the logic, not letter positions)

| Pattern | Correct principle | Typical wrong distractor |
|---|---|---|
| Team-shared `/review` command | `.claude/commands/` in repo (VCS) | `~/.claude/commands/` |
| Scattered test conventions | `.claude/rules/` with `**/*.test.*` globs | Root `CLAUDE.md` with headings |
| 400-line `CLAUDE.md` mixing workflows | Universal standards in `CLAUDE.md`; workflow guidance in Skills | Move everything to Skills (loses always-on standards) |
| Ambiguous API transformation | 2–3 concrete input/output examples | JSON schema validation alone on prose requirements |
| Conflicting research statistics | Both values + attribution → coordinator reconciles | Pick one via credibility heuristic |
| Subagent timeout | Structured error context to coordinator | Empty success or abort workflow |
| Mandatory tool sequence | Programmatic precondition / hook | Stronger system prompt only |
| Escalation miscalibration | Explicit criteria + few-shot examples | Self-rated confidence threshold |
| Blocking vs batch API | Sync for pre-merge; batch for overnight | Move both to batch for 50% savings |

Sources: [guide_en.MD:1938-2116](), [guide_en.MD:2588-2734]()

### How to study each practice question

1. Read the **situation** — identify which domain signal words appear (`CLAUDE.md`, `CI`, `schema`, `escalate`, `coordinator`, `batch`).
2. Predict the answer **before** reading options.
3. Read **Why X** explanation — it states the trade-off principle the exam rewards.
4. Tag the question with domain numbers (3, 4, or 5) for gap analysis.
5. Revisit wrong tags after the HTML summary groups misses by scenario.

---

## Interactive HTML Rehearsal Workflow

The repository ships self-contained practice test pages (`practical_test_en.html`, plus `ru`, `ja`, `zh`, `it`, `ko`) built from guide questions.

### Build pipeline

```text
  guide_<lang>.md (Practice Test section)
           │
           ▼
  extract_question.py <lang> all   ──► JSON question array
           │
           ▼
  utils/build_practical_test_html.py ──► practical_test_<lang>.html
```

The builder embeds questions as `const QUESTIONS = [...]`, applies exam-like styling, and ships a sidebar navigation UI.

Sources: [utils/build_practical_test_html.py:1-24](), [utils/build_practical_test_html.py:423-475]()

### Runtime behavior (what to expect when rehearsing)

| UI element | Behavior |
|---|---|
| Sidebar | Groups questions by scenario; tracks answered count |
| Question card | Scenario badge, situation, prompt, four options |
| Answer lock | First click locks choice; shows correct/wrong styling |
| Explanation | Reveals "Why {letter}" rationale immediately after answering |
| Finish & Review | Score summary (total/correct/incorrect) + wrong answers grouped by scenario |
| Restart | Clears answers for a full retake |

```text
  ┌─────────────┐     select option      ┌──────────────────┐
  │  Sidebar    │ ─────────────────────► │  Locked answer   │
  │  (scenario  │                        │  + explanation   │
  │   groups)   │ ◄── navigate Prev/Next └────────┬─────────┘
  └─────────────┘                                   │
                                                    ▼
                                          ┌──────────────────┐
                                          │ Finish & Review  │
                                          │ (score by scenario)│
                                          └──────────────────┘
```

Sources: [utils/build_practical_test_html.py:235-420](), [practical_test_en.html:223-242]()

### Offline study paths

- **Browser:** Open `practical_test_en.html` locally (no server required — questions are embedded).
- **Print/PDF:** The guide PDF is auto-built from markdown on push to `main` via `md-to-pdf` with shared stylesheet; use `pdf/guide_en.pdf` for offline reading of the same question rationales.

Sources: [.github/workflows/markdown-to-pdf.yml:35-46](), [README.md:30-41]()

### Rehearsal schedule (recommended)

| Day | Activity | Target |
|---|---|---|
| 1 | Domains 3–5 notes + Exercise 2 | Configure a real repo's `CLAUDE.md` / rules / skills |
| 2 | Exercise 3 + Domain 4 schema drills | Build one extraction tool + retry loop |
| 3 | HTML practice test, scenarios 1–2 (Q1–30) | ≥80% with explanations read for misses |
| 4 | HTML practice test, scenarios 3–4 (Q31–60) | ≥80%; list recurring miss patterns |
| 5 | Exercise 4 + timed full 60-question retake | Simulate exam pacing; answer every question |

---

## Out-of-Scope Topic Traps

The guide explicitly lists topics **not** on the exam. These appear as plausible-sounding distractors:

| Trap topic | Why it sounds right | Why it's wrong |
|---|---|---|
| Fine-tuning / custom model training | "Improve accuracy" | Exam focuses on prompting, tools, and architecture — not training |
| Claude internal architecture / RLHF | "Understand the model" | Not tested |
| Deploying/hosting MCP servers (K8s, networking) | Scenario mentions MCP | Exam covers tool design and integration, not infra |
| OAuth / API key rotation details | Security scenarios | Authentication protocols are out of scope |
| Cloud-specific configs (AWS/GCP/Azure) | Enterprise scenarios | Provider-neutral Claude patterns only |
| Streaming API / SSE | Real-time systems | Out of scope |
| Token counting algorithms | Context management domain | Know context limits; not tokenization internals |
| Computer use / Vision | Agent capabilities | Not on this certification |
| Embedding models / vector DB implementation | RAG patterns | Out of scope |

**Exam tactic:** If an answer requires infrastructure you would configure in a cloud console rather than in `CLAUDE.md`, a prompt, or an agent loop — it is likely a trap.

Sources: [guide_en.MD:3366-3385]()

---

## Certification Pitfalls: Quick-Reference

### Domain 3 pitfalls

- Putting team standards in `~/.claude/CLAUDE.md`
- Using `@import` (not a real syntax — correct is `@path`)
- Choosing direct execution for architectural migrations
- Using batch API for blocking CI checks
- Expecting narrative CI output to parse reliably without `--json-schema`

### Domain 4 pitfalls

- Assuming JSON schema fixes semantic correctness
- Making all fields required (forces fabrication)
- "Be more conservative" instead of explicit categorical criteria
- Moving iterative tool-calling workflows to Message Batches API
- Self-review in the same session that generated the code

### Domain 5 pitfalls

- Escalating on sentiment or low self-rated confidence
- Picking one conflicting source without attribution
- Returning generic error strings from failed subagents
- Relying on progressive summarization for numeric facts
- Filtering findings before developers see them when stakeholders rejected filtering

---

## Final Preparation Checklist

Complete every item before scheduling the exam:

### Knowledge verification

- [ ] Explain the three-level `CLAUDE.md` hierarchy and when each level applies
- [ ] Describe when to use `.claude/rules/` globs vs Skills vs always-on `CLAUDE.md`
- [ ] State when planning mode beats direct execution (and vice versa)
- [ ] Configure CI non-interactive mode (`-p`) and structured output flags
- [ ] Design a JSON schema with nullable fields, enums, and `"other"` + detail
- [ ] Explain syntax vs semantic errors and when retry-with-feedback helps
- [ ] Match workflows to sync API vs Message Batches API by latency requirement
- [ ] List escalation triggers: explicit human request, policy gaps, inability to progress
- [ ] Describe structured subagent error propagation and provenance preservation

### Hands-on verification

- [ ] Complete Exercise 2 (Claude Code team config)
- [ ] Complete Exercise 3 (extraction pipeline with validation loop)
- [ ] Run the HTML practice test to completion with score review
- [ ] Score ≥80% on practice test; for misses, read the "Why" explanation and tag the domain

### Exam-day tactics

- [ ] Remember: **no guessing penalty** — answer every question
- [ ] Passing score is **720** on a 100–1000 scale
- [ ] Expect **4 of 8 scenarios** — Domains 3–5 surface across Code Generation, CI, Research, Support, and Structured Extraction scenarios
- [ ] For each question: identify the **root cause** the stem describes, then pick the fix with the most **deterministic** or **proportional** impact
- [ ] Eliminate out-of-scope distractors (fine-tuning, cloud infra, streaming, tokenization)

Sources: [guide_en.MD:31-36](), [guide_en.MD:3389-3405]()

---

## Summary

Domains 3–5 reward architects who configure Claude Code deliberately (`CLAUDE.md` hierarchy, path rules, skills with `context: fork`, planning mode for architectural work, CI structured output), shape prompts with explicit criteria and schemas while separating syntax from semantic validation, and manage context with escalation discipline, structured error propagation, and provenance through multi-agent pipelines. The four practical exercises and 60-question HTML practice test in this repository are your highest-fidelity rehearsal tools: work the exercises for muscle memory, run the HTML test for pacing and gap analysis, and use the out-of-scope list to avoid elegant but irrelevant distractors. Finish with the checklist above — if you can explain every "Why" explanation for your missed practice questions, you are ready to sit the exam.

---