Ansible is Red Hat's automation tool that configures your servers from a description of the desired state, over SSH, without installing anything on the target machines. This free course takes you from your first playbook to the RHCE EX294 certification: 27 modules, 182 lessons and 112 labs to replay on your own machines, about 146 hours of work. It is aimed at Linux administrators and DevOps profiles who want a solid skill rather than a cheat sheet. The labs run on AlmaLinux 9, the free equivalent of RHEL 9, the system the exam is taken on.
What is Ansible and how does it work?
Ansible applies a configuration described in a YAML file to a fleet of servers, connecting over SSH and acting only on what differs from the desired state. No agent is installed on the managed machines: this is what sets it apart from Puppet, Chef or Salt, which all rely on a resident daemon.
You administer servers. With five machines, you configure them by hand. With fifty, you write a script, and that script quickly becomes the problem: it does not know whether the package is already installed, it fails halfway and leaves half the fleet in an unknown state.
Ansible attacks the problem from the other end. You do not write the sequence of commands to run, you write the expected result: this package is installed, this service is running, this port is open. Ansible connects, compares the real state with your description, and acts only on the difference. Replay the same file ten times, only the first run changes anything. This is idempotence, and it is what sets Ansible apart from a script.
All of it is agentless: no daemon to install on the servers, no certificate authority to maintain, no extra port to open. Ansible borrows the SSH you already use, drops a Python module for the duration of a task, collects the result, cleans up.
What remains is knowing what Ansible does not do, because that is where bad decisions are made. It does not create cloud infrastructure, that is Terraform's job. It does not orchestrate containers, that is Kubernetes's. Ansible starts where Terraform stops: once the machine is created, it configures it.
What does the Ansible course contain, and how long does it take?
The course has 27 modules, 182 lessons and 112 labs, for about 146 hours of actual work, reading and practice included. It is free and fully available online, with no sign-up.
| What you follow | Volume |
|---|---|
| Teaching modules | 27 |
| Lessons | 182 |
| Practical labs in ansible-training | 112 |
| Quiz questions | 653 |
| Estimated duration | about 146 hours |
| Lab distribution | AlmaLinux 9, free equivalent of RHEL 9 |
| Verified engine | ansible-core 2.20 |
These hours do not measure reading time. They count reading, thinking and reproducing the exercises, because an automation course is judged by what you can do on a machine, not by the number of pages you went through.
How do you track your progress in the course?
Each lesson has a checkbox, and your progress is saved in your browser, with no account or sign-up. No data leaves for a server.
The page My path shows the full programme, module by module, with the percentage completed. At the top of each lesson, a banner reminds you where you are; at the bottom, a button marks the lesson as read and takes you to the next one. You can therefore resume where you stopped, even several weeks later.
The course, section by section
The course is read in order if you are a beginner, and browsed if you are looking for a specific point. Each section has its own home page, its guides and its labs.
Understand and get started
The foundations. In the first one you do not write a playbook yet, you understand the model. The second has you build your lab and run your first file.
- Discover Ansible: the declarative approach, the architecture, installation, everyday commands, the
ansible.cfgfile. - First steps: four machines on KVM, the SSH connection, ad hoc commands, the first playbook and reading its output.
Write code
The core of the job, and the biggest part of the course. This is where the difference is made between a playbook that works and a playbook you dare to run again.
- Write code: YAML, variables, facts, loops, conditions, error handling, Jinja2 templates.
- Modules: the modules you will really use, sorted by domain: files, packages, services, users, network, storage.
- Inventories: describing your fleet, from the static file to the dynamic inventory, and organising your variables without getting lost.
Structure and secure
The moment your code stops being a personal file and becomes a team asset.
- Roles: structure, parameterise, test with Molecule, publish on Galaxy.
- Collections: find, install and pin third-party modules, create one.
- Secrets and Vault: encrypt what must be, and plug in HashiCorp Vault or Passbolt when the project grows.
- Securing your playbooks: the hardening areas to know before touching production.
Industrialise
What separates artisanal automation from enterprise automation.
- Execution Environments: bundle engine, collections and dependencies in an image, with
ansible-navigator. - Tooling: the editor, linters, static analysis.
- Troubleshooting: reading a trace, using the debugger, repairing a broken idempotence.
- Advanced development: writing your own Python modules, filters and plugins.
- Advanced practices: GitOps with
ansible-pull, versioning, image building. - AWX: the web interface, its administration and its future compared with Automation Platform.
Validate with the certification
The certification is not mandatory to be competent, but it structures learning and proves your skill to an employer. The course targets first and foremost the RHCE EX294, Red Hat's reference exam for Ansible.
- Certifications: the RHCE EX294, but also the EX374 for development and the EX467 for administering Automation Platform.
What I stand for
I have been using Ansible since 2015. I saw version 1.x before the Red Hat acquisition, the arrival of collections, then the switch to running in containers. This course condenses what the field taught me, and it has opinions. Here they are, so you know what you are signing up for.
Idempotence is not negotiable. A playbook that reports changes on every run is broken, even if it "works". In six months you will run it again, it will restart services and flush caches for no reason. The rule fits in one line: the second run must show changed=0. Otherwise we fix it, we do not debate it.
The full module name is mandatory. You write ansible.builtin.copy, never copy. That is what ansible-lint requires in the production profile, what the RHCE expects, and above all what pins the origin collection when you install dozens of them. A tutorial that still shows the short form in 2026 pulls you down.
The linter runs before the commit, not in continuous integration. ansible-lint --profile production costs three seconds locally. Discovering the same error twenty minutes later in a pipeline is a waste, and discovering that it reached production is worse.
Secrets are handled at the first commit, never after. The Vault password file in 0600, ignored by Git from the repository's initialisation, and no_log: true on every task that handles a credential. I have seen a token leak into continuous integration logs because of a forgotten no_log: thirty minutes of panic and an emergency rotation.
One tool per need. Ansible or Salt, not both. Terraform or Pulumi, not both. The consistency of your tooling is worth far more than the best technology on every link, because it decides whether a colleague can take over your work.
What I advise against
Three mistakes come back so often that they deserve to be named before you make them.
Provisioning cloud with Ansible. The module exists, it works, and your infrastructure will drift anyway. Ansible has no state to compare, so it does not know what it created last time. Use Terraform to create, Ansible to configure.
Paying for Automation Platform too early. Red Hat's commercial offering brings an interface, a certified catalogue and fine-grained governance. For a team of ten people on fifty servers, ansible-core and a GitLab pipeline cover the need. Wait until you have several hundred machines or a real constraint on separation of duties.
Learning on Ubuntu to pass a Red Hat certification. The exam runs on RHEL, with dnf, firewalld and SELinux enabled. Prepare on AlmaLinux or Rocky, otherwise you will discover the differences on exam day.
Which distribution and version is the course validated on?
The labs run on AlmaLinux 9 and the guides are verified on ansible-core 2.20. One question comes up before starting: will it work for me? Here is the exact foundation of the course, and what changes if yours differs.
The managed machines in the labs run AlmaLinux 9, the free equivalent of RHEL 9. This choice is not trivial: it is the version on which the RHCE EX294 exam is taken, with dnf, firewalld and SELinux enabled. Practising on the same base as the exam avoids bad surprises on exam day. The examples work identically on Rocky Linux 9 and RHEL 9. On Debian and Ubuntu, the logic does not change but the package and firewall modules differ, and the guides point it out when that is the case.
On the engine side, the guides are verified on ansible-core 2.20, the current version of the open-source engine. The distribution you administer and the engine version you install on your workstation are two independent things: nothing forces you to use the ansible-core shipped with your system, and the course precisely recommends installing it separately.
The control node, for its part, does not matter: any Linux with Python will do, and macOS works too. Ansible needs nothing more than SSH access and a Python on the managed machines.
Two names cause confusion and are worth stating. ansible-core is the engine alone. The package named ansible is a bundle that adds several hundred preinstalled collections to it, which explains the difference in download size. Finally, Ansible Automation Platform is Red Hat's commercial offering, built on top of the same engine, with a web interface, a certified catalogue and governance. Everything you learn here with ansible-core remains true on that platform.
What prerequisites do you need before starting Ansible?
Three skills are enough to start: administering a Linux system, reading YAML, and connecting over SSH with a key. The rest is learned here.
If you are aiming for the certification, know that the RHCE is not a stand-alone exam: Red Hat requires the RHCSA as an official prerequisite, and I have never seen anyone pass the RHCE without a solid RHCSA foundation. You only automate properly what you can do by hand. The full path therefore goes through the Linux fundamentals, then the RHCSA, then this course, then the EX294 exam.
How do you validate what you learned and prepare for the RHCE EX294?
Three tools validate the skill: 653 quiz questions, 112 labs verified by automated tests, and a mock RHCE exam in real conditions. Reading is not enough, and that is even truer for a tool judged by what it does on a real machine.
The quiz covers the sections with 653 questions spread by chapter. Fifteen minutes a week are enough to stay clear on variable precedence and the Jinja2 filters you forget between two projects.
The labs live in the ansible-training repository: 112 progressive exercises, the KVM infrastructure that goes with them, and pytest and testinfra tests that validate your answer. You clone, you provision, and the tool tells you which lab is next.
Finally, a full mock RHCE exam, 18 tasks in 4 hours, each proved by a pytest test on the real state of the machines rather than on the playbook you wrote. Pass it twice before booking the exam with Red Hat.
FAQ: frequently asked questions
sudo dnf install pipx && pipx ensurepath && pipx install --include-deps ansible. Avoid sudo pip install (pollutes the system Python) and apt install ansible (often outdated). pipx isolates the install and updates are atomic.pip install ansible or from your distribution's repositories.Red Hat's paid offering, Ansible Automation Platform (AAP), adds a web interface, a centralised execution engine, support and certified content. It targets large organisations, but nothing forces you to use it: all the automation described in this course is done with Ansible Core, for free.| Tool | Role | Example |
|---|---|---|
| Terraform | Provisions infrastructure from scratch | Create 3 VMs, a network, a load balancer |
| Ansible | Configures existing machines | Install nginx, open a port, deploy an app |
&name) mark a node, and aliases (*name) reuse it elsewhere. The merge operator << merges values while allowing overrides. Useful to share JVM options, ports or configurations between several apps. Beware: not every YAML parser supports complex anchors, so check Ansible compatibility.