Top Ansible Interview Questions for DevOps Engineers (2025)

Ansible has become a cornerstone of modern DevOps, enabling infrastructure as code (IaC) with simplicity and power. In interviews, you'll be expected to demonstrate not just syntax knowledge but a deep understanding of Ansible's architecture, best practices, and troubleshooting. This guide covers the most common Ansible interview questions, from basic concepts to advanced topics like custom modules and dynamic inventories. We'll explore real-world scenarios, including a production incident that highlights the importance of idempotency and error handling. Whether you're preparing for a DevOps engineer role or a platform engineer position, mastering these questions will give you the confidence to ace your interview. Let's dive into the world of Ansible and equip you with the knowledge to succeed.

1. What is Ansible and how does it work?

Ansible is an open-source automation tool that automates configuration management, application deployment, and task orchestration. It is agentless, meaning it does not require any software installed on managed nodes. Instead, it uses SSH (or WinRM for Windows) to connect and execute tasks. Ansible follows a push-based model: the control node pushes modules to managed nodes, executes them, and removes them after completion. Playbooks are YAML files that define the desired state of systems. Ansible uses a declarative approach—you describe what the end state should be, and Ansible ensures that state is achieved. Key components include the inventory (list of hosts), modules (units of work), and roles (reusable collections of tasks).

---
- name: Test connectivity
  hosts: all
  tasks:
    - name: Ping all hosts
      ping:

2. Explain idempotency in Ansible.

Idempotency means that running a playbook multiple times produces the same result without unintended side effects. Ansible modules are designed to be idempotent: they check the current state before making changes. For example, the 'file' module creates a file only if it doesn't exist; the 'yum' module installs a package only if it's not already installed. This ensures that playbooks can be run repeatedly without causing drift. However, not all modules are inherently idempotent—the 'command' and 'shell' modules run every time unless you use 'creates' or 'when' conditions. Best practice is to use idempotent modules whenever possible and avoid 'command' unless necessary.

---
- name: Ensure package is installed
  yum:
    name: httpd
    state: present

- name: Non-idempotent command
  command: echo "Hello" > /tmp/hello.txt
  creates: /tmp/hello.txt

3. What are Ansible roles and how do you structure them?

Roles are a way to organize playbooks into reusable components. Each role has a standard directory structure: tasks, handlers, templates, files, vars, defaults, meta, and tests. This structure promotes modularity and reusability. For example, a 'webserver' role might contain tasks to install Apache, templates for virtual hosts, and handlers to restart the service. Roles can be shared via Ansible Galaxy. To use a role, you include it in a playbook using the 'roles' keyword. Best practices include using 'defaults' for default variables and 'vars' for overrides, and keeping roles focused on a single function.

roles/
  common/
    tasks/
      main.yml
    handlers/
      main.yml
    templates/
      ntp.conf.j2
    files/
      motd
    vars/
      main.yml
    defaults/
      main.yml
    meta/
      main.yml
    tests/
      inventory
      test.yml

4. How do you handle variables in Ansible?

Variables in Ansible can be defined in multiple places with a specific precedence order (from lowest to highest): role defaults, inventory vars, inventory group_vars, inventory host_vars, playbook vars, playbook vars_prompt, playbook vars_files, role vars (defined in role/vars), block vars, task vars, extra vars (passed via command line). The highest precedence wins. Variables can be used in playbooks using Jinja2 templating ({{ variable }}). Best practices include using descriptive names, avoiding hardcoding, and leveraging 'group_vars' and 'host_vars' for environment-specific settings. Use 'debug' module to print variable values during development.

---
- hosts: all
  vars:
    package: httpd
  tasks:
    - name: Install {{ package }}
      yum:
        name: "{{ package }}"
        state: present
    - name: Show variable
      debug:
        var: package

5. Explain Ansible modules and give examples of commonly used ones.

Modules are the units of work in Ansible. They are executed on the managed node and can be written in Python, PowerShell, or other languages. Common modules include: 'command' (runs a command), 'shell' (runs a command via shell), 'copy' (copies files), 'file' (manages file attributes), 'yum'/'apt' (package management), 'service' (manages services), 'template' (Jinja2 templating), 'user' (user management), 'lineinfile' (ensure line in file), and 'debug' (print messages). Each module has parameters and returns JSON output. Use 'ansible-doc' to view module documentation.

---
- name: Install and start nginx
  hosts: webservers
  tasks:
    - name: Install nginx
      yum:
        name: nginx
        state: present
    - name: Start nginx
      service:
        name: nginx
        state: started
        enabled: yes
    - name: Copy config
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: restart nginx
  handlers:
    - name: restart nginx
      service:
        name: nginx
        state: restarted

6. What is Ansible Galaxy and how do you use it?

Ansible Galaxy is a hub for finding, sharing, and managing Ansible roles. You can download roles from Galaxy using the 'ansible-galaxy' command. For example, 'ansible-galaxy install geerlingguy.apache' installs a role. You can also create roles with 'ansible-galaxy init role_name'. Galaxy allows you to manage dependencies via a 'requirements.yml' file. Best practices include specifying version numbers in requirements and reviewing roles before use. Galaxy also supports namespaces and collections (Ansible 2.9+), which bundle multiple roles and modules.

---
roles:
  - name: geerlingguy.apache
    version: 3.1.0
  - name: geerlingguy.nginx
    version: 2.7.0
collections:
  - name: community.general
    version: 4.0.0

7. How do you manage secrets in Ansible?

Ansible Vault encrypts sensitive data like passwords, keys, and API tokens. You can encrypt entire files or individual variables. Use 'ansible-vault create' to create a new encrypted file, 'ansible-vault encrypt' to encrypt an existing file, and 'ansible-vault decrypt' to decrypt. When running a playbook, provide the vault password via '--ask-vault-pass' or a password file. Vault IDs allow multiple passwords. Best practices include never committing unencrypted secrets to version control, using vault for sensitive variables, and integrating with external secret managers like HashiCorp Vault.

# Create encrypted file
ansible-vault create secrets.yml

# Encrypt existing file
ansible-vault encrypt vars/passwords.yml

# Run playbook with vault
ansible-playbook playbook.yml --ask-vault-pass

# Use vault ID
ansible-playbook playbook.yml --vault-id prod@vault-pass.txt

8. What are handlers in Ansible?

Handlers are special tasks that run only when notified by another task. They are typically used for restarting services after configuration changes. Handlers are defined in the 'handlers' section of a playbook or role, and tasks notify them using the 'notify' keyword. Handlers run at the end of the play, in the order they are defined, and only once even if notified multiple times. This prevents unnecessary restarts. You can also force handlers to run with 'meta: flush_handlers'.

---
- name: Configure web server
  hosts: webservers
  tasks:
    - name: Update config
      template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: restart nginx
  handlers:
    - name: restart nginx
      service:
        name: nginx
        state: restarted

9. How do you test Ansible playbooks?

Testing Ansible playbooks involves syntax checks, dry runs, and integration tests. Use 'ansible-playbook --syntax-check' to validate YAML syntax. '--check' mode performs a dry run without making changes. '--diff' shows changes. For unit testing, use 'ansible-playbook' with '--step' to confirm each task. For integration testing, tools like Molecule provide a framework for testing roles in containers or VMs. Molecule supports drivers like Docker, Vagrant, and AWS. It runs converge, verify, and destroy phases. Use 'ansible-lint' to enforce best practices.

---
- name: Converge
  hosts: all
  roles:
    - role: my_role

- name: Verify
  hosts: all
  tasks:
    - name: Check service is running
      service:
        name: nginx
        state: started
      check_mode: no

10. What is dynamic inventory and how do you implement it?

Dynamic inventory allows Ansible to fetch host information from external sources like cloud providers (AWS, GCP, Azure), CMDB, or custom scripts. Instead of a static file, you use a script or plugin that returns JSON. Ansible provides built-in inventory plugins for major clouds. For example, the 'aws_ec2' plugin uses boto3 to list EC2 instances. You can also write custom scripts in any language that output JSON with the required structure. Dynamic inventory enables auto-scaling and reduces manual maintenance.

plugin: aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
hostnames:
  - dns-name
keyed_groups:
  - key: tags.Name
    prefix: tag_Name_