Ansible Interview Questions

Analogy categoryAnalogies

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.

yaml

- 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: restarted

Troubleshooting 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) vs changed_when (post-execution change reporting) vs register (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_to runs a task on a different host than the current target; run_once limits 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.