Build the practice lab

The idea

The RHCSA is a hands-on, performance-based exam: you are given a live system and a list of tasks, and the result is judged by checking the system’s state. Red Hat describes it as real-world administration tasks on RHEL 10, with no internet access and no personal notes, but with the documentation that ships on the machine available. Confirm the exact format, duration and scoring on Red Hat’s exam page when you book, because they can change.

The consequences for how you practise:

• There is no multiple choice. Reading about a command does not count; running it correctly does.
• The machine is the answer sheet. Nothing you write in a text file is graded. A configuration that works now but vanishes at reboot scores zero.
• You work offline. Practise using man, --help and /usr/share/doc, never a browser.
• You need two machines. Some tasks touch a second host (NFS, SSH between nodes, a firewall rule tested from the other side, resetting a password).

The lab in this course

Machine	Address	Disks	Role
node1	192.168.122.50	vda system, vdb 2 GiB, vdc 1 GiB (unused)	Where almost all tasks are done
node2	192.168.122.51	vda system	The peer: NFS server, SSH target, second host for tests

Use any network that lets the machines see each other. Names and addresses are only a convention; keep yours consistent and change the tasks if you differ.

Operating system. RHEL 10 is free for individual developers with a Red Hat account. AlmaLinux 10 and Rocky Linux 10 are rebuilds with the same commands, packages, defaults and file paths for everything in the RHCSA objectives, and they work for practice (they do not replace the real exam environment). Where a command differs, such as Red Hat subscription steps, the lessons say so.

What to put in the baseline

1. Static IPv4 address, host names, /etc/hosts lines for both machines.
2. User alex (password Ex200!Lab) in the wheel group on both.
3. The installation ISO attached and mounted as a repository on both (lesson Configuring repositories), so installation works offline.
4. Packages used by the exam tasks: httpd, nfs-utils, autofs, tuned, chrony, policycoreutils-python-utils, setroubleshoot-server, flatpak, bind-utils, lvm2, at.
5. A snapshot named clean.

Take the snapshot after step 5 and before attempting any exam. Reverting restores the same starting point for every attempt, which is also what makes practising honest: the second time you do the exam you cannot rely on leftovers from the first.

Try it

A baseline checker

Run this on each machine. It prints one PASS or FAIL per fact the exam expects to be true at the start.

#!/bin/bash
# Prints PASS/FAIL for the starting state of the practice lab.
check() { if eval "$2" &>/dev/null; then echo "PASS  $1"; else echo "FAIL  $1"; fi; }

check "host name is a FQDN"          '[[ $(hostname) == *.lab.example ]]'
check "peer resolves"                'getent hosts node2 || getent hosts node1'
check "user alex exists, in wheel"   'id -nG alex | grep -qw wheel'
check "repositories configured"      '[ "$(dnf repolist -q | wc -l)" -ge 3 ]'
check "SELinux is enforcing"         '[ "$(getenforce)" = Enforcing ]'
check "firewalld is running"         'firewall-cmd --state'
check "chronyd installed"            'rpm -q chrony'
if [[ $(hostname) == node1* ]]; then
    check "spare disk vdb (2G)"      '[ "$(lsblk -bdno SIZE /dev/vdb)" -ge 2000000000 ]'
    check "spare disk vdc (1G)"      '[ "$(lsblk -bdno SIZE /dev/vdc)" -ge 1000000000 ]'
    check "vdb and vdc unused"       '! lsblk -n /dev/vdb /dev/vdc | grep -q part'
fi

sudo chmod 755 /usr/local/bin/lab-check.sh
lab-check.sh

PASS  host name is a FQDN
PASS  peer resolves
PASS  user alex exists, in wheel
PASS  repositories configured
PASS  SELinux is enforcing
PASS  firewalld is running
PASS  chronyd installed
PASS  spare disk vdb (2G)
PASS  spare disk vdc (1G)
PASS  vdb and vdc unused

Writing your own checks is an excellent habit: if you can express “task N is done” as a one-line test, you understand exactly what the grader looks at.

Working offline

sudo mandb
man -k autofs | head -3
man 5 autofs.conf | grep -i -A2 timeout
ls /usr/share/doc | head -5

autofs (5)           - Linux file system automounter configuration
auto.master (5)      - Master Map for automounter
autofs.conf (5)      - autofs configuration

The second command prints the lines of autofs.conf(5) that describe the timeout setting; the exact wording depends on the version.

The man -k search needs the manual-page index (mandb). Build it once in the baseline snapshot. Start from the section 5 page of a service for its configuration file syntax, section 8 for administrative commands, and the EXAMPLES section at the bottom, which often contains the exact line you need.

Going further

For more realistic rehearsal, remove any shell aliases and custom ~/.vimrc from the lab, because you will not have yours on the exam system. Practise working in the default editor (vim), and learn the minimal set of vi commands from the editing lesson. A second monitor is not available in some testing environments, so learn to switch terminals (tmux is not guaranteed to be installed). Automating the build with Kickstart, a cloud-init image or Ansible is a good project for later, but do the setup by hand once: it is practice for the exam, too.