RHCSA Practice ExamLesson 1 of 4
Exam briefing, rules and marking sheet
How the practice exam works: environment, time, scoring, allowed help, preparation on node2, and the sheet you mark yourself on.
lab-check.shvirsh snapshot-revertman -kfindmnt --verify
After this lesson you can
- State the rules, the time limit and the pass mark, and prepare both machines to the exam's starting state.
- Map the 23 tasks and their dependencies before starting the clock.
About this exam
This is a practice exam written for Linux Roads. It follows the EX200 objectives for RHEL 10 and the kinds of task that candidates commonly report (users and sudo, LVM and swap, SELinux for a web server, autofs home directories, rich firewall rules, key-based SSH, recovering the root password, scripts that take arguments, tuned profiles, and more). It is not Red Hat’s exam, does not contain real exam questions, and the time, number of tasks and scoring below are this practice’s own design. Check Red Hat’s exam page for the official format when you book.
Rules
| Item | Rule |
|---|---|
| Time | 3 hours (180 minutes) from the moment you read the first task |
| Score | 300 points: Part A 100, Part B 100, Part C 100 |
| Pass mark | 210 points (70 %) |
| Scoring | A task earns its points only if every check in its list passes. No partial credit inside a task |
| Machines | node1 (main), node2 (peer). Task text says where to work |
| Internet | None. No browser, no search, no AI assistant, no notes |
| Allowed help | man, --help, info, /usr/share/doc, and the commands on the machine |
| Persistence | Every change must survive a reboot. You will reboot at the end and the checks are run after it |
| Starting state | The clean snapshot plus the preparation below |
The suggested minutes of each task add up to about 160, leaving 20 minutes for reading, the final reboot and your own verification. If you are short of time, drop to tasks with higher points per minute first.
Fixed facts used by the tasks
| Item | Value |
|---|---|
| Domain | lab.example |
| node1 | node1.lab.example, 192.168.122.50/24, IPv6 fd00:122::50/64, gateway 192.168.122.1 |
| node2 | node2.lab.example, 192.168.122.51/24, IPv6 fd00:122::51/64 |
| Password for every new account | Ex200!Lab |
| Disks on node1 | /dev/vdb 2 GiB, /dev/vdc 1 GiB (both unused) |
| Installation media | Mounted at /mnt/dvd with BaseOS and AppStream (your lab’s repository) |
| Flatpak remote | URL and application ID are given in task B1; use your lab’s equivalent |
If your addresses differ, substitute them consistently.
Preparation on node2
Before the clock starts, make node2 able to play its roles. This is part of building the exam, not part of the exam.
# Time server for node1
printf 'allow 192.168.122.0/24\nlocal stratum 10\n' >> /etc/chrony.conf
systemctl enable --now chronyd && firewall-cmd --permanent --add-service=ntp && firewall-cmd --reload
# NFS export for home directories and for a shared directory
dnf install -y nfs-utils
mkdir -p /home/remoteusers/remoteuser1 /srv/share
echo 'hello from node2' > /srv/share/readme.txt
echo 'remote home' > /home/remoteusers/remoteuser1/notes.txt
useradd -d /home/remoteusers/remoteuser1 -u 4001 -M remoteuser1
chown -R remoteuser1:remoteuser1 /home/remoteusers/remoteuser1
printf '/srv/share 192.168.122.0/24(rw,sync)\n/home/remoteusers 192.168.122.0/24(rw,sync)\n' >> /etc/exports
systemctl enable --now nfs-server && exportfs -ra
firewall-cmd --permanent --add-service=nfs && firewall-cmd --reload
# Account for the SSH key task C4
useradd natasha && echo 'natasha:Ex200!Lab' | chpasswd
# Forgotten root password for task B5 (set to something you do not remember)
echo "root:$(head -c12 /dev/urandom | base64)" | chpasswd
On node1, create the matching user: useradd -u 4001 -M -d /rhome/remoteuser1 remoteuser1 (task C2 mounts that directory). Then run lab-check.sh again and take a new snapshot called exam-start. Revert to exam-start for every attempt.
The marking sheet
Print it or copy it into a file outside the lab. After the exam, mark each task Y only if all of its checks passed, add up the points, and compare.
| Part | Task | Topic | Pts | Min | Done |
|---|---|---|---|---|---|
| A | A1 | Users, groups, sudo | 18 | 10 | |
| A | A2 | Password policy and umask | 12 | 6 | |
| A | A3 | Shared directory | 12 | 6 | |
| A | A4 | Cron job and systemd timer | 16 | 8 | |
| A | A5 | Shell script | 18 | 10 | |
| A | A6 | Archives, find, grep | 14 | 8 | |
| A | A7 | Time client | 10 | 5 | |
| B | B1 | Repositories, packages, Flatpak | 14 | 8 | |
| B | B2 | Target, services, journal | 12 | 6 | |
| B | B3 | tuned and priority | 10 | 5 | |
| B | B4 | Runaway process and boot loader | 10 | 6 | |
| B | B5 | Reset root password on node2 | 14 | 8 | |
| B | B6 | LVM and XFS | 16 | 8 | |
| B | B7 | Extend the volume | 8 | 4 | |
| B | B8 | Swap | 8 | 4 | |
| B | B9 | Labelled file systems | 8 | 5 | |
| C | C1 | Network and names | 14 | 7 | |
| C | C2 | NFS and autofs | 16 | 8 | |
| C | C3 | Firewall | 14 | 7 | |
| C | C4 | SSH keys and sshd | 12 | 6 | |
| C | C5 | SELinux web server | 20 | 10 | |
| C | C6 | Troubleshooting | 14 | 8 | |
| C | C7 | Persistence after reboot | 10 | 8 |
How to read your result:
- 210 or more: you are in pass territory. Look at the missed tasks for gaps.
- 150 to 209: close. Almost always a few persistence mistakes (see the Exam Technique skill) and one or two areas that need drilling.
- Under 150: go back to the skill for each missed objective and repeat the matching exercises, then retake after a week.
How the checks work
Each task ends with a checks list in its “verify” box: commands and what they should print. Run them yourself, in a different order from how you configured, and after the final reboot. Task C7 deliberately grades persistence of earlier tasks, so a setting that vanishes at reboot costs you twice: once on its own task, and again in C7.
Dependency map
C1 names/network --> C2 NFS/autofs, C3 firewall, C4 SSH, A7 time (need node2 by name)
B1 repositories --> every task that installs a package (A4 timer needs none; B2, B3, C2, C5 do)
A1 users --> A2, A3, A4(natasha), A5(sudo), C2(autofs home), C4(SSH key), C6
B6 LVM --> B7 extend, C5 (web content on the new LV is optional)
B5 node2 reboot --> start early, ignore until it returns; C2 and C4 need node2 up again
C7 --> last
Start the clock when you are ready to read Part A.
Practice
0 of 2 done
Do these on your own system. They get harder. Check each result, then tick it off.
- Warm-up
Prepare the lab and read every task
Revert both machines to the
cleansnapshot, runlab-check.shon each (all PASS), prepare node2 as described below, then read all 23 tasks in Parts A to C without typing any answer. Write a one-line plan: the order, the three tasks you will do first, and the two you will keep for last.Check your result
lab-check.shprints onlyPASSon both nodes,systemctl is-active chronyd nfs-servershowsactiveon node2, and your plan lists task IDs in order.Hint
Start the clock only after the plan is written. Reading time is part of the 3 hours.
Solution
Order: C1 network names -> B1 repos/packages -> A1 users -> A2 -> A3 -> A4 -> A5 -> A6 -> A7 -> B5 (node2 reboot, start early) -> B2 -> B3 -> B4 -> B6 -> B7 -> B8 -> B9 -> C2 -> C3 -> C4 -> C5 -> C6 -> C7 (final reboot pass) First three: C1, B1, A1. Last two: C5 (SELinux web), C6 (troubleshooting). - Challenge
Write your three-hour budget
Using the marking sheet, write a budget for your own attempt: time for reading, a per-task limit for each part, the rule that makes you skip a task, and 20 minutes reserved for the final reboot and checks. Then name the single task whose failure would hurt most (many dependants) and say how you would protect it.
Check your result
Your budget adds up to 180 minutes or less, has a skip rule stated as a number of minutes, and names a task from the dependency map.
Hint
Points per minute: A1 is 1.8, C5 is 2.0, B7 is 2.0, C7 is 1.25. Do the high-value, low-risk ones first.
Solution
Reading 10 | Part A 55 | Part B 55 | Part C 40 | Reserve 20 = 180 Skip rule: 12 minutes over the suggested time on one task -> mark it, move on. Most protected: C1 (names and network); do it first and verify with ping before moving on.