Ansible Playbook Language Exercises

1 / 5

An Ansible playbook run completes with the following summary:

PLAY RECAP: webserver01 : ok=8  changed=5  unreachable=0  failed=1  skipped=2  rescued=0

What does "changed=5" indicate?

Ansible reports a distinct outcome for every task execution. Understanding the PLAY RECAP counters is essential for interpreting automation results:

Counter	Meaning	Example
ok	Task ran, system already in desired state — no change made	Package already installed
changed	Task ran and modified the system	Config file was updated, service was restarted
failed	Task encountered an error and aborted	Non-zero exit code from a shell command
skipped	Task was skipped — `when:` condition evaluated to false	Deploy task skipped because target is already at latest version
unreachable	SSH connection to host failed	Host is down or firewalled

Idempotency health check: Run the same playbook twice. If the second run shows changed=0, your playbook is idempotent — it only changes what needs to change.

2 / 5

A new engineer asks about the Ansible role directory structure: tasks/, handlers/, vars/, defaults/, templates/, and files/.

What is the purpose of the handlers/ directory?

Handlers are special tasks that are "notified" by regular tasks and run at the end of a play (after all tasks complete), and only if they were notified.

- name: Copy nginx config
  template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
  notify: Restart nginx          # triggers the handler

Behaviour	Detail
Deduplication	Handler runs once even if notified by 10 tasks — prevents multiple restarts
Execution timing	After all tasks in the play, unless `meta: flush_handlers` is used mid-play
Conditional triggering	Only runs if the notifying task reported "changed" — not if "ok"

3 / 5

During a code review, a senior engineer comments: "This Ansible task is not idempotent — it will fail or cause side effects on repeated runs."

What does idempotency mean in an Ansible context?

Idempotency = a task checks current state before acting; it only makes changes when needed. This is the core design principle behind Ansible modules.

Module	Idempotent?	Reason
`apt / yum`	✓ Yes	Checks if package is already installed; "ok" if so
`template / copy`	✓ Yes	Compares file checksum; only writes if content differs
`command / shell`	✗ Not by default	Runs unconditionally — use `creates:` or `removes:` to add a condition
`service`	✓ Yes	Checks service state before starting/stopping

Convergence = the process of applying idempotent automation until the system reaches the desired state. If the system is already converged, re-running causes no changes.

4 / 5

An Ansible inventory file defines the following groups:

[webservers]
web01.example.com
web02.example.com

[databases]
db01.example.com

[all:vars]
ansible_user=deploy
ansible_python_interpreter=/usr/bin/python3

What does [all:vars] define?

Ansible inventory groups use the [group:vars] syntax to define variables scoped to that group. [all:vars] is the special "all hosts" group's variable section.

Variable precedence (low → high)
Role defaults (`defaults/main.yml`)
Inventory `[all:vars]`
Inventory group vars (`[webservers:vars]`)
Inventory host vars
Playbook `vars:` block
Extra vars (`-e` flag, highest precedence)

Dynamic inventory — instead of a static file, a script or plugin generates the inventory from a cloud provider API at runtime (AWS EC2 plugin, GCP plugin)
host_vars / group_vars directories — preferred alternative to inline inventory variables for larger projects

5 / 5

A DevOps team is growing and is asked to migrate from flat Ansible playbooks to a role-based structure. When should you use Ansible roles instead of a flat playbook?

Roles solve the reusability and maintainability problems of large flat playbooks:

Approach	Best for	Trade-offs
Flat playbook	One-off scripts, quick automation tasks	Simple, no structure overhead; hard to reuse
Role	Team-maintained, reusable automation components	Structured, testable (Molecule), shareable via Galaxy

Ansible Galaxy — community registry for sharing and consuming roles (like npm for Ansible)
Molecule — testing framework for Ansible roles: spins up containers/VMs, runs the role, verifies the outcome
role dependencies — a role can declare that it requires other roles to run first (meta/main.yml)