![\"Mascote](\"\/wp-content\/uploads\/2026\/09\/certificacao-rhcsa-v4.webp\")
<\/p>\n<\/p>\n
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 \u2014 not just recognize commands in a textbook. This guide brings together a study path, original exercises, and a validation routine for EX200.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
hostnamectl\ncat \/etc\/redhat-release\nlsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS\nip -br address\n<\/code><\/pre>\nA six-stage study plan<\/h2>\n
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.<\/p>\n
\n- Stage 1 \u2014 terminal: files, permissions, links, redirection,
grep<\/code>, archives, and small scripts with arguments.<\/li>\n- Stage 2 \u2014 operations: users, groups, privileges, processes, logs, services, and boot recovery at the VM console.<\/li>\n
- Stage 3 \u2014 storage: empty disks, logical volumes, file systems, swap, and persistent mounting.<\/li>\n
- Stage 4 \u2014 integration: connectivity between VMs, name resolution, firewall, SSH, NFS, and autofs.<\/li>\n
- Stage 5 \u2014 maintenance and security: repositories, scheduling, SELinux, and troubleshooting without disabling security controls.<\/li>\n
- Stage 6 \u2014 your own mock exam: combine earlier tasks, time yourself, and validate everything after rebooting.<\/li>\n<\/ul>\n
Integrated exercise: a web service that survives a reboot<\/h2>\n
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<\/code>. 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.<\/p>\nsudo dnf install -y httpd firewalld\nprintf \"RHCSA lab OK\\n\" | sudo tee \/var\/www\/html\/index.html\nsudo chmod 0644 \/var\/www\/html\/index.html\nsudo restorecon -v \/var\/www\/html\/index.html\nsudo systemctl enable --now firewalld\nsudo systemctl enable --now httpd\nsudo firewall-cmd --get-active-zones\n<\/code><\/pre>\nIdentify 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.<\/p>\n
sudo firewall-cmd --zone=public --add-service=http\nsudo firewall-cmd --permanent --zone=public --add-service=http\nsudo firewall-cmd --zone=public --query-service=http\nsudo firewall-cmd --permanent --zone=public --query-service=http\ncurl --fail http:\/\/127.0.0.1\/\n<\/code><\/pre>\nThe rule without --permanent<\/code> affects the running state; the permanent rule is saved for subsequent starts. Here we configure both explicitly. From the client, use curl<\/code>. to access the server\u2019s actual private IP. Then reboot only the server VM and repeat the remote test.<\/p>\nsudo reboot\n<\/code><\/pre>\nAfter 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.<\/p>\n
systemctl is-active httpd\nsystemctl is-enabled httpd\nsudo ss -ltnp\nsudo firewall-cmd --zone=public --query-service=http\ngetenforce\nls -lZ \/var\/www\/html\/index.html\ncurl --fail http:\/\/127.0.0.1\/\n<\/code><\/pre>\n\n- RHEL 10: Apache HTTP Server documentation<\/a><\/li>\n
- firewalld: runtime and permanent rules<\/a><\/li>\n<\/ul>\n
SELinux: fix the cause instead of disabling protection<\/h2>\n
In your practice, separate Unix permissions, SELinux context, the listening port, and the firewall. These are different layers. A permissive chmod<\/code> does not fix an incorrect context, and opening a firewall port does not make a service start listening on it.<\/p>\nTo practice persistent labeling on a new lab directory, register the context and then apply it. This example does not change Apache\u2019s DocumentRoot<\/code> : it demonstrates only the SELinux part. If the rule already exists, inspect it before trying to add it again.<\/p>\nsudo dnf install -y policycoreutils-python-utils\nsudo mkdir -p \/srv\/rhcsa-web\nsudo semanage fcontext -a -t httpd_sys_content_t \"\/srv\/rhcsa-web(\/.*)?\"\nsudo restorecon -Rv \/srv\/rhcsa-web\nls -Zd \/srv\/rhcsa-web\n<\/code><\/pre>\n\n- RHEL 10: contexts, semanage, and restorecon<\/a><\/li>\n<\/ul>\n
Storage: validate before rebooting<\/h2>\n
Try another scenario: create a logical volume on an empty virtual disk, mount it at \/dados<\/code>, 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.<\/p>\nAfter editing \/etc\/fstab<\/code> in the lab, use findmnt<\/code> to check the configuration. The --verify<\/code> 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.<\/p>\nsudo findmnt --verify --verbose\nlsblk -f\nfindmnt \/dados\ndf -hT \/dados\n<\/code><\/pre>\n\n- findmnt manual: verifying configuration<\/a><\/li>\n<\/ul>\n
Study tricks that do not rely on memorization<\/h2>\n\n- Keep an error notebook: symptom, hypothesis, diagnostic command, fix, and final test. Record why you made the mistake, not just the command that worked.<\/li>\n
- Repeat the same scenario with different names, directories, and sizes. This reveals whether you understood the task or merely memorized the sequence.<\/li>\n
- Practice local documentation: man, searching with \/ inside the manual,
--help<\/code> and \/usr\/share\/doc<\/code>. Knowing how to find an option is more useful than memorizing them all.<\/li>\n- Separate configuration from validation. Write the expected test before the solution: command output, access by another user, or a response from another VM.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n<\/ul>\n
Resources and preparation for exam day<\/h2>\n
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.<\/p>\n
\n- Official courses and skills assessment<\/a><\/li>\n<\/ul>\n
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.<\/p>\n
\n- Official remote exam preparation guide<\/a><\/li>\n<\/ul>\n
Next Steps<\/h2>\n
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.<\/p>\n
\n- Linux fundamentals: Toca do Tux course<\/a><\/li>\n
- Explore LPIC-1<\/a><\/li>\n
- Explore LFCS<\/a><\/li>\n
- Explore CompTIA Linux+<\/a><\/li>\n
- After the fundamentals: getting started with Ansible<\/a><\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"
Prepare for RHCSA on RHEL 10: official resources, a study plan, a reboot-tested lab, SELinux, firewall, and practical EX200 study tips.<\/p>","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13,2],"tags":[366,364,4,368,367],"class_list":["post-765","post","type-post","status-publish","format-standard","hentry","category-cursos","category-linux","tag-carreira","tag-certificacao","tag-linux","tag-red-hat","tag-rhcsa"],"_links":{"self":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/765","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/comments?post=765"}],"version-history":[{"count":5,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/765\/revisions"}],"predecessor-version":[{"id":1582,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/posts\/765\/revisions\/1582"}],"wp:attachment":[{"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/media?parent=765"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/categories?post=765"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/en\/wp-json\/wp\/v2\/tags?post=765"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}