The RHCSA (Red Hat Certified System Administrator) validates practical Red Hat Enterprise Linux administration skills. It makes sense if you work with RHEL or want to demonstrate that you can configure, troubleshoot, and recover a system — not just recognize commands in a textbook. This guide brings together a study path, original exercises, and a validation routine for EX200.
Reviewed on 12 September 2026: check the version and conditions of your booking before buying study material or scheduling. The study plan below is an editorial suggestion, not a promise of passing or a reproduction of actual exam tasks.
How RHCSA works and which RHEL version to study
The current EX200 page specifies RHEL 10. The exam is hands-on, with no internet or personal materials; installed documentation may be available. Configurations must persist after reboot. Use the official list as your main reference instead of mixing guides for different versions.
The official learning path published in 2022 lists 3 hours for EX200. Confirm the duration, language, delivery format, and price in your booking; do not treat a price converted from another country as a definitive quote.
Red Hat considers certifications current for 3 years. After that, a credential may become non-current; this does not erase the certification history. Check the official renewal options, including retaking the exam.
Topic checklist: pay attention to RHEL 10
Organize your study around tools and shell, software, processes and boot, storage, file systems, services, networking, users, and security. The current list includes RPM and Flatpak, GPT/LVM, VFAT/ext4/XFS, NFS/autofs, systemd timers, IPv4/IPv6, firewalld, and SELinux. Containers are not listed as a specific objective in the consulted list; do not assume an older Podman course represents the current syllabus.
Turn each topic into an observable outcome: can a user access the directory? Does the volume mount automatically? Does the service respond from another machine? Mark a topic as mastered only when you can reproduce, explain, and test it without following a ready-made recipe.
Build a disposable lab
For studying, I suggest two VMs: a server and a client, with a private network between them, internet access for installing packages, and a clean snapshot. Add empty virtual disks reserved for storage exercises. Do not run partitioning, boot, firewall, or SELinux exercises on a production server.
The Red Hat Developer Subscription for Individuals provides no-cost RHEL with self-support and up to 16 physical or virtual nodes, subject to its terms. Use an eligible individual account and check the program conditions; this is not the same as purchasing production support.
Before each exercise, confirm the machine and its disks. Device names can differ between VMs; identifying a disk by its size and purpose is safer than copying a destructive command with a fixed name.
hostnamectl
cat /etc/redhat-release
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
ip -br address
A six-stage study plan
Use these stages as a sequence, not a mandatory deadline. Beginners may need to repeat several of them. In each session, allow time to build the scenario, make mistakes, consult documentation, and repeat it without looking at notes.
- Stage 1 — terminal: files, permissions, links, redirection,
grep, archives, and small scripts with arguments. - Stage 2 — operations: users, groups, privileges, processes, logs, services, and boot recovery at the VM console.
- Stage 3 — storage: empty disks, logical volumes, file systems, swap, and persistent mounting.
- Stage 4 — integration: connectivity between VMs, name resolution, firewall, SSH, NFS, and autofs.
- Stage 5 — maintenance and security: repositories, scheduling, SELinux, and troubleshooting without disabling security controls.
- Stage 6 — your own mock exam: combine earlier tasks, time yourself, and validate everything after rebooting.
Integrated exercise: a web service that survives a reboot
This is an original lab combining packages, services, permissions, firewall, and tests; it is not an official question or an exam prediction. Use a disposable RHEL VM, working repositories, and a user with sudo. Keep access to the VM console before enabling the firewall in case SSH is blocked. The example uses the standard HTTP port to avoid confusing service configuration with authorizing an alternative port.
sudo dnf install -y httpd firewalld
printf "RHCSA lab OK\n" | sudo tee /var/www/html/index.html
sudo chmod 0644 /var/www/html/index.html
sudo restorecon -v /var/www/html/index.html
sudo systemctl enable --now firewalld
sudo systemctl enable --now httpd
sudo firewall-cmd --get-active-zones
Identify the zone assigned to the interface used by the client. If it is public, use the commands below; otherwise, replace public with the correct name. Opening HTTP in the wrong zone does not open the intended interface.
sudo firewall-cmd --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --zone=public --query-service=http
sudo firewall-cmd --permanent --zone=public --query-service=http
curl --fail http://127.0.0.1/
The rule without --permanent affects the running state; the permanent rule is saved for subsequent starts. Here we configure both explicitly. From the client, use curl. to access the server’s actual private IP. Then reboot only the server VM and repeat the remote test.
sudo reboot
After reconnecting to the server, check its state, automatic startup, port, and context. An active service alone does not prove external connectivity; the test from the second VM is still necessary.
systemctl is-active httpd
systemctl is-enabled httpd
sudo ss -ltnp
sudo firewall-cmd --zone=public --query-service=http
getenforce
ls -lZ /var/www/html/index.html
curl --fail http://127.0.0.1/
SELinux: fix the cause instead of disabling protection
In your practice, separate Unix permissions, SELinux context, the listening port, and the firewall. These are different layers. A permissive chmod does not fix an incorrect context, and opening a firewall port does not make a service start listening on it.
To practice persistent labeling on a new lab directory, register the context and then apply it. This example does not change Apache’s DocumentRoot : it demonstrates only the SELinux part. If the rule already exists, inspect it before trying to add it again.
sudo dnf install -y policycoreutils-python-utils
sudo mkdir -p /srv/rhcsa-web
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/rhcsa-web(/.*)?"
sudo restorecon -Rv /srv/rhcsa-web
ls -Zd /srv/rhcsa-web
Storage: validate before rebooting
Try another scenario: create a logical volume on an empty virtual disk, mount it at /dados, persist the mount by UUID, and increase capacity without losing a test file. Success means the file remains readable, capacity increases, and the mount returns after reboot. Do not confuse extending a logical volume with growing its file system.
After editing /etc/fstab in the lab, use findmnt to check the configuration. The --verify option checks consistency; it does not perform a mount or guarantee that a remote NFS server is available. Also test mounting and accessing the file.
sudo findmnt --verify --verbose
lsblk -f
findmnt /dados
df -hT /dados
Study tricks that do not rely on memorization
- Keep an error notebook: symptom, hypothesis, diagnostic command, fix, and final test. Record why you made the mistake, not just the command that worked.
- Repeat the same scenario with different names, directories, and sizes. This reveals whether you understood the task or merely memorized the sequence.
- Practice local documentation: man, searching with / inside the manual,
--helpand/usr/share/doc. Knowing how to find an option is more useful than memorizing them all. - Separate configuration from validation. Write the expected test before the solution: command output, access by another user, or a response from another VM.
- Break one thing at a time in a disposable copy: a disabled service, an incorrect permission, or a missing rule. Diagnose without opening the recipe and restore the snapshot when finished.
- Use time limits to prioritize, not to guess. If an exercise blocks you, note the exact issue, move on in your mock exam, and return with a testable hypothesis.
Resources and preparation for exam day
The official path offers RH124 and RH134 to build the foundations, and RH199 for those already experienced in Linux administration. Use the skills assessment to identify gaps. Videos and courses help, but hands-on lab work needs a substantial place in your study.
If you choose a remote exam, read the current preparation guide and run compatibility checks in advance. Check identification, workspace, camera, audio, network, and the instructions for your booking. Do not leave equipment preparation until exam time or look for exam dumps.
Next Steps
Start with Linux fundamentals and compare RHCSA with other paths before investing. In the lab, the goal is always the same: perform the task, verify it, reboot, and verify again. A schedule cannot guarantee a pass; preparation improves when you can explain and reproduce the result.