Core Concept Questions
Interviewers frequently start with fundamentals: what is Ansible, why is it agentless, and what is the difference between a playbook, a role, and a module. Being able to clearly explain that a module is the smallest unit of work (like apt or copy), a task invokes one module with specific arguments, a play maps a set of tasks to a group of hosts, and a playbook is an ordered list of plays, demonstrates that you actually understand the execution model rather than having memorized commands. A strong answer also mentions that Ansible uses an inventory (static INI/YAML or dynamic script/plugin) to define which hosts exist and how they're grouped.
Cricket analogy: Explaining the module-task-play-playbook hierarchy is like explaining cricket's own structure: a delivery is the smallest unit (module), an over is a set of six deliveries (task with loop), an innings is a set of overs against one team (play), and a full match is the whole structured event (playbook) — interviewers want to see you know the hierarchy, not just buzzwords.
A strong candidate distinguishes 'play' from 'playbook' precisely: a playbook is the YAML file containing one or more plays, and each play targets a specific host group with its own set of tasks/roles and connection variables (become, vars, etc).
Playbook Mechanics Questions
A very common question is: 'what is the difference between when and changed_when, and how does register interact with them?' The when clause is a conditional that decides whether a task runs at all, evaluated before execution; changed_when overrides how Ansible reports whether a task caused a change, evaluated after execution, which is critical for keeping command/shell tasks idempotent-looking in output. register captures a task's full result object (stdout, stderr, rc, changed) into a variable so later tasks can branch on it with when. Interviewers also probe handlers versus regular tasks — handlers only run once at the end of a play, triggered by notify, even if notified by multiple tasks, and they run in the order they're defined, not the order they were notified.
Cricket analogy: The when clause is like an umpire deciding before the ball is bowled whether a no-ball call applies (a pre-condition), while changed_when is like the third umpire reviewing after the ball to decide how the outcome gets recorded on the scorecard — two different decision points.
- name: Check disk usage
ansible.builtin.command: df -h /
register: disk_check
changed_when: false # read-only, never reports 'changed'
- name: Alert if disk usage is high
ansible.builtin.debug:
msg: "Disk usage is high on {{ inventory_hostname }}"
when: "'9' in disk_check.stdout.split()[4]"
- name: Update config file
ansible.builtin.template:
src: app.conf.j2
dest: /etc/app/app.conf
notify: Restart app
handlers:
- name: Restart app
ansible.builtin.service:
name: app
state: restartedTroubleshooting and Scenario Questions
Senior interviews probe practical debugging: 'a playbook worked fine in staging but fails only on one host in production — how do you debug it?' A strong answer walks through ansible-playbook -vvv for verbose output, ansible <host> -m setup to inspect gathered facts for that specific host (checking for an OS version or package manager difference), running the failing task in isolation with ansible <host> -m <module> -a '<args>', and checking whether the host has a stale fact cache or a different Python interpreter path (ansible_python_interpreter). Another classic scenario question is explaining delegate_to and run_once — used when a task (like updating a load balancer or sending a deployment notification) should execute on a different host, or only a single time, rather than once per host in the play's target group.
Cricket analogy: Debugging one failing host among many is like a fast bowler who's brilliant in every match except on one particular pitch — you check pitch-specific conditions (facts) rather than assuming the bowler's technique itself changed, the way analysts studied why certain bowlers struggled specifically on flat Chepauk pitches.
A frequently mishandled detail: run_once still requires a valid host to execute on, and by default it picks the first host in the play's batch — combine it carefully with delegate_to if the task must run on a specific control or utility host rather than an arbitrary member of the target group.
- Know the execution hierarchy: module (smallest unit) -> task -> play -> playbook, plus how inventory groups hosts.
- Be precise about
when(pre-execution condition) vschanged_when(post-execution change reporting) vsregister(captures results). - Handlers run once at the end of a play, in definition order, only if notified by at least one task.
- Debug host-specific failures with
-vvv,ansible <host> -m setup, and isolated ad-hoc module runs. delegate_toruns a task on a different host than the current target;run_oncelimits a task to a single execution across the batch.- Explain agentless SSH-based architecture clearly, since it's almost always the first fundamentals question asked.
- Practical scenario answers (debugging steps, rolling deploy design) impress more than reciting command syntax alone.
Practice what you learned
1. In the Ansible execution hierarchy, what is the smallest unit of work?
2. What is the key difference between `when` and `changed_when`?
3. When do handlers execute in a playbook run?
4. What does `register` do in a task?
5. What is the purpose of `delegate_to` in a task?
Was this page helpful?
You May Also Like
Ansible Best Practices
Field-tested conventions for structuring playbooks, roles, and inventories so Ansible automation stays maintainable, secure, and idempotent as it scales.
Ansible Quick Reference
A condensed cheat sheet of the most-used Ansible CLI commands, playbook keywords, and module patterns for day-to-day automation work.
Deploying a Web App with Ansible
A hands-on walkthrough of provisioning a server, installing dependencies, and deploying a web application with an Ansible playbook, including zero-downtime rollout patterns.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics