RHCSA Exam Preparation Checklist

A candidate who has watched every video course and highlighted every chapter can still fail EX200 badly, because the Red Hat Certified System Administrator (RHCSA) exam never asks what you know — it puts live Red Hat Enterprise Linux (RHEL) systems in front of you and marks whatever state those systems are in when time runs out. There is not a single multiple-choice question on the paper, because there is no paper. So "am I ready?" cannot be answered by how much you have read. It is answered by whether you can, for example, extend a logical volume from memory, under a clock, on a machine you have never touched before. Every item in this checklist is written to test that kind of readiness and nothing softer.

The right moment to run it is the final two to four weeks before your booked date, once your main study phase is behind you. Candidates still building that foundation should begin with the step-by-step guide on how to prepare for the RHCSA, which covers lab setup and objective-by-objective study. Here the studying is assumed; the only question left is whether you can prove it at a keyboard.

How to grade yourself honestly

Every item below is a task, not a topic. The standard for ticking a box is strict:

1. You performed the task on a fresh lab system — not one you had pre-configured.
2. You did it without notes, search engines or your shell history.
3. Your change survived a reboot. In a performance-based exam, configuration that does not persist is configuration that does not exist.
4. You could verify your own work — you know the command that proves the task succeeded, not just the command that attempts it.

Anything you cannot tick under those conditions is a lab session, not a re-reading session. One important boundary note: Red Hat revises exam objectives between RHEL versions, and as of August 2026 Red Hat's page states EX200 is based on RHEL 10 — so before your final review, pull the current objectives list from the official EX200 page and reconcile it against this checklist. Where Red Hat's list names something this article does not, the official list wins.

Core skills you must demonstrate live

Everyday command-line operation

• Navigate, create, copy, move, link and delete files and directories fluently, including with globbing.
• Find files by name, size, ownership and permissions, and act on the results.
• Use input/output redirection and pipes to combine tools.
• Search file contents with grep and regular expressions.
• Read and edit files in a terminal editor quickly enough that editing is never the bottleneck.
• Archive and compress files, and unpack archives you are given.

Users, groups and permissions

• Create, modify and delete local users and groups, including password ageing settings.
• Configure standard permissions and default permission behaviour, and explain the effect of each change before you make it.
• Apply special permissions and access control lists where a task calls for finer-grained control.
• Configure administrative privilege so a named user can perform elevated tasks.

Storage management

• Partition a disk, create and mount file systems, and make every mount persistent across reboots.
• Build and extend logical volumes without destroying the data on them — resizing under pressure is a classic exam-day stumble, so drill it until it is boring.
• Configure swap space and verify the system is using it.
• Mount network storage and make that persistent too.

System operation with systemd

• Start, stop, enable, disable and mask services, and interpret a failing service's status output.
• Set the default boot target and boot into a non-default target.
• Recover access to a system when you cannot log in — practise the root-password recovery workflow until you can do it calmly, because panicking at the console burns exam minutes fast.
• Schedule tasks to run at fixed times, both one-off and recurring.

Networking

• Configure IPv4 and IPv6 addressing, hostname and name resolution on a RHEL system, persistently.
• Verify connectivity and diagnose the difference between an addressing problem, a resolution problem and a firewall problem.
• Manage the system firewall: list the active configuration, permit a service, and make the change permanent.

SELinux — do not skip this block

• Report the current SELinux mode and switch between modes.
• Restore default file contexts and set a persistent context on a non-standard location.
• List and set SELinux booleans.
• Diagnose an SELinux denial: when a service fails for no visible reason, checking SELinux should be reflex, not afterthought. Candidates who treat SELinux as optional walk into the single most commonly mishandled area of the exam.

Software and system maintenance

• Install, update and remove packages, and work with repositories, including configuring the system to use a repository you are pointed at.
• Inspect and manage the boot loader configuration at a basic level.
• Read system logs and journals to answer "what went wrong and when".
• Set the system time and time synchronisation.

Exam-environment realities to rehearse

Knowing the tasks is half the checklist; the other half is knowing the room. Three conditions are worth rehearsing deliberately.

Documentation, but no internet. Red Hat's exam page confirms there is no internet access, but the product documentation installed in the exam environment is available. That is a genuine lifeline — if you practise using man pages and in-system docs during your labs. If your lab habit is a browser tab, you are training a skill you will not be allowed to use. For your last two weeks, ban the browser and force every lookup through the machine itself.

The clock. Red Hat does not state the exam duration prominently on its public page, and third-party reports conflict, so plan for "about three hours" without treating that as official — and more importantly, train pace rather than a number. In timed lab runs, note which task types eat your minutes. A full-length, timed RHCSA practice exam run under the same no-browser rule is the cleanest way to benchmark pace and expose weak domains while there is still time to fix them — analyse which task families you fumbled rather than memorising anything.

Scoring is on outcomes. Widely reported figures put the pass mark at 210 out of 300 (70%) — Red Hat itself does not publish this prominently, so treat it as unofficial. The practical implication is the same regardless: partial, working configurations earn more than perfect intentions, so when a task fights you, secure what works, persist it, and move on.