Ansible Interview Questions — Playbooks, Roles, Vault & Cheat-Sheet

❓ Q · What is the difference between a module and a plugin?

Modules are the units of work that get copied to and executed ON the managed node — ansible.builtin.dnf, copy, service, etc. Each one runs on the target, does the action, and returns JSON (ok/changed/failed). Plugins are Python pieces that run on the control node and extend Ansible's own behaviour — they never touch the target. The families interviewers expect you to name: lookup plugins (pull data in at templating time, e.g. lookup('file', …), lookup('env', …)), filter plugins (the | default, | to_json, | regex_replace transforms in Jinja2), connection plugins (ssh, winrm, local, docker — how Ansible reaches the host), callback plugins (control on-screen output and logging, e.g. the recap or a Slack notifier), plus inventory, test and become plugins. Trap: "everything is a module" is wrong — say "modules execute on the target, plugins execute on the controller."

❓ Q · Static vs dynamic inventory — what is dynamic inventory and when do you use it?

A static inventory is a hand-written INI or YAML file listing hosts and groups — fine when the fleet is small and stable. A dynamic inventory is generated at runtime by an inventory plugin that queries a live source so the host list is never stale. In 2026 the right answer is plugins, not the old executable scripts: amazon.aws.aws_ec2 for AWS, azure.azcollection.azure_rm for Azure, google.cloud.gcp_compute for GCP, plus VMware, OpenStack and constructed. You enable it with a *.aws_ec2.yml config in the inventory path (and enable_plugins in ansible.cfg), then run ansible-inventory -i inventory.aws_ec2.yml --graph to verify. The big win is keyed_groups / compose: hosts auto-group by tag, region or instance state, so a new EC2 box appears in tag_role_web automatically. Use dynamic for cloud/auto-scaling fleets; use static for a fixed lab or bootstrap. Trap: don't say "a Python script that prints JSON" — that's the deprecated style; lead with inventory plugins.

❓ Q · What are block / rescue / always, and how do you do error handling and retries?

A block groups tasks so you can apply shared directives (when, become, tags) once — and, crucially, it gives Ansible a try/catch/finally. rescue runs only if a task in the block fails; always runs no matter what (success or failure) — perfect for cleanup, releasing a lock, or re-enabling monitoring. Inside a rescue, ansible_failed_task and ansible_failed_result tell you what blew up. For retries on flaky steps, use until with retries and delay: until: result.rc == 0, retries: 5, delay: 10, with register: result — Ansible re-runs the task until the condition is true or attempts run out. Related controls interviewers pair with this: ignore_errors: true (keep going past a failure), failed_when: (define your own failure condition, e.g. a string in stderr), and any_errors_fatal: true (abort the whole play across all hosts on the first failure). Trap: rescue does NOT catch unreachable hosts — those are transport failures, not task failures; only failed tasks trigger a rescue.

❓ Q · How do loops work (loop vs with_items) and how do you use when: and register together?

loop: is the modern, recommended way to iterate; with_items (and the other with_* styles) is the older syntax now superseded — say "use loop; with_items still works but is legacy." Inside the loop the current element is item. Tune behaviour with loop_control: loop_var (rename item to avoid clashes in nested loops), label (clean up noisy output, e.g. show just item.name), index_var, and pause. Conditionals use when: — a raw Jinja2 expression (no {{ }} needed), e.g. when: ansible_facts['os_family'] == 'RedHat'; multiple items in a when list are AND-ed. register captures a task's result into a variable so a later task can branch: register: svc then when: svc.rc != 0. Two classic gotchas: (1) when you loop AND register, the result holds a .results list, so you iterate svc.results, not svc directly; (2) when is evaluated per item, so combining loop + when filters elements rather than skipping the whole task. Trap: don't reach for with_items in a 2026 interview — and never put {{ }} around the whole when expression.

❓ Q · Explain Ansible variable precedence in full — where do extra-vars, role vars, defaults, host_vars and set_fact sit?

Ansible merges variables from about 22 sources; when the same name is set in several, the highest-precedence one wins. You don't have to recite all 22, but you must know the anchors and their order. Lowest to highest, the ones interviewers test: role defaults (defaults/main.yml, the weakest — built to be overridden) → inventory group_vars → playbook group_vars → inventory host_vars → playbook host_vars → host facts / cached set_facts → play vars / vars_files → role vars (vars/main.yml, much stronger than defaults) → block vars → task vars → include_vars → set_fact / registered vars → role & include params → extra-vars (-e / --extra-vars, the absolute winner). The two facts that catch people: group_vars beats role defaults but loses to role vars; and -e overrides everything — even set_fact. Trap: "my override doesn't work" is almost always because the value was put in role vars/ (high precedence) instead of defaults/ (low), or because something passed -e upstream. Use ansible-playbook --extra-vars only as a deliberate override, and put tunables in defaults/.

❓ Q · What is Event-Driven Ansible (EDA) and how do rulebooks differ from playbooks?

Event-Driven Ansible (EDA) is the part of Ansible that reacts to events automatically instead of waiting for a human to press run — it's how you do auto-remediation and self-healing in 2026. The unit of work is a rulebook (run by ansible-rulebook), and it has three parts: sources (plugins that listen for events — a webhook, Kafka, Prometheus/Alertmanager alerts, a Git change, AWX/AAP job events), rules (condition: expressions written in a language called Drools-style / EDA condition syntax, e.g. event.payload.alertname == "DiskFull"), and actions (most often run_playbook or run_module). The contrast interviewers want: a playbook is imperative-on-demand — you run it and it configures desired state top-to-bottom; a rulebook is declarative-reactive — it sits running, watches a stream of events, and fires a playbook only when a condition matches. In AAP this runs on the EDA Controller alongside the Automation Controller. Trap: don't say "EDA replaces playbooks" — it triggers them; the playbook is still where the actual change happens.

❓ Q · How do you test Ansible code with ansible-lint and Molecule, and why use FQCN?

ansible-lint is static analysis — it parses your playbooks/roles without running them and flags style problems, deprecations and risky patterns (using command where a module exists, missing name:, bare variables, non-FQCN module names). It ships profiles (min → production) you tighten over time and runs in CI on every PR. Molecule is the functional test harness for roles: it spins up a throwaway target (Docker/Podman by default, also Vagrant/cloud), runs the role, and then runs a converge + idempotence check — the idempotence step re-runs the role and fails the build if anything reports changed, which is how you prove idempotency automatically. Its phases are dependency → create → converge → idempotence → verify → destroy, where verify asserts the end state (often with Ansible asserts or testinfra). FQCN (Fully Qualified Collection Name, e.g. ansible.builtin.copy instead of bare copy) removes ambiguity about which collection a module comes from, is required by the production lint profile, and future-proofs you as modules move between collections. Trap: lint is static (no hosts touched); Molecule actually executes the role on a real ephemeral host — name both and say which is which.

❓ Q · What do delegate_to, run_once, async/poll and tags do, and when would you use each?

delegate_to runs a task on a different host than the one being looped over — the classic uses are talking to a load balancer or DNS API to drain a node, or gathering something from a central box; pair it with delegate_facts: true if you want the facts stored against the delegate. run_once: true runs a task a single time for the whole batch instead of once per host (e.g. take one DB migration, send one notification) — often combined with delegate_to: localhost. async + poll handle long-running or fire-and-forget tasks: async: 600 sets a max runtime and poll: 0 means "start it and don't wait" (kick off a long job, check it later with the async_status module), while poll: 5 backgrounds it but checks every 5s so SSH doesn't time out. tags let you run or skip slices of a play: label tasks/roles with tags:, then --tags deploy runs only those, --skip-tags slow excludes them; --tags always and the special never tag give you always-on / opt-in tasks. Trap: run_once picks the first host in the current batch, so under serial it can run once per wave, not truly once — delegate to localhost if you need exactly one execution.