RHCE (EX294) Exam Strategy: Format, Time and Common Point Losses
EX294 is a hands-on exam of about four hours. You get a control node and several managed nodes, a list of 15 to 20 tasks, and no internet. Nobody reads your playbooks for style: a grader logs in afterwards, often reboots the machines, re-runs your playbooks and checks the end state on every node. That shapes how you should work.
Before you write a single task
Read the whole task list first (five minutes well spent). Note which groups each task targets, which files must have exact names, and which tasks depend on others. The order is almost always the same: Ansible configuration and inventory, access to the nodes, repositories, collections and roles, then the content tasks. If the foundation is wrong, every later task fails with it, so test it hard: ansible-inventory --graph, ansible-config dump --only-changed and ansible all -m ping must all look right before you move on.
Time management
Four hours sounds generous until a dnf transaction hangs or a template refuses to render. Give each task a budget (about ten minutes) and move on when you hit it; write the task number on a list and come back. Easy points first: users, files, cron and /etc/issue are quick wins, storage with block/rescue and the hardware report take longer. Keep the last 30 minutes for the full re-run.
Work the way the grader checks
- Always run from the project directory, so ansible.cfg is picked up. A playbook that only works with extra options you typed on the command line will fail when the grader runs it plainly. - Use the exact file names, group names, paths and values from the task. /etc/myhosts is not /etc/myhost, and Development is not development. - Target the right group. Many tasks are graded by also checking that the change is absent elsewhere. hosts: all where the task says prod costs the task. - Check the result on the nodes, not just the PLAY RECAP: ansible dev -m command -a 'cat /etc/issue', curl http://node3, ansible all -m command -a 'lvs'.
Verify with re-runs
Run every playbook twice. The second run should show changed=0. Typical offenders: command and shell without changedwhen or creates, passwordhash without updatepassword: oncreate (a new salt every run), and lineinfile with a regexp that does not match the line it writes. At the end, run everything again in order. If a later playbook breaks an earlier result (two plays writing the same file, for example), you find out now and not in the score report.
Common point losses
- Forgetting become, or putting remoteuser in the wrong section of ansible.cfg. - Installing collections or roles into the wrong path, or a collectionspath that hides the system collections, so redhat.rhelsystemroles stops resolving. - Firewall rules with permanent: true but no immediate: true (or the reverse): one of them is lost on reboot or not active now. - Facts used from hosts that were never contacted: the /etc/myhosts template needs a play that gathers facts on all hosts. - Vault: an encrypted file the playbook cannot open because the password file was not passed, or rekeying the wrong file. Keep the password file in the project directory with mode 0600. - Storage tasks that crash on the host without the volume group instead of printing the message. Test the when: condition and the rescue: path on every host. - Leaving a half-finished playbook that fails at the first task. A clean playbook with fewer tasks earns more than a broken one with all of them.
Last 30 minutes
Re-run each playbook in task order, compare every requirement against the end state once more, and fix only what is clearly wrong. Do not start refactoring working code. If you can, reboot a node and check that services, mounts and SELinux settings come back.