Learn › RHCSA (EX200) › Exam Orientation + Essential Tools
exam-info - a hands-on Linux lab on a real virtual machine.
Orient to the current performance-based EX200 on RHEL 10: real machines, graded on end state only, single total score, no internet. Drill the two exam lifelines, reading system identity and finding a tool by keyword with man -k.
Picture the moment the exam starts. A terminal, a blinking cursor, and a list of tasks. No browser bookmark bar. No second monitor with your notes. No phone. If you do not know how to spell an option, there is exactly one place on Earth you are allowed to look, and it is already installed on the machine in front of you.
That single fact shapes everything about how you prepare. The RHCSA exam, code name EX200, does not test whether you memorised flags. It tests whether you can make a real Red Hat system reach a required state, using only what ships on the disk. This lesson is your map of that room before you ever walk into it.
The black boxes below are a practice terminal: a safe sandbox that only checks the one command each step teaches. Nothing you type here can break anything. Later in the track you get a real RHEL 10 machine to run these on for real.
The EX200 is a performance-based exam. Performance-based means there are no multiple-choice questions and nothing to write down. You are handed live machines and a list of tasks, and you do the tasks. Think driving test, not written test. You do not describe how to parallel park; you park.
The exam runs about three hours. You get real Red Hat Enterprise Linux systems, and this track mirrors them with two hosts named servera and serverb. servera is your main workstation and boots on its own; serverb is a second system some tasks send you to. There is no graphical desktop. Everything happens at the command line.
This lesson serves the very first EX200 objective: *understand and use essential tools for handling files, directories, command-line environments, and documentation.* Everything else in the module builds on the two moves you drill here.
Here is the rule that changes how you work. Every task is graded by an automated script that runs after you leave, and it checks one thing only: the end state of the machine. End state means the final condition of the system, not the path you took to get there.
If a task says create a user with a specific ID, the grader checks that the user exists with that ID. It does not read your command history. It does not care whether you used a menu, an editor, or three tries. Any method that produces the correct end state scores the same. Your whole score comes back as a single total number, with no per-task breakdown. A task you half-finished simply does not count.
This is freeing. You are never marked down for a clumsy route. Reach the required end state by whatever path you can remember under pressure, and the points are yours.
The first thing any careful engineer does on an unfamiliar system is ask it what it is. On the exam you will hop between servera and serverb, and running the wrong task on the wrong host is a classic way to lose points. So the very first skill is reading system identity.
Start with the release file. Red Hat systems keep their exact version in a small text file under /etc. On this track's AlmaLinux 10 machines that file is /etc/almalinux-release. Reading it tells you the distribution and version in one line. Run it now:
cat /etc/almalinux-release
prompt: student@servera:~$ answer: cat /etc/almalinux-release output: AlmaLinux release 10.2 (Lavender Lion) hint: The command that prints a file is cat, followed by the path /etc/almalinux-release.
The exact version string is this machine's. Yours may read a later point release, and on a true Red Hat exam host the file is /etc/redhat-release instead. The MOVE is what matters: one cat of the release file tells you what you are standing on.
Sometimes you need the running kernel version, the core of the operating system that talks to the hardware. Several tasks and a few troubleshooting moments hinge on it. The tool is uname, short for unix name, and the -r flag asks for just the kernel release string.
You commit before you run: expect a long version number with dots and a Red Hat style .el10 marker baked in, telling you it is an Enterprise Linux 10 kernel. Run it and read that marker:
uname -r
prompt: student@servera:~$ answer: uname -r output: 6.12.0-211.7.3.el10_2.x86_64 hint: The command is uname, and the flag for the kernel release is a single -r.
That precise build number belongs to the capture machine and will differ on yours. What never changes is the shape: a version, a Red Hat build string with .el10 in it, and the CPU architecture. You are reading the shape, not memorising the digits.
There is a richer identity command that answers who am I and what am I running on together: hostnamectl. Run bare, it prints the machine's static hostname, the fact that it is a KVM virtual machine, the operating system, and the kernel, all at once. On the exam this instantly confirms whether you are on servera or serverb before you touch anything.
hostnamectl
prompt: student@servera:~$ answer: hostnamectl output: Static hostname: servera.lab.example.net Virtualization: kvm Operating System: AlmaLinux 10.2 (Lavender Lion) Kernel: Linux 6.12.0-211.7.3.el10_2.x86_64 hint: One word, no flags. It is hostname with ctl on the end: hostnamectl.
The hostname line here reads servera.lab.example.net. On serverb it would read serverb, and on your own machine something else again. Read the line, do not assume it.
Now the single most valuable exam skill, because it turns forgetting into a ten-second lookup. With no internet, your only documentation is what is installed: the man pages (the manual), and the files under /usr/share/doc. On RHEL 10 the info reader is not even installed by default, so man is the lifeline.
The trick most people miss is searching man pages by keyword. When you know WHAT you need but not the command name, man -k <keyword> (the same tool is also called apropos) searches every manual page's one-line description and lists the matches. Say you need something about passwords. Ask the manual:
man -k passwd
prompt: student@servera:~$ answer: man -k passwd output: chgpasswd (8) - update group passwords in batch mode chpasswd (8) - update passwords in batch mode fgetpwent_r (3) - get passwd file entry reentrantly getpwent_r (3) - get passwd file entry reentrantly hint: The manual search is man, then the -k flag for keyword, then the word passwd.
The full list is longer, and its exact order and section numbers differ per machine as packages change. The number in parentheses is the manual section: 1 is user commands, 5 is file formats, 8 is admin commands. When two entries share a name, the section tells you which one you want.
man -k casts a wide net. When you already have the command name and just want to confirm what it does, whatis prints the single description line for it, no scrolling. It is man -k aimed at exactly one name. Confirm what ls is:
whatis ls
prompt: student@servera:~$ answer: whatis ls output: ls (1) - list directory contents hint: The command that prints one description line is whatis, followed by the name ls.
Scaffolding off. No command is shown this time. You have every piece you need from the identity moves above.
You have just connected to a machine and you are not sure whether it is servera or serverb. You want the fullest single-command answer: the static hostname, the operating system, and the kernel, all in one printout, without stringing several commands together.
prompt: student@servera:~$ answer: hostnamectl output: Static hostname: servera.lab.example.net Virtualization: kvm Operating System: AlmaLinux 10.2 (Lavender Lion) Kernel: Linux 6.12.0-211.7.3.el10_2.x86_64 hint: You want hostname AND os AND kernel in one shot. Which single identity command prints all of them at once?
One word did it. hostnamectl bundled the hostname, the virtualization type, the OS, and the kernel into a single answer. That is why it beats running cat, uname, and a hostname command separately when the clock is ticking. Your hostname line will read whatever host you are actually on, but the shape of the answer is identical everywhere.
You earned this cheat sheet. Every row is something you just ran, or a rule you now understand about the exam itself:
And the exam rules that decide your score, learned once:
man, /usr/share/doc, and (where present) info.Two survival rules that lose people points every sitting. First, reboot the machines several times DURING the exam, not just at the end. That catches anything that breaks on boot while you still have time to fix it. All your work must survive a reboot to count. Second, SELinux must end enforcing. If you ever set it permissive to get past something, put it back to enforcing before you finish. Otherwise a whole class of tasks silently fails the grader.
You now know the room. You can read any machine's identity three ways, you can find a tool you half-remember with man -k, and you understand the one rule that matters: reach the required end state, by any path, and make it survive a reboot.
The essential-tools module ends with the module mission on a real RHEL 10 machine, the essential-tools capstone. That capstone is a full servera-style host that boots just for you. It carries the same man pages and the same identity commands you drilled here. It hands you objectives and shows no commands: you read the goal, recall the move, and type it yourself. That recall is what makes it stick on exam day.
Finish the other essential-tools lessons, then go orient yourself on a real machine.
Practice The EX200 Exam Environment in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.