15 Common RHCSA Mistakes — and How to Avoid Them
RHCSA is a practical, performance-based exam. The biggest risk is rarely not knowing a command; it is delivering a system that works now but does not meet every requirement after a reboot.
1. Starting before reading the whole task
1. Missing a small requirement
A task may require a specific owner, group, mode, service state, mount option, or path. Completing only the headline requirement can still fail the task.
Avoid it: underline every deliverable, then turn each one into a short checklist before typing.
2. Using a different path or name
“Equivalent” is not always equivalent in an automated evaluation. A correct configuration in the wrong location may not be found.
Avoid it: use exact spelling, capitalization, paths, and names from the task.
2. Building it once, but not making it survive
3. Forgetting persistent mounts
Mounting a filesystem manually proves only that it works for the current session. A reboot can expose a missing or incorrect /etc/fstab entry.
Avoid it: validate with mount -a, then confirm the expected mount with findmnt.
4. Forgetting to enable a service
systemctl start starts a service now; it does not necessarily start it at boot.
Avoid it: when persistence is required, use systemctl enable --now service and check systemctl is-enabled.
5. Creating a temporary network configuration
Commands that change an address or route immediately may disappear after a reboot if the connection profile was not updated.
Avoid it: inspect the active NetworkManager connection and make the intended persistent change.
3. Not verifying from the evaluator’s point of view
6. Trusting a command’s lack of errors
A command can exit successfully while the resulting state is still wrong: a typo in a unit, an incorrect label, or an unmounted filesystem.
Avoid it: inspect state, not just command output. Use tools such as lsblk -f, getent, id, systemctl status, and findmnt.
7. Not testing access as the intended user
Root can read or enter places ordinary users cannot. Testing only as root hides permission and sudo errors.
Avoid it: switch to the target account or use sudo -l -U username when checking delegated access.
4. Treating SELinux and firewalld as afterthoughts
8. Disabling SELinux instead of fixing the label or policy
Changing enforcing mode to work around an access issue is not a robust solution and may violate the task requirements.
Avoid it: check getenforce, inspect labels with ls -Z, apply the correct context, and make custom file-context rules persistent with semanage fcontext followed by restorecon.
9. Opening the wrong firewall service or port
Adding a runtime rule—or a rule to the wrong zone—can leave the service unreachable after reload or reboot.
Avoid it: identify the active zone, add the required permanent rule, reload, and verify the final zone configuration.
5. Storage mistakes that cost easy marks
10. Confusing partitions, physical volumes, volume groups, and logical volumes
These are different layers. Creating the right object at the wrong layer means the requested filesystem cannot be built as specified.
Avoid it: sketch the requested storage stack first: disk → partition → PV → VG → LV → filesystem → mount.
11. Using device names that can change
Entries such as /dev/sdb1 may not be the stable identifier expected for persistent mounting.
Avoid it: use the UUID shown by blkid when writing persistent mount entries, unless the task explicitly says otherwise.
12. Skipping syntax checks after editing fstab
One invalid entry can cause a boot-time failure or an emergency-mode recovery situation.
Avoid it: always run mount -a immediately after editing /etc/fstab.
6. Users, groups, permissions, and sudo
13. Mixing up primary and supplementary groups
Users can belong to multiple groups, but the primary group and supplementary group requirements are not interchangeable.
Avoid it: confirm with id username and use the appropriate user-management option for each requirement.
14. Misreading numeric permission requirements
Permissions affect owner, group, and others separately. Directories also need execute permission to traverse them.
Avoid it: verify both numeric and symbolic views with stat or ls -ld; test as the non-root user.
15. Making unsafe sudoers edits
A malformed sudoers file can block administrative access.
Avoid it: create a clearly named file under /etc/sudoers.d/, use visudo -f, and validate before leaving the task.
7. Network and name-resolution oversights
Check addresses, routes, DNS, and hostname configuration independently. A system can have the correct IP address but an unusable route or resolver. Use ip addr, ip route, nmcli, and a real lookup or connectivity test where appropriate.
8. Losing time to perfectionism
Final pre-submit checklist
- Every named user, group, path, service, filesystem, and setting matches the task exactly.
- Required services are running and enabled.
- Mounts, networking, SELinux changes, firewall rules, and scheduled work are persistent where required.
- Configuration files were syntax-checked and the resulting system state was verified.
- You tested user-facing requirements as the relevant non-root account.
Use RCW’s RHCSA hands-on challenges to build, break, verify, and repeat.
Explore RHCSA practice tasks →