Back to Learning
RedHat · RH294Intermediate

Ansible Playbook Automation

Run the playbook twice and the change count never reaches zero. Find the task that cannot tell state from action, live, right below.

Interactive simAutomationAnsibleLinux

Symptom

Write and run real Ansible playbooks against multiple managed hosts: inventories, roles, idempotent tasks and ad-hoc modules.

Your mission

Inspect, recover, then verify

Format

Linux shell

Ansible: The Task That Is Always Changed

Investigate before you configure.

Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.

Observe the symptom and link state.

Diagnose by comparing the protocol evidence.

Verify the expected device state and confirm the original symptom is resolved.

Console access: Linux

This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.

Need a hint?

Reveal the root cause when you're ready.

Try the investigation first, then use this as your escape hatch, not a dead end.

Locked

Sign up with your email to open Ansible Playbook Automation, free. You get the root cause and the full step-by-step fix.

No spam. The fix lands in your inbox too. Signing up includes 4 guided labs free, tracked against your email. After that, the Learning Pass unlocks every remaining lab.

Lab debrief

Turn the session into a repeatable troubleshooting pattern.

Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.

The problem

A playbook runs cleanly against a host that should already be fully converged, but every run reports changes, even on hosts nobody has touched since the last run.

What you'll practice

  • Build a static inventory and group hosts by role
  • Write playbooks using core modules (package, service, copy, template)
  • Structure reusable roles instead of one long playbook
  • Run ad-hoc commands for quick fact-gathering and one-off changes
  • Verify idempotency by re-running a playbook against a converged host

The topology

An Ansible control node reaches three managed Linux hosts over SSH, enough targets to practice inventory grouping, host-pattern targeting and role reuse without a single-host toy setup.

Commands to run yourself

The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.

Run the playbook
ansible-playbook -i inventory.ini site.yml
List the tasks
ansible-playbook -i inventory.ini site.yml --list-tasks
Read the play
cat site.yml

Topology diagram

Fact-checked references

The commands and behaviour in this lab were checked against these primary references.

Frequently asked

Do I need to set up SSH keys and hosts myself?

No. The control node and managed hosts are already keyed and reachable. You focus on writing playbooks, not bootstrapping SSH access.

Does this match the RH294 exam scope?

Yes. Inventories, playbooks, roles and idempotent task design are the core RH294 objectives this lab is built around.

Ready to run this lab yourself?

No setup, no image sourcing. Book a session or ask for a live demo.