What is the single machine that orchestrates thousands of others without you having to log into each one? That's the control node, the heart of Ansible. For the EX294 exam, understanding how to install and prepare this central command post is your first and most critical step to automating everything else.
Jump to a section
A simple way to picture Installing Ansible and Setting Up the Control Node
Have you ever decided to renovate your kitchen yourself, only to realise halfway through that you can't be in two places at once?
That's the problem Ansible solves, but for computers. You (the control node) have a list of instructions—the cookbook, or Ansible playbook—that tells you exactly how to install new cabinets, wire the lights, and tile the backsplash (the managed nodes). Before you start, you need to set up your workshop properly. First, you buy the tool belt (install Ansible itself). You create a central clipboard (an inventory file) that lists every room in the house and what tools are already in each one. Then you start a single command (ansible-playbook) and your helpers—Ansible modules—run off to each room simultaneously, each executing their specific task. One helper installs the smart oven, another connects the gas, a third fits the handles on drawers. They all report back to you when done.
Without this central control, you'd have to run back and forth endlessly, or worse, have five different workers each doing their own thing without coordination. Setting up that central workbench and tool belt is exactly what 'setting up the control node' means in Ansible. It turns chaos into a calm, repeatable project plan.
Ansible is an open-source automation tool that lets you manage multiple remote servers from one central place. You write a set of instructions (a playbook) in a simple language called YAML, and Ansible executes those instructions on all the servers you specify. Think of it as a universal remote for your entire server fleet.
Before you can do any of that, you need to install Ansible on one machine—this machine becomes your control node. The control node is the only machine that has Ansible installed. All the other machines (called managed nodes or hosts) do not need Ansible installed on them. This is a key point: Ansible is agentless. It uses SSH (Secure Shell) to connect to managed nodes and execute commands there. SSH is a secure network protocol that lets you log into a remote computer and run commands, similar to using a remote desktop but purely text-based.
The control node can be any Linux machine—typically a laptop, a desktop, or a virtual machine (a software-based emulation of a computer). For EX294, Red Hat Enterprise Linux (RHEL) is the supported distribution, but for lab practice you can use CentOS, Rocky Linux, or AlmaLinux.
To install Ansible on RHEL, you need to have a valid Red Hat subscription and enable the Ansible Engine repository using the 'subscription-manager' command. 'subscription-manager' is a tool that manages your software subscriptions in RHEL. Then you run:
'sudo dnf install ansible'
'dnf' (Dandified Yum) is the package manager for RHEL and Fedora—it downloads and installs software packages from repositories. 'sudo' (superuser do) gives you administrative privileges to install software. Once Ansible is installed, you can check its version with 'ansible --version'.
Now the control node is ready, but it needs to know which machines to manage. That information lives in an inventory file. The default location is /etc/ansible/hosts, but you can create your own. An inventory file is a plain text file that lists the hostnames or IP addresses (a unique numeric label for a device on a network) of your managed nodes. You can group them as well. For example:
[webservers] 192.168.1.10 192.168.1.11
[dbservers] db.example.com
You also need SSH access from the control node to each managed node. The easiest way is to generate an SSH key pair on the control node using the 'ssh-keygen' command, then copy the public key to each managed node using 'ssh-copy-id'. An SSH key pair is two related files: a private key (kept secret on the control node) and a public key (placed on the managed node). When you try to connect, the private key proves your identity without needing a password every time. This is called passwordless SSH authentication.
After the keys are set up, you can test the connection from the control node to a managed node using:
'ansible all -m ping -i inventory'
Here, '-m ping' tells Ansible to use the 'ping' module (which checks if a managed node is reachable) and '-i' specifies the inventory file. If everything is configured correctly, you will see a 'SUCCESS' message for each host.
Why does this matter? Without a control node, you would have to manually log into each server via SSH and run commands by hand. That is fine for one or two servers, but for a hundred or a thousand, it is error-prone and slow. Ansible turns that manual drudgery into a single command execution.
Enable the Red Hat Ansible Repository
Run 'sudo subscription-manager repos --enable ansible-2.9-for-rhel-8-x86_64-rpms' (adjust for your RHEL version). This makes the Ansible package available in your package manager.
Install Ansible on the Control Node
Execute 'sudo dnf install ansible -y'. The '-y' flag automatically confirms the installation. This places the 'ansible' and 'ansible-playbook' commands on your system.
Create an Inventory File
Create a file, e.g., '~/inventory.ini', listing your managed nodes. Use the '[group_name]' header to group hosts. This file tells Ansible which machines to manage and how to reach them.
Generate and Deploy SSH Keys
Run 'ssh-keygen' on the control node to create a key pair (default location ~/.ssh/id_rsa). Then use 'ssh-copy-id user@managed-node-ip' for each managed node. This enables passwordless SSH access.
Test Connectivity to Managed Nodes
Run 'ansible all -i ~/inventory.ini -m ping'. The 'ping' module checks if the control node can reach and authenticate to all listed nodes. A green 'SUCCESS' means you are ready.
Write and Execute a Simple Playbook
Create a YAML file (e.g., 'test.yml') with a single task, like ensuring a package is installed. Run it with 'ansible-playbook -i ~/inventory.ini test.yml'. This validates your entire setup works end-to-end.
Imagine you work at a company called 'ShopFast', an e-commerce platform running 50 web servers, 10 database servers, and 5 load balancers. A critical security patch needs to be applied to all web servers immediately, otherwise the site could be breached. Without Ansible, you would need to SSH into each of the 50 servers manually, running the patch command over and over. That would take hours and you could easily miss one, leaving a security hole.
Instead, you set up an Ansible control node on a small virtual machine in your data centre. Here is the step-by-step process you would follow:
Install RHEL on the control node and activate a Red Hat subscription.
Install Ansible using: 'sudo dnf install ansible'
Create an inventory file called 'inventory.ini' with the following content:
[webservers] web1.shopfast.com web2.shopfast.com ... (all 50 web servers)
Generate an SSH key pair: 'ssh-keygen -t rsa -b 4096' and press Enter to accept defaults.
Copy the public key to every web server using: 'ssh-copy-id user@web1.shopfast.com'. Repeat for each server. (In reality, you would use a configuration management tool like Ansible itself to do this, or use a central directory service like LDAP, but for the first setup you can do it manually or with a script.)
Test connectivity: 'ansible webservers -m ping -i inventory.ini'
Write a playbook called 'patch.yml':
--- - hosts: webservers tasks: - name: Apply security patch yum: name: kernel state: latest
Run the playbook: 'ansible-playbook -i inventory.ini patch.yml'
In a few seconds, Ansible connects to all 50 web servers simultaneously, each running the 'yum' module to update the kernel package. You get a unified report showing which servers succeeded and which failed. You can now go grab a coffee while Ansible does the heavy lifting.
This is exactly what IT professionals do daily. They use the control node to manage server configurations, deploy applications, restart services, and enforce security policies across hundreds of machines without ever logging into them directly. The control node becomes the single source of truth for all automation tasks.
The EX294 exam tests your ability to install Ansible on a control node and configure it for basic operation. You will not be memorising every option, but you must know the exact commands and files involved. Here is what you absolutely need to know:
Install Ansible on RHEL using 'sudo dnf install ansible'. The exam expects you to know 'dnf' and not 'yum' (though 'yum' works as a symlink, use 'dnf'). The repo must be enabled via 'subscription-manager repos --enable ansible-2.9-for-rhel-8-x86_64-rpms' (or the appropriate version).
The default inventory file location is '/etc/ansible/hosts'. However, they will almost always ask you to create a custom inventory file in a different location. Know how to specify it with the '-i' option.
SSH key-based authentication is mandatory. You must create a key pair with 'ssh-keygen' and copy it with 'ssh-copy-id'. The exam will not allow password-based authentication for managed nodes.
The 'ansible --version' command is used to verify the installation. It lists the version, configuration file location, and Python version. The Python version is important because Ansible relies on Python on the control node.
Common traps they like to set:
Asking for the path to the Ansible configuration file. The default is '/etc/ansible/ansible.cfg', but you can override it with a local 'ansible.cfg' in the current directory. If both exist, the local one takes precedence.
Forgetting to enable the correct repository. If you try 'dnf install ansible' without enabling the repo, it will fail silently or install an older version from EPEL. The correct repo name is 'ansible-2.9-for-rhel-8-x86_64-rpms' (version dependent).
Confusing the control node with managed nodes. Remember: Ansible is only installed on the control node. Managed nodes only need Python and an SSH server running (usually already present).
Key definitions to memorise:
Control node: the machine where Ansible is installed and from which all automation is run.
Managed node: any machine that Ansible controls. It does not have Ansible installed.
Inventory: a file listing managed nodes and their groups.
Module: a reusable, standalone script that Ansible runs on managed nodes (e.g., 'ping', 'yum', 'copy').
Playbook: a YAML file containing a set of instructions (plays) to execute on managed nodes.
They love to test the concept of agentless architecture. A typical question: 'What must be installed on managed nodes for Ansible to work?' The answer: only Python (2.7+ or 3.5+). No extra agent.
They will test the order of operations: first install Ansible, then create/configure inventory, then set up SSH keys, then write and run playbooks.
Install Ansible only on the control node using 'sudo dnf install ansible' after enabling the correct Red Hat repository.
Ansible is agentless: managed nodes never need Ansible installed, only Python and an SSH server.
The default inventory file is /etc/ansible/hosts, but you can and should use custom inventory files with the -i flag.
SSH key-based authentication is mandatory for connecting to managed nodes; use 'ssh-keygen' and 'ssh-copy-id' to set it up.
Always verify your Ansible installation and connectivity with 'ansible --version' and 'ansible all -m ping'.
The control node is the single machine that orchestrates all automation; its configuration file (ansible.cfg) can override the default settings.
These come up on the exam all the time. Here's how to tell them apart.
Control Node
Runs Ansible software
Orchestrates automation tasks
Only one is needed
Managed Node
Does not run Ansible
Receives commands from the control node
Can be many machines
ansible command (ad-hoc)
Runs single tasks directly
No YAML file needed
Best for quick checks like ping
ansible-playbook command
Runs complex playbook files
Requires a YAML file
Best for repeatable, multi-step automation
Default inventory (/etc/ansible/hosts)
Located in system directory
Requires root to edit
Used when no -i flag is given
Custom inventory file
Can be anywhere (e.g. ~/myhosts)
No root needed
Must be specified with -i
Password-based SSH
Requires human to type password
Not suitable for automation
Less secure if passwords are weak
Key-based SSH
No password needed after setup
Ideal for automation
More secure using private/public key pairs
Red Hat Ansible Engine
Supported by Red Hat
Uses specific repository
EX294 tests this version
Community Ansible (upstream)
Free and open-source
Installed via EPEL or pip
May have newer features but not exam-relevant
Mistake
I need to install Ansible on every server I want to manage.
Correct
Ansible is agentless. You only install it on the control node. Managed nodes only need Python and an SSH server.
Because most other automation tools (like Puppet or Chef) do require agents, beginners assume Ansible works the same way.
Mistake
The default inventory file /etc/ansible/hosts is the only inventory I can use.
Correct
You can create any inventory file anywhere and specify it with the -i option. EX294 will expect you to use custom inventory files.
The default location is convenient but not always accessible without root privileges. The exam forces you to work with custom paths.
Mistake
Ansible can manage Windows machines without any extra setup on the control node.
Correct
Managing Windows requires additional configuration: the control node needs to use WinRM (Windows Remote Management) instead of SSH, and Python modules are different.
Since most beginners learn Ansible with Linux, they forget that Windows is a different paradigm and requires specific setup.
Mistake
I can run ansible-playbook commands without setting up SSH keys first because the control node is a local machine.
Correct
You must have SSH key-based authentication from the control node to every managed node, even if they are virtual machines on the same host. The control node itself does not need keys for localhost operations, but for remote nodes it does.
Beginners often test on local virtual machines with passwords and assume it will work in production. The exam strictly enforces SSH key-based access.
Mistake
Ansible version doesn't matter; I can use any version for EX294.
Correct
The exam explicitly tests Red Hat's supported version. For RHEL 8, it is Ansible Engine 2.9 (or later). Using a newer community version may have different syntax or modules.
Open-source Ansible (community version) and Red Hat Ansible Engine have slight differences in module availability and support. The exam is based on Red Hat's version.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
It means you run the 'sudo dnf install ansible' command on one Linux machine. That machine becomes your control node. All other machines you manage (managed nodes) do not get Ansible installed.
Yes, if you are using Red Hat Enterprise Linux (RHEL). The exam expects you to use the official Red Hat repository. For lab practice, you can use CentOS or Rocky Linux with EPEL, but the exam uses RHEL.
An inventory file is a text file listing the hostnames or IP addresses of your managed nodes. You can place it anywhere, but you must tell Ansible where it is using the '-i' option when running commands.
SSH keys are more secure and allow automation without storing passwords in plaintext. Ansible can be configured to use passwords (with sshpass), but EX294 specifically tests the key-based method.
Officially, the control node must be a Linux/Unix-based system. Red Hat does not support Windows as a control node. Windows can be a managed node, but not the controller.
The 'ansible' command runs ad-hoc tasks (like a single ping or command). 'ansible-playbook' runs a full playbook file containing multiple tasks, variables, and conditional logic.
You've finished Installing Ansible and Setting Up the Control Node. Continue through the EX294 study guide to build a complete picture of the exam.
Done with this chapter?