RHCSA EX200 on RHEL 10: Make Every Task Survive the Reboot

On the RHCSA exam (EX200), a task only counts if it still works after the machine restarts. Red Hat says it plainly on the official EX200 exam page: "configurations must persist after reboot without intervention." So the habit worth drilling is not just knowing the command. It is knowing which half of a change lives in memory and which half is written to disk.

This post pairs the runtime command with its persistent form for each area of the RHEL 10 objectives, then ends with a small script you can run after a reboot to prove your lab still holds.

What does "persist after reboot" mean on the RHCSA exam?

EX200 is a hands-on exam. You get real systems and a list of tasks, not multiple-choice questions. The current version is based on Red Hat Enterprise Linux 10. Red Hat's training store lists it for the United States as a 3-hour individual exam at USD 500; prices differ by country. You cannot use the internet, notes or books, but for most Red Hat exams the documentation that ships with the product is available.

The grader looks at the system state, and a reboot is part of how that state is judged. A firewall rule that only exists in the running config, a mount you typed by hand, or SELinux switched to enforcing with setenforce 1 alone will all look fine at the prompt. Then they disappear.

Results arrive by email within three U.S. business days. They show pass or fail plus a score breakdown by objective, so a persistence slip shows up as a weak section rather than a mystery.

Which changes vanish at reboot if you do only the runtime half?

Most RHCSA objectives have a "now" command and a "for good" command. Here are the pairs that catch people most often.

The rest of this post walks through each group with commands you can paste into a RHEL 10 lab VM.

How do you build storage that mounts itself again after a reboot?

Create the LVM stack, put a file system on it, and mount it by UUID, not by device name. Device names such as /dev/vdb can change between boots. A UUID does not.

pvcreate /dev/vdb vgcreate vgdata /dev/vdb lvcreate --name lvdata --size 1G vgdata mkfs.xfs /dev/vgdata/lvdata mkdir -p /data blkid /dev/vgdata/lvdata # copy the UUID value echo 'UUID=<paste-uuid-here> /data xfs defaults 0 0' >> /etc/fstab systemctl daemon-reload # regenerate mount units from fstab mount -a && findmnt /data 

mount -a is your safety net. If it errors, the line in /etc/fstab is wrong, and you want to learn that now and not from a system that will not boot. Red Hat's RHEL 10 guide to logical volumes uses the long option names shown above.

Growing a volume is one command if you let LVM resize the file system for you:

lvextend --size +500M --resizefs vgdata/lvdata df -h /data 

Swap follows the same pattern: mkswap on the new device, swapon to use it now, and a line such as UUID=<uuid> none swap defaults 0 0 in /etc/fstab so it comes back. The RHEL 10 file systems guide explains each /etc/fstab field and the systemctl daemon-reload step.

How do you make firewall and SELinux changes permanent?

With firewalld, a rule without --permanent lives only in the runtime configuration. Write it to the permanent configuration and reload:

firewall-cmd --permanent --add-service=http firewall-cmd --permanent --add-port=82/tcp firewall-cmd --reload firewall-cmd --list-all 

If you already built a working runtime setup, firewall-cmd --runtime-to-permanent copies it over in one step. The RHEL 10 firewall guide uses both styles.

SELinux has three separate persistence traps: the mode, the file labels and the booleans.

# Mode: setenforce alone does not survive a reboot setenforce 1 sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config # Labels: record the rule, then apply it semanage fcontext -a -t httpd_sys_content_t '/srv/web(/.*)?' restorecon -Rv /srv/web # Non-standard port for a confined service semanage port -a -t http_port_t -p tcp 82 # Booleans: -P writes the value to the policy on disk setsebool -P httpd_enable_homedirs on 

chcon does change a label, and that change even survives a reboot. But the next restorecon or full relabel puts the policy's default back, which is why the exam objective says "restore default file contexts". The RHEL 10 SELinux guide shows semanage fcontext -a followed by restorecon as the lasting fix.

How do services, boot targets and time sync come back on their own?

systemctl start runs a service now. systemctl enable makes it start at boot. Using --now does both, so it is the safer reflex on the exam:

systemctl enable --now httpd systemctl set-default multi-user.target systemctl get-default 

Time sync is a client setting in /etc/chrony.conf plus an enabled chronyd:

echo 'server classroom.example.com iburst' >> /etc/chrony.conf systemctl enable --now chronyd systemctl restart chronyd chronyc sources 

Replace classroom.example.com with whatever server the task names. The RHEL 10 time synchronization guide documents the server ... iburst line and the chronyc sources output.

How do you keep the system journal across reboots?

The objective "preserve system journals" means logs from the previous boot must still be readable after a restart. Set the storage mode in the journald config and restart the service:

mkdir -p /etc/systemd/journald.conf.d printf '[Journal]\nStorage=persistent\n' > /etc/systemd/journald.conf.d/persist.conf systemctl restart systemd-journald journalctl --list-boots # after a reboot, the earlier boot is listed too 

With Storage=persistent, journald writes below /var/log/journal and creates the directory if needed. With auto, it only does so when that directory already exists. The journald.conf manual page spells out all four storage modes.

How do you change kernel arguments and network settings for good?

A kernel argument typed at the GRUB menu lasts for one boot. grubby writes it to every boot entry:

grubby --update-kernel=ALL --args="audit=1" grubby --info=ALL | grep args 

The RHEL 10 kernel guide covers --args and --remove-args for the "modify the system bootloader" objective.

Network settings belong in a NetworkManager connection profile, which is already stored on disk:

nmcli connection modify ens3 ipv4.method manual ipv4.addresses 192.0.2.10/24 \ ipv4.gateway 192.0.2.254 ipv4.dns 192.0.2.200 connection.autoconnect yes nmcli connection up ens3 hostnamectl set-hostname server1.example.com 

Use the connection name your system shows in nmcli connection show. ip addr add would work only until the next reboot.

How can you test persistence before you hand in the exam?

Reboot your practice VM on purpose, then run a check script. Writing it is also practice for the "create simple shell scripts" objective, since it uses if, for and a script argument.

#!/bin/bash # after-reboot.sh usage: ./after-reboot.sh /data mnt=${1:-/data} fail=0 check() { if eval "$2" >/dev/null 2>&1; then echo "OK $1"; else echo "FAIL $1"; fail=1; fi; } check "mount $mnt" "findmnt $mnt" check "selinux enforcing" "[ \"\$(getenforce)\" = Enforcing ]" check "http in firewall" "firewall-cmd --list-services | grep -qw http" check "journal kept" "journalctl -q -b -1 -n 1" # fails if the last boot's log is gone for svc in httpd chronyd; do check "$svc enabled" "systemctl is-enabled $svc" done exit $fail 

A clean run after a real reboot is the closest you can get at home to how the exam will be judged. On exam day, leave time at the end to reboot and check your work. Fixing a missed --permanent takes seconds. Finding out from your score report takes days.

Where does RHCSA lead after you pass?

Since May 11, 2026, Red Hat sorts its certifications into five tracks. Its training and certification FAQ says EX200 is the foundational exam for both the Enterprise Linux track and the Ansible track. The usual next step is EX294, now titled Red Hat Certified Advanced System Administrator in Ansible. The VMExam channel has no RHCSA video yet, so here is its short take on EX294, the exam that builds on these skills:

For a side-by-side view of every EX200 objective group, the RHCSA EX200 exam syllabus lists them in the same order as Red Hat, which makes it easy to tick off each one as your reboot script passes.

Frequently asked questions

1. Is the RHCSA EX200 exam multiple choice?

No. EX200 is a performance-based exam. You complete real system administration tasks on live systems within 3 hours, and your configurations must still work after a reboot.

2. Which version of RHEL is EX200 based on?

The current EX200 exam is based on Red Hat Enterprise Linux 10. Practice on a RHEL 10 system so commands, defaults and documentation match what you will see.

3. Can I use documentation during the RHCSA exam?

You get no internet access and cannot bring notes, books or electronic documents. For most Red Hat exams, the documentation that ships with the product is available on the exam system.

4. What happens if I fail EX200 on my first attempt?

Red Hat gives a free retake after an unsuccessful first attempt at an individual exam. Your results arrive within three U.S. business days with a score breakdown by objective, so you can see which sections to rework.

5. How long does the RHCSA certification stay valid?

Red Hat certifications are current for three years from the date you earn them. You can renew by retaking the exam for your highest certification, earning another one at the same level, or earning a higher-level certification.

Written by the team behind VMExam, which publishes study notes and practice tests for cloud, virtualization and Linux certification exams.