> **<One-line hook.>** *Why this module exists for an IT pro: the pain it removes or the payoff it > delivers. One sentence. Make them want to keep reading.* --- ## Prerequisites *Which prior modules this one depends on, named explicitly (the dependency chain). If a reader could parachute in here with only some of the course, say what they minimally need.* - Module X: <what it gave you that this module uses> --- ## Learning objectives *3–5 outcomes, action verbs, phrased as what the reader can **do** afterward, not "understand X."* By the end of this module you can: 1. … 2. … 3. … --- ## Key concepts *The teaching content: **theory only**. Explain the concept and why it matters; reframe an ops instinct the reader already has. To show a command, show it **with example output** as illustration; do NOT tell the reader to run anything here (all hands-on is the lab, and the lesson must not duplicate it). No slop filler. No fixed length; go as deep as the topic needs, no further.* --- ## The AI angle *The module's AI-specific reason for existing: the thing that makes this more than a generic devops lesson. Pull it from the syllabus entry for this module and make it concrete. This section is the differentiator; never skip it.* --- ## Hands-on lab *The only place the reader runs things. End at a keyboard, not a quiz. State the lab language (Python or shell) once; provide starter files in `lab/` and reference them by path. **From Module 4 on, the learner directs the AI agent (Claude Code as the worked example) to do the git/setup work and then verifies it; they don't type the commands by hand.** In Modules 1–3 the learner still runs git manually, on purpose.* **You'll need:** *<tools/setup required for this lab>* **Steps:** 1. … 2. … --- ## Where it breaks *The honest caveats: limits, pitfalls, where a tool or analogy stops holding. This section builds trust with a skeptical audience. Always present; never sanded off.* --- ## Check for understanding *A short self-check or a concrete "you're done when…" criterion. Self-assessment only, no grading.* **You're done when:** … --- ## Verify-before-publish *For fast-moving topics only: what to re-check at build/publish time: versions, pricing, tool behavior, UI labels that drift. Omit this section for durable-core modules with nothing volatile.*

# Module NN: > **<One-line hook.>** *Why this module exists for an IT pro: the pain it removes or the payoff it > delivers. One sentence. Make them want to keep reading.* --- ## Prerequisites *Which prior modules this one depends on, named explicitly (the dependency chain). If a reader could parachute in here with only some of the course, say what they minimally need.* - Module X: <what it gave you that this module uses> --- ## Learning objectives *3–5 outcomes, action verbs, phrased as what the reader can **do** afterward, not "understand X."* By the end of this module you can: 1. … 2. … 3. … --- ## Key concepts *The teaching content: **theory only**. Explain the concept and why it matters; reframe an ops instinct the reader already has. To show a command, show it **with example output** as illustration; do NOT tell the reader to run anything here (all hands-on is the lab, and the lesson must not duplicate it). No slop filler. No fixed length; go as deep as the topic needs, no further.* --- ## The AI angle *The module's AI-specific reason for existing: the thing that makes this more than a generic devops lesson. Pull it from the syllabus entry for this module and make it concrete. This section is the differentiator; never skip it.* --- ## Hands-on lab *The only place the reader runs things. End at a keyboard, not a quiz. State the lab language (Python or shell) once; provide starter files in `lab/` and reference them by path. **From Module 4 on, the learner directs the AI agent (Claude Code as the worked example) to do the git/setup work and then verifies it; they don't type the commands by hand.** In Modules 1–3 the learner still runs git manually, on purpose.* **You'll need:** *<tools/setup required for this lab>* **Steps:** 1. … 2. … --- ## Where it breaks *The honest caveats: limits, pitfalls, where a tool or analogy stops holding. This section builds trust with a skeptical audience. Always present; never sanded off.* --- ## Check for understanding *A short self-check or a concrete "you're done when…" criterion. Self-assessment only, no grading.* **You're done when:** … --- ## Verify-before-publish *For fast-moving topics only: what to re-check at build/publish time: versions, pricing, tool behavior, UI labels that drift. Omit this section for durable-core modules with nothing volatile.* - [ ] …