What is idempotency in Ansible and why does it matter?
Understand idempotency in Ansible — how tasks change only what differs, why re-running playbooks is safe, and how changed vs ok reporting works.
Expected Interview Answer
Idempotency in Ansible means that running the same playbook multiple times produces the same end state — a task only makes changes when the system differs from the desired state, so re-runs on an already-correct host report 'ok' and change nothing.
Ansible modules achieve this by checking current state before acting: the apt module won't reinstall a package that's already present, and the copy module won't rewrite a file whose content already matches. This lets you run playbooks safely and repeatedly, converging drifting systems back to the declared state. It matters because it makes automation predictable, safe to retry after failures, and honest about what actually changed via the changed/ok reporting.
- Safe to re-run playbooks without side effects
- Accurate change reporting (changed vs ok)
- Enables convergence toward a declared desired state
- Supports check mode (dry runs) reliably
- Reduces risk in CI/CD and scheduled automation
AI Mentor Explanation
Idempotency is like a groundsman asked to keep the pitch rolled to a set firmness: if the pitch already meets the spec, he does nothing and notes 'no action'; if it has softened, he rolls it back to spec. Whether he's asked once or five times a day, the pitch ends identical — extra requests on an already-correct pitch change nothing, exactly how a re-run Ansible task reports 'ok' without acting.
Step-by-Step Explanation
Step 1
Declare desired state
Write tasks that describe the target state (package present, service started) rather than imperative commands.
Step 2
Module checks current state
Before acting, the module inspects the host — is the package installed, is the file content already correct?
Step 3
Act only on difference
If current state matches desired, the module does nothing and reports 'ok'; if it differs, it makes the change and reports 'changed'.
Step 4
Report accurately
Ansible aggregates changed/ok/failed counts so you see exactly what re-running did — often nothing on a converged host.
Step 5
Re-run safely
Because tasks are state-checking, you can run the playbook repeatedly to enforce and verify configuration without side effects.
What Interviewer Expects
- A clear definition: same result no matter how many times you run
- Understanding that modules check state before acting
- Awareness of changed vs ok reporting
- Recognition that command/shell are not idempotent by default
- Why idempotency enables safe re-runs and check mode
Common Mistakes
- Assuming every task is automatically idempotent, including shell/command
- Confusing idempotency with simply not erroring on re-run
- Using command to do work a stateful module already handles idempotently
- Ignoring changed_when/creates to make ad-hoc commands idempotent
- Thinking idempotency means the task never runs, rather than never changing state unnecessarily
Best Answer (HR Friendly)
“Idempotency means you can run the same Ansible automation over and over and always end up in the same, correct state. If a server is already set up right, Ansible leaves it alone; if something is off, it fixes just that. This makes automation safe to repeat without breaking anything.”
Code Example
- name: Converge web server config
hosts: web
become: true
tasks:
- name: Ensure nginx installed (no reinstall if present)
ansible.builtin.apt:
name: nginx
state: present
- name: Deploy config (rewrites only if content differs)
ansible.builtin.copy:
src: nginx.conf
dest: /etc/nginx/nginx.conf
mode: '0644'# command is NOT idempotent by default; guard it
- name: Initialize database only once
ansible.builtin.command: /usr/local/bin/init-db.sh
args:
creates: /var/lib/app/.initialized
- name: Run migration and control 'changed' status
ansible.builtin.shell: /usr/local/bin/migrate.sh
register: migrate
changed_when: "'applied' in migrate.stdout"Follow-up Questions
- Which built-in modules are inherently idempotent and which are not?
- How do the creates and removes arguments make command idempotent?
- What are changed_when and failed_when used for?
- How does check mode (--check) rely on idempotency?
- How would you make a shell task report changed correctly?
MCQ Practice
1. What does idempotency guarantee when a playbook is re-run on an already-correct host?
An idempotent task checks state first; if the host already matches the desired state, it changes nothing and reports 'ok'.
2. Which module is NOT idempotent by default?
The command module runs whatever you give it every time; you make it idempotent with guards like creates/removes or changed_when.
3. Which argument makes a command task skip when a marker file already exists?
The creates argument tells the command module to skip execution if the named file already exists, adding idempotency.
Flash Cards
What is idempotency in Ansible? — Running the same playbook repeatedly yields the same end state; tasks only change hosts that differ from desired state.
Why does idempotency matter? — It makes automation safe to re-run, gives accurate change reporting, and supports convergence and check mode.
Is the command module idempotent? — No — it runs every time unless you add guards like creates, removes, or changed_when.
What is 'changed' vs 'ok'? — 'changed' means the task altered state; 'ok' means the desired state already existed and nothing was modified.