Ansible interview questions and answers

"Run the playbook twice," the interviewer said. "What changes the second time?" The candidate said nothing would, which is the right answer — until the interviewer pointed at a task using the shell module to append a line to a config file. Run it twice and you have the line twice. Run it in a loop for a week and you have a config file that is mostly one line.

Idempotency is the whole point of Ansible, and it is the first thing Ansible interview questions test — usually by finding the place where you broke it. This guide covers the execution model, playbooks and roles, inventory and variables, handlers, Vault, and the Ansible-versus-Terraform question every loop asks.

What Ansible interviews actually test

Ansible interview questions appear in DevOps, SRE, platform and infrastructure loops. Five bands:

• The model — agentless push over SSH, idempotency, declarative modules vs shell commands.
• Structure — playbooks, roles, collections, and how a real repository is laid out.
• Inventory and variables — static vs dynamic inventory, group vars, and precedence.
• Control flow — handlers, conditionals, loops, error handling, check mode.
• Secrets and comparison — Vault, and Ansible versus Terraform.

The agentless model and idempotency

Ansible is agentless and push-based: a control node connects over SSH (or WinRM), copies small Python modules to the target, executes them, collects the result and removes them. Nothing runs permanently on the managed host, which is the main practical advantage over Puppet and Chef — no agent to install, upgrade or debug. The requirements are SSH access and Python on the target.

Then idempotency, which is the concept the whole interview hangs on. Running a playbook repeatedly should converge on the same state, not repeat the same actions. Ansible achieves this because modules are declarative: ansible.builtin.package checks whether the package is installed and reports ok rather than changed if it already is.

So the failure mode is the one in the intro — the shell and command modules cannot know your intent, so Ansible always reports them as changed and they may genuinely repeat work. The expected answers:

• Prefer a real module — lineinfile, blockinfile, copy or template instead of shell: echo ... >> file. This is the single best answer to the intro's question.
• Use creates or removes on command so it skips when the artefact already exists.
• Guard with when after registering a check.
• Set changed_when and failed_when so a read-only command does not report a false change — useful and a strong detail to volunteer.

Also know check mode (--check) as a dry run and --diff to show what would change, plus that check mode is unreliable for playbooks depending on shell output, for the same reason.

Playbooks, roles and structure

A play maps a group of hosts to a list of tasks; a playbook is one or more plays. A role is the reusable unit, with a conventional directory layout — tasks/, handlers/, templates/, files/, vars/, defaults/, meta/ — that Ansible loads automatically.

--- # site.yml
- name: Configure web tier
  hosts: webservers
  become: true
  vars:
    app_port: 8000

  tasks:
    - name: Install nginx
      ansible.builtin.package:
        name: nginx
        state: present          # declarative: 'ok' if already installed

    - name: Deploy config from template
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
        validate: 'nginx -t -c %s'   # never ship a config that fails to parse
      notify: Reload nginx     # only fires if this task reported 'changed'

  handlers:
    - name: Reload nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

Two things in that snippet are common interview points. validate runs a syntax check before replacing the file, so a broken template cannot take the service down — a detail that reads as production experience. And notify introduces handlers.

Handlers, and the question about when they run

A handler is a task that runs only when notified by a task that actually reported changed, and by default it runs once, at the end of the play, no matter how many tasks notified it. That design means ten config changes cause one service restart rather than ten.

The follow-ups interviewers use:

• What if the play fails before the end? The handler never runs, leaving a changed config that has not been applied. Force it with --force-handlers, or flush explicitly with meta: flush_handlers when the ordering matters.
• How do you run a handler mid-play? meta: flush_handlers.
• Why did my handler not fire? Almost always because the notifying task reported ok, not changed — which is idempotency working correctly.

Also know the control-flow basics: when conditionals, loop (which replaced with_items), register to capture output, block/rescue/always for error handling, serial for rolling updates across a fleet, and tags to run part of a playbook.

Inventory, variables and precedence

Inventory defines hosts and groups, in INI or YAML. Dynamic inventory plugins query AWS, Azure or GCP so the host list reflects reality instead of a file someone forgot to update — expect a question on why that matters for autoscaling groups.

Variables can be set in a dozen places, and interviewers ask about precedence because it causes real confusion. The practical summary: defaults/ in a role is the weakest (designed to be overridden), then inventory group vars, then host vars, then play vars, then -e extra vars on the command line, which win over everything. The usable rule to state: role defaults are for sensible defaults, group vars for environment differences, and -e for one-off overrides.

Know group_vars/ and host_vars/ directory conventions, facts gathered automatically from targets (and gather_facts: false as a speed optimisation), and Jinja2 templating, since template is one of the most-used modules.

Ansible Vault, and Ansible vs Terraform

Vault encrypts secrets at rest so they can live in Git — ansible-vault encrypt, edit, view, and running with --ask-vault-pass or a password file. Best practice worth stating: encrypt only the secret values rather than whole files where practical, so diffs stay readable; use !vault-tagged variables; and in mature setups source secrets from a real secret manager rather than Vault files.

Then the comparison, asked in essentially every loop. The clean framing is provisioning versus configuration:

• Terraform is declarative infrastructure provisioning with state — it creates the servers, networks and managed services, and knows what it created so it can plan and destroy.
• Ansible is configuration management and orchestration — it configures what exists, deploys applications, and runs ordered operational procedures like rolling restarts.
• They are complementary, and the common pattern is Terraform to build infrastructure, Ansible to configure it. Ansible can provision cloud resources and Terraform can run provisioners, but each is worse at the other's job.
• State is the sharpest difference — Terraform keeps a state file and reconciles against it; Ansible is stateless and inspects the target each run.

Our Terraform interview questions guide covers the other side, and the Jenkins interview questions guide covers the pipeline that usually triggers both.

The docs, a real fleet, ChatGPT — where each fits

• The official Ansible documentation — the module index is the reference you will actually use, and the best-practices page answers the structure questions.
• Ansible for DevOps (Jeff Geerling) — the standard practical book, and his GitHub roles are good examples of real structure.
• Ansible Galaxy — worth naming as the shared role/collection registry, and worth reading a popular role's source for layout.
• Configuring three throwaway VMs — highest yield. Write a role, run it twice, and find the task that reports changed every time. That is the interview question, discovered by yourself.
• Molecule — role testing. Naming it signals maturity, since most candidates have never tested a role.
• ChatGPT — good for generating YAML and explaining modules. It will not point at your shell task and ask what happens on the second run.
• Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud and pushes when your answer describes a feature rather than a consequence. Fair tradeoff: Ari will not run your playbook.

How to prepare for an Ansible interview

• Week 1: the model. Configure a VM with a playbook, run it twice, and make every task report ok on the second run.
• Week 2: structure. Refactor that playbook into a role with defaults, templates and handlers, and explain the layout aloud.
• Week 3: inventory, variables and control flow — dynamic inventory, precedence experiments, block/rescue, and serial for a rolling restart.
• Final week: Vault, then rehearse the Terraform comparison as complementary rather than competing, and run two full spoken mocks.

Building the rest of the stack? The Terraform guide covers provisioning, the Jenkins guide covers CI/CD, the Linux guide covers the systems knowledge these playbooks assume, and the DevOps engineer guide covers the wider loop.

Frequently asked questions

What are the most common Ansible interview questions?

The most common questions cover what idempotency means and what happens when you run a playbook twice, why the shell and command modules break idempotency and what to use instead, the difference between a playbook and a role, when handlers run and why one might not fire, variable precedence across defaults, group vars and extra vars, how Ansible Vault protects secrets, and how Ansible compares with Terraform.

What is idempotency in Ansible?

Idempotency means running a playbook repeatedly converges on the same desired state rather than repeating the same actions. Ansible achieves this because its modules are declarative — a package module checks whether the package is already installed and reports ok rather than changed. The exception is the shell and command modules, which cannot know your intent, always report changed, and may genuinely repeat work such as appending a line to a file every run.

How do you make a shell command idempotent in Ansible?

First prefer a real module such as lineinfile, blockinfile, copy or template, which is almost always possible and is the best answer. If you must run a command, use the creates or removes arguments so it skips when the target artefact already exists, guard it with a when condition after registering a check, and set changed_when and failed_when so a read-only command does not report a false change.

When do handlers run in Ansible?

A handler runs only when notified by a task that actually reported changed, and by default it runs once at the very end of the play regardless of how many tasks notified it, so ten config changes trigger one service restart. If the play fails before the end the handler never runs, leaving changed configuration unapplied — use --force-handlers or meta: flush_handlers to control this. A handler not firing usually means the notifying task reported ok.

What is the difference between Ansible and Terraform?

Terraform is declarative infrastructure provisioning that maintains a state file, so it creates servers, networks and managed services and can plan and destroy what it created. Ansible is configuration management and orchestration that configures existing machines, deploys applications and runs ordered procedures such as rolling restarts, and it is stateless, inspecting the target each run. They are complementary, and the common pattern is Terraform to build and Ansible to configure.

What is Ansible Vault and how should you use it?

Ansible Vault encrypts sensitive values at rest so they can safely live in version control, using commands such as ansible-vault encrypt, edit and view, with playbooks run using a vault password prompt or password file. Best practice is to encrypt individual secret values rather than entire files where practical, so diffs remain readable, and in mature environments to source secrets from a dedicated secret manager rather than committing vault files at all.