Ansible Interview Questions: Idempotence, Handlers and Check Mode

Prepare the local playbook

The exercise was run with ansible-core 2.19.0 and Python 3.12.14 on macOS arm64. Save this file as config.yml in a new practice directory. The only managed file is practice.conf inside the directory you supply. The handler prints a message; it does not restart anything.

- name: Practice a local configuration change
  hosts: localhost
  gather_facts: false
  vars:
    marker: release-a
  tasks:
    - name: Write the fictional marker
      ansible.builtin.copy:
        dest: "{{ practice_dir }}/practice.conf"
        content: "marker={{ marker }}\n"
        mode: '0600'
      notify: Report configuration change
  handlers:
    - name: Report configuration change
      ansible.builtin.debug:
        msg: "Practice handler ran; no service was restarted."

1. What does idempotence mean in this example?

After the first run writes marker=release-a with the requested mode, an identical second run reports no change for the copy task. That is an observed property of this task, its inputs and current file state. It is not a guarantee that any playbook using Ansible will be idempotent; a command or changing input could behave differently.

Follow-up practice: Which inputs must remain the same for this comparison? Include content, destination and relevant file attributes rather than only the playbook filename.

Create a disposable destination and explicit local connection

Use a Python 3.12 environment with ansible-core 2.19.0 installed. These shell commands keep Ansible’s temporary files with the practice directory and explicitly select localhost with a local connection. The trailing comma makes localhost, an inventory host list.

python3.12 -m venv .venv
. .venv/bin/activate
python -m pip install ansible-core==2.19.0
practice_dir=$(mktemp -d)
export ANSIBLE_HOME="$practice_dir/.ansible"
export ANSIBLE_LOCAL_TEMP="$practice_dir/.ansible-local"
export ANSIBLE_REMOTE_TEMP="$practice_dir/.ansible-remote"
ansible-playbook --version
ansible-playbook -i localhost, -c local config.yml \
  -e "practice_dir=$practice_dir" \
  -e "ansible_python_interpreter=$(command -v python)"
cat "$practice_dir/practice.conf"

2. What causes the handler to run?

The copy task notifies the named handler when it reports a change. In the observed first run, the task changed the file and the handler printed its message. On the identical second run, changed was zero and the handler did not run. The notification depends on the task’s change status, not merely on reaching its position in the playbook.

Follow-up practice: What would happen if two changed tasks notified the same handler before it ran? Consult the handler rules and distinguish notification from immediate execution.

Repeat the run, then change one variable

These commands repeat the original run, then change the marker. The unchanged repeat leaves release-a and reports changed=0. The changed-variable run writes release-b, reports changed=1 and invokes the handler.

ansible-playbook -i localhost, -c local config.yml \
  -e "practice_dir=$practice_dir" \
  -e "ansible_python_interpreter=$(command -v python)"
ansible-playbook -i localhost, -c local config.yml \
  -e "practice_dir=$practice_dir" \
  -e "ansible_python_interpreter=$(command -v python)" \
  -e marker=release-b
cat "$practice_dir/practice.conf"

3. Is a handler the same thing as a task that runs immediately after copy?

No. A notification schedules the handler according to Ansible’s handler execution behavior. The sample has one notifying task, so its output is easy to follow. In a longer play, other tasks may run before handlers are processed; explicit flush behavior also exists. Do not infer immediate execution from two adjacent lines in this small example.

Follow-up practice: If a later task needs the handler’s effect immediately, what timing assumption should you investigate instead of relying on this short play’s output order?

4. What did check mode prove here?

With marker=release-c, the check/diff run predicted a changed copy task and showed the content difference. The harmless debug handler also ran in the tested check-mode execution. Reading the destination afterward still returned marker=release-b. That verifies this copy task’s simulation for these inputs; it does not prove arbitrary tasks cannot change anything in check mode.

Follow-up practice: Why is reading the actual file after the command useful? Distinguish a predicted changed count from an observed write.

Compare the prediction with the unchanged file

The expected diff proposes release-c, but the final cat still shows release-b. Do not run the same command without --check until you deliberately want that content written.

ansible-playbook -i localhost, -c local config.yml \
  -e "practice_dir=$practice_dir" \
  -e "ansible_python_interpreter=$(command -v python)" \
  -e marker=release-c --check --diff
cat "$practice_dir/practice.conf"

5. Why is “check mode never changes anything” too broad?

Check-mode support depends on the module, and tasks can override check-mode behavior. Unsupported modules and tasks that depend on results from actions that were skipped can also limit the simulation. Inspect the actual modules, check_mode settings and data dependencies. This exercise uses copy’s supported behavior and a debug-only handler, not a service-management task.

Follow-up practice: How would adding a command task change what you need to review? Explain what information is missing before claiming the same guarantees.

6. How would you report the result in an interview?

I ran the same local copy task twice and saw changed=1 then changed=0. Changing the marker produced changed=1 and notified the handler. A later check/diff run predicted another change while the file stayed at the previous value. I verified both the task output and file content, and I would not generalize that result to an unreviewed playbook.

Follow-up practice: What would you investigate if the identical second run still reported changed=1? Name a possible changing input and a way to inspect it before calling Ansible broken.

Rehearse with an observation table

The following is the observed sequence from the isolated run. The handler’s message is intentionally harmless so that its notification can be inspected independently of an external service.