EX200 Red Hat Certified System Administrator Study Guide¶

Independent AI-assisted resource — SOURCES + OBJECTIVES CHECKED; HUMAN REVIEW PENDING. Objective coverage, citations, volatility labels, links, and exam-integrity compliance were checked on October 28, 2026. This is not a guarantee that the guide is error-free or current after that date. See the sources-and-objectives record. The official EX200 objectives are authoritative.

Study guide at a glance

Start here

Report an issue with EX200

Blueprint checked2026-10-28

Review stateSources + objectives checked — human review pending

Guide-only active reading45 min–1 hr

Prerequisites: No formal certification prerequisite. Red Hat recommends RH124 plus RH134, RH199 for experienced Linux administrators, or comparable RHEL experience. Practice every public task on RHEL 10, including shell/files, RPM/Flatpak, Bash, boot/services/logs, GPT/LVM/filesystems/NFS/autofs, scheduling, networking, users, firewalld, SSH and SELinux; validate all required state after reboot.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Use the first hands-on exercise in the guide, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

See the objective map in this guide

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current baseline: EX200 based on Red Hat Enterprise Linux 10
Upcoming blueprint change: None announced when checked September 28, 2026
Important freshness boundary: RHEL 9 and older RHCSA material remains useful for durable Linux concepts, but the current public objectives add or emphasize RHEL 10 details such as Flatpak software management and systemd timers. Practice on RHEL 10 and reconcile every objective.
Official source: Red Hat Certified System Administrator exam (EX200)

Current guide watch — October 28, 2026¶

Red Hat's release index lists RHEL 10.2 as the latest minor release. The EX200 exam page still binds the exam to RHEL 10 without naming a minor release; use the current 10.2 documentation to learn product behavior, but do not turn 10.2-only features into new exam objectives. Red Hat's May 2026 framework now maps EX200 into both Enterprise Linux and Ansible paths and uses three-year credential validity; these are credential-path changes, not objective changes. See RHEL 10.2 release notes and the Red Hat certification FAQ.

How to use this guide¶

EX200 is a performance-based administration exam. You configure real systems without internet access or personal notes; for most exams, product documentation shipped with the environment is available. Red Hat explicitly requires configurations to persist after reboot. Preparation therefore means repeatedly doing each public objective from a clean RHEL 10 machine, verifying the requested outcome, rebooting when safe, and diagnosing failures without a copied recipe.

The official prerequisites section accepts RH124 plus RH134, RH199, or comparable RHEL administration experience. It does not specify another certification as a prerequisite. Red Hat also recommends the courses as preparation. The public exam page does not expose one universal price or appointment duration before location selection; verify the scheduler and the current Certification Program Guide before booking. A Red Hat skills-path resource lists a three-hour exam, but delivery metadata is volatile.

For each task, use a five-part loop:

inspect current state, devices, dependencies, policy, and the exact requested end state;
make the smallest correct change with a native RHEL tool or well-understood configuration file;
validate runtime behavior, configuration syntax, permissions, logs, and exit status;
make the change persistent and test the next boot/mount/service activation path;
record a rollback/recovery method and repeat later from memory using local documentation only.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

Objective map¶

Red Hat publishes task groups but no percentage weights. Do not invent a priority ranking from page order.

Official task group	Performance outcome
Understand and use essential tools	Work accurately at the shell, transform text, manage files/links/archives/permissions, use SSH, and find local help.
Manage software	Configure RPM and Flatpak repositories and install/remove software.
Create simple shell scripts	Use inputs, command output, conditionals, tests, and loops safely.
Operate running systems	Control boot/targets/processes/tuning/logs/services and transfer files.
Configure local storage	Manage GPT partitions, PVs, VGs, LVs, swap, labels/UUIDs, and nondestructive additions.
Create and configure file systems	Build/use VFAT, ext4, XFS, NFS, autofs, extend LVs, and fix permission failures.
Deploy, configure, and maintain systems	Schedule work, manage service/boot state/time/software updates, and modify the bootloader.
Manage basic networking	Configure IPv4/IPv6, resolution, activation, and firewall restrictions.
Manage users and groups	Administer accounts, groups, memberships, aging, and privileged access.
Manage security	Apply firewalld, default permissions, SSH keys, and SELinux modes/contexts/ports/booleans.

1. Understand and use essential tools¶

Shell, redirection, text, and local documentation¶

Know command syntax, quoting, globbing, variables, paths, exit status, standard input/output/error, pipes, and redirection. > replaces a file; >> appends; 2> redirects standard error; a pipeline passes one command's output to the next process. Avoid destructive redirections until you have confirmed the target. Use grep with basic/extended regular expressions deliberately and distinguish a regular expression from a shell glob.

Use man, info, --help, /usr/share/doc, package file lists, examples, and configuration comments. Search by purpose with man -k/apropos, then inspect synopsis, options, files, examples, and related pages. Build the habit of solving an unfamiliar option from local help because internet access is unavailable during the exam.

Manage files/directories with ownership and metadata in mind. Understand absolute/relative paths, hidden files, recursive operations, safe copying, hard links (same inode/filesystem constraints), symbolic links (path reference and dangling behavior), archives versus compression, and tar with gzip/bzip2. Verify results with ls -l, stat, file, find, checksums, and content inspection rather than assuming a command succeeded.

Access remote systems with SSH and transfer files securely using the supported SSH tools. Confirm host/user/key, permissions, target path, and ownership. Switching identities with su and privileged commands through sudo have different environment, authentication, and audit behavior.

Related item: A command that returns zero can still produce the wrong operational result. Validate the required state, not only the exit code—for example, archive contents, resolved link target, ownership, and service behavior.

2. Manage software¶

RPM is the package format/database; DNF resolves repositories, dependencies, installation, removal, and updates. Configure repositories with correct base URL, enabled state, GPG checking/key, and reachability. Inspect dnf repolist, package availability/version/info, owning package, installed files, dependencies, history, and transaction result. Installing an RPM directly does not give the same dependency workflow as DNF.

Flatpak uses remotes and application/runtime refs rather than RPM repositories. Add/list/remove a remote, search/install/list/update/uninstall applications, and understand system-versus-user scope. Validate application/runtime state and source. Keep RPM and Flatpak mental models separate.

Related item: A repository being syntactically configured does not prove its metadata, GPG trust, architecture, or required package is available. Test the actual transaction path.

3. Create simple shell scripts¶

Write small Bash scripts with a shebang, executable permission or explicit interpreter, meaningful variables, quoted expansions, positional parameters, command substitution, tests, if/elif/else, and for loops. Validate required arguments and files, handle failure, and emit useful errors to standard error. Use shellcheck only if available during study; the final script must be understandable without it.

Distinguish string, numeric, and file tests. Quote "$1" and command output when word splitting/globbing is not intended. Prefer an idempotent state change where repeated execution should be safe. Test empty input, whitespace, missing resources, and a failed command—not just the happy path.

Related item: Scripting is a force multiplier for both success and mistakes. Limit input scope, verify targets, use temporary test data, and avoid unbounded recursive or destructive operations.

Run a small shell contract¶

Save this original example as record-report.sh. It reads a plain-text list, preserves spaces and backslashes, skips empty lines and lines starting with #, and includes a final line even if its newline is missing. It does not change accounts or system configuration. Run bash -n record-report.sh, then bash record-report.sh "sample list.txt" > report.txt 2> report.log. Inspect both outputs and the exit code. The input must be a regular readable file; directories and missing arguments are rejected before output starts.

#!/usr/bin/env bash
set -u
if [[ $# -ne 1 ]]; then
    printf 'usage: record-report.sh INPUT\n' >&2
    exit 2
fi
input=$1
if [[ ! -f "$input" || ! -r "$input" ]]; then
    printf 'input must be a readable regular file\n' >&2
    exit 2
fi
count=0
while IFS= read -r record || [[ -n "$record" ]]; do
    [[ -z "$record" || "$record" == \#* ]] && continue
    count=$((count + 1))
    printf '%s\n' "$record" || exit 1
done < "$input"
printf 'records=%s\n' "$count" >&2

Use # note, alpha beta, a literal backslash, an empty line and a final unterminated omega as fixtures. Expected output contains three records; stderr reports records=3. Redirecting with > report.txt is performed by the shell before the script validates its input: it can truncate an existing report even when the script fails. For important reports, write to a separate candidate file, verify success/content, then replace the destination deliberately. set -u catches unset variables; it does not check every command's success or make the process transactional.

4. Operate running systems¶

Boot, targets, processes, tuning, and services¶

Use systemctl to inspect and change default target, isolate an appropriate target when safe, start/stop/restart/reload services, enable/disable boot activation, and distinguish active from enabled. Read unit status and dependencies. A service can be enabled but currently failed, or active now but not persistent.

Understand the boot path sufficiently to diagnose firmware/bootloader, kernel/initramfs, root filesystem, systemd target, mount, and service failures. Practice interrupting the boot process and recovering administrative access only in disposable VMs using the current RHEL 10 procedure. Back up relevant configuration and test normal reboot afterward.

Inspect processes with ps, top and /proc; identify CPU/memory consumers; distinguish PID, parent, user, state, priority/nice, and command; send appropriate signals; manage shell jobs; and adjust scheduling with nice/renice. Prefer graceful termination before force when possible. Use tuned profiles by workload requirement and verify the active/recommended profile.

Use journalctl and conventional log files to filter by unit, boot, priority, time, and fields. Configure persistent journal storage when required and verify across reboot. Accurate time and hostname identity make logs useful. Transfer files securely and validate ownership/permissions at the destination.

Related item: Restarting a failed service before reading logs may obscure the original state. Capture status, journal, configuration syntax and dependency evidence first, then change one cause at a time.

5. Configure local storage¶

Inventory devices and topology with lsblk, blkid, findmnt, LVM reporting, and partition tools before writing. Know disk/device versus partition versus filesystem versus mount point. Use GPT partitioning, reread/verify the table, and never infer a device name from memory in a multi-disk system.

For LVM, understand physical volume → volume group → logical volume → filesystem/swap. Create and remove the correct layer in safe order; inspect extents and free capacity; name devices predictably; and avoid deleting a layer still in use. Add partitions, LVs, and swap non-destructively. Activate and verify swap runtime and persist it with a stable identifier.

Mount file systems at boot by UUID or label where required. An /etc/fstab typo can break boot, so create the mount point, choose correct type/options, use mount -a as a preflight, validate with findmnt, and test a reboot in the lab. Understand nofail and timeout options as operational design choices, not universal fixes.

Related item: Extending an LV and extending its filesystem are distinct operations. The filesystem-specific growth tool and online/offline behavior matter; inspect both block device and filesystem size afterward.

For a persistent mount, inspect the intended device's blkid output, the matching fstab entry, and findmnt output as separate evidence. Validate file syntax and dependencies before a lab reboot. mount -a does not activate swap and does not prove every already-mounted filesystem has the newly requested options. Verify swap with swapon --show and compare live mount options with the requested configuration. Keep recovery console access for the disposable VM.

6. Create and configure file systems¶

Create, mount, unmount, label, and use VFAT, ext4, and XFS according to the requested interoperability and Linux-feature needs. Do not assume shrink/grow behavior is the same: XFS and ext4 have different supported resize semantics. Ensure no busy process prevents unmounting, and validate ownership/mode after mount because the mounted filesystem hides the underlying directory contents.

The current RHEL 10 filesystem comparison is explicit: XFS can grow but has no supported shrink utility; ext4 shrinking requires an unmounted filesystem. Do not reduce an LV underneath a larger filesystem. XFS growth uses xfs_growfs after enlarging the underlying device; ext4 uses resize2fs for its supported operation. Check device capacity and filesystem capacity separately.

VERIFY CURRENT — small practice disks: RHEL 10 storage changes require at least 300 MB for a newly created XFS filesystem and remove the older V4 format. A legacy exercise with a 100 MB XFS LV is unsuitable. Allocate, for example, a 1 GiB disposable LV and inspect the real filesystem format; do not override the limit to preserve an old recipe.

For NFS clients, identify server export/path, network/DNS reachability, mount type/options, persistence, and identity/permission behavior. Use autofs maps for on-demand mounts, restart/reload safely, trigger the map, and confirm the path unmounts according to policy. Diagnose failures across name resolution, route/firewall, export, client package/service, SELinux, mount options, ownership and permissions.

Permission diagnosis requires traversing every directory component, comparing owner/group/other mode, default umask, special bits where relevant, mount options, ACL/extended attributes if present, and SELinux context. Avoid chmod 777; determine the intended principal and minimum access.

7. Deploy, configure, and maintain systems¶

Schedule one-time work with at, recurring work with cron, and service-linked schedules with systemd timer/service units. Validate command path, user, environment, permissions, calendar expression, enablement, next/last run, output/logging, and persistence. A script that works interactively can fail under a minimal scheduler environment.

Install/update packages from Red Hat CDN, remote repositories, or local files as requested. Control services and default target. Configure time clients and verify source/synchronization, not merely that a daemon runs. Modify the bootloader only from a known-good backup/recovery plan and verify generated/current configuration plus a normal reboot.

Related item: systemd timers can express dependencies, missed-run persistence, random delay, and logging through their service unit. Cron remains appropriate for simpler calendar execution. Choose by required behavior.

Pair a timer with a service and inspect both¶

In a disposable RHEL 10 VM, use matching study-report.service and study-report.timer files. The service below only writes a message to its journal; it illustrates scheduling without changing application data.

# study-report.service
[Unit]
Description=Study timer observation
[Service]
Type=oneshot
ExecStart=/usr/bin/printf study-timer-ran

# study-report.timer
[Unit]
Description=Daily study report
[Timer]
OnCalendar=*-*-* 03:15:00 UTC
Persistent=true
[Install]
WantedBy=timers.target

First validate the files with systemd-analyze verify and the calendar with systemd-analyze calendar. After installing the pair in the VM's system unit directory, run systemctl daemon-reload, enable/start the timer, and inspect list-timers, both units' state and journalctl -u study-report.service. Starting a future calendar timer is not necessarily an immediate service invocation; test the service separately when needed. A successful oneshot service normally returns to inactive after completion.

According to the upstream timer manual, Persistent=true applies to calendar timers and triggers a catch-up activation when at least one run was missed. It does not replay one invocation per missed interval. An already-active service is not started again when the timer elapses, so RemainAfterExit=yes can defeat a repeating oneshot design. Inspect the locally installed manual because upstream documentation can describe newer options.

For clock evidence, compare chronyc tracking, chronyc sources -v, daemon status and the approved source configuration using the RHEL 10 chrony reference. Morgan Peterman's chrony walkthrough separates client source selection from server access. Use its client verification method with current RHEL documentation; operating an NTP server is related context, not an added EX200 task. A running daemon with no suitable source is not proof of synchronization.

8. Manage basic networking¶

Use NetworkManager tools such as nmcli to inspect connections/devices and configure IPv4/IPv6 addresses, prefix/gateway, DNS, search domains, autoconnect, and hostname resolution. Distinguish a connection profile from the live device state. Activate the correct profile, verify addresses/routes/DNS/listening services, and test the exact protocol from a peer.

Use /etc/hosts for deliberate static host mappings and understand its relationship to resolver configuration. A ping test does not validate DNS or the application port. Diagnose local interface → address/prefix → route/gateway → DNS → service listener → firewall/SELinux → remote path.

Restrict network access with firewalld using the correct zone, interface/source binding, service or port/protocol, runtime/permanent state, reload behavior, and rich/direct features only where required. Verify both allowed and denied behavior after reload and reboot.

For a service allowed only in a chosen lab zone, compare firewall-cmd --zone=ZONE --query-service=SERVICE with the same query using --permanent. Substitute the actual zone and service. The RHEL firewalld reference explains that reload replaces runtime state from permanent configuration. A runtime-only opening can disappear; a permanent-only edit has not yet changed current traffic. Check the interface/source binding, deliberately reconcile both configurations, then verify allowed and denied peer access after reload. --runtime-to-permanent saves the entire runtime configuration, so inspect all temporary changes before using it.

9. Manage users and groups¶

Create, modify, lock/unlock, and remove local users; set shell, home, UID, primary/supplementary groups, password, and aging. Know when removal should retain or delete a home directory and how orphaned numeric ownership appears. Create/modify groups and memberships without accidentally replacing existing supplementary groups.

Configure privileged access with sudoers and included files, edit safely with visudo, scope users/groups/hosts/commands, and test as the target identity. Avoid broad passwordless root access unless explicitly required. Password aging, account expiration, shell locking, and password locking solve different requirements.

Related item: Numeric UID/GID ownership is stored on the filesystem. Reusing an identifier can grant a new account access to old files; inspect and resolve orphaned ownership deliberately.

10. Manage security¶

Permissions, SSH, firewalld, and SELinux as layers¶

Use standard user/group/other read-write-execute permissions, ownership, directory traversal semantics, default umask, and special permissions only when intended. Generate and deploy SSH public keys with correct account and .ssh/authorized_keys ownership/modes; verify key authentication before disabling or changing fallback access.

SELinux mode (enforcing/permissive), policy decisions, process domain, file type, port label, and boolean are different concepts. Inspect with getenforce, ls -Z, ps -eZ, semanage, getsebool, and AVC/journal tools. Restore a known default context with restorecon; use persistent file-context mappings for nonstandard paths rather than repeatedly applying a transient label. Add/modify a port type or boolean only when it expresses the intended policy. Permissive mode is diagnostic, not a permanent repair.

Firewalld controls network traffic; SELinux constrains processes even after network access arrives; Unix permissions constrain filesystem access; service configuration determines whether anything listens. Troubleshoot all layers and keep the minimum necessary opening.

Related item: chcon can be useful for an experiment but its label can be lost on relabel. A persistent semanage fcontext rule followed by restorecon expresses the durable intent.

The RHEL 10 SELinux troubleshooting guide distinguishes policy mappings from actual labels. In a disposable web-server exercise, after confirming /srv/study-web is the intended directory, a persistent httpd_sys_content_t mapping for /srv/study-web(/.*)? must be followed by restorecon on that exact tree. Inspect matchpathcon and ls -Z, then test the confined service. semanage fcontext alone does not relabel existing files; chmod alone cannot repair an SELinux type mismatch. Review AVC evidence before changing policy.

For permission calculations without ACLs, the creation mode is masked bit by bit: a normal file request of 0666 under umask 0027 yields 0640; a directory request of 0777 yields 0750. Do not subtract decimal-looking mode numbers. A default ACL can change this calculation, and group setgid inheritance does not itself grant group write permission.

Integrated scenarios¶

Scenario 1: New application host that survives reboot¶

Create a service account and group, scoped sudo rule, application directory with least permissions and persistent SELinux context, RPM repository/package, simple systemd-managed script/service, configuration file, log path, static network profile, time client, and firewalld service access. Verify from a peer, inspect journal/context/listener/firewall, reboot, and repeat every validation. Roll back the repository, service, user, firewall, and context changes cleanly.

Scenario 2: Expand storage without an outage¶

Inventory a test disk and existing VG/LV/filesystem. Add a GPT partition and PV to the VG, extend the target LV and its supported filesystem, create a separate LV/filesystem labeled for application data, persist by stable identifier, and add swap. Use mount -a, confirm sizes and swap, fill only with safe test data, reboot, and verify. Then diagnose a deliberately incorrect UUID or mount option from rescue/console access.

Scenario 3: “The service is down” layered diagnosis¶

Given a host that cannot be reached, do not immediately disable controls. Confirm connection profile/address/route/DNS, process/unit state and enablement, configuration syntax, listening socket, journal, file permissions, SELinux contexts/AVCs/port/boolean, firewalld zone/rules, and client-side error. Correct one root cause, validate allowed and denied paths, make persistence explicit, reboot, and confirm the incident is resolved.

Hands-on labs¶

Use disposable RHEL 10 VMs from an authorized no-cost Developer subscription or an entitled lab. Snapshot before boot/storage recovery exercises and never practice destructive commands on production or personal-data disks.

Review execution boundary: the shell example passed local Bash checks in Git for Windows. The timer files were parsed structurally only. No RHEL VM, systemd activation, SELinux, firewall, storage, account or reboot lab was executed; all eight system labs below remain proposed. Local WSL startup was unavailable during this review.

Shell and local-help circuit: complete 20 file/text/archive/link/permission tasks using only man, info, --help, and /usr/share/doc; write assertions that prove every result.
RPM and Flatpak sources: create/use a safe test RPM repository and Flatpak remote, install/remove one item from each, inspect provenance/state, break one source, and diagnose it.
Scripted account report: accept a file/group as inputs, validate them, loop through records/members, test conditions, capture command output, send errors correctly, and rerun safely.
Boot/service/log recovery: change a disposable VM's target and service activation, persist the journal, adjust a tuning profile, create one recoverable boot/service failure, and restore normal boot from console.
Partition/LVM/filesystem: create GPT storage, PV/VG/LVs, XFS/ext4/VFAT and swap as appropriate, mount by UUID/label, extend supported layers, run mount -a, reboot, and verify.
NFS/autofs and permissions: export or use an authorized test NFS path, mount directly and through autofs, diagnose a permission/identity/context failure, and verify on-demand behavior.
Network/security layers: configure IPv4 and IPv6 profiles, resolver/hostname, SSH keys, a test service, firewalld, and an SELinux nonstandard port/context; prove allowed and denied paths after reboot.
Timed rebuild: from a clean two-VM snapshot, complete a randomized checklist spanning all ten groups, score only observable persistent outcomes, preserve 20% of time for validation, and write an error log.

Original knowledge checks¶

How do a shell glob and a regular expression differ?
What should be verified after creating an archive?
How do hard and symbolic links behave differently when the original name is removed?
Which local sources help discover an unfamiliar command option without internet access?
Why can a successful exit code still be insufficient evidence?
How do RPM and DNF responsibilities differ?
How does a Flatpak remote differ from a DNF repository?
Which checks prove repository trust and usability?
Why should positional parameters usually be quoted?
How would a script handle a missing input without partially changing state?
What is the difference between active and enabled for a systemd service?
Which evidence should be captured before restarting a failed service?
How do process priority and a tuned profile differ?
What makes journal storage persistent across reboot?
Why must a boot-recovery procedure end with a normal reboot test?
How do partition, PV, VG, LV, filesystem, and mount point relate?
Why use UUID or label rather than a guessed device name in fstab?
What two layers may need growth after extending storage?
Which preflight catches many fstab failures before reboot?
Why is “non-destructive” a separate requirement from “command succeeded”?
How do XFS and ext4 resize capabilities differ?
Why can permissions change when a filesystem is mounted on a directory?
What layers can cause an NFS client mount failure?
When is autofs preferable to a permanent boot-time mount?
How do cron, at, and systemd timers differ?
Why can an interactive script fail under a scheduler?
What proves time synchronization rather than just daemon activity?
How do a NetworkManager profile and current device state differ?
Why does ping not prove that name resolution or an application works?
What is the firewalld runtime/permanent distinction?
What happens if supplementary groups are replaced instead of appended?
How do password lock, account expiry, and an unusable shell differ?
Why can UID reuse expose old files?
How should a sudo rule be syntax-checked and tested?
How do Unix mode, firewalld, SELinux, and service configuration layer together?
Why is permissive SELinux mode not a durable fix?
When is restorecon preferable to chcon?
What must be correct for SSH public-key authentication to work?
Which validations should be repeated after every exam-style reboot?
What RHEL 10 objective gaps must older RHCSA material be checked for?

Answers to the original knowledge checks¶

A shell glob expands file names before a command runs; a regular expression is interpreted by a tool against text. Quote a regex intended for grep.
List the archive, extract into a separate test directory and compare expected paths, contents and required metadata. Successful creation alone is insufficient.
A hard link retains the inode while another link exists; a symlink retains a path and can become dangling when its target name disappears.
Use man, info, --help, package file lists and /usr/share/doc; search by purpose with apropos/man -k.
The command can complete while selecting the wrong path, identity, zone or value. Test the requested outcome and persistence.
RPM inspects/manages package records and files; DNF adds repository and dependency resolution to transactions.
A Flatpak remote supplies application/runtime refs with user/system scope; it is not an RPM repository.
Check configured location, enabled state, architecture, metadata reachability, signing trust, package availability and a permitted transaction.
Quoting preserves one argument containing spaces or glob characters; unquoted expansion can change argument count and meaning.
Validate arguments, file type/readability and prerequisites first; report errors on stderr with nonzero status before changes. Caller redirections still happen first.
Active describes current runtime state; enabled describes activation links for boot or another target. Test both independently.
Capture unit state, journal/exit status, configuration validation and dependencies before replacing the failure evidence with a restart.
Nice/renice adjusts process scheduling priority; a tuned profile applies a coordinated system configuration for a workload.
Persistent journal configuration/storage and correct directory permissions allow disk retention; confirm an earlier boot is readable after a real reboot.
It proves the repaired credentials, boot path, mounts, services and policy work through ordinary startup, beyond the recovery environment.
A partition can host a PV; a VG pools PV space; an LV consumes VG extents; a filesystem lives on a suitable block device and is attached at a mount point.
A stable identity reduces dependence on discovery order, but verify that it uniquely identifies the intended device and remains correct after cloning.
The block-device/LV capacity and the filesystem capacity. Growing one does not by itself prove the other grew.
Inspect fstab syntax, identities and options, then use a controlled mount preflight and findmnt checks. mount -a does not prove swap or all changed live options.
Existing data and configuration must remain intact. Check the exact target, backups and before/after contents; an unintended deletion can succeed.
XFS supports growth but not shrinking; ext4 supports growth and offline shrink. Apply filesystem-specific tools and correct layer order.
The mounted filesystem exposes its own root inode and permissions, hiding the previous directory contents until unmounted.
Check DNS/routes, server export, protocol/firewall, client support, mount options, identities, Unix permissions and applicable SELinux policy.
Use it when access should trigger a mount and inactivity should release it; prove map lookup, access and expiry rather than just daemon activity.
at schedules a one-off job, cron matches recurring calendar fields, and a systemd timer activates a service with unit dependencies/state/logging.
Its PATH, working directory, identity, environment, permissions and interactive assumptions differ. Specify the required contract explicitly.
A suitable selected time source and tracking/synchronization evidence, alongside service state; daemon activity alone is insufficient.
A saved connection profile describes desired configuration; the live device uses its currently activated state. Verify activation and persistence.
ICMP reachability does not prove name lookup, a listening TCP/UDP application, authentication or authorization.
Runtime affects current traffic; permanent supplies state on reload/start. Compare both and test the relevant zone and peer behavior.
Existing memberships can be removed. Preserve the intended list or use the appropriate append operation, then refresh/test the login session.
Password locking blocks that credential, expiration limits account validity, and an unusable shell limits shell sessions; other access paths require separate checks.
Files store numeric ownership. A reused UID can make old files appear owned by the new account unless those files are reviewed.
Use visudo validation, narrow the identity/command scope and test allowed and denied commands as the target account.
Network rules control traffic, the service controls listeners/behavior, Unix permissions control file access, and SELinux constrains process access.
It stops enforcement without establishing the correct policy or labels. Repair the cause, restore enforcing mode and repeat the test.
Use restorecon to apply the expected policy mapping. For a nonstandard path, establish a persistent mapping first; chcon is not durable policy intent.
Correct account/key mapping, directory/file ownership and permissions, server policy, applicable contexts, and a real login with the intended key.
Required mounts/swap, network/resolution, services/timers, access controls, logs/time and the end-to-end application or task outcome.
Map every current task, especially Flatpak/timers and RHEL 10 storage/boot/security behavior. Do not infer exam scope from an older course or new product feature.

RHEL 9-to-10 preparation checklist¶

Before relying on older material, map it line by line to the live objectives. Specifically confirm current practice for:

RPM repository structure and current DNF behavior;
Flatpak repository and package operations;
simple shell scripts using arguments, command substitution, conditions and loops;
systemd timer units alongside at and cron;
GPT partitioning, LVM, UUID/label persistence, swap, VFAT/ext4/XFS and supported extension paths;
current NetworkManager, IPv4/IPv6, hostname resolution, firewalld, SSH, SELinux and bootloader/recovery procedures;
any removed older objectives—do not study a legacy task as current solely because it appears in an old course;
a complete reboot-and-validate loop on the RHEL 10 minor version available to you.

Source map and freshness notes¶

The live Red Hat exam page is the objective and product-version contract. RHEL 10 documentation is the technical authority. Official course pages describe recommended preparation; third-party resources are optional learning paths.

VERIFY CURRENT: exact exam appointment duration/price/delivery rules, RHEL 10 minor version, objective text, DNF/Flatpak/NetworkManager/systemd/firewalld/SELinux/boot behavior, course versions, runtimes and access.
Stable performance pattern: inspect → change minimally → validate runtime and policy → persist → reboot → validate again → recover/rollback.
Older resources: retain for durable Linux knowledge only after closing every current RHEL 10 objective gap.

This guide uses no recalled exam tasks or restricted course content. The scenarios, labs and checks are original and test only public objectives and product behavior.

Places to learn¶

This is not a complete list, and it is not meant to be consumed in full. Select one primary RHEL 10 route, use current documentation for gaps, and spend at least as much time performing and recovering tasks as watching or reading. Public metadata was checked September 28, 2026. Both O'Reilly book/video pages blocked automated access, so their previously observed editions and runtimes below were not reverified. Sign-in-only lessons were not reviewed. Other totals are planning estimates.

Resource	Access	Estimated time
EX200 objectives and RHEL 10 documentation	Public	8–16 hours selected mapping/reference
Red Hat RH124 + RH134	Paid/RHLS	About 10 instructor-led days plus labs
Red Hat RH199 rapid track	Paid/RHLS	About 5 instructor-led days plus labs
O'Reilly / Sander van Vugt RHEL 10 video	Paid/trial	15 hours 7 minutes plus 30–60 hours labs
O'Reilly / Sander van Vugt RHCSA 10 Cert Guide	Paid/book	714 pages / 15 hours 39 minutes listed plus labs
O'Reilly live RHEL 10 prep	Paid	Four live days with labs and practice review
Chrony client verification — Morgan Peterman, June 6, 2022	Public	10–15 minutes reading plus 30–45 minutes comparing daemon/source/clock evidence; reconcile with RHEL 10
KodeKloud RHCSA RHEL 10	Paid	Runtime varies; plan 35–60 hours with labs/mock exams
Coursera RHCSA Certification Preparation	Paid/audit varies	Provider pacing: four weeks at ten hours/week; plan 45–80 hours with independent RHEL 10 practice

Official standard route: RH124 plus RH134, both based on RHEL 10. Red Hat's skills path has historically listed five days each; delivery format and lab entitlement vary.
Official experienced route: RH199 combines the core path for experienced Linux administrators (about five instructor-led days historically). It is intentionally too fast for a new Linux user.
Official free orientation: RH024 is a free technical overview (about three hours), useful before RH124 but not complete EX200 preparation.
Previously observed video; metadata not reverified: O'Reilly/Pearson Red Hat RHCSA RHEL 10 with Exam Labs by Sander van Vugt is 15 hours 7 minutes, published August 2025, with lesson labs and a sample exam.
Previously observed book; metadata not reverified: O'Reilly/Pearson Red Hat RHCSA 10 Cert Guide is 714 pages / 15 hours 39 minutes listed, June 2026, with chapter labs and four practice exams.
Live option: O'Reilly Red Hat RHCSA RHEL 10 Prep is structured as four live days with labs and final practice review; verify the next session times and availability.
Interactive labs: KodeKloud RHCSA lists Andrei Balint and lab/course content. The earlier review recorded an August 2026 RHEL 10 replacement announcement; the public page fetched on September 28 did not independently establish that version. Verify the signed-in curriculum. Allow 35–60 hours as a practice estimate; no stable current combined runtime was exposed.
Structured alternative: Coursera RHCSA Certification Preparation publicly describes four RHEL 10 courses and pacing of four weeks at ten hours/week. Allow 45–80 hours with independent repetition; these are planning estimates, not proof that the signed-in lessons cover every objective.
Practice environment: RHEL downloads are available through no-cost Red Hat Developer membership. Match the major version, use disposable VMs, snapshot risky exercises, and never expose an insecure lab to the internet.

No exact current EX200 Pluralsight, Whizlabs, or MeasureUp product was independently verified September 28. Avoid question-dump claims: performance readiness is demonstrated by observable system state, recovery, and persistence. A realistic total is 120–200 hours for an experienced Linux user and 250–400 hours for a Linux beginner.