by

Claude Architect Hands-on Labs: 8 Practical Exercises

📚 Exam guide v1.0 (July 2026)🔄 Checked against official sources: 11 Nov 2026✏️ Updated: 12 Nov 2026⏱️ 10 min read🎯 All five domains (practical)

👋 In plain words: Reading builds knowledge, but the exam tests judgement, and judgement comes from doing. These eight labs take you from your first API call to a working CI review bot. Each ends with a 'prove it' check so you know when you are ready.

Advertisement

The exam rewards judgement you only build by doing. These eight labs follow the official preparation exercises and cover all five domains. Each ends with a “prove it” check — if you can explain the answer, you’re ready for that topic.

📖 What You’ll Learn: You will practise every exam domain hands-on, from a raw agentic loop to a CI review bot.

🔑 Key terms

  • API key: A secret key that lets your code call Claude. Keep it out of Git.
  • SDK: A library that makes calling the API easier, such as anthropic for Python.
  • Pydantic: A Python library that checks data matches a schema.
  • GitHub Actions: GitHub's built-in CI system, which runs jobs on each push or pull request.

📖 The story in this lesson

Each lab builds one small piece of ShopNest: the support bot's loop, invoice extraction, the nightly review batch, the research team, the team's Claude Code setup, a ticket MCP server and Ravi's CI reviewer.

💡 Think of it like this

The labs are like driving lessons after the theory test. You only really learn when to brake by driving the car.

💡 Tip: Setup. Install the Python SDK with pip install anthropic, set ANTHROPIC_API_KEY, and install Claude Code from the official docs at code.claude.com. For the Agent SDK use pip install claude-agent-sdk.

🛑 Lab 1: Your first calls and stop reasons (45 min)

  1. Send a basic request; print stop_reason and usage.
  2. Set max_tokens=20 on a long answer and observe "max_tokens".
  3. Add a system prompt and compare the behaviour.

Prove it: name every stop_reason and what your code should do for each.

🌍 Real-world example: Where you'd use this at work

Before building ShopNest's bot, Asha's team checks how every stop reason looks in practice, so their code handles max_tokens and refusal properly instead of crashing on the first long answer.

🔁 Lab 2: Agentic loop with structured errors (90 min)

  1. Define get_customer and lookup_order with detailed descriptions.
  2. Implement the loop on stop_reason.
  3. Return a transient error (retryable) and a business error (not retryable); watch how Claude reacts.
  4. Add a code gate: no lookup_order until get_customer returns verified.

Prove it: explain the three loop-termination anti-patterns.

🌍 Real-world example: Where you'd use this at work

This is the core of ShopNest's support bot: look up the customer, then the order, and react sensibly when the order service times out (retry) or the refund window has passed (explain).

Advertisement

🧪 Lab 3: Structured extraction pipeline (90 min)

  1. Create a record_invoice tool with nullable fields, an enum with “other” + detail, and calculated vs stated totals.
  2. Feed an invoice with no PO number — confirm you get null, not an invented value.
  3. Validate with Pydantic; retry with the document, the failed output and the specific error.
  4. Add two few-shot examples for different layouts and compare empty-field rates.

Prove it: list which failures retries fix and which they can’t.

🌍 Real-world example: Where you'd use this at work

This is ShopNest's invoice pipeline in miniature. The invoice with no PO number is exactly the case that once produced invented values in production.

📦 Lab 4: Message Batches (45 min)

  1. Submit 20 requests with custom_ids; poll until ended.
  2. Match results by custom_id (note the order).
  3. Resubmit only the failed IDs after chunking oversized inputs.

Prove it: calculate the submission cadence for a 30-hour SLA.

🌍 Real-world example: Where you'd use this at work

ShopNest's nightly review classification works this way: submit, wait, match the results by custom_id, and resubmit only the failures.

🤖 Lab 5: Agent SDK coordinator, subagents and hooks (2 h)

  1. Define searcher, analyst and synthesizer AgentDefinitions with scoped tools.
  2. Include "Task" in the coordinator’s allowedTools; check it emits parallel Task calls in one turn.
  3. Pass findings explicitly as structured JSON with source URL and date.
  4. Add a PostToolUse hook that normalises dates, and a pre-tool hook that blocks rm -rf.
  5. Simulate a timeout and return structured error context; confirm the report lists coverage gaps.

Prove it: show that a subagent can’t see the coordinator’s history unless you pass it.

🌍 Real-world example: Where you'd use this at work

This mirrors the carrier-comparison research team, with a safety hook added. When the timeout is simulated, the report must say which section is weaker, not hide the gap.

🧪 Lab 6: Claude Code team configuration (90 min)

  1. Run /init; add a personal preference in ~/.claude/CLAUDE.md; confirm both with /memory.
  2. Create .claude/rules/testing.md with paths: ["**/*.test.*"] and check when it loads.
  3. Add .claude/commands/review.md and a skill with context: fork, allowed-tools and argument-hint.
  4. Configure .mcp.json with ${GITHUB_TOKEN} plus a personal server; confirm both are available.
  5. Try a one-line fix directly and a 30-file change in plan mode.

Prove it: explain why a teammate wouldn’t receive your user-level rules.

🌍 Real-world example: Where you'd use this at work

This is exactly what Ravi did so that new testers get the team's rules, commands and MCP servers the moment they clone the repository.

🔌 Lab 7: Build an MCP server (2 h)

  1. With the Python MCP SDK, expose search_tickets and get_ticket tools and a tickets://catalog resource.
  2. Return isError with categories for failures, and an empty list (not an error) for no matches.
  3. Connect it to Claude Code over stdio; improve descriptions until Claude prefers it over Grep.

Prove it: explain when to use a resource instead of a tool.

🌍 Real-world example: Where you'd use this at work

ShopNest's support team wanted Claude to search their ticket system. A tiny MCP server with two tools and one resource was all it took.

Advertisement

🔍 Lab 8: CI review bot (90 min)

  1. In a GitHub Actions job, run claude -p with --output-format json --json-schema.
  2. Put explicit report/skip criteria and a severity rubric in CLAUDE.md.
  3. Compare a single pass with per-file plus integration passes on a 14-file PR.
  4. Re-run after a new commit, passing earlier findings, and confirm there are no duplicate comments.

Prove it: explain why “only report high-confidence findings” doesn’t reduce false positives.

🌍 Real-world example: Where you'd use this at work

This is Ravi's pull-request reviewer: non-interactive, JSON output, explicit criteria, and no duplicate comments when developers push fixes.

🚫 Common beginner mistake: Doing all eight labs in one weekend. Spread them over the study plan, so each lab follows the lesson it practises.

🛠️ Try it yourself (about 10 minutes)

  1. Create an empty folder or repository called claude-labs.
  2. Run pip install anthropic and set your ANTHROPIC_API_KEY environment variable.
  3. Send one 'Hello' request and print stop_reason and usage.

✅ You are done when: you see end_turn and token counts printed, which is the first step of Lab 1.

🧪 Exam-Style Practice Questions

Try these before opening the answers. They use the same scenario style as the real exam.

Question 1. What must be true for a coordinator built with the Agent SDK to spawn subagents?

  • A. tool_choice must be "any"
  • B. The coordinator's allowedTools must include "Task"
  • C. Each subagent must share the coordinator's session
  • D. Subagents must be MCP servers
Show answer

Answer: B. The Task tool is how subagents are spawned, so it must be allowed. C: subagents run in isolated contexts. D: subagents are AgentDefinitions, not MCP servers. A: tool_choice isn't related.

Question 2. You must ensure extract_metadata runs before any enrichment tool on each document. Per the exam guide, what's the mechanism?

  • A. tool_choice: "none"
  • B. tool_choice: "auto"
  • C. tool_choice: {"type": "tool", "name": "extract_metadata"} on the first call, then later steps in follow-up turns
  • D. Put extract_metadata first in the tools array
Show answer

Answer: C. Forced selection guarantees that specific tool runs first. B leaves it to the model. A prevents tool calls. D: array order doesn't enforce anything. 🔄 On the newest models, forced selection returns a 400; use auto, a clear instruction, and code-side enforcement or structured outputs instead.

Question 3. How many few-shot examples does the guide recommend for ambiguous cases, and what should they contain?

  • A. 2–4 targeted examples showing the reasoning for why one option was chosen over plausible alternatives
  • B. None; use instructions
  • C. 20+, with answers only
  • D. 1 generic example
Show answer

Answer: A. Targeted examples with reasoning help the model generalise. C wastes tokens and teaches pattern-matching. D is too thin. B ignores the most effective technique.

Advertisement

📝 Assignment

Do these tasks in order. Each one has a Done when check, so you know when it is complete. The stretch task is optional but close to what the exam expects from an architect. Keep your answers in one notes file or Git repository, and revisit them in your final week of revision together with the cheat sheet in the last lesson of this course.

  1. Task 1: Complete Labs 1–3 and keep your code in one repository.
    ✅ Done when: Labs 1–3 run end to end from a clean checkout, using only the README you wrote.
  2. Task 2: Complete Labs 5–7 and write two sentences on what surprised you in each.
    ✅ Done when: Each of Labs 5–7 has two sentences of notes covering what surprised you and what you would do differently.
  3. Stretch: finish Lab 8 and run it on a real pull request.
    ✅ Done when: Your CI review bot posted at least one useful comment on a real pull request without duplicates.
Advertisement

❓ Frequently Asked Questions

🤔 Do I need to pay for the labs?

You need a Claude API key with credit for API labs; Claude Code needs an eligible plan or API access.

🤔 Which language should I use?

Python or TypeScript. The labs use Python examples, and both SDKs work the same way.

🤔 How long do the labs take?

About 12 hours in total, spread over the six-week study plan.

🤔 Are the labs required to pass?

No, but the exam tests practical judgement, which the labs build faster than reading.

🏁 Summary

  • Each lab ends with a “prove it” check: if you can explain the answer, you are ready for that topic.
  • Labs 1–4 cover the API (loop, errors, extraction, batches); Labs 5–8 cover the Agent SDK, Claude Code, MCP and CI.
  • About 12 hours in total; spread them across the six-week study plan.
📝 Test yourself: Mock Test 1 · Mock Test 2 · Mock Test 3 · Mock Test 4 · Mock Test 5 (30 scenario-based questions in 60 minutes, with explanations).

Next, continue with Claude Architect Exam: 6-Week Study Plan, Cheat Sheet and Exam-Day Tips.

🎬 Prefer video? Watch QA, automation and AI testing tutorials on the SQA Tools YouTube channel.

Independent study material by SQA Tools. Not affiliated with, endorsed by or sponsored by Anthropic. Claude is a trademark of Anthropic. Mock questions are original practice items, not real exam content. Exam facts checked against Anthropic's official exam guides and certification FAQ on 11 November 2026.