Memory hook: Describe the state once, parameterize the differences.
Must remember
A play selects hosts and applies tasks; a playbook is an ordered list of plays. Each task invokes a module with arguments. Use fully qualified collection names to identify the intended module. YAML indentation and list/mapping structure matter; quote a value that begins with a Jinja expression and quote file modes such as '0640' to avoid type surprises.
Prefer state-aware modules over shell commands. package, user, file and service modules can reason about existing state. command avoids shell interpretation; shell enables features such as pipelines but increases quoting and injection concerns. Use a shell only when its features are actually required.
Variables come from multiple scopes with defined precedence. Role defaults are intended to be easy to override; extra variables supplied with -e have very high variable precedence. Facts describe discovered host properties. A registered result records a task's return structure for that host, such as return code, stdout or changed state. Inspect the structure instead of guessing a field.
Loops repeat a task over items. With a registered loop, results are commonly a list of per-item outcomes; do not treat the aggregate as one simple stdout. Use meaningful loop variable names for nested reuse. Conditions use expressions, normally without wrapping the entire condition in Jinja delimiters.
Keep host-specific data in inventory variables and reusable logic in tasks/roles. Validate required values with assertions before changing systems. Avoid hard-coding a distribution version, device name or username when the requirement calls for inventory-driven behavior.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Install a package only if absent | A package module with the intended state. |
| Use a command result later | register, then inspect the returned fields. |
| Apply the same user definition to several users | A loop over structured data. |
Traps
- A registered loop result is not the same shape as one task result.
- Using shell for everything discards useful state awareness.
Active recall
1. Fact versus variable versus registered result?
Discovered host data, supplied/computed values and a task’s returned data.
2. Why use FQCNs?
To select the intended module unambiguously.
3. Why quote file modes?
To preserve the intended permission representation rather than accidental numeric parsing.
4. command versus shell?
Direct command execution versus shell interpretation.
5. Why assert inputs early?
To stop before partial changes when prerequisites or data are invalid.