RHCSA proves you can administer Linux. RHCE proves you can automate it.

The RHCSA exam (EX200) tests the ability to configure and manage a single Red Hat Enterprise Linux system: users, storage, networking, services, SELinux, firewalls, and containers. It is a comprehensive systems administration credential. The RHCE exam (EX294) starts where RHCSA ends and asks a different question entirely: how do you make 50 servers behave identically, deploy applications reproducibly across environments, and enforce configuration drift prevention on an estate you could not possibly manage by hand? The answer is Ansible — and EX294 is the exam that tests whether you can actually use it.

The shift in focus is deliberate and reflects a real industry transition. In 2019, Red Hat retired the previous RHCE exam (which covered advanced networking, iSCSI, and Apache configuration on RHEL 7) and replaced it with an entirely Ansible-focused curriculum tied to RHEL 8, updated again for RHEL 9. The message was unambiguous: the core competency that distinguishes a senior Linux engineer from a junior one is no longer memorised command syntax — it is the ability to encode infrastructure intent as code, version it, test it, and execute it reliably at any scale. Ansible became the primary vehicle for that competency in the Red Hat ecosystem, and RHCE became the credential that proves it.

The prerequisite matters structurally. RHCE does not test RHCSA topics directly, but it assumes them completely. An RHCE candidate who is weak on SELinux, systemd, firewalld, or storage management will fail RHCE tasks that require Ansible to configure those subsystems correctly — because the automated grader checks the actual resulting system state, not the playbook syntax. Ansible is a vehicle for Linux administration; RHCE tests Ansible competency against the full breadth of RHCSA-level system knowledge.

The EX294 exam domains

Domain 1 — Understand Core Ansible Concepts

The foundational domain covers the mental model and architecture of Ansible: how the control node communicates with managed hosts, how agentless execution works over SSH, and how Ansible’s idempotency model differs from imperative scripting.

  • Agentless architecture: Ansible does not require a daemon or agent on managed hosts. The control node pushes Python scripts over SSH, executes them, captures the result, and removes the temporary files. EX294 tests candidates’ understanding of what this means in practice: managed hosts need Python (installed by default on RHEL), SSH connectivity from the control node, and a user account with privilege escalation configured via sudo. The exam tests setting up these prerequisites, not just writing playbooks that assume they exist.
  • Idempotency: a correctly written Ansible task produces the same result whether run once or fifty times. EX294 tests idempotency both conceptually and practically: tasks that fail idempotency checks (such as using the command module without creates or removes guards when a dedicated module exists) are considered poor practice even if they produce the correct immediate result.
  • Ansible configuration file (ansible.cfg): the exam tests reading and writing ansible.cfg to configure the default inventory path, remote user, privilege escalation method, and SSH connection settings. Understanding configuration file precedence (project-level ansible.cfg > home directory ~/.ansible.cfg > /etc/ansible/ansible.cfg) is tested in scenarios where multiple configuration files exist.

Domain 2 — Install and Configure an Ansible Control Node

This domain covers the operational setup of an Ansible environment from scratch — a task the exam presents as the starting condition for subsequent problem sets.

  • Installing Ansible on RHEL 9: Ansible is available in the RHEL AppStream repository. EX294 tests enabling the correct module stream (dnf module enable ansible-core or via Red Hat Ansible Automation Platform subscription) and installing the package. Candidates must understand the difference between the community ansible package and the enterprise ansible-automation-platform stack and which is appropriate for the exam environment.
  • Configuring static and dynamic inventory: static inventory files in INI or YAML format define the managed hosts and groups that Ansible targets. EX294 tests defining host groups, nested groups ([groupname:children]), and group variables directly in the inventory file. Dynamic inventory — where the host list is generated by an external script or plugin — is tested conceptually but typically not implemented from scratch in the exam.
  • Ad hoc commands: before playbooks, candidates must demonstrate proficiency with ad hoc Ansible commands using the -m module flag for one-shot tasks: checking connectivity (ansible all -m ping), gathering facts, copying files, managing packages, and starting or stopping services without writing a full playbook. Ad hoc commands test module knowledge under time pressure — knowing which module to reach for without consulting documentation is a speed advantage in the exam.

Domain 3 — Configure Ansible Managed Nodes

This domain covers the host-side configuration that allows Ansible to operate, and it overlaps directly with RHCSA content — the credential prerequisite is operationalised here.

  • SSH key-based authentication: Ansible communicates with managed nodes over SSH. EX294 tests generating an SSH key pair on the control node, distributing the public key to managed hosts using ssh-copy-id or the authorized_key Ansible module, and verifying passwordless connectivity. The exam typically provides managed hosts that require this setup before any playbook can run.
  • Privilege escalation with sudo: most Ansible tasks that manage system state require root-equivalent privileges. EX294 tests configuring sudoers on managed hosts to allow the Ansible remote user to execute commands without a password prompt (NOPASSWD: ALL or targeted command sets), and configuring the become: true and become_user: root playbook directives to trigger that escalation.
  • Ansible facts and the setup module: Ansible automatically gathers facts about managed hosts (OS version, IP addresses, disk layout, installed packages) before running tasks. EX294 tests using gathered facts in playbook conditions (when: ansible_distribution == "RedHat"), disabling fact gathering for performance-sensitive playbooks, and defining custom facts by placing JSON files in /etc/ansible/facts.d/ on managed hosts.

Domain 4 — Script Administration Tasks with Ansible Playbooks

The central domain: writing and executing playbooks that perform the full breadth of RHEL administration tasks using Ansible modules.

  • Core module categories: EX294 tests proficiency with the modules that cover day-to-day Linux administration — package / dnf (software installation), service / systemd (service management), user / group (account management), copy / template (file distribution), file (permissions and ownership), firewalld (firewall rules), lineinfile / blockinfile (targeted file editing), mount (filesystem management), and selinux / seboolean / sefcontext (SELinux policy). Candidates who have not practised the SELinux modules consistently struggle with tasks that require enabling a boolean or restoring a context because the semanage and restorecon command equivalents are not a direct one-to-one mapping.
  • Variables and variable precedence: Ansible resolves variables from multiple sources with a defined precedence order. EX294 tests defining variables at the playbook level, in vars_files, in group variable files (group_vars/), in host variable files (host_vars/), and on the command line with -e. Tasks that fail because a variable resolves to the wrong value due to precedence misunderstanding are a common exam failure mode.
  • Jinja2 templating: the template module renders Jinja2 templates before deploying them to managed hosts. EX294 tests writing templates that embed variables ({{ variable_name }}), conditionals ({% if %}), and loops ({% for %}) to generate configuration files that differ per host or group. Common exam scenarios include generating /etc/hosts entries, Apache virtual host configurations, and sshd_config files from templates.
  • Handlers: a handler is a task that runs only when notified by another task that reports a change. EX294 tests using handlers to restart services only when configuration files are actually modified — not on every playbook run. Misunderstanding handler timing (handlers run at the end of the play, not immediately after the notifying task) is a consistent source of exam errors.
  • Conditionals, loops, and error handling: EX294 tests when conditions that gate task execution on facts, variables, or registered results; loop directives that iterate a task over a list of items; and error handling with ignore_errors, failed_when, block/rescue/always constructs. The exam typically presents tasks where naive playbooks would abort on a non-fatal error, and candidates must implement the correct rescue pattern to continue execution.

Domain 5 — Protect Secret Data Using Ansible Vault

This domain covers securing sensitive data — passwords, API keys, certificates — that playbooks need to access without embedding them in plaintext in version control.

  • Encrypting files with ansible-vault encrypt: any file in an Ansible project can be encrypted with Vault. EX294 tests encrypting variable files that contain credentials, using ansible-vault encrypt_string to inline an encrypted value within a plaintext YAML file, and decrypting files for review with ansible-vault decrypt or ansible-vault view.
  • Running playbooks with Vault-protected content: playbooks that include Vault-encrypted files must be run with --ask-vault-pass (interactive prompt) or --vault-password-file (reads the password from a file). EX294 tests both approaches and the security implication of each: password files on disk must be protected with restrictive permissions, since they represent the same secret in a different form.
  • Multiple Vault passwords: EX294 tests scenarios where different files are encrypted with different passwords using Vault IDs (--vault-id label@source). This allows a single playbook to consume secrets from different teams or environments without sharing a single master password.

Domain 6 — Use Ansible Roles and Ansible Content Collections

Roles and Collections are the packaging and reuse layer of Ansible. This domain tests the ability to consume existing automation from Ansible Galaxy and Red Hat Automation Hub, and to write reusable roles for internal use.

  • Ansible role structure: a role is a directory tree with standardised subdirectories: tasks/, handlers/, templates/, files/, vars/, defaults/, meta/. EX294 tests creating a role from scratch using ansible-galaxy role init, populating its directories with appropriate content, and calling it from a playbook with the roles: directive or the include_role / import_role modules. The exam tests understanding when to use role defaults versus role vars and how role variable precedence interacts with playbook variable precedence.
  • Installing roles and collections from Ansible Galaxy: Ansible Galaxy is the public repository for community-contributed roles and collections. EX294 tests installing a specific role version from Galaxy using ansible-galaxy role install namespace.rolename, defining requirements in a requirements.yml file for reproducible installation, and understanding the difference between roles (single-purpose automation libraries) and collections (namespace-scoped bundles of roles, modules, plugins, and documentation).
  • RHEL System Roles: Red Hat ships a curated set of supported Ansible roles for common RHEL subsystem management: rhel-system-roles.network, rhel-system-roles.selinux, rhel-system-roles.timesync, rhel-system-roles.storage, rhel-system-roles.firewall, and others. EX294 specifically tests using these roles because they represent the supported, enterprise-grade automation path for the tasks they cover. Candidates who attempt to implement networking or SELinux management from scratch instead of using the system role are writing more code and introducing more failure risk than necessary.

Domain 7 — Manage Automation with Ansible Automation Platform

The final domain covers Ansible Automation Platform (AAP), Red Hat’s enterprise execution layer for Ansible. AAP adds web-based job scheduling, RBAC, audit logging, and credential management on top of the core Ansible engine.

  • Automation Controller (formerly Ansible Tower): Automation Controller is the web interface and API for scheduling and running Ansible jobs across large organisations. EX294 tests conceptual understanding of Controller’s core objects: inventories, credentials, projects (Git-backed playbook repositories), job templates (the combination of a playbook, inventory, and credential), and workflows (directed acyclic graphs of job templates). Candidates do not need to administer a full AAP cluster from scratch in the exam, but must demonstrate understanding of how these objects relate to command-line Ansible.
  • Execution environments: Ansible Execution Environments are OCI-compliant container images that bundle an Ansible version, its Python dependencies, and selected Collections into a reproducible execution context. EX294 tests understanding why Execution Environments replace the older Python virtualenv approach, how to select an Execution Environment for a job template in Automation Controller, and how ansible-navigator uses Execution Environments locally for testing before production deployment.
  • Private Automation Hub: organisations that cannot publish content to the public Ansible Galaxy can use Private Automation Hub to host internally approved Collections and Execution Environments. EX294 tests configuring Ansible to pull Collections from a private hub by setting the server_list in ansible.cfg, understanding authentication requirements, and the governance model where content must be approved before it is available to project teams.

Exam format: four hours on a live lab

The EX294 exam runs for exactly four hours on a live RHEL 9 environment. The candidate receives a control node with Ansible pre-installed and a set of managed hosts. The exam presents a series of tasks — typically 15–20 graded items — each specifying a desired end state that must be achieved using Ansible. Automated graders run after the exam and check the actual state of the managed hosts against the expected configuration. There is no partial credit per task — a task is either complete or not.

The exam is entirely open-environment in one sense: candidates can use the terminal, man pages, and any documentation available on the control node or managed hosts through the terminal. There is no internet access and no web browser. This means the Ansible module documentation accessible via ansible-doc modulename (which runs locally) is the primary reference tool during the exam. Candidates who practise using ansible-doc instead of searching online during preparation are better positioned for exam conditions than those who rely on web searches.

The most common RHCE failure pattern is not understanding Ansible — it is being too slow. Four hours sounds generous but the exam typically includes 15–20 weighted tasks that require writing, testing, and debugging playbooks under real multi-host conditions. Candidates who can write a functional playbook for a new task in under ten minutes without reference material are ready for the exam. Candidates who need to look up basic module parameters for every task will run out of time.

RHCE in the job market: where the credential lands in 2026

RHCE is positioned between the RHCSA (entry-to-mid Linux administration) and the more specialised Red Hat certs that follow it: Red Hat Certified Specialist in Ansible Automation (EX407), Red Hat Certified Architect (RHCA, which requires five specialist certs), and role-specific credentials for OpenShift, containers, and performance tuning. In the job market, RHCE functions as the dividing line between administrators who manage infrastructure manually and engineers who manage it as code.

In the US market, RHCE holders in Senior Linux Administrator roles command median salaries of $110,000–$135,000 USD in 2026, compared to $80,000–$100,000 for RHCSA-only holders in comparable positions. In DevOps Engineer and Platform Engineer roles, RHCE appears alongside Terraform Associate and CKA as the standard combination that demonstrates infrastructure-as-code competency across provisioning, configuration management, and container orchestration. Federal government and defence contracting organisations that standardise on Red Hat Enterprise Linux (common across US federal civilian agencies and DoD environments) frequently list RHCE as a required or preferred qualification for mid-to-senior Linux engineering positions, giving the credential outsized weight in that segment relative to the broader commercial market.

Preparing for EX294: the effective approach

RHCE preparation requires a hands-on lab environment with at least three virtual machines: one RHEL 9 control node and two managed hosts. The Red Hat Developer subscription (free for individual use) provides access to RHEL 9 and the RHEL System Roles package, which are the primary lab resources needed. Setting up this environment — whether locally with VirtualBox/KVM, on a cloud provider, or using Red Hat’s own lab environments — should happen on the first day of preparation, not the week before the exam.

The preparation sequence that consistently produces exam-ready candidates: start with the RHCSA topics that underpin EX294 (SELinux, firewalld, systemd, storage) and ensure those are fluent before introducing Ansible. Then work through every module category systematically: install a package, then a list of packages, then conditional package installation based on OS version. Configure a service, then configure it differently per host group, then configure it via a template. Build a role. Use a RHEL System Role for a task you have already done manually. Write a Vault-encrypted variable file and use it in a playbook. Each of these exercise types builds procedural fluency that the exam tests under time pressure.

Start with RHCSA, then build toward RHCE

RHCE requires an active RHCSA (EX200). If you hold RHCSA and are ready to step up to automation, EX294 is the natural next credential — and the one that most directly expands your role scope and compensation ceiling. The official Red Hat EX294 exam page lists current objectives, pricing, and scheduling. Practice every domain task in a real RHEL 9 environment using ansible-doc as your only reference — that is the closest simulation of exam conditions available.

Practice Linux and automation concepts with hands-on certification questions on CertQuests.

Browse Linux Certifications →