EX294 is the Red Hat Certified Advanced System Administrator in Ansible exam, a hands-on, performance-based test of writing playbooks and running system administration tasks with Red Hat Ansible Automation Platform. If you already hold RHCSA, passing EX294 earns you Red Hat Certified Engineer in Ansible. This guide covers the official objectives, how the exam is run and scored, fees and retakes, and a worked practice case on task behavior.
What EX294 is called now and what it earns you
EX294 is officially the Red Hat Certified Advanced System Administrator in Ansible exam. Passing it contributes to Red Hat Certified Engineer in Ansible and Red Hat Certified Architect in Ansible.
Red Hat's exam page titles EX294 the Red Hat Certified Advanced System Administrator in Ansible exam. It is performance-based and tests your ability to write playbooks to manage systems and execute common system administration tasks using Red Hat Ansible Automation Platform.
The credential path matters for planning. RHCSA holders who complete EX294 earn the Red Hat Certified Engineer in Ansible credential. Red Hat also notes that candidates who earn it automatically extend the currency of other RHCE credentials they hold, plus any credentials below RHCE.
One naming caution: EX294 alone does not make you an RHCE. If you are not yet an RHCSA, Red Hat points you to Linux system administration certification first, because the automation skills build on that foundation.
Official sources: Red Hat Certified Advanced System Administrator in Ansible Exam | EX294 — Official Red Hat exam page; Red Hat Certified Engineer in Ansible — Official Red Hat certification page
Prerequisites and who the exam suits
Red Hat recommends RH124, RH134, and AU294 or comparable work experience, and expects you to be able to perform every RHCSA task. Course attendance is recommended, not required.
The published prerequisites combine two things. First, either Red Hat System Administration I and II (RH124 and RH134), the RHCSA Rapid Track course (RH199), or comparable RHEL system administration experience. Second, Red Hat Enterprise Linux Automation with Ansible (AU294) or comparable automation experience.
The objectives set an RHCSA baseline: candidates must be able to perform the administration tasks listed on the EX294 page. Review the EX200 objectives too. Its current page covers RHEL 10; separately confirm the product version attached to your EX294 booking before choosing a practice environment.
The exam suits administrators who want to automate work across several systems and demonstrate that their playbooks produce the required result.
Official sources: Red Hat Certified Advanced System Administrator in Ansible Exam | EX294 — Official Red Hat exam page; Red Hat Certified System Administrator exam | EX200 — Official Red Hat exam page
How the hands-on exam is run and scored
You receive multiple systems, configure Ansible Automation Platform, and create playbooks for a task list. Red Hat applies your playbooks to freshly installed systems and grades whether the end state matches the specification.
This is a practical exam on live systems, not a multiple-choice test. Tasks are mostly described as a specific end state you must achieve, and your work is evaluated by running the playbooks you created against freshly installed systems and verifying that those systems and services work as specified.
Configurations must persist after reboot without intervention. Practice checking both the immediate result and the settings needed to retain it. Internet access is not provided, and you may not bring personal notes, books or electronic documentation. For most exams, the documentation supplied with the product is available.
Official scores come only from Red Hat Certification Central, reported as total scores with no per-item feedback. Be aware the two official sources give different timelines: the EX294 page says scores are usually reported within three U.S. business days, while the certification program guide says results arrive within five business days with a pass/fail status and an objective-area breakdown. Plan around the longer window.
Official sources: Red Hat Certified Advanced System Administrator in Ansible Exam | EX294 — Official Red Hat exam page; Red Hat Certification program guide — Red Hat Documentation, Red Hat Learning Subscription 1-latest
The tested objectives at a glance
The objectives combine the full RHCSA task baseline with Ansible work: core components, configuration, managed nodes, playbooks, roles, collections, templates, Vault, and automating standard administration tasks.
Use these groups to plan your practice, then check every task on the current official objective list for your booked version.
- RHCSA baseline: essential tools, running systems, local storage, file systems, deployment and maintenance, users and groups, security, and simple shell script analysis.
- Core Ansible components: inventories, modules, variables, facts, loops, conditional tasks, plays, task failure handling, playbooks, configuration files, and roles.
- Ansible configuration: create and modify ansible.cfg and ansible-navigator.yml, build static inventories with host groups, distribute SSH keys, configure privilege escalation, and deploy files to managed nodes.
- Running playbooks: use both ansible-navigator and ansible-playbook, discover modules in installed Content Collections through navigator, and perform basic Git operations such as cloning a repository and adding files.
- VS Code workflow: create playbooks and push them to Git, configure ansible-navigator, and run playbooks inside an Ansible development container.
- Play design: register command results in variables, control execution with conditionals, and configure error handling.
- Roles and collections: create and work with roles, install roles and Content Collections, and combine their content in playbooks.
- Automating RHCSA-level work with modules: packages and repositories, services, firewall rules, file systems, storage devices, file content, archiving, task scheduling, security, and users and groups.
- Templates and secrets: build customized configuration files with templates and protect sensitive data with Ansible Vault in playbooks.
Official sources: Red Hat Certified Advanced System Administrator in Ansible Exam | EX294 — Official Red Hat exam page
Booking, fees, retakes and delivery formats
The standard list price is $500 USD and may vary by region. Every paid first attempt includes one free retake, and certifications stay current for three years.
You can take Red Hat exams remotely from home or office using a bootable LiveUSB under webcam proctoring, at an authorized testing center, or in a classroom setting after a training course. All formats are hands-on and performance-based.
If you choose the remote format, a compatibility test using the LiveUSB is mandatory before exam day, and hardware or connection issues discovered on exam day can forfeit your attempt. Request disability-related or religious accommodations at least two weeks ahead through Red Hat's accommodation portal.
On retakes: every paid first attempt carries one free second attempt on the same exam, schedulable immediately. After a second failed attempt a waiting period applies, further attempts require a new paid registration, and you cannot take the same exam twice in one calendar day. Certification currency lasts three years from the date earned, and renewing a higher-level credential renews everything at or below it.
Official sources: Red Hat Certification program guide — Red Hat Documentation, Red Hat Learning Subscription 1-latest
Official preparation guidance and a suggested rebuild drill
Red Hat recommends RH124, RH134, and AU294 but does not require them and endorses no third-party materials. Beyond the courses, practice ending every lab task with a verified, reboot-proof end state.
The official guidance is straightforward: consider the three courses, but attendance is not required and you may sit just the exam. Red Hat also notes that previous experience, practice, and aptitude all influence results, and it does not endorse any external books or resources as exam preparation.
A suggested lab drill is to restore managed nodes from a clean snapshot, apply your playbooks and verify each requested result. Run them again to check for unnecessary changes, then reboot and verify the required configuration and services. This is preparation advice based on the published evaluation model; a quiet recap alone does not prove that the result is correct.
Practice finding module parameters in the supplied Ansible documentation. The objectives explicitly include using provided documentation and discovering modules with ansible-navigator.
Official sources: Red Hat Certified Advanced System Administrator in Ansible Exam | EX294 — Official Red Hat exam page
Worked case: what a command task reports on its second run
In the successful normal runs considered here, an unguarded command executes and reports changed each time. creates can skip execution when a matching file exists; changed_when controls reporting and handler notification.
Work through the paper case below to separate execution from reporting. Assume normal execution, a successful command and no other conditions that skip the task. The command module does not determine whether the command actually changed the desired resource, so it reports changed by default.
The creates parameter checks for a matching file and skips the command if it exists. changed_when overrides the reported change status and affects handler notification. It does not prevent the command from executing.
- name: Generate monthly report data
ansible.builtin.command: /usr/local/bin/mkreport --month current
register: report_out
# Second run: executes again and reports changed, even though
# /var/reports/current.csv already exists
- name: Same task, guarded
ansible.builtin.command: /usr/local/bin/mkreport --month current
args:
creates: /var/reports/current.csv
# Second run: skipped, reported as ok with no changePractice case
Assume a single managed host where /usr/local/bin/mkreport exists, always writes /var/reports/current.csv, and exits with return code 0 whether or not the file already exists. A play contains the unguarded task shown in the code block. (a) What does the recap report on the first run, and why? (b) What does it report on the second consecutive run against the same host, and why? (c) If you instead add changed_when: false to the unguarded task, does the command still execute on the second run, and what is the effect on handler notification? (d) State the guard that makes the second run skip execution, and its exact condition.
Show the answer
(a) The task reports changed: the command runs, exits 0, and command tasks count a successful run as a change by default. (b) It still reports changed: the command module does not check whether /var/reports/current.csv exists, so the script runs again and the run is counted as a change. (c) Yes, the command executes. changed_when only changes what Ansible reports about the task and whether this task notifies handlers; it never prevents execution. With changed_when: false the recap shows ok, and this task does not send a change notification to a handler. (d) Add creates: /var/reports/current.csv. Ansible checks for that file before running the command, and if a matching file already exists the step is not run, so the second run shows the task as ok.
The command module's documentation states that it executes the given command on all selected nodes and processes nothing through the shell, and that the creates parameter skips the step when a matching file exists, checked before removes. The error-handling documentation shows that changed_when defines when a task counts as changed for reporting and handler purposes, with an explicit example of a task that never reports changed while still being a command execution. The handlers documentation confirms that tasks notify handlers on a change, which is why a false changed report also silences notification.
| Situation | Better choice | Why |
|---|---|---|
| Manage a package, service, file, user, or firewall rule | A dedicated module for that resource | Check the module documentation for its state handling and supported options. |
| Run a binary with plain arguments, no shell features | ansible.builtin.command, ideally with argv | No shell metacharacters are processed, and argv avoids quoting pitfalls |
| Need pipes, redirection, or globs | ansible.builtin.shell, quoting any templated values | The shell module provides shell parsing; the command module does not. |
| Run only when a file-existence condition requires it | command with an appropriate creates or removes guard | Choose a condition that represents the real requirement; file existence alone does not validate file contents. |
Official sources: ansible.builtin.command module — Ansible Community Documentation; Error handling in playbooks — Ansible Community Documentation, playbook guide; Handlers: running operations on change — Ansible Community Documentation, playbook guide
Roles, collections and the tooling objectives
Expect to build and consume roles, install Content Collections, and work through Git, VS Code, and ansible-navigator, since each appears explicitly in the published objectives.
On the content side, the objectives ask you to create and work with roles, install roles and use them in playbooks, install Content Collections, and draw related roles, supplementary modules, and other content from collections into a play. Prefer fully qualified names such as ansible.builtin.command, which the Ansible documentation recommends for avoiding conflicts with same-named modules in other collections.
On the workflow side, rehearse the full toolchain the objectives name: clone a Git repository and add files, create playbooks in VS Code and push them to Git, configure ansible-navigator, and run playbooks inside an Ansible development container. Also practice using navigator to discover modules in installed collections and to create inventories and configure the Ansible environment.
For variables, facts, templates, and Vault, the objectives set the scope: use variables to capture command results, control play execution with conditionals, configure error handling, build customized configuration files with templates, and protect sensitive data with Ansible Vault inside playbooks. The Ansible product documentation is your technical reference for each of these; the exam page confirms only that these skills are tested.
Official sources: Red Hat Certified Advanced System Administrator in Ansible Exam | EX294 — Official Red Hat exam page; ansible.builtin.command module — Ansible Community Documentation
Official sources
Key facts checked against official Red Hat and Ansible documentation: