# Module NN —
> **** *Why this module exists for an IT pro — the pain it removes or the payoff it
> unlocks. 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 —
---
## 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 actual teaching content, in prose, with commands and snippets inline. This is the bulk of the
module. No fixed length — go as deep as the topic needs and no further. Use subheadings freely.
Reframe an ops instinct the reader already has wherever you can.*
---
## 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
*A practical exercise that uses AI **and** the tool together, run on the reader's own machine. This
is a tools course — end at a keyboard, not a quiz. State the lab language (Python or shell) once.
Provide starter files in `lab/` where useful and reference them by path.*
**You'll need:** **
**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.*
- [ ] …