Red Hat Certified System Administrator (RHCSA) #15: Exam tips, time management, and patterns people get wrong

From #1 through #14 we covered every RHCSA domain. This post is the compressed read to go through one more time right before you enter the hands-on exam. There’s no new domain here — only how to run the 2.5-hour hands-on exam and the traps where candidates most often bleed points across the whole series. Because it isn’t multiple choice but an exam where you perform tasks directly on a bare RHEL system and a grading script inspects the resulting state, the same knowledge plays out differently: how you run the exam decides pass or fail.

Running your 2.5 hours #

Pile up points starting with the easy tasks #

RHCSA typically gives you 15–20 tasks to solve within 2.5 hours. Unlike CKA, the point values per task aren’t shown on screen, so the key is to finish the tasks you can definitely solve first and rack up points. Skim the task list once at the start, mentally sort what you know cold from what will take time, and start with the procedural tasks like creating users, granting permissions, and enabling services.

Keep the order for dependent tasks #

RHCSA tasks often have dependencies on one another. For example, you can only create a logical volume after creating the LVM volume group, and only put a file system on it and register it in fstab after creating the logical volume. You have to create a user before you can grant that user ACLs or sudo permissions. So when you skim the task list, group prerequisite and follow-on tasks to establish the order, and if a prerequisite task gets stuck, flag the follow-on tasks that depend on it as well.

Don’t over-fixate on one task #

The passing line is 210/300, that is 70%. Even if you give up on one or two hard tasks, you clear the line if you solve the rest reliably. The most common failure is clinging to one stuck task while missing several tasks you know cold. Set a personal cut-off: push a stuck task as far as you can, then move on.

Solve unfamiliar tasks with man pages #

RHCSA has no internet, so you can’t look at Stack Overflow or blogs. The only allowed references are local man pages and /usr/share/doc. So even when you can’t recall a command name, the habit of finding man pages quickly is itself worth points.

Find the command itself by keyword #

When you have the task in mind but can’t remember the command name, search by keyword with man -k (apropos).

# Search all man pages that contain the "partition" keyword
man -k partition

# Find user-related commands
man -k user | grep -i add

Jump straight to examples inside man #

Man pages are long, and reading from the top eats time. After opening man, search with /EXAMPLE to jump straight to the examples section. Most commands have copy-and-use forms right there in EXAMPLES.

man lvcreate
# Inside man, type /EXAMPLE and Enter, then n to move to the next match

Use the config examples in /usr/share/doc #

Complex config files often have example files under /usr/share/doc. For tasks where the format is confusing — the autofs master map, the chrony config example — checking the format here is faster.

# Check the per-package doc directory
ls /usr/share/doc/autofs/
ls /usr/share/doc/ | grep -i chrony

The timer keeps running while you dig through man pages. Drill the frequently used commands until they’re automatic, and use man pages only to look up options that are hard to memorize or to check config file formats.

Verify with a reboot #

The most common cause of lost points in RHCSA is settings disappearing after a reboot. Grading happens with the system rebooted, so you earn points only when you’ve confirmed not “it works now” but “it still works after a reboot.”

Ask yourself about persistence on every task #

Every time you finish a task, ask yourself “does this persist after a reboot?” Mounts go in fstab, services get enabled, networking goes in NetworkManager persistent settings, and SELinux booleans must include -P.

Reboot once at the very end #

In the verification phase, I recommend rebooting once at the very end of the exam. After the reboot, confirm that the system comes up properly to the multi-user target and that the mounts and services you created are still alive. That said, a reboot takes time and an fstab typo can halt the boot, so always verify fstab with mount -a before rebooting.

# Before reboot: verify there are no typos in fstab (safe if it finishes with no error)
mount -a

# Whether the service is enabled
systemctl is-enabled httpd

# One final reboot at the end
reboot

Patterns people get wrong #

These are the recurring patterns that cost points across the whole series. More points are lost to operational mistakes than to gaps in knowledge.

1) fstab typo makes the system unbootable #

A typo in fstab drops the system into emergency mode on reboot and halts it. If the system is stuck at boot during grading, every subsequent task can score zero at once — making it the most dangerous mistake. Right after adding a new entry, always verify with mount -a, and don’t type the UUID by hand — copy it from the blkid output.

# Don't type the UUID directly — check and copy it
blkid /dev/vdb1

# Verify immediately after editing fstab — safe if it finishes with no error
mount -a

2) Forgetting to enable a service #

If you only systemctl start and forget enable, it’s up now but the service won’t come up after a reboot. Since grading is post-reboot, there are no points. Bundle start and enable into one action with --now.

# start and enable at once
systemctl enable --now httpd

# Check
systemctl is-enabled httpd
systemctl is-active httpd

3) Forgetting firewall –permanent and –reload #

When you open a port with firewall-cmd, forgetting --permanent means the rule disappears after a reboot, and giving only --permanent while forgetting --reload means it isn’t applied to the current runtime. You have to handle both so it works now and persists after a reboot.

firewall-cmd --permanent --add-service=http
firewall-cmd --reload

# Confirm it actually went into the permanent ruleset
firewall-cmd --permanent --list-all

4) Forgetting SELinux setsebool -P #

When changing an SELinux boolean, forgetting -P (persistent) means it reverts to the default after a reboot. Since grading is post-reboot, a change without -P earns no points.

# Changing without -P means it disappears after a reboot
setsebool -P httpd_can_network_connect on

# Check
getsebool httpd_can_network_connect

5) Missing SELinux relabel after root password recovery #

In the task where you intercept boot with GRUB to change the root password, editing /etc/shadow after entering with rd.break throws the SELinux contexts off. If you don’t create the /.autorelabel file before rebooting, the system may fail to log in.

# After entering rd.break
mount -o remount,rw /sysroot
chroot /sysroot
passwd root
# Schedule a relabel (skip this and you can't log in after a reboot)
touch /.autorelabel
exit
exit

6) Confusing LVM units #

It’s easy to mix up size units and options in LVM tasks. -L is an absolute size (e.g. -L 1G), while -l is an extent count or percentage (e.g. -l 50%FREE). When extending, if you grow only the logical volume with lvextend and forget to extend the file system, you can’t use the added space. Growing the file system too in one shot with -r prevents the omission.

# Extend the logical volume and file system together (-r)
lvextend -L +500M -r /dev/vgdata/lvdata

# Or take all remaining space as an extent percentage
lvextend -l +100%FREE -r /dev/vgdata/lvdata

7) Missing -aG for a user’s supplementary group #

Using just usermod -G wipes all existing supplementary groups and overwrites them with the groups you specify. When you add a supplementary group, you must use -aG (append) to keep the existing memberships while adding the group.

# Using -G without -a blows away the existing supplementary groups
usermod -aG wheel,developers alice

# Check
groups alice
id alice

Easily confused concept pairs #

These are pairs that are easy to mix up mid-task, each captured in a one-line difference.

restorecon and chcon pull in opposite directions. restorecon returns a file to the default context defined in policy, so it’s the right answer for most SELinux file-context problems. chcon assigns a context by hand and makes things work for now, but the change disappears when restorecon -R runs or a system relabel happens. If the task is “create a directory and give it the correct context,” registering a rule with semanage fcontext and then applying it with restorecon is the persistent approach.

# Persistent: register the rule, then apply
semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"
restorecon -Rv /web

Domain-by-domain checklist right before you sit #

The core commands to reach for in each domain, along with the persistence checkpoints.

Essential tools and shell scripts #

• redirection/pipe, file search with find/grep, tar/gzip archives
• ssh/scp remote access, key-based authentication setup
• Scripts: conditionals, loops, $1 arguments, exit codes ($?)

Boot and system operations #

• Change the default target: systemctl set-default, systemctl isolate
• Root password recovery via GRUB: passwd after rd.break, and touch /.autorelabel
• Time sync with chronyd, logs with journalctl, cron/systemd timer

Local storage and file systems #

• Create partitions/swap/LVM, distinguish the -L and -l units
• Extend the logical volume and file system together with lvextend -r
• Verify with mount -a after registering in fstab, copy the UUID from blkid
• NFS/AutoFS mounts, LUKS encryption

Packages and networking #

• dnf install/repository registration, module stream
• Set IP/gateway/DNS (persistent) with nmcli, hostname, /etc/hosts

Users and security #

• Create users/groups, add supplementary groups with usermod -aG, set UID/GID
• sudo permissions, ACL (setfacl/getfacl), password policy (chage)
• firewalld: add with --permanent then --reload
• SELinux: setsebool -P, restorecon after semanage fcontext, audit2allow

Containers #

• Pull/run images with podman, mount volumes, publish ports
• Register a rootless container as a systemd service (quadlet), enable --now and linger

Checks right before the Remote Exam #

You take RHCSA at a testing center (kiosk) or via the Red Hat Remote Exam. Confirm the following before the exam starts.

ID #

• A government-issued ID with your name in Roman letters (a passport is recommended), matching your registration info exactly
• Present the ID to the camera as the proctor instructs

Testing environment #

• Clear everything off the desk, remove wall notes and posters
• Use a single monitor, block others from entering
• The Remote Exam boots from a provided live image via USB, so secure a stable wired network

Right after tasks begin #

• Skim the task list once to sort what your hands know from what will take time
• Mentally organize the prerequisite/follow-on order of dependent tasks
• Enter with the habit of asking yourself about persistence from the very first task

Wrap-up #

What this post locked in:

• Running your 2.5 hours. Pile up points starting with the easy tasks, keep the order for dependent tasks, and don’t over-fixate on one task. The passing line is 70%
• Using man pages. Find commands with man -k, jump straight to examples with /EXAMPLE inside man, check config formats with /usr/share/doc
• Reboot verification. Ask yourself about persistence on every task, verify fstab with mount -a, then confirm everything persists with one final reboot
• Recurring mistakes. fstab typo making it unbootable, missing service enable, missing firewall permanent/reload, missing SELinux -P, missing relabel after root recovery, confusing LVM units, missing -aG for a supplementary group
• Easily confused concept pairs. restorecon vs chcon, -L vs -l, enable vs start, permanent vs runtime
• Per-domain core procedures and persistence points, and Remote Exam checks

Next: full-scale mock exam #

This is the final post.

In #16 Full-scale mock exam (all-domain integrated scenario + explanations), we solve an integrated scenario with a domain distribution close to the real exam and attach detailed explanations. It’s the last step: solve it timed like the exam environment, using only man pages with no internet, and firm up the heavyweight domains like storage and security one more time.