# Trainer’s Guide — Advanced Level, Session 10
# “Mock exam & final project”

**Program:** Applied AI — Yann Isola
**Audience:** Solutions architects preparing for certification *Claude Certified Architect*
**Duration:** 2 hours (tight structure: 45 minutes mock exam + 45 minutes defenses + 30 minutes retrospective)
**Prerequisites:** Sessions 1 to 9 of the advanced level — **this session is the capstone** (capstone = final synthesis project): no new concepts, only validation and consolidation.
**Material:** interactive web page (`webpage/index.html` — complete exam simulator 30 questions/45 min, preparation dashboard with radar of the 5 areas, map of the 10 sessions), `quiz/quiz.md` (paper version of the mock exam with commented corrections), `exercises/exercises.md` (grid /100 of the final project + 3 warm-up challenges), visible stopwatch, projector, an evaluation grid printed per defense.

---

## Session positioning

This is the last session of the advanced course and it has three distinct functions that should not be allowed to mix:

1. **Certify readiness** — the practice exam in real conditions gives everyone an honest measurement: ready, almost ready, or not ready. The role of the trainer is to make this measure **usable** (diagnosis by domain, revision plan), not to reassure.
2. **Complete the final project** — each participant designed the complete architecture of a real AI system along the way. Today he **defends** her in front of the group. This is the exercise closest to the real job: convincing peers that an architecture stands up.
3. **Close the loop** — the retrospective links the 10 sessions into a coherent system and traces the rest: exam reservation, monitoring, continued practice.

> ⚠ **Convention:** all numbers marked ⚠ (exam format: 60 questions, 90 minutes, threshold 720/1000 ≈ 72%; weightings: 27/18/20/20/15%; prices, cache times, CLI flags) are **volatile**. Last reflex to install before leaving: *we check the official source before booking, before calculating, before asserting.*

---

## Timed plan

| Block | Duration | Content |
|------|-------|---------|
| 0. Opening & examination instructions | 5 mins | Rules of the mock exam, reminder of the time management method |
| 1. **MAKE EXAM** | 45 mins | 30 timed questions, real conditions, via the web simulator (or paper) |
| 2. Quick fix & diagnosis | 10 mins | Score by domain, radar reading, identification of red zones |
| 3. ** FINAL PROJECT DEFENSES ** | 45 mins | 5 to 7 defenses of 6 min (4 min presentation + 2 min questions), cross-evaluation |
| 4. Journey retrospective | 12 mins | Map of the 10 sessions, the 10 architect reflexes, what changes in production |
| 5. Self-assessment of preparation & plan | 8 mins | Preparation dashboard, individual decision: reserve or revise |
| 6. Closing | 5 mins | Certification logistics, monitoring resources, final words |

**Time arbitration:** if the group exceeds 7 participants, reduce the defenses to 5 minutes (3 + 2) and announce the constraint at the start. **Never** cut corners on the 45 minutes of examination: the diagnostic value requires real conditions.

---

## Block 0 — Opening & examination instructions (5 min)

**Catchphrase:** “Ten sessions. Today, we don't add anything — we check that everything fits.First alone faced with 30 questions, like on the big day. Then standing up, defending your architecture in front of your peers. At the end of the session, everyone knows whether they are reserving their exam or what they are reviewing first. »

### Mock exam instructions (project)

1. **30 questions, 45 minutes** — same pace as the real exam: 90 seconds/question on average ⚠.
2. **No documentation, no AI** — on the big day you will be alone.
3. **Answer all** — no penalty for error ⚠: an empty box is a point offered at random that we refuse.
4. **Two-pass method**: first quick pass (answer everything that is certain, mark the doubtful ones), second pass on the marked ones. The web simulator has a “mark for review” button that replicates this mechanism.
5. **MCQ reading grid** (reminder of session 9): identify the *root cause* of the problem described → look for the *least effort* response that addresses it → check if the statement requires a *guarantee* (programmatic mechanism) or accepts an *instruct* (instruction to the model). Three out of four distractors fall at this grid.

**Logistics:** each participant opens `webpage/index.html`, “Mock exam” tab, and starts the timer at the same time as everyone else. If there are no machines, distribute the paper quiz (without the corrections section!) and time it on the board.

---

## Block 1 — Mock exam (45 min)

The trainer **does not circulate** and **does not answer any substantive questions** — real conditions. Three interventions authorized only:

- Announcement of the remaining time at **20 min**, **10 min**, **2 min**.
- Technical failure (switch the participant to the paper version).
- Reminder of the instruction “answer everything” 2 minutes from the end.

**During the exam, the trainer prepares block 3:** order of presentation of the defenses (drawing or volunteering noted on the board), evaluation grids distributed face down.

### Distribution of questions (for trainer information)

| Domain | Weight review ⚠ | Questions | Course sessions covered |
|---|---|---|---|
| D1 Architecture & orchestration | 27% | Q1–Q8 | S3 (Agent SDK), S4 (multi-agent) |
| D2 Tools & MCP | 18% | Q9–Q13 | S2 (tool use), S5 (MCP) |
| D3 Claude Code | 20% | Q14–Q19 | S6 (Claude Code & CI/CD) |
| D4 Prompt engineering & structured output | 20% | Q20–Q25 | S1 (API), S7 (prompt engineering) |
| D5 Context & reliability | 15% | Q26–Q30 | S8 (context, reliability, provenance) |

---

## Block 2 — Flash correction & diagnosis (10 min)

The simulator automatically corrects and displays: overall score, **domain score**, and a 5-axis radar. On paper: self-correction with the quick grid of `quiz.md` (2 min), calculation by domain by hand.

**Do NOT correct the 30 questions one by one** — there is no time and the simulator's review mode (detailed explanation per question) is for individual post-session work.

**Instead, correct 3 strategically chosen questions:**

1. **The most failed of the group** (the simulator does not report group stats: ask by show of hands on 4–5 questions that you suspect — typically Q20 prefill, Q27 cache, Q8 workflow/agent).
2. **A “deposit vs. guarantee” question** (Q18 or Q28) — this is THE distinction that the exam tests in ten disguises.
3.**A “least effort” question** (Q9 or Q4) — the distractor “switch to a more powerful model” or “deploy a full agent” traps those who do not have the reflex of architectural economy.

**Reading the score (project the interpretation scale of `quiz.md`):**

- **27–30** → reserve the exam, review only areas < 80%.
- **22–26** → at threshold, insufficient margin: one targeted week + second blank.
- **17–21** → repeat the sessions in areas < 60%, redo the **practical exercises**.
- **< 17** → do not reserve; structured recovery, real API practice above all.

**Point of emphasis:** an area < 60% is a red zone **even with a good overall score**. The exam weights: D1 at 27% collapsed cannot be made up for by D5 at 15% perfect.

---

## Block 3 — Final project defenses (45 min)

### The format

Each participant presents **the complete architecture of a real AI system** designed throughout the course (instructions given in session 4, marked since). Strict format:

- **4 min presentation** — business problem, architecture (mandatory diagram), justification of choices, reliability strategy, costs.
- **2 min of questions** — the group + the trainer. At least one difficult question per defense (the trainer asks it if the group is tender).
- **Visible and merciless stopwatch** — knowing how to last 4 minutes is an architect's skill.

### The evaluation grid (/100 — full details in `exercises/exercises.md`)

| Criterion | Points |
|---|---|
| 1. Business problem & framing | 15 |
| 2. Architecture & justification of choices | 30 |
| 3. Design of tools & integrations | 15 |
| 4. Reliability, security & human supervision | 20 |
| 5. Costs, evaluation & operation | 10 |
| 6. Clarity of the defense | 10 |

**Cross-assessment:** each participant marks **two** peers on the grid (assigned by the trainer to cover everyone), the trainer marks everyone. The indicative score = average. The objective is not the score: it is to force everyone to **listen as an evaluator**, that is to say as an architect who challenges.

### The deciding questions (trainer's bank)

Ask at least one question of this caliber per defense:

1. “Your orchestrator breaks down at 3 a.m. What does the user see, and what does your system do on its own? »
2. “Why an agent here, and not a fixed-step workflow?” What is *unpredictable* about the path? »
3. “Show me the exact point where a human approves.” Why there and not elsewhere? »
4. “This system prompt makes 2,000 tokens and leaves on each request. How much does it cost per month at your volume? Did you plan for the prompt cache? »
5. “How will you know the quality has dropped *before* users complain?” »
6. “What’s the worst thing a malicious user can make your system say or do?” »
7. “If Anthropic changes the behavior of [volatile feature used], how does your system detect it? »

**What we want to hear:** answers which distinguish between deposit/guarantee, which provide figures, which admit the limits (“this case is not covered, here is why it is acceptable”). **Red flag:** “the model is intelligent, it will manage” — systematically sanction this response in the grid (criterion 4).

### Group management- **≤ 5 participants:** comfortable format 6 min + collective discussion of 2 additional min per project.
- **6–7:** nominal format.
- **> 7:** 5 min per defense (3 + 2) OR sessions in parallel evaluator pairs with restitution of the 2 best architectures in plenary. Announce the format from block 0.

---

## Block 4 — Retrospective of the course (12 min)

Use the “Course” tab of the web page: interactive map of the 10 sessions with their key concepts and connections.

### The thread of the retrospective (unroll orally, supported by the map)

| Session | What we built | The reflex that remains |
|---|---|---|
| S1 — Claude Deep API | Raw calls, settings, streaming, vision | *The API is stateless; everything the model “knows” is you who put it into context.* |
| S2 — Advanced tool use | Schemas, Call Orchestration, Tool Errors | *Tool description is a prompt. Tool error is reasoning data.* |
| S3 — Agent SDK | Agentic loops, sessions, state | *Workflow if the path is known, agent if it depends on the discoveries.* |
| S4 — Multi-agent architecture | Orchestrator, subagents, consensus, routing | *We cut to isolate the contexts, not to look pretty on a diagram.* |
| S5 — MCP in depth | Servers, tools/resources/prompts, transports | *MCP standardizes the connection; the quality of the descriptions remains your job.* |
| S6 — Claude Code & CI/CD | CLAUDE.md, slash commands, headless, permissions | *CLAUDE.md is an instruction; settings.json is a guarantee.* |
| S7 — Prompt engineering advanced | CoT, few-shot, prefill, chains, evals | *A prompt is a software component: versioned, tested, measured.* |
| S8 — Context, reliability & provenance | Compaction, hiding, hallucinations, traceability | *Context is a managed resource. Confidence is journalized.* |
| S9 — Certification scenarios | Reading grid, 8 scenarios, revision plan | *Think like the questioner: root cause, least effort, guaranteed.* |
| S10 — Capstone | Mock exam, project defended | *An architecture that cannot be defended in 4 minutes is not included.* |

### The 3 meta-lessons (to be formulated by the group before projecting them)

Ask: “If you had to retain only three transversal principles from the entire journey? » Leave 2 minutes of discussion, then project:

1. **Deposit ≠ guarantee.** A prompt request; the code requires. Anything critical (permissions, schema validation, human approval, citation checking) must be enforced programmatically.
2. **The least architectural effort.** A call before a chain; a string before an agent; an agent before multi-agents. Each floor is paid for in cost, latency and debugging — you only go up if the floor below has proven its insufficiency.
3. **Measure before believing.** Automated evaluations, golden sets, scores by domain, provenance logs: intuition initiates, measurement decides. This goes for the prompts as well as for your own exam preparation.

---

## Block 5 — Self-assessment of preparation & individual plan (8 min)

Everyone opens the “Preparation” tab of the web page: self-assessment on the 5 areas (5 statements per area, scale “I know how to do it / to consolidate / to repeat”), crossed with the score of the mock exam → preparation radar + recommendation.

**Instructions:** Complete honestly, alone, in 5 minutes.The page generates a revision plan prioritized by exam weighting (a weak area at 27% comes before a weak area at 15%).

**Individual decision to be made in writing before leaving** (one line):

- “I reserve the exam for the week of ___” **or**
- “I revise [domains] for ___ weeks, second mock exam on ___, then I reserve. »

The trainer notes these commitments — it is the only “evaluation” of the block, and it conditions post-training follow-up.

---

## Block 6 — Closing (5 min)

### Certification logistics (project, everything is volatile ⚠)

- Check on the official Anthropic page: current format, price, available languages, terms (monitored online / center), ironing policy.
- Reserve a **morning** slot if possible; allow 15 minutes of technical margin for online monitoring.
- The day before: only reread your reflex sheets (no new content), repeat 10 questions from the simulator to get back into rhythm.

### Continue after the route

1. **Practice > reading** — a personal project with real API calls per week maintains the level; reading alone makes it decrease.
2. **Structured monitoring** — Anthropic API changelog, Claude Code release notes, MCP specification: three sources, one monthly review. Everything with ⚠ in your notes comes from there.
3. **The community** — share your architectures and challenge them: today's defense was training for a permanent practice of the profession.

### Final words (suggestion)

“You entered this journey knowing how to use a model. You come out knowing how to design *systems*: cut out, equipped, measured, governed. Certification will validate what you know — but what you defended today in front of the group, no one needs to certify: it was already the work of an architect. Go book that exam. »

---

## Trainer appendices

### A. Mock exam correspondence scale → real exam

The blank has 30 questions where the exam has 60 ⚠: the variance is higher. Cautious rule: consider the interval **score ± 2 questions** before concluding. A 23/30 is “21 to 25”, therefore straddling the threshold → recommend consolidation week.

### B. Last minute traps to remember if time permits

1. “ALL choices seem true” questions → reread the question: it often asks for the **first** gesture, the **most** effective, or the **main** lever — a superlative changes the answer.
2. The distractor “temperature 0 suppresses hallucinations” (false: reproducible ≠ true).
3. The distractor “--dangerously-skip-permissions in CI” (never the right answer in an uncontrolled automated context).
4. The distractor “the prompt system guarantees” (instruction ≠ guaranteed, always).
5. The exact numbers (cache times, prices, limits): the exam tests **orders of magnitude and mechanisms**, not the pricing gazette — but check the documentation the week of the exam ⚠.

### C. If a participant fails badly in the blank (< 15/30)

Take 3 minutes aside after the session. Typical diagnosis: (a) lack of real API practice → prescribe practical exercises from sessions 1–3 with real calls; (b) reading statements too quickly → prescribing the two-passage method with 2 min/question in training; (c) confusion of domains D1/D2 → repeat session 4 then 5, in that order.Never let someone go without a concrete plan.