Jargon, debugging & interview prep

Last lesson. Nothing in it is new — that’s the point. The course handed you a debugging tool here, a flag there. This lesson assembles them into the single reflex a colleague already has, then covers the day-to-day job and what an interviewer will and won’t expect.

When the run breaks

The instinct when a run fails is to jump straight to -vvv and drown in output. Resist it. Work outward from the cheapest check, in a fixed order: reachability → inventory → syntax → dry run → narrow → inspect.

ansible web -m ansible.builtin.ping        # 1 can I even reach it? (lesson 7)
ansible-inventory --graph                  # 2 is the host where I think? (lesson 8)
ansible-playbook site.yml --syntax-check   # 3 does it parse? (lessons 13, 29)
ansible-playbook site.yml --check --diff   # 4 what would change? (lesson 29)
ansible-playbook site.yml --limit web01 \
  --start-at-task 'Deploy config'          # 5 shrink the blast radius (lessons 10, 29)
ansible-playbook site.yml -vvv             # 6 full trace, last resort (lesson 29)

Step 1 catches the most common failure class — SSH or WinRM auth — before you read a line of playbook output. Use ansible.windows.win_ping for the Windows estate. If only the second hop fails, that’s lesson 35’s double hop. Step 2 catches “right playbook, wrong hosts”: a host missing from the group , a pattern matching more or less than you meant. Steps 3–4 catch YAML and logic without touching a machine. Step 5 makes the failure cheap to reproduce — one host, starting at the failing task. Only step 6 is archaeology. register plus ansible.builtin.debug prints the value you’re suspicious of (lesson 15). And -vvv — lesson 29’s verbosity ladder — shows what Ansible actually connected to and ran (lesson 16 used it to trace which variable value won).

The failures repeat, and each maps to a lesson you’ve done: auth failures (7, 31), undefined variables — usually a precedence surprise or a group_vars filename that doesn’t match the group (16, 9), YAML/indentation (13), non-idempotent shell tasks reporting changed forever (22), unreachable hosts (2, 8), and missing collections — fixed by requirements.yml (4, 26).

What the job actually is

Day to day, Ansible work is mundane in the best way: patching (win_updates on one side of the estate, package modules on the other), package and service management, templating config files (23), user management, onboarding new hosts (32 for the Windows ceremony), and deploying releases — usually behind serial (28) or a Jenkins job (41). Add compliance enforcement, which is idempotency (22) pointed at policy: run the playbook on a schedule and drift gets corrected. Every “what people say at work” phrase from the course is on the glossary page. Skim it the night before you start.

The interview

For a mid-level role, interviewers expect you to explain: the agentless architecture (2), playbook vs role vs collection (12, 24, 4), idempotency (22), variable precedence at a high level (16), when/loops/handlers (18–20), Vault (27), ad-hoc vs playbook (7), inventory and patterns (8, 10), tags and --limit (29, 10), check mode (29), a debugging approach — the ritual above is your answer — and basic AWX/AAP awareness (39). Scenario questions are common: rolling updates (serial, 28), jump hosts (delegation territory, 28), dynamic inventory (11), secret handling (27). Not expected unless the role is specialist: writing custom modules or deep plugin internals.

If certification comes up, the name you’ll hear is RHCE, exam code EX294: fully hands-on, 240 minutes on RHEL 9/10, minimum score 210/300. It requires an active RHCSA (EX200) before the RHCE is awarded. Its current objectives include running playbooks with ansible-navigator and execution environments, so lesson 40 is on the syllabus. Worth having — but it’s entirely Linux/RHEL, no Windows content, so for this job it validates half your estate.

That’s the course. You arrived reading Bicep and PowerShell. You leave able to read a role and predict which variable wins, explain why a Windows task dies on the second hop, and debug a broken run in the order a senior would. The fluency comes from the first month of real runs. Go break some (in check mode first).