RHCSA: essential skills

This page lists the official skills of the RHCSA exam (EX200), as published by Red Hat in the certification's study points. For each block, it translates these skills into concrete know-how to demonstrate on RHEL 10.

It is not a closed list of commands to memorise. Red Hat publishes skill objectives, not a checklist of tools. The goal is to help you identify what you must be able to do on exam day, a performance-based exam where each task must produce a working result on a real RHEL system.

What you will learn

• Place the ten official sections of the EX200 on RHEL 10
• Translate each published objective into concrete actions to demonstrate
• Avoid the frequent pitfalls, block by block
• Prioritise the most discriminating skills before the exam

The EX200 exam is based on RHEL 10

The RHCSA is now based on Red Hat Enterprise Linux 10. Your preparation must be done on a RHEL 10 environment or a very close equivalent. Check the official objectives before registering: redhat.com, EX200.

The RHCSA is the mandatory foundation for the RHCE (EX294). Passing the RHCSA means mastering day-to-day system administration in a Red Hat environment.

The exam takes place on an isolated workstation, and this constraint shapes all your preparation: you will have to find a command option on your own, with no search engine or assistant. So practise with the same resources as those allowed on the day.

Resources allowed during the exam

From the exam terminal, you can use: man, --help, info and /usr/share/doc. You can install packages from the RHEL repositories provided. No Internet access, no external documentation.

The main EX200 skill blocks

Red Hat does not publish a numerical weighting per block. The official EX200 page for RHEL 10 splits its objectives into ten sections, listed below in its order and under their original title (checked on 2026-10-01).

Official section	What it covers
Understand and use essential tools	Shell, redirections, grep, regex, SSH, files, links, permissions, documentation
Manage software	RPM repositories, RPM packages, Flatpak repositories and applications
Create simple shell scripts	Conditionals, loops, script arguments, command output
Operate running systems	Boot targets, boot interruption, processes, tuning, logs, network services, transfers
Configure local storage	GPT partitions, LVM, swap, persistent mounts by UUID or label
Create and configure file systems	VFAT, ext4, XFS, NFS, autofs, LV extension, permission problems
Deploy, configure, and maintain systems	Scheduling, services at boot, default target, time client, packages, boot loader
Manage basic networking	IPv4 and IPv6, hostname resolution, network services at boot, firewalld
Manage users and groups	Accounts, passwords and aging, groups, privileged access
Manage security	Firewall, default permissions, SSH keys, SELinux

Swipe to see more

This page groups Manage software and Manage basic networking into the Deploy, configure, and maintain systems block, and access restriction with firewalld into Manage security. Container management, for its part, no longer appears in the objectives published for RHEL 10; see the matching section further down.

How to read this page

For each block, the "Official skills" section repeats the objectives published by Red Hat. The "What it means in practice" section is a teaching translation: it describes what a candidate must be able to do in practice on RHEL 10.

---

Understand and use essential tools

This block covers mastery of the shell, file handling, standard Unix permissions and the use of the built-in documentation.

Official skills

Here are the objectives published by Red Hat for this block, translated without rewording. They describe actions, not commands: "archive, compress, unpack" imposes neither tar nor gzip, it is the result that is assessed. Read them as the list of situations the automatic grader can hand you.

1. Access a shell and issue commands with correct syntax
2. Use input-output redirection (>, >>, |, 2>, etc.)
3. Use grep and regular expressions to analyse text
4. Access remote systems using SSH
5. Log in and switch users in multi-user targets
6. Archive, compress, unpack files with tar, gzip, bzip2
7. Create and edit text files
8. Create, delete, copy and move files and directories
9. Create hard and soft links
10. List, set and change standard ugo/rwx permissions
11. Locate, read and use system documentation, man, info, /usr/share/doc

What it means in practice

This block is the one you think you have mastered and that still costs time on the day. The difference between a fast candidate and a slow one is not knowledge of the commands but the absence of hesitation: every round trip to a man page to find an option is paid for in a timed exam. The six families below must be worked on until they become a reflex.

Shell and redirections:

• Chain commands with pipes without hesitation
• Redirect stdout, stderr or both to a file, know the difference between overwriting and appending
• Use tee to display and save at the same time
• Work cleanly without syntax errors; in the exam, a redirection mistake can produce an incomplete result

Grep and regular expressions:

• Search for a pattern in a file or recursively in a tree
• Use basic and extended regex: anchors (^, $), character classes, alternation
• Exclude lines (comments, empty lines)
• Combine grep with other tools (awk, cut, sort, uniq) to extract and format data

SSH:

• Connect to a remote system with a specific user
• Use scp and rsync to transfer files securely
• Work on a remote system as if it were the local system

Files, links, archives:

• Create, copy, move and delete files and directories quickly
• Understand the difference between a hard link and a symbolic link, know when to use each
• Create a compressed tar archive (gzip or bzip2) and extract it into a target directory
• List the content of an archive without extracting it

Permissions:

• Read and interpret the permissions shown by ls -l
• Change permissions in symbolic and octal notation
• Understand the special bits: SUID, SGID, sticky bit
• Apply a suitable umask
• Change the owner and group of a file or a tree

Documentation:

• Quickly find an option in a man page (navigation, search with /)
• Identify the right man section when several exist
• Look in /usr/share/doc for configuration examples

Frequent pitfalls

These four mistakes have in common that they are silent: nothing signals the failure, and you discover the problem when rereading the result, or never. The first is the most destructive, because it destroys the configuration file the next task was expecting.

• Confusing > (overwrite) and >> (append): a candidate can overwrite a configuration file by mistake
• Forgetting the quotes around regexes in grep: the shell interprets the special characters
• Not knowing man -k to search for a command by keyword
• Applying chmod -R too broadly without thinking about the consequences on files and directories

---

Create simple shell scripts

This block is dedicated to simple shell scripts. It is not about advanced development, but about the ability to automate an administration task with a working Bash script.

Official skills

Red Hat details this block in four objectives, all centred on the structure of a script, never on a library or a writing style. Remember the wording of the last one: processing the output of a command inside a script, which assumes you know how to capture output and loop over it.

1. Conditionally execute code (if, test, [ ], etc.)
2. Use loops (for, etc.) to process a file or command line input
3. Process script inputs ($1, $2, etc.)
4. Process the output of shell commands within the script

What it means in practice

An exam script does not need to be elegant, it must produce the right result without intervention. The grader runs your script, possibly with arguments, and looks at what comes out. So work on the seven points below while forcing yourself to run the script from a different directory than the one where you wrote it: it is the condition closest to the exam.

• Write a Bash script with a shebang (#!/bin/bash) and the right execute permissions
• Use variables (assignment, expansion, special variables $?, $1, $#)
• Write conditionals: if/elif/else, tests on files (-f, -d, -e), on strings, on numeric values
• Write loops: for, while, iterating over a list or over a command's output
• Handle a return code: test the success or failure of a command and react accordingly
• Read and modify a small existing script without getting lost
• Make the script executable and run it correctly

Frequent pitfalls

Three of these four pitfalls prevent the script from starting or make it fail without a clear message. The second is the most insidious: [[ "$a" = "$b" ]] compares strings, [ "$a" -eq "$b" ] compares numbers, and mixing them up gives a test that "works" on some values and not on others.

• Forgetting the shebang or the execute permissions: the script does not run
• Confusing = (string comparison in [[ ]]) and -eq (numeric comparison)
• Not testing the return code of the previous command when the script must react to a failure
• Writing scripts without minimal error handling: in the exam, a script that crashes silently scores no point

---

Operate running systems

This block covers the operational management of a running system: boot, processes, tuning, logs, services and file transfers. Scheduling, attached by Red Hat to the Deploy block, is handled here with the other operating actions.

Official skills

This block is the broadest of the exam, and it contains boot recovery, the most mechanical exercise and the most rewarding one to automate mentally. Two objectives are often forgotten in preparations: adjusting a process's scheduling, and preserving the system journals between two reboots.

1. Boot, reboot and shut down a system normally
2. Boot into different targets manually
3. Interrupt the boot process in order to gain access to a system
4. Identify CPU- or memory-intensive processes and kill them
5. Adjust process scheduling (nice, renice)
6. Manage tuning profiles (tuned-adm)
7. Locate and interpret log files and system journals
8. Preserve system journals across reboots
9. Start, stop and check the status of network services
10. Securely transfer files between systems

What it means in practice

The thread running through this block is the move from observation to action: noticing that a service has failed scores nothing, you must read the journal, understand the cause and fix it. The five families below are practised on a real machine that you reboot on purpose, not by reading.

Boot and targets:

• Know the main systemd targets: multi-user.target, graphical.target, rescue.target, emergency.target
• Change the default target persistently
• Switch to a target live to diagnose a problem
• Interrupt the boot through GRUB2: edit the boot entry to add a kernel parameter
• Run the rd.break procedure to reset the root password, including the remount read-write, the chroot, the password change and the touch /.autorelabel required by SELinux

Processes:

• List the processes and identify the one using the most CPU or memory
• Send a signal to a process: graceful stop (SIGTERM), forced stop (SIGKILL)
• Change the priority of a running process (nice/renice)
• Manage shell background jobs (bg, fg, jobs, nohup)

Logs:

• Read the logs of a specific service with journalctl
• Search the logs by date, priority or unit
• Configure journal persistence (/etc/systemd/journald.conf) to keep logs across reboots
• Read the logs of the previous boot (only possible if persistence is configured)

Scheduling:

• Create a recurring task with cron, master the 5-field syntax
• Create a one-off deferred task with at
• Check that a scheduled task is in place
• Know the /etc/cron.d/, /etc/cron.daily/… directories

Services:

• Start, stop, restart a service with systemctl
• Enable a service at boot with systemctl enable
• Check that a service is active and enabled, understand the difference
• Diagnose a service in the failed state by reading the logs

File transfer:

• Copy a file to a remote system with scp or rsync over SSH
• Keep permissions and timestamps during the transfer
• Check the integrity of the received file on the remote side

Frequent pitfalls

These four mistakes share the same symptom: everything seems to work during the session, and the point disappears after the assessment reboot. The first is the most brutal, as it can make the system unusable at the next boot.

• Forgetting touch /.autorelabel after the rd.break procedure: SELinux blocks the system at the next boot
• Confusing systemctl enable (persistent) and systemctl start (immediate): both are needed, or use systemctl enable --now
• Not configuring journald persistence: without it, logs are lost at reboot and post-reboot diagnosis is impossible
• Neglecting tuned: knowing how to activate a performance profile is part of the operate running systems objectives

---

Configure local storage

This block covers partitioning, logical volumes, swap and persistent mounts.

Official skills

Red Hat breaks this block down to the level of each LVM object, which is a strong hint: the exam expects the full chain, from the raw disk to the persistent mount point. The last objective contains the most important word, "non-destructively": adding space must never lose existing data.

1. List, create and delete partitions on GPT disks
2. Create and remove physical volumes (PV)
3. Assign physical volumes to volume groups (VG)
4. Create and delete logical volumes (LV)
5. Mount file systems at boot by UUID or by label
6. Add partitions, logical volumes and swap non-destructively

What it means in practice

Storage is the block where a mistake shows immediately at reboot, and it is also the one that can stop the machine from booting. Always work in this order: create, format, test the mount, and only then write to /etc/fstab. The four families below follow this progression.

Partitions:

• Create GPT partitions with gdisk or parted
• Tell the kernel that a partition table has changed (partprobe)
• Identify the available disks and partitions (lsblk, blkid)

LVM:

• Create a Physical Volume, a Volume Group and a Logical Volume
• Extend a VG by adding a disk, then extend an LV
• Resize the file system after extending the LV, resize2fs for ext4, xfs_growfs for XFS (mounted only)
• Create an LVM snapshot if asked
• Cleanly delete an LV

Swap:

• Create a swap partition or a swap file
• Enable swap temporarily and persistently through /etc/fstab
• Check the state of the active swap

Persistence (fstab):

• Mount a file system through /etc/fstab using the UUID, never /dev/sdX
• Test the consistency of /etc/fstab before the reboot (mount -a, findmnt --verify)
• Understand that an error in fstab can stop the system from booting

Frequent pitfalls

The first two pitfalls in this list are the most frequent of the whole exam. The third is the most serious: a syntax error in /etc/fstab drops the system into maintenance mode at reboot, and you then lose much more than a point on one task.

• Using /dev/sdb1 instead of the UUID in /etc/fstab: device names can change between reboots
• Extending an LV without resizing the file system: the extra space stays invisible
• Not testing mount -a after changing /etc/fstab: a syntax error can make the system unbootable
• Forgetting to create the mount point (mkdir -p) before adding the fstab entry

---

Create and configure file systems

This block covers the creation of file systems, labels, network file systems and advanced permissions (ACLs), useful for the permission diagnosis objective.

Official skills

This block explicitly names the three file systems expected, and it puts autofs on the same level as the classic NFS mount: it is the most often neglected topic of the whole exam. The last objective is worded as a diagnosis, not as a configuration, and that is indeed how it comes up.

1. Create, mount, unmount and use VFAT, ext4 and XFS file systems
2. Mount and unmount network file systems using NFS
3. Configure autofs
4. Extend an existing logical volume
5. Diagnose and correct file permission problems

What it means in practice

The word to remember here is mounted. Many operations do not behave the same depending on whether the file system is mounted or not: xfs_growfs requires it to be, xfs_repair requires the opposite. Always check the state with findmnt before acting; the five families below depend on it.

Creating and managing file systems:

• Format a partition or an LV as ext4, XFS or VFAT
• Give a file system a label
• Check and repair an unmounted file system (e2fsck, xfs_repair)
• Mount a file system with the appropriate options

Attributes and labels:

• Change the label of an existing file system
• Find the UUID of a block device with blkid

ACL:

• Add a permission for a specific user or group on a file or directory
• Set default ACLs so that new files inherit the permissions
• Remove targeted ACLs or reset all ACLs
• Check for ACLs with getfacl and recognise the + in the output of ls -l

NFS:

• Mount an NFS share persistently through /etc/fstab (the nfs type is enough for systemd to treat it as a network mount)
• Discover the exports available on an NFS server (showmount -e)
• Enable the NFS client service if needed

Autofs:

• Configure autofs to mount a share on demand
• Understand the relationship between /etc/auto.master and the map files
• Enable autofs and check that it works

Frequent pitfalls

The first pitfall is a widespread belief about network mounts, which makes you look for the failure in the wrong place. The last two concern ACLs, whose inheritance behaviour is anything but intuitive and is only learnt by handling them.

• Believing _netdev is essential for NFS: according to systemd.mount(5), systemd recognises the nfs type as a network mount and orders it after the network; the option is only for mounts whose type does not give them away, such as an iSCSI volume
• Not practising autofs: dynamic mounting is a topic only mastered through lab practice
• Confusing classic ugo/rwx permissions and ACLs: ACLs do not replace the basic permissions, they complement them
• Forgetting setfacl -d for default ACLs: new files do not automatically inherit the parent directory's ACLs

---

Deploy, configure, and maintain systems

This block covers software installation, repository management, system maintenance and the configuration of basic services.

Official skills

This block brings together the objectives of two official sections: Deploy, configure, and maintain systems and Manage software. Two objectives are regularly underestimated: the time client configuration (chronyd), and the boot loader modification, which is not the same thing as the boot interruption seen above.

1. Schedule tasks using at, cron and systemd timer units
2. Start and stop services, and configure them to start at boot
3. Configure systems to boot into a specific target automatically
4. Configure time service clients
5. Install and update packages from the Red Hat CDN, a remote repository or the local file system
6. Modify the system boot loader
7. Configure access to RPM repositories, install and remove RPM packages
8. Configure access to Flatpak repositories, install and remove Flatpak applications

What it means in practice

This block is the one where persistence is easiest to forget, because everything works during the session: a service started without enable, an interface configured with ip addr instead of nmcli, an at task instead of a cron entry. AppStream modules, taught for RHEL 8 and 9, are no longer part of it: modularity is deprecated under DNF5 and does not appear in the RHEL 10 objectives. The five families below each cover a case where the immediate command and the persistent command differ.

Package management (dnf/rpm):

• Install, remove, update a package
• Search for a package or identify which package provides a given file
• Read the transaction history and roll back if needed
• Check the integrity of an installed package

Repositories (yum/dnf repos):

• Add an external or local repository
• Enable or disable an existing repository
• Create a .repo file in /etc/yum.repos.d/ with the right syntax
• Clear and rebuild the cache

Flatpak:

• Add a Flatpak repository (Flathub)
• Install, list, update and remove a Flatpak application
• Flatpak is part of the EX200 objectives, do not neglect it

Tuned:

• List the available tuning profiles
• Activate a performance profile suited to the system's use
• Check the active profile and know which profile is recommended

Basic network configuration:

• Configure a network interface with a static IPv4 and IPv6 address through nmcli
• Change the hostname persistently
• Configure DNS resolution
• Add persistent static routes
• Apply the changes without a reboot

Frequent pitfalls

The first and last pitfalls in this list describe the same confusion seen from two angles: on RHEL, changing a network configuration and applying that change are two distinct actions. The third reminds you that Flatpak is indeed a published objective, despite its anecdotal look.

• Forgetting nmcli con up after nmcli con mod: the changes are not applied until the connection is reactivated
• Not knowing how to create a .repo file by hand: in the exam, the repository may not be preconfigured
• Ignoring Flatpak in the preparation: it is a recent official objective
• Confusing immediate and persistent network configuration: without nmcli, ip addr changes are temporary

---

Manage users and groups

This block covers the management of user accounts, groups and access rights.

Official skills

Only four objectives, but the last one, "configure privileged access", covers on its own the whole sudo delegation. Also note that password aging is cited explicitly: it is not a detail, it is an objective in its own right.

1. Create, delete and modify local user accounts
2. Change passwords and adjust password aging for local user accounts
3. Create, delete and modify local groups and group memberships
4. Configure privileged access (sudo)

What it means in practice

This block is graded almost entirely with the id command and the /etc/shadow file. So get into the habit of ending each task with a verification showing the real state of the account, rather than relying on the absence of an error message. The four families below depend on it.

User accounts:

• Create a user with precise parameters: home, shell, UID, primary group, secondary groups
• Add a user to a secondary group without losing their existing groups (usermod -aG)
• Lock and unlock an account
• Delete an account and its home directory
• Set a password interactively and non-interactively

Password policy:

• Configure password expiry (max duration, min duration, warning)
• Configure account expiry (deadline)
• Force a password change at next login
• Check the policy applied to a user

Groups:

• Create a group with a specific GID
• Add and remove group members
• Check a user's group memberships

sudo delegation:

• Configure targeted sudo rules in /etc/sudoers.d/
• Apply least privilege: do not grant ALL=(ALL) ALL when a specific command is enough
• Check a user's effective sudo rights
• Understand the role of the wheel group on RHEL

Frequent pitfalls

The first pitfall is the most classic of all Linux administration, and it produces no error message: the user simply loses their other groups, which breaks access elsewhere on the system. The last one creates an account that exists but stays unusable, so it is not validated by the grader.

• Using usermod -G instead of usermod -aG: without -a, the existing secondary groups are overwritten
• Not checking the result with id after a change: the exam assesses the result, not the command
• Creating sudo rules that are too permissive: in a Red Hat environment, least privilege is expected
• Forgetting to set a password after useradd: the account exists but cannot be used

---

Manage security

This block covers system security: firewall, SELinux and SSH key authentication.

Official skills

It is the block whose objectives Red Hat details the most, and five of them are about SELinux alone. The message is clear: the exam does not ask you to "know" SELinux, it asks you to be able to diagnose and fix it in Enforcing mode. The objective on default permissions points to umask, often forgotten.

1. Configure firewall settings using firewall-cmd / firewalld
2. Manage default file permissions (umask)
3. Configure key-based authentication for SSH
4. Set SELinux to Enforcing and Permissive modes
5. List and identify SELinux file and process contexts
6. Restore default file contexts
7. Manage SELinux port labels
8. Use booleans to modify SELinux behaviour

What it means in practice

Remember that the firewall and SELinux are two independent layers that block different things: opening a port in firewalld tells SELinux nothing, and labelling an SELinux port does not open it in the firewall. For a service on a non-standard port, you almost always have to do both, and that is exactly what the exam is trying to check.

Firewall (firewalld):

• Allow a service or a port in the firewall permanently
• Apply permanent rules with --reload: without a reload, the permanent rule is not active
• Change the default zone
• Check the full firewall configuration
• Understand that --permanent alone does not make the rule immediately active, and that a rule without --permanent is lost at reboot

SELinux:

• Check the current mode (Enforcing, Permissive, Disabled) and the active policy
• Switch from Enforcing to Permissive temporarily and persistently (/etc/selinux/config)
• Display and understand the SELinux context of a file (ls -Z) and of a process (ps -Z)
• Fix a file context: define a persistent rule with semanage fcontext then apply it with restorecon
• Do not use chcon alone: the context will be overwritten at the next relabel
• Enable an SELinux boolean persistently (setsebool -P)
• Allow a non-standard port for a service (semanage port -a)
• Diagnose an SELinux denial: read the audit logs (ausearch -m avc), use sealert to get suggestions, then apply the fix (context, boolean or port)
• Understand that SELinux and the firewall are two independent layers: a service can be blocked by one, the other, or both

SSH keys:

• Generate a key pair (prefer ed25519)
• Deploy the public key to a remote server
• Configure the SSH server: disable password authentication, forbid direct root login
• Check the required permissions on ~/.ssh/ (700) and ~/.ssh/authorized_keys (600)
• Apply SSH server changes without cutting active sessions

Frequent pitfalls

Two of these five pitfalls produce a configuration that works during the session and disappears afterwards: the --permanent rule without --reload, and the context set with chcon. The second pitfall is of another kind, it is a fault of attitude: disabling SELinux to get a task through invalidates the work instead of validating it.

• Adding a firewall rule with --permanent but forgetting --reload: the rule exists in the config but is not active
• Disabling SELinux instead of managing it: the RHCSA requires working in Enforcing mode
• Using chcon instead of semanage fcontext + restorecon: the fix does not survive a relabel
• Forgetting that semanage port and firewall-cmd are two different things: one manages the port's SELinux label, the other allows it in the firewall, both are often needed for a non-standard service
• Wrong permissions on ~/.ssh/: SSH silently refuses key authentication

---

Container management, outside the RHEL 10 objectives

On RHEL, the reference tool for containers is Podman in rootless mode. This block appeared in the EX200 objectives based on RHEL 9; it no longer appears in the list published for RHEL 10.

Containers: check the EX200 objectives before the exam

The list of objectives published by Red Hat for the EX200 on RHEL 10 has no section devoted to containers. This section is kept here because the preparation materials from RHEL 9 still talk about it, and because these skills remain useful in production. Do not spend time on it at the expense of storage, services or SELinux, and reread the official objectives before registering: Red Hat changes them without a separate announcement.

What rootless Podman requires you to know

These actions are not assessed by the EX200 on RHEL 10, but they make up the expected foundation of a RHEL administrator and come up again in the higher-level certifications.

• Search for and pull an image from a registry
• Run a container in the background with an exposed port
• Inspect a container and run a command inside it
• Stop and remove a container
• List local images
• Make a container persistent with a systemd unit
• Enable the container service in rootless mode (systemctl --user enable)
• Configure loginctl enable-linger so that a rootless container starts without an interactive session

Frequent pitfalls

The first pitfall is the one that surprises most: a user service does not survive the end of the session until lingering is enabled. The second is a generational pitfall, because the method taught by most materials is now obsolete.

• Forgetting loginctl enable-linger: the rootless container does not start automatically at boot
• Relying on podman generate systemd: the command prints [DEPRECATED] Generate systemd units and its own help points to Quadlet (podman-systemd.unit(5)), the declarative method now recommended
• Overweighting containers in the preparation at the expense of system fundamentals: this block remains secondary compared with storage, services or SELinux

---

Persistence, the common thread of the RHCSA

The RHCSA is not just about running commands. The exam assesses your ability to produce a stable state that survives a reboot. The system is rebooted before the final assessment.

This concerns every block:

Area	What must persist
Storage	Mounts in /etc/fstab with UUID, swap enabled
Network	Configuration through nmcli (not ip addr), hostname, routes, DNS
Firewall	Rules with --permanent + --reload
SELinux	Contexts through semanage fcontext + restorecon, booleans with -P, ports with semanage port
Services	systemctl enable (not just start)
Journals	Storage=persistent in /etc/systemd/journald.conf
Containers	systemd unit + loginctl enable-linger
Scheduling	crontab entries, files in /etc/cron.d/
Boot target	systemctl set-default
Tuned	tuned-adm profile (persistent by default if the service is enabled)

Swipe to see more

Golden rule: if you configure something during the exam and it is no longer there after reboot, the point is not scored.

---

The most discriminating skills

These topics often make the difference between a candidate who narrowly fails and one who passes. They have one thing in common: they are skills people work around day to day in production, for lack of time or because a colleague handles them, and that become blocking the day you have to carry them out alone and against the clock.

Two clarifications on how to read this table. ACLs and autofs do not have the same status in the RHEL 10 objectives: the former are not named there and fall under the objective "diagnose and correct file permission problems", the latter on the other hand is cited explicitly under Create and configure file systems. And if you had to work on only one line, take LVM and file system resizing: forgetting resize2fs or xfs_growfs after extending the logical volume is the most frequently reported mistake.

Skill	Why it is discriminating
SELinux	Many work around it day to day, the RHCSA requires managing it in Enforcing mode
LVM + FS resizing	Extending an LV without resizing the FS is the most common mistake
Interrupting the boot (rd.break)	A mechanical procedure that must be fluent, the slightest omission blocks
Persistent firewall	The --permanent + --reload pair must be automatic
Services and logs	Diagnosing a failed service with journalctl is expected, not just starting services
fstab with UUID	An error in fstab can make the system unbootable, testing before the reboot is vital
ACL	Advanced permissions are often neglected, and serve the permission diagnosis objective
Autofs	On-demand mounting cannot be improvised, you must have practised it
Shell scripts	A non-working script scores no point, the syntax must be reliable

Swipe to see more

---

Preparation reflexes

These principles apply across all the skill blocks.

Always tell immediate configuration from persistent configuration:

On RHEL, many changes are temporary by default. If you do not know how to make a change permanent, you have not yet mastered the skill.

Always check the result after a change:

The exam assesses the state of the system, not the commands typed. After each action: systemctl status, findmnt, firewall-cmd --list-all, getenforce, ip addr, ss -tulpn…

Know how to diagnose, not just execute:

The blueprint explicitly asks you to troubleshoot and locate problems. Reading logs, interpreting an error message, identifying a cause: these are skills in their own right.

Revise on a RHEL 10 environment:

The exam is based on RHEL 10. The RHEL tools (dnf, nmcli, firewalld, SELinux) are specific; mastering them on another distribution is not enough.

Work on the fundamentals before the peripheral topics:

Storage (LVM, fstab), services (systemd, journalctl), security (firewalld, SELinux) and boot recovery make up the core of the exam. Master them perfectly before the shorter objectives such as Flatpak, and all the more before containers, which are outside the RHEL 10 objectives.

Use the allowed resources:

During the exam, man, --help, info and /usr/share/doc are available. Knowing how to navigate a man page quickly to find the right option saves precious time.

---

Key points

• The RHCSA is a performance-based exam on RHEL 10; each task must produce a working and persistent result.
• Red Hat publishes skill objectives, not a list of commands; the EX200 page describes what you must be able to do.
• The system is rebooted before assessment; anything that is not persistent is lost and scores no point.
• The heaviest blocks are: storage and LVM, services and logs, firewall and SELinux, boot recovery.
• SELinux cannot be worked around: the exam requires working in Enforcing mode and knowing how to diagnose denials.
• The semanage + firewall-cmd pair is often needed together for a non-standard service.
• The RHCSA is the mandatory foundation for the RHCE; the skills acquired here are cumulative.
• Lab practice on RHEL 10 is irreplaceable; rereading a skills page is not enough.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →