<aside> 🧭

Module 14 · Full Interview Simulation

The final module. Four rounds in the shape a real DevOps interview takes: rapid-fire concepts, scenario design, debugging under pressure, and system design.

How to use this one is different. Do not read it. Answer out loud first, then open the toggle. Reading the answers produces recognition; producing them produces recall, and only recall survives an interview room.

Prerequisite: Modules 01–13.

</aside>

Part A · How Ansible interviews are actually structured

<aside> 🎭

The analogy. Think of the difference between reading about swimming and getting into the water. You can know the theory of a stroke perfectly and still flounder the first time, because reading builds recognition — the comfortable feeling of "yes, that is correct" — while an interview demands recall, which is producing the answer out of nothing with someone watching you.

Those are two different skills, and only one of them is trained by reading. So do not read this module. Answer each question aloud first, then open the toggle. The gap between what came out of your mouth and what is written there is precisely the thing worth working on — and it is a gap you cannot see any other way.

</aside>

Round	What is asked	What is actually assessed
Rapid-fire	Definitions, mechanisms, "what is the difference between"	Whether you used it or read about it
Scenario	"How would you roll out X to 500 servers?"	Judgement, risk awareness, and whether you volunteer the failure modes
Debugging	A broken playbook or a described incident	Method — do you classify before investigating, or guess
System design	"Design automation for a 2,000-host estate"	Whether you think about people and process, not just YAML

<aside> 🔑

Three habits that raise every answer, regardless of the question:

1. Name the trade-off unprompted. "strategy: free is faster, but it removes every cross-host ordering guarantee." Volunteering the cost is the clearest signal of real use.

2. Reach for the concrete failure. "I've had that fail because sudo changed $HOME and Ansible looked in /root/.ssh." A specific scar beats a correct definition.

3. Say what you would check, not just what you would conclude. Interviewers hire people who can diagnose, not people who happen to know this answer.

</aside>

Part B · Round 1 — Rapid-fire

<aside> ⏱️

Twenty questions. Give yourself 60 seconds each, out loud. Open the toggle only after answering.

</aside>

1. Explain Ansible in one sentence, then unpack it.
2. Walk me through what happens when a task runs.
3. Does Ansible run all tasks on host 1 then move to host 2?
4. What does ansible all -m ping test?
5. Four ansible.cfg locations, in order. Do they merge?
6. Highest and lowest variable precedence?
7. set_fact versus register versus vars:?
8. Why is when: myvar true when the value is false?
9. Three ways to make a shell task idempotent — and the better question.