<aside> 🧭
Module 01 · Fundamentals, Connectivity & Your First Playbook
This module assumes zero Ansible knowledge. It takes you from "what is this tool" to a working, idempotent playbook — in the order you actually need to learn it.
🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)
</aside>
<aside> 🍽️
The analogy. Think of a restaurant chain with fifty branches, and tonight the same dish has to be cooked in every kitchen. You could fly to each branch and cook it yourself — slow, and you cannot be in two places at once. You could install a robot chef in every kitchen — expensive, and now you own fifty robots that need patching and repairing. Or you could pick up the phone, call each kitchen in turn, and read out the recipe.
That third option is Ansible. The phone line is SSH, the recipe is your playbook, and the kitchen's own oven is the target's Python. When the call ends, nothing of yours is left behind in the kitchen — which is exactly what people mean when they say Ansible is "agentless".
</aside>
Ansible is a push-based, agentless, declarative-ish configuration management and orchestration engine.
Every word in that sentence is a separate interview answer:
| Term | Meaning | Why it matters |
|---|---|---|
| Push-based | The control node starts the connection and pushes config out to the targets | Opposite of Puppet/Chef, where agents pull from a master every ~30 min |
| Agentless | No daemon on managed nodes. SSH for Linux, WinRM/PSRP for Windows | No agent to install, patch, monitor, or carry a CVE |
| Declarative-ish | You describe desired state, but tasks still execute top-down in order | Not a dependency graph like Terraform — order matters |
| Orchestration | Coordinates work across hosts in a defined sequence | Rolling restarts, DB before app — a bash loop cannot do this |
<aside> 🏢
The analogy. Think of a head office and its branch shops. The head office holds the manuals, the staff list and the phone — and it is the only place that needs any of them. A branch needs just two things to be useful: a working phone line, and someone on the end of it who speaks your language.
The head office is the control node. The phone line is SSH, and the person who understands you is Python. That two-item list is the complete requirement for a managed node. And notice what the branches never receive: a filing cabinet of their own. Nothing of yours sits on the server between runs, which is why adding your five-hundredth machine costs one line in a text file rather than an installation.
</aside>
There are only two roles a machine can play.
flowchart TD
A["🖥️ CONTROL NODE<br>ansible-core installed HERE only<br>Python 3.9+<br>Holds inventory, playbooks, roles"]
A -->|"SSH · port 22"| B["web01<br>needs: sshd + Python"]
A -->|"SSH · port 22"| C["web02<br>needs: sshd + Python"]
A -->|"SSH · port 22"| D["db01<br>needs: sshd + Python"]
A -->|"WinRM · port 5985"| E["win01<br>needs: PowerShell<br>no Python"]
A -->|"network_cli"| F["switch01<br>no Python at all"]
Read the diagram carefully. Ansible exists on exactly one machine. The targets have nothing installed for Ansible's benefit — they have sshd because every Linux server already has sshd, and they have Python because every modern Linux distribution ships Python. That is the entire "agentless" claim, and it is why Ansible spreads through organisations faster than agent-based tools.
<aside> ⚠️
A control node cannot be native Windows. WSL2 works, native Windows does not. Managed nodes can be Windows, over WinRM. This exact asymmetry is a frequent trap question.
</aside>