What the Exam Actually Asks
In one line
What the RHCE really asks is not Ansible syntax but whether you can bring RHEL into the desired state. That is why the points lost cluster on the system side.
Why the system and not the syntax
The RHCE (EX294) looks like an Ansible exam, but what it really asks is whether you can bring a RHEL system into the desired state. So the places where points are lost cluster on the system side, not the syntax.
started and enabled
state: started # 지금 돌고 있는가
enabled: true # 재부팅 후에도 뜨는가
The two are different stories. If you write only started, it passes at the moment of grading. After a reboot it disappears, and reboots usually happen at dawn.
The two worlds of firewalld
firewalld manages the rules running now (runtime) and the rules written in files (permanent) separately.
| What you gave | Result | Symptom |
|---|---|---|
permanent only |
It is written to the file but not open right now | "I configured it, so why doesn't it work" |
immediate only |
It is open now but disappears when restarted | "It worked yesterday" |
| Both | Complete |
SELinux blocks quietly
When SELinux blocks something, it looks to the application like an ordinary error. It is connection refused or 403. The file permissions are fine, which confuses things more.
And if you leave out persistent: true on a boolean, it is turned on only for now and reverts at reboot. Because the symptom after the reversion is exactly the same as at the start, you go through the same outage again believing you fixed it.
File contexts are two steps. sefcontext only registers a rule, and to apply it to files that already exist, you have to run restorecon separately.
Idempotence is a number, not a belief
"I wrote it to be idempotent" is a belief, and "the changed of the second run is 0" is a fact. Only the latter means anything.
What breaks it is almost always one of two things.
- An unconditional
command/shell— it is always changed. Give it a condition withcreates:orchanged_when:. - A template that differs every time — if you put in a time or a random number, the content keeps changing. Then the handler restarts the service every time, so even though nothing changed, every deployment causes an interruption.
Where you lose time in the exam room
On the RHCE, people fail not because they cannot use what they know but because they run out of time. So settling the procedure in advance is as important as knowledge.
Check the inventory and connectivity first. However well you write a playbook, if it cannot reach the targets, it is 0 points. With one ansible all -m ping, see whether all respond, and also check whether privilege escalation works. The 1 minute this check takes prevents the 20 minutes you would lose later on "why doesn't it work".
Decide where you will look at documentation. Module option names are not something to memorize but something to find with ansible-doc. However, because finding takes time, get the frequently used ones (package, service, copy, template, lineinfile, user, firewalld, seboolean) into your fingers and look up only the rest.
When you finish one problem, verify it on the spot. If you check everything in a batch later, you have to find again which problem had what wrong. If you dealt with a service, look as far as systemctl is-enabled on the spot, and if you dealt with the firewall, as far as firewall-cmd --list-all.
If you get stuck, move on. While you cling to one problem, two problems you could have solved slip by. When you move on, note what you left behind, and come back in the remaining time.
And at the end, be sure to leave time to check the state after a reboot. This is the only way to catch the persistence problem this module has kept talking about. If you have no time to reboot, at least skim systemctl is-enabled and firewalld's permanent list. It is the same in practice. "What works now" and "what works after a reboot" are different states, and the difference always shows up at the worst moment.
What really matters in practice
For modules that change state, always write the persistence alongside. Pair enabled: true with state: started, permanent and immediate with firewalld, and persistent: true with SELinux booleans. If you leave it out, it passes now and disappears after a reboot, and reboots usually happen at dawn.
Idempotence is proven only by the changed of the second run being 0. What breaks it is almost always two things: an unconditional command/shell and a template that differs every time. The latter is especially bad — the handler restarts the service every time, so even though nothing changed, every deployment causes an interruption.
When SELinux blocks, it looks like an application error. It shows up as connection refused or 403, and with the file permissions fine, it takes the longest to find the cause. You also have to remember that sefcontext only registers a rule — to apply it to files that already exist, you have to run restorecon separately.
The next lab runs on an AlmaLinux 9 VM. SELinux is Enforcing and firewalld is alive, so if you leave out the things above, it really gets blocked.