RHCSA EX200 Self-Study Curriculum and Hands-On Lab Manual

Gold-standard home-study roadmap for the Red Hat Certified System Administrator (RHCSA) exam EX200 Research cut-off: 2026-10-06 Primary authority: current official Red Hat EX200 page, Red Hat Certification Program Guide, Red Hat Training Policies, and RHEL 10 documentation. IMPORTANT: Red Hat can change objectives and policies. Re-check the official EX200 page immediately before booking and again during the final week of study.

How to use this guide

This guide is designed for a learner studying at home without requiring Red Hat classroom training. The learning loop is: Learn -> Configure -> Break -> Troubleshoot -> Rebuild -> Repeat -> Time yourself. The exam-objective wording in this guide is deliberately paraphrased. This avoids reproducing Red Hat material verbatim while preserving the current scope. The current official EX200 page is the final authority. Legend: REQUIRED means the skill is represented by the current official EX200 objectives. SUPPORTING means it helps perform or troubleshoot a required skill but is not separately listed as an objective. OUTSIDE CURRENT SCOPE means it should not be treated as an EX200 requirement unless Red Hat later changes the objectives.

Part 1 – RHCSA / EX200 Overview

1. What is RHCSA?

Red Hat Certified System Administrator (RHCSA) is the certification awarded when a candidate passes EX200. It validates practical administration skills on Red Hat Enterprise Linux. In the current 2026 Red Hat framework, RHCSA is a foundational credential for the Enterprise Linux and Ansible certification tracks. At RHCSA level you should be able to work from the command line, administer users and groups, manage software, services, processes, storage, file systems, basic networking, firewalls, SSH, SELinux, scheduling, system logs, time configuration, and simple shell automation. The current exam also explicitly includes RPM and Flatpak repository/package tasks, GPT storage, systemd timers, tuning profiles, and persistent system journals. RHCSA does not by itself certify advanced Ansible automation, OpenShift administration, Kubernetes administration, advanced Linux troubleshooting at the EX342 level, or advanced network/storage engineering.

2. What is EX200?

Do not confuse the certification, the exam, and training: RHCSA is the credential; EX200 is the assessment; RH124/RH134/RH199 are preparation options; this document is a self-study path.

Part 2 – Current EX200 Objective Map

The following matrix covers every skill currently listed on the official EX200 objective page, paraphrased and assigned an internal ID for study tracking.

Objective interpretation rules

1. Do not add an old RHCSA topic merely because it appears in RHEL 8/9 study material. 2. Supporting commands may be taught when they help complete or verify a current objective. 3. Containers/Podman are not a separate objective on the current EX200 objective list reviewed here; treat them as background unless Red Hat changes the page. 4. Persistence after reboot is a cross-cutting requirement, so every persistent configuration lab ends with a reboot test.

Part 3 – Complete Curriculum From Beginner to Exam Ready

Module 1 – Command Line, Documentation, Files, Text, Links and Archives

1. Learning objectives

• Use the shell confidently
• Redirect data and build pipelines
• Use grep and basic regular expressions
• Manage files/directories/links
• Archive and compress files
• Use man/info/product documentation

2. Concepts

Practice creating a workspace tree, copying and moving content, making hard/symbolic links, filtering logs with grep, redirecting stdout/stderr separately, and creating/restoring compressed tar archives. Use man pages before searching the web so local documentation becomes normal.

3. Core commands

pwd, ls, cd, touch, mkdir, cp, mv, rm, ln, cat, less, head, tail, grep, find, tar, gzip, gunzip, bzip2, bunzip2, man, info

4. Configuration files/directories

• /usr/share/doc
• ~/.bash_history

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Build /root/rhcsa-lab with data, logs, backups, and links.
• Lab 2: Create a tar.gz and tar.bz2 backup and restore each to a clean directory.
• Lab 3: Use grep plus redirection to produce a report from a log file.
• Lab 4: Break a symbolic link and diagnose why it fails.
• Lab 5: Find a command option only from man/info.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Wrong path
• Permission denied
• Accidental overwrite due to > versus >>
• Broken symbolic link
• Archive extracted to unexpected path

9. Exam-style practice tasks

• Create a compressed archive from a supplied directory and restore only one requested file.
• Create a report containing matching lines and errors in separate output files.

10. Knowledge check

• Can I work without a GUI?
• Can I distinguish stdout from stderr?
• Can I explain hard versus symbolic links?

11. Completion criteria

Move on only when common file operations, redirection, grep, tar, and local documentation feel automatic.

Module 2 – Users, Groups, Passwords, Privileged Access and Default Permissions

1. Learning objectives

• Administer local users/groups
• Set and inspect password aging
• Configure supplementary groups
• Use sudo safely
• Manage umask/default permissions

2. Concepts

Create users with explicit UID, shell, home, and group settings; modify memberships; expire and unexpire passwords; create a least-privilege sudo rule in /etc/sudoers.d and validate it with visudo. Set umask temporarily and through an appropriate shell startup file when persistence is required.

3. Core commands

useradd, usermod, userdel, groupadd, groupmod, groupdel, id, passwd, chage, su, sudo, visudo, umask, chown, chmod

4. Configuration files/directories

• /etc/passwd
• /etc/shadow
• /etc/group
• /etc/gshadow
• /etc/sudoers
• /etc/sudoers.d/

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Create three users and two groups with controlled memberships.
• Lab 2: Configure password aging and verify with chage -l.
• Lab 3: Grant one administrative command through sudoers.d.
• Lab 4: Set a restrictive umask and prove resulting modes.
• Lab 5: Break ownership and permissions on a shared directory, then fix them.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• User cannot log in
• Supplementary group not applied to current session
• Malformed sudoers file
• Wrong ownership
• Unexpected file mode caused by umask

9. Exam-style practice tasks

• Create an account with stated UID/group/password-aging requirements.
• Configure privileged access without giving everyone full root access.

10. Knowledge check

• Can I tell primary from supplementary group?
• Can I read /etc/passwd fields?
• Can I calculate permissions after umask?

11. Completion criteria

Move on when user/group/sudo/permission tasks can be completed and verified quickly from CLI.

Module 3 – SSH and Secure Remote Administration

1. Learning objectives

• Connect with SSH
• Create and deploy SSH keys
• Transfer files securely
• Troubleshoot client/server access

2. Concepts

Build key-based trust from servera to serverb. Confirm correct ownership and modes under ~/.ssh. Verify sshd status and listening sockets. Transfer files with scp or sftp and validate hashes or sizes.

3. Core commands

ssh, ssh-keygen, ssh-copy-id, scp, sftp, ss, systemctl, journalctl

4. Configuration files/directories

• /etc/ssh/sshd_config
• ~/.ssh/authorized_keys
• ~/.ssh/config

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Generate an SSH key pair.
• Lab 2: Deploy the key and log in without password.
• Lab 3: Copy a backup to the second VM.
• Lab 4: Break authorized_keys permissions and troubleshoot.
• Lab 5: Enable sshd at boot and verify after reboot.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Connection refused
• No route to host
• Permission denied (publickey,password)
• Bad .ssh permissions
• Firewall issue

9. Exam-style practice tasks

• Configure key-based login for a named account and transfer a file to a specified path.

10. Knowledge check

• What is client-side versus server-side?
• Which file contains public keys?
• How do I prove sshd listens?

11. Completion criteria

Move on when you can distinguish network, daemon, firewall, authentication, and file-permission SSH failures.

Module 4 – Software Management: RPM, DNF, Repositories and Flatpak

1. Learning objectives

• Configure RPM repos
• Install/remove/query packages
• Install/update from remote or local sources
• Configure Flatpak remotes
• Install/remove Flatpak apps

2. Concepts

Create or use a valid DNF repository, verify it, install and remove packages, query ownership with rpm, install a local RPM with dnf, and inspect transaction history. Separately add/list/remove Flatpak remotes and applications in a lab where a suitable remote is available.

3. Core commands

dnf, rpm, subscription-manager, flatpak

4. Configuration files/directories

• /etc/yum.repos.d/*.repo

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Build a local/remote DNF repo definition.
• Lab 2: Install and remove a package.
• Lab 3: Install a local RPM with dependency handling.
• Lab 4: Disable a broken repo and recover DNF.
• Lab 5: Add a Flatpak remote and install/remove an app.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Repo metadata unreachable
• Wrong baseurl
• GPG/repository configuration problem
• Package dependency issue
• Flatpak remote missing

9. Exam-style practice tasks

• Configure a supplied repository and install named packages.
• Configure a Flatpak remote and remove an installed application.

10. Knowledge check

• When should I use dnf instead of rpm -i?
• How do I list enabled repos?
• How do I list Flatpak remotes?

11. Completion criteria

Move on when RPM and Flatpak tasks can be completed without confusing the two packaging systems.

Module 5 – Simple Bash Scripting for EX200

1. Learning objectives

• Use if/test/[ ]
• Use for loops
• Read positional parameters
• Use command substitution
• Return useful exit status

2. Concepts

Write very small administration scripts. Keep them readable and predictable. Focus on conditionals, loops, arguments, and command substitution rather than advanced Bash programming.

3. Core commands

bash, test, printf, echo

4. Configuration files/directories

• #!/bin/bash

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Script that verifies a file exists.
• Lab 2: Loop through usernames and report id output.
• Lab 3: Script taking a directory as $1 and reporting disk usage.
• Lab 4: Capture hostname/date with command substitution.
• Lab 5: Make scripts executable and test good/bad input.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Quoting errors
• Missing spaces around [ ]
• Unquoted positional parameters
• Wrong exit status
• Script lacks execute bit

9. Exam-style practice tasks

• Write a script that checks multiple paths supplied on the command line and prints a status for each.

10. Knowledge check

• Why quote “$1”?
• What does $? mean?
• What is the difference between $(cmd)and$(cmd)and(( ))?

11. Completion criteria

Move on when you can write small scripts from memory and debug syntax errors with bash -n.

Module 6 – Processes, systemd Services, Targets, Boot, Tuning and Logs

1. Learning objectives

• Manage processes
• Adjust nice priority
• Manage services
• Select targets/default target
• Recover through boot interruption
• Use tuning profiles
• Read/persist journals

2. Concepts

Practice service lifecycle and enablement, process identification/termination, nice/renice, boot targets, default target, basic bootloader changes through supported tooling, tuning profile selection, and journal filtering. Configure persistent journal storage and verify after reboot.

3. Core commands

ps, top, pgrep, kill, pkill, nice, renice, systemctl, journalctl, tuned-adm, reboot, shutdown, grubby

4. Configuration files/directories

• /etc/systemd/system/
• /etc/systemd/journald.conf
• /var/log/journal/
• /etc/default/grub

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Find and terminate a resource-heavy process.
• Lab 2: Change scheduling priority.
• Lab 3: Enable/start a network service and verify boot persistence.
• Lab 4: Change default target and revert.
• Lab 5: Make journal persistent and prove old-boot records survive.
• Lab 6: Select a tuning profile and verify.
• Lab 7: Perform a controlled boot-recovery lab on a disposable VM snapshot.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Service fails due to config
• Unit disabled after reboot
• Target changed unintentionally
• Journal not persistent
• Process restarts because a service manager owns it
• Wrong bootloader setting

9. Exam-style practice tasks

• Enable a service at boot, verify its logs, then prove persistence after reboot.
• Set a requested target and tuning profile.

10. Knowledge check

• Can I distinguish start from enable?
• Can I filter journal by unit/boot/time?
• Can I safely recover after a bad boot setting?

11. Completion criteria

Move on when service/process/boot/log tasks can be performed and rolled back safely.

Module 7 – Local Storage: GPT, LVM and Swap

1. Learning objectives

• Create/delete GPT partitions
• Build PV/VG/LV
• Grow storage non-destructively
• Configure swap
• Identify devices safely

2. Concepts

Attach extra virtual disks to practice repeatedly. Identify the correct disk before writing. Create GPT partitions, LVM PVs/VGs/LVs, swap, and persistent entries. Practice extending rather than recreating resources.

3. Core commands

lsblk, blkid, fdisk, parted, partprobe, pvcreate, pvs, vgcreate, vgextend, vgs, lvcreate, lvextend, lvs, lvremove, mkswap, swapon, swapoff

4. Configuration files/directories

• /etc/fstab
• /dev/mapper/

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Create GPT partitions on a blank disk.
• Lab 2: Create PV/VG/LV and display each layer.
• Lab 3: Create and persist swap.
• Lab 4: Extend a VG using a second PV.
• Lab 5: Extend an LV without data loss.
• Lab 6: Break an fstab storage entry and recover from snapshot/console.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Wrong disk selected
• PV already in use
• Insufficient VG free extents
• Swap not active after reboot
• Bad fstab identifier
• Partition table not re-read

9. Exam-style practice tasks

• Create a requested LV size and mount it persistently by UUID.
• Add swap non-destructively and prove it survives reboot.

10. Knowledge check

• Can I explain disk->partition->PV->VG->LV->filesystem?
• Can I distinguish UUID from device name?
• Can I extend without recreating?

11. Completion criteria

Move on only after repeated rebuilds from blank virtual disks with zero data-loss mistakes.

Module 8 – File Systems, Persistent Mounts, NFS and autofs

1. Learning objectives

• Create VFAT/ext4/XFS
• Mount by UUID/label
• Use /etc/fstab
• Mount NFS
• Configure autofs
• Extend logical volumes and file systems
• Troubleshoot permissions

2. Concepts

Create each required file-system type on disposable devices, mount manually, then persist appropriate mounts by UUID or label. Build NFS client mounts between two VMs. Configure autofs maps and validate on-demand behavior. Grow an LV and then the file system using the correct method.

3. Core commands

mkfs.vfat, mkfs.ext4, mkfs.xfs, mount, umount, findmnt, blkid, df, du, mount.nfs, showmount, automount

4. Configuration files/directories

• /etc/fstab
• /etc/auto.master
• /etc/auto.master.d/
• /etc/auto.*

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Create VFAT/ext4/XFS and mount them.
• Lab 2: Persist an ext4/XFS mount by UUID or label.
• Lab 3: Mount an NFS export.
• Lab 4: Configure autofs indirect map.
• Lab 5: Extend an LV and file system.
• Lab 6: Break execute permission on a parent directory and diagnose traversal failure.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Wrong filesystem type
• Mount point missing
• Bad fstab option
• NFS server unreachable
• autofs map syntax error
• Filesystem not grown after LV extension

9. Exam-style practice tasks

• Configure persistent storage and verify after reboot.
• Configure an autofs path that appears only when accessed.

10. Knowledge check

• What happens if fstab contains a bad mandatory mount?
• Why can an LV be larger but df unchanged?
• How does autofs differ from fstab?

11. Completion criteria

Move on when local, NFS, and autofs mounts can be created, verified, reboot-tested, and repaired.

Module 9 – Networking, Hostname Resolution and Firewalld

1. Learning objectives

• Configure IPv4/IPv6
• Set hostname and name resolution
• Manage NetworkManager connections
• Enable network-related services
• Manage firewalld

2. Concepts

Use nmcli as the primary configuration tool. Practice static IPv4, IPv6, gateway, DNS, connection autoconnect, hostname, and verification. Apply firewalld services/ports permanently and validate both runtime and permanent state.

3. Core commands

nmcli, ip, hostnamectl, getent, ping, ss, systemctl, firewall-cmd

4. Configuration files/directories

• /etc/hosts
• /etc/resolv.conf
• /etc/NetworkManager/system-connections/

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Configure static IPv4 on lab interface.
• Lab 2: Add an IPv6 address and verify.
• Lab 3: Set hostname and test local resolution.
• Lab 4: Enable autoconnect.
• Lab 5: Allow one service with firewalld and remove it.
• Lab 6: Break DNS settings and diagnose with getent.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Connection profile down
• Wrong prefix/gateway
• DNS failure despite IP connectivity
• Service not listening
• Firewall runtime/permanent mismatch
• Wrong zone

9. Exam-style practice tasks

• Configure a static address, hostname resolution, and firewall allowance; prove all persist after reboot.

10. Knowledge check

• Can I separate link/IP/route/DNS/service/firewall problems?
• Can I inspect active connection profiles?
• Can I prove a firewall rule is permanent?

11. Completion criteria

Move on when network configuration and firewall rules survive a reboot and can be diagnosed layer by layer.

Module 10 – Scheduling and Time Synchronization

1. Learning objectives

• Use at
• Use cron
• Create systemd timer units
• Configure time sync client
• Verify scheduling/time

2. Concepts

Schedule one-time and recurring work using each required mechanism. For systemd timers, pair a .timer with a .service and use systemctl list-timers. Configure and verify a time client with chrony/timedatectl as appropriate.

3. Core commands

at, atq, atrm, crontab, systemctl, systemd-analyze, timedatectl, chronyc

4. Configuration files/directories

• /etc/crontab
• /etc/cron.d/
• /etc/systemd/system/*.timer
• /etc/systemd/system/*.service
• /etc/chrony.conf

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Schedule a one-time job.
• Lab 2: Create user cron entry.
• Lab 3: Create systemd timer+service pair.
• Lab 4: Break a timer by wrong Unit name and troubleshoot.
• Lab 5: Configure time source and verify synchronization.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Job never ran
• PATH/environment differences under cron
• Timer not enabled
• Service unit fails
• Time source unreachable

9. Exam-style practice tasks

• Schedule a recurring job with a systemd timer and verify invocation in the journal.

10. Knowledge check

• When is at different from cron?
• Why does cron PATH differ?
• How do I prove a timer fired?

11. Completion criteria

Move on when all three scheduling mechanisms and time verification are comfortable.

Module 11 – SELinux Focused Administration

1. Learning objectives

• Manage enforcing/permissive state
• Inspect contexts
• Restore labels
• Manage port labels
• Manage booleans
• Troubleshoot denials without disabling SELinux

2. Concepts

Keep SELinux enforcing during normal labs. Learn to identify whether a failure is caused by UNIX permissions, firewall, service configuration, or SELinux. Use semanage for persistent policy mappings such as port labels, restorecon for default labels, and setsebool -P for persistent boolean changes when required.

3. Core commands

getenforce, setenforce, sestatus, ls -Z, ps -Z, restorecon, semanage, getsebool, setsebool

4. Configuration files/directories

• /etc/selinux/config
• /var/log/audit/audit.log

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Switch permissive/enforcing and verify.
• Lab 2: Inspect file/process labels.
• Lab 3: Mislabel a test file and restore default context.
• Lab 4: Add/remove an allowed SELinux port mapping.
• Lab 5: Change a boolean persistently.
• Lab 6: Troubleshoot a service blocked by wrong context.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Wrong file label
• Wrong port type
• Boolean off
• Confusing DAC permissions with SELinux
• Using chcon as a permanent fix

9. Exam-style practice tasks

• Repair a mislabeled path and configure an approved nondefault service port without disabling SELinux.

10. Knowledge check

• Can I explain type enforcement at a practical level?
• Why is restorecon preferred for default labeling?
• How do I verify a boolean persisted?

11. Completion criteria

Move on when your first response to an SELinux failure is diagnosis, not setenforce 0.

Module 12 – Integrated Troubleshooting and Persistence

1. Learning objectives

• Diagnose multi-layer failures
• Verify persistence after reboot
• Use logs/documentation efficiently
• Recover safely

2. Concepts

Use a fixed diagnostic order: understand the requested end-state, inspect current state, isolate the failing layer, make the smallest persistent change, verify, reboot if safe, and verify again. Build confidence by intentionally breaking one layer at a time.

3. Core commands

journalctl, systemctl, findmnt, lsblk, ip, nmcli, ss, firewall-cmd, getenforce, ls -Z, df, du, id, namei

4. Configuration files/directories

• /etc/fstab
• /etc/yum.repos.d/
• /etc/ssh/sshd_config
• /etc/systemd/system/
• /etc/selinux/config

5. Step-by-step tutorial pattern

1. Inspect the current state before changing anything.
2. Read the relevant local man page or help output.
3. Make the smallest change that satisfies the requirement.
4. Verify from a second command or second host where appropriate.
5. If persistence is expected, reboot and verify again.

6. Hands-on labs

• Lab 1: Service + firewall + SELinux three-layer failure.
• Lab 2: Storage mount + permissions failure.
• Lab 3: Network IP + DNS failure.
• Lab 4: Repo misconfiguration.
• Lab 5: User + sudo failure.
• Lab 6: Boot target or fstab recovery.

7. Verification

Use at least two independent checks: state/configuration command plus functional behavior. For persistent tasks, include a reboot test.

8. Troubleshooting drills

• Symptom-chasing without checking state
• Changing multiple variables at once
• Fix works only until reboot
• Using chmod 777 or disabling SELinux as shortcuts

9. Exam-style practice tasks

• Complete a 45-minute mixed lab with no notes and reboot verification.

10. Knowledge check

• Can I state evidence for each diagnosis?
• Can I undo my changes?
• Can I prove persistence?

11. Completion criteria

You are ready for mock exams only when integrated failures no longer cause random guessing.

Part 4 – Home Lab Environment

Recommended topology

Practical recommendation (not an official exam hardware specification): use two RHEL 10 VMs. A third VM is optional for extra NFS/network practice. HOST COMPUTER | +– servera (primary practice VM) | 2 vCPU, 4 GiB RAM, 50+ GiB disk | extra virtual disks for LVM/partition practice | +– serverb (SSH/NFS/network peer) | 2 vCPU, 2-4 GiB RAM, 30+ GiB disk | +– serverc (optional rebuild/NFS target)

Legal access to RHEL

Red Hat currently offers the no-cost Red Hat Developer Subscription for Individuals. The current Red Hat support article says registration in the Red Hat Developer Portal provides the entitlement and recommends installing RHEL on physical hardware or a VM using VirtualBox, VMware, Microsoft Hyper-V, or Linux KVM/libvirt. The Individual subscription is self-supported and intended for individual use; review current terms before use.

Windows

Preferred practical options: Hyper-V (where available), VMware, or VirtualBox. Give each VM its own virtual disk and add 2-3 small extra disks to servera. Use NAT for Internet access and an internal/host-only network for predictable lab addresses.

macOS

VMware or another hypervisor capable of running the correct RHEL architecture is practical. On Apple Silicon, use a RHEL aarch64 image when using an ARM virtual machine. UTM can be practical, but it was not one of the virtualization products named in the current Red Hat no-cost subscription support article reviewed for this guide; treat UTM as a third-party practical option, not an official exam recommendation.

Linux

KVM/libvirt is the most natural option. VirtualBox or VMware can also work. Use virsh/virt-manager if you prefer. Keep a dedicated isolated network plus NAT.

Snapshot and rebuild strategy

1. Baseline snapshot immediately after clean RHEL 10 install and updates.
2. Module snapshot before destructive boot/storage exercises.
3. Never rely only on snapshots: rebuild servera from scratch at least twice during preparation.
4. Keep lab scripts/config snippets on the host so a VM can be destroyed and recreated.
5. For storage labs, attach disposable virtual disks; never practice destructive partition commands on the host.

Example lab addressing

These addresses are examples only. Adapt them to your hypervisor network.

Part 5 – Lab-First Learning System

For every major domain run six progressively harder labs. The pattern is intentionally repetitive because speed and recovery skill come from repeated reconstruction.

Part 6 – Command Mastery List

This is not a general Linux dictionary. These commands directly support current EX200 objectives or their verification/troubleshooting.

Part 7 – Configuration File Mastery

Part 8 – Dedicated Troubleshooting Curriculum

Part 9 – SELinux Deep Dive

Current EX200 scope explicitly includes mode control, file/process context inspection, restoring default file contexts, port labels, and booleans. It does not require advanced custom policy authoring. ausearch and chcon are useful supporting tools but are not separately named current objectives; learn them as troubleshooting context, not as headline objectives.

Practical diagnostic order:

1. Confirm the service works at the UNIX-permission level.
2. Confirm service configuration and listener.
3. Confirm firewall.
4. Confirm SELinux mode and context.
5. Check whether the path label matches its intended use.
6. Check whether a nondefault port needs an SELinux port type.
7. Check relevant booleans.
8. Apply persistent policy-aligned correction.
9. Return to enforcing and retest. Avoid two classic anti-patterns: disabling SELinux, or using chmod 777. They hide the real configuration error and do not demonstrate the required skill.

Part 10 – Storage Deep Dive

Required storage workflow: identify device -> create GPT partition if needed -> build PV/VG/LV where required -> create filesystem or swap -> mount/activate -> persist -> reboot -> verify -> extend -> verify data survived.

Example practice sequence (adapt device names):

• lsblk -f
• parted /dev/vdb print
• create a GPT partition on a disposable disk
• pvcreate /dev/vdb1
• vgcreate vgpractice /dev/vdb1
• lvcreate -L 2G -n lvdata vgpractice
• mkfs.xfs /dev/vgpractice/lvdata
• blkid /dev/vgpractice/lvdata
• create /data and add an fstab entry by UUID
• mount -a; findmnt /data
• reboot; findmnt /data
• lvextend -r -L +1G /dev/vgpractice/lvdata
• verify both lvs and df -h Never practice destructive commands on a disk containing valuable data. Use disposable virtual disks.

Part 11 – Networking Deep Dive

Use a layer-by-layer method: interface/link -> NetworkManager profile -> IP -> route -> DNS -> service listener -> firewall -> SELinux if relevant -> remote functional test. This prevents random changes. Primary persistent configuration tool for study: nmcli. Supporting inspection: ip, getent, ss, hostnamectl, systemctl, firewall-cmd.

Part 12 – Users, Groups and Permissions Deep Dive

Practice combined requirements, not isolated commands. Example: create account alice with specified UID, primary group developers, supplementary group ops, password aging, a shared directory owned by root:ops, group write access, a stated umask, and limited sudo. Then log in as alice and verify the real behavior.

Part 13 – systemd and Services Deep Dive

Know the difference between service state and boot enablement. systemctl start changes current state; systemctl enable configures boot behavior. systemctl enable --now does both. Verification should use is-active, is-enabled, logs, listener checks where applicable, and a reboot when persistence matters. Systemd timer units are explicitly current EX200 scope. Build at least three timer/service pairs from scratch.

Part 14 – Software Management Deep Dive

Current scope includes both RPM/DNF repository management and Flatpak repository/application management. Old study plans that omit Flatpak are incomplete for the current objective page. Conversely, old RHEL module-stream objectives are not present on the current EX200 page reviewed here, so do not make AppStream module-stream commands a core requirement unless the official objective page changes.

Part 15 – Bash and Automation Deep Dive

Stay narrow: if/test/[ ], for loops, positional inputs, and command substitution. Useful supporting habits include quoting, exit codes, executable permissions, and bash -n. Advanced arrays, associative arrays, functions, traps, sed/awk programming, and complex regex are useful Linux skills but are not separately stated EX200 objectives.

Part 16 – EX200-Style Original Practice Task Bank

These are original practice tasks, not real Red Hat exam questions. Each maps to current objective IDs.

Part 17 – Five Original Mock Exams

The timeboxes below are training constraints chosen for practice. They are NOT a claim about the official EX200 duration.

Mock Exam 1 – Foundation

Practice timebox: 90 minutes

1. Create two users and groups with requested memberships and password aging.
2. Create a directory tree with ownership, permissions, hard link and symbolic link.
3. Build a compressed archive and restore it.
4. Configure SSH key login between servera and serverb.
5. Enable one service and inspect its journal.
6. Configure one DNF repository and install a package.

Solution/verification guide

Grade by end state, persistence, and evidence. For each task record: command/config used, verification command, functional test, and whether it still works after reboot. Do not grade based on matching one exact command if another valid RHEL method reaches the requested state.

• 2 points: end state correct and persistent.
• 1 point: end state currently correct but persistence/verification incomplete.
• 0 points: requirement not achieved or destructive side effect introduced. Target for progression: at least 85 percent, with no zero on storage, networking, privilege, or boot-critical persistence tasks. This threshold is a self-study recommendation, not an official Red Hat passing score.

Mock Exam 2 – Intermediate

Practice timebox: 120 minutes

1. Configure static IPv4 and hostname resolution.
2. Apply a permanent firewall rule for a supplied service.
3. Create GPT partition -> PV -> VG -> LV -> XFS -> persistent mount.
4. Create persistent swap.
5. Create cron and at jobs.
6. Write a simple Bash script using positional arguments and a loop.
7. Make the journal persistent.

Solution/verification guide

Grade by end state, persistence, and evidence. For each task record: command/config used, verification command, functional test, and whether it still works after reboot. Do not grade based on matching one exact command if another valid RHEL method reaches the requested state.

• 2 points: end state correct and persistent.
• 1 point: end state currently correct but persistence/verification incomplete.
• 0 points: requirement not achieved or destructive side effect introduced. Target for progression: at least 85 percent, with no zero on storage, networking, privilege, or boot-critical persistence tasks. This threshold is a self-study recommendation, not an official Red Hat passing score.

Mock Exam 3 – Advanced

Practice timebox: 150 minutes

1. Repair an NFS mount and configure autofs.
2. Extend an existing LV and file system without data loss.
3. Repair a service that fails because of permissions and SELinux context.
4. Configure a nondefault SELinux port label.
5. Create a systemd timer unit.
6. Configure time synchronization.
7. Fix a broken repository and install a local RPM.

Solution/verification guide

Grade by end state, persistence, and evidence. For each task record: command/config used, verification command, functional test, and whether it still works after reboot. Do not grade based on matching one exact command if another valid RHEL method reaches the requested state.

• 2 points: end state correct and persistent.
• 1 point: end state currently correct but persistence/verification incomplete.
• 0 points: requirement not achieved or destructive side effect introduced. Target for progression: at least 85 percent, with no zero on storage, networking, privilege, or boot-critical persistence tasks. This threshold is a self-study recommendation, not an official Red Hat passing score.

Mock Exam 4 – Full Simulation

Practice timebox: 180 minutes

1. Mixed user/group/sudo requirements.
2. Mixed shell/file/archive task.
3. Repository plus Flatpak task.
4. Process priority and process termination.
5. Service enablement + persistent logs.
6. GPT/LVM/swap build.
7. VFAT/ext4/XFS practice across disposable devices.
8. NFS/autofs client configuration.
9. IPv4+IPv6+hostname+firewall.
10. SELinux context, port, boolean tasks.
11. Systemd timer plus cron task.
12. One boot/target recovery task on disposable snapshot.

Solution/verification guide

Grade by end state, persistence, and evidence. For each task record: command/config used, verification command, functional test, and whether it still works after reboot. Do not grade based on matching one exact command if another valid RHEL method reaches the requested state.

• 2 points: end state correct and persistent.
• 1 point: end state currently correct but persistence/verification incomplete.
• 0 points: requirement not achieved or destructive side effect introduced. Target for progression: at least 85 percent, with no zero on storage, networking, privilege, or boot-critical persistence tasks. This threshold is a self-study recommendation, not an official Red Hat passing score.

Mock Exam 5 – Final Readiness

Practice timebox: 180 minutes

1. Rebuild servera from baseline and complete 15-20 requirements drawn randomly from every objective domain.
2. At least 4 requirements must deliberately contain a broken initial state.
3. At least 8 requirements must need persistence after reboot.
4. At the end reboot once and grade only the post-reboot state.
5. Do not use external notes; use local man/info/product docs only.

Solution/verification guide

Grade by end state, persistence, and evidence. For each task record: command/config used, verification command, functional test, and whether it still works after reboot. Do not grade based on matching one exact command if another valid RHEL method reaches the requested state.

• 2 points: end state correct and persistent.
• 1 point: end state currently correct but persistence/verification incomplete.
• 0 points: requirement not achieved or destructive side effect introduced. Target for progression: at least 85 percent, with no zero on storage, networking, privilege, or boot-critical persistence tasks. This threshold is a self-study recommendation, not an official Red Hat passing score.

Part 18 – 30 / 45 / 60 / 90 Day Study Plans

30-Day Intensive

45-Day Balanced

60-Day Moderate

90-Day Limited Daily Time

Part 19 – Beginner to EX200 Ready Roadmap

Linux/RHEL fundamentals | v Command line + files + documentation | v Users + groups + permissions + sudo | v SSH + secure transfer | v RPM/DNF + Flatpak | v Simple Bash scripting | v Processes + systemd + logs + boot + tuning | v GPT + LVM + swap | v File systems + NFS + autofs | v Networking + firewalld | v Scheduling + time sync | v SELinux | v Integrated break/fix + persistence | v Five mock exams | v EX200 READY

Part 20 – Readiness Checklist

For every item below, check all four dimensions before calling it mastered: [ ] without notes [ ] command line [ ] troubleshoot [ ] under time pressure.

• [ ] E01 – Open a shell and run commands with correct syntax | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E02 – Redirect standard input/output/error and use pipelines | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E03 – Search and analyze text with grep and regular expressions | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E04 – Connect to remote systems securely with SSH | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E05 – Log in and change user identity in multi-user operation | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E06 – Archive and compress/uncompress data with tar, gzip, and bzip2 | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E07 – Create and edit text files from the command line | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E08 – Create, remove, copy, and move files and directories | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E09 – Create hard links and symbolic links | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E10 – Inspect and change standard owner/group/other rwx permissions | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] E11 – Find and use local system documentation | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] S01 – Configure access to RPM package repositories | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] S02 – Install and remove RPM packages | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] S03 – Configure access to Flatpak repositories | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] S04 – Install and remove Flatpak applications | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] B01 – Conditionally execute commands in a script | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] B02 – Use loops to process files or command-line input | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] B03 – Process positional script arguments | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] B04 – Use command output inside scripts | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R01 – Perform normal boot, reboot, and shutdown operations | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R02 – Boot manually into alternate systemd targets | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R03 – Interrupt boot to recover access to a system | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R04 – Find CPU or memory heavy processes and terminate them | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R05 – Adjust process scheduling priority | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R06 – Select and manage system tuning profiles | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R07 – Locate and interpret logs and the system journal | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R08 – Configure the journal to persist across reboot | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R09 – Start, stop, and inspect network-facing services | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] R10 – Transfer files securely between systems | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] L01 – Inspect, create, and remove GPT disk partitions | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] L02 – Create and remove LVM physical volumes | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] L03 – Add physical volumes to volume groups | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] L04 – Create and remove logical volumes | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] L05 – Configure boot-time mounts using UUID or filesystem label | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] L06 – Add partitions, LVs, and swap without destroying existing data | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] F01 – Create and use VFAT, ext4, and XFS file systems | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] F02 – Mount and unmount NFS network file systems | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] F03 – Configure on-demand mounts with autofs | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] F04 – Extend existing logical volumes and associated file systems | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] F05 – Diagnose and repair file permission problems | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] D01 – Schedule one-time and recurring work with at, cron, and systemd timers | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] D02 – Start/stop services and enable them at boot | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] D03 – Set the default systemd boot target | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] D04 – Configure a time synchronization client | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] D05 – Install or update packages from Red Hat CDN, remote repos, or local files | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] D06 – Modify system bootloader configuration | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] N01 – Configure IPv4 and IPv6 addressing | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] N02 – Configure hostname and name resolution | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] N03 – Ensure required network services start automatically | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] N04 – Restrict network access using firewalld/firewall-cmd | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] U01 – Create, remove, and modify local users | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] U02 – Set passwords and local password aging rules | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] U03 – Create/modify/delete groups and memberships | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] U04 – Configure privileged administrative access | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] X01 – Configure host firewall rules with firewalld | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] X02 – Manage default permissions for newly created files/directories | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] X03 – Configure SSH public-key authentication | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] X04 – Switch SELinux between enforcing and permissive modes | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] X05 – Inspect SELinux labels for files and processes | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] X06 – Restore default SELinux file contexts | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] X07 – Manage SELinux network port labels | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed
• [ ] X08 – Manage SELinux booleans | [ ] without notes | [ ] CLI | [ ] troubleshoot | [ ] timed

Part 21 – Final Seven Days

Do not spend the last week learning advanced Linux topics outside the current objective list. Fix weak fundamentals and persistence instead.

Part 22 – Exam-Day Strategy and Current Official Rules

Officially verified: Red Hat certification exams are performance-based; EX200 is hands-on; Internet access is not provided; personal hardcopy/electronic documentation is not permitted; product documentation is available for most exams; Individual Exams may be delivered at a testing center or remotely where available; remote exams require the current compatibility process; the current training policy governs scheduling, proctoring, equipment, retakes, and conduct. Strategy guidance below is this guide authorship, not a Red Hat policy: read every requirement before changing the system, complete high-confidence tasks first, avoid destructive shortcuts, keep a short internal list of items to revisit, verify each task functionally, and reserve time for persistence checks. Reboot only when safe and useful; the official requirement is that configurations intended to persist must survive reboot.

Part 23 – What NOT to Study as a Core EX200 Requirement

Important nuance: the current EX200 audience description mentions container fundamentals, but the current objective list does not contain a dedicated container/Podman objective. For exam preparation, objective scope is the safer authority.

Part 24 – Official Resource Map

Part 25 – Final Master Curriculum Table

Part 26 – Final Quality Audit

Part 27 – Final Self-Study Operating Rules

1. Official EX200 objectives are the source of truth.
2. Type commands yourself; do not learn by watching only.
3. Every persistent task gets a reboot test.
4. Every configuration topic gets a break/fix lab.
5. Use local documentation until it becomes fast.
6. Rebuild storage repeatedly on disposable disks.
7. Keep SELinux enforcing during normal practice.
8. Never use chmod 777, firewall disablement, or SELinux disablement as generic fixes.
9. Separate current state from persistent state.
10. Before booking, re-check the live EX200 objectives and current Red Hat exam policies.

Source verification notes

Verified 2026 facts used in this guide: EX200 is currently based on RHEL 10; it is performance-based; the official objective list includes Flatpak, GPT partitions, systemd timer units, tuning profiles, and persistent journal handling; configurations must persist after reboot. Red Hat reorganized the certification framework in May 2026 but stated that the framework change itself did not change exam content/objectives/proctoring. Current Red Hat Training Policies were last updated June 29, 2026 in the source reviewed. The no-cost Red Hat Developer Subscription for Individuals remains available according to a Red Hat support article updated September 28, 2026. Where an item was not directly stated in the current official material reviewed, this guide labels it as practical guidance or says: Not officially specified in the current Red Hat documentation.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.