RHCSA Exam Changes 2026: What Actually Changed in EX200 for RHEL 10

$ grep -E '^(NAME|VERSION)=' /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="10.0 (Coughlan)"

$ uname -r
6.12.0-*.el10.x86_64   # RHEL 10 ships the 6.12 kernel line; the build suffix moves with each minor release

What Red Hat actually changed in EX200 for RHEL 10

Exam version changes at Red Hat are not press releases. There is no blog post saying "EX200 is now v10". The objectives page just changes one day, and everyone downstream (course authors, lab vendors, the SERP full of "RHCSA 2026" articles) catches up at their own pace. So the only reliable move is to diff the current objectives against the ones you memorized. I did that diff. Here is what came out of it.

The blueprint is now RHEL 10

The official EX200 page states the exam is based on Red Hat Enterprise Linux 10. RHEL 10 itself went GA in May 2025, so the exam followed the platform with the usual lag. That matters more than it sounds, because RHEL 10 removed things an RHCSA candidate used to touch daily: the X.Org server is gone (Xwayland only), the legacy ifcfg- network scripts in /etc/sysconfig/network-scripts/ are no longer supported, and package modularity is no longer part of the picture. If you are drilling on a RHEL 9 image, some of your muscle memory is now wrong.

Out: the containers domain

The RHEL 9 blueprint had a tenth domain, "Manage containers", with eight objectives: pull images from a registry, inspect images, use podman and skopeo, build from a Containerfile, run and list containers, run a service in a container, configure a container to start as a systemd service, attach persistent storage. On the current RHEL 10 objective list, that section does not exist. Not trimmed, not reworded: absent.

That is a real change and it is the single biggest time saver in your study plan, because container objectives were the part most people over-prepared. It also fits the wider reorganization: containers now live in the cloud-native track, where EX188 was renamed to "Red Hat Certified Developer in Cloud-native Applications".

Caveat worth stating plainly: my evidence for the removal is the absence of the section from Red Hat's live objectives page, cross-checked against the RHEL 9 list. Red Hat did not publish a changelog saying "we removed containers". Absence from the official blueprint is the strongest evidence available, and it is the same evidence Red Hat expects you to act on, but it is absence, not an announcement.

In: a "Manage software" domain, with Flatpak

The RHEL 10 list opens a domain that did not exist before, right after the essential tools section:

• Configure access to RPM repositories
• Install and remove RPM software packages
• Configure access to Flatpak repositories
• Install and remove Flatpak software packages

Flatpak in the RHCSA is new territory. It is also the objective people will handle worst, because almost nobody administering servers has ever added a Flatpak remote from a shell. The mechanics are small and very learnable, and I walk through them below.

In: systemd timer units

Under "Deploy, configure, and maintain systems", the RHEL 9 objective read "Schedule tasks using at and cron". The RHEL 10 objective reads "Schedule tasks using at, cron and systemd timer units". Writing a .timer unit by hand, with a correct OnCalendar= expression, is now explicitly in scope.

Reworded: privileged access

Under "Manage users and groups", "Configure superuser access" became "Configure privileged access". Same territory (sudo, /etc/sudoers.d/, the wheel group), broader wording. I would not read a dramatic change into a rename, but I would practice sudoers drop-in files until they are boring.

The bigger change is not the exam, it is the map around it

On 11 May 2026 Red Hat restructured the certification portfolio itself, and this one is announced, in Red Hat's own post. Five tracks (Enterprise Linux, Ansible, OpenShift, cloud-native applications, AI) crossed with five levels (Technologist, Administrator/Developer, Engineer, Specialist, Architect).

RHCSA keeps its name, keeps the EX200 code, and sits at level 2 in the Enterprise Linux track. Nothing to do there. The part that surprised me is one level up. On Red Hat's certification listing, the Engineer level of the Enterprise Linux track is Red Hat Certified Engineer in Enterprise Linux, and its required exam is EX342, the troubleshooting-focused advanced system administration exam, with RHCSA as the prerequisite. EX294, the Ansible automation exam that was the RHCE for years, now belongs to the Ansible track, where it is titled "Red Hat Certified Advanced System Administrator in Ansible".

So if your plan was "RHCSA, then RHCE via EX294", that plan still exists, but it now means Ansible track rather than Enterprise Linux track. Pick deliberately instead of by inertia. The other consequence is at the top: RHCA now requires five credentials inside a single track (one Administrator/Developer, one Engineer, three Specialists) instead of any five specialist exams from the whole catalog. Existing certifications stay valid for their three years and nobody has to retest because of the restructure.

What did not change

• The format. Still entirely performance based. No multiple choice. You get a broken or empty system and you make it work.
• The persistence rule. Red Hat still states that configurations must survive a reboot without intervention. Every task you finish, reboot and re-verify. This single habit fails more candidates than any objective does.
• Closed book. No internet, no notes. Product documentation may be available on the exam system, which is why man -k and /usr/share/doc are literally an objective.
• Validity. Three years, per Red Hat's certification FAQ. Expired certifications cannot be renewed, they have to be earned again.
• SELinux and firewalld. Still a full domain each way: enforcing and permissive modes, file and process contexts, restorecon, port labels, booleans, plus firewall-cmd. Nothing in the RHEL 10 blueprint softened here, and no exam task is ever solved by turning SELinux off.

What I could not confirm

This is the section the AI-generated "RHCSA 2026" pages do not have, so read it carefully.

• The exact date EX200 flipped to RHEL 10. I found no Red Hat announcement with a date. Anyone giving you a precise switchover date is inferring it.
• Whether a RHEL 9 version of EX200 is still schedulable in your region. Red Hat's public page lists RHEL 10 only. If you hold an older voucher, confirm the version at scheduling time and treat your appointment confirmation as authoritative.
• Price and duration are not on the objectives page. US$500 in the United States and three hours are what the market consistently reports and what has been true for years, but pricing varies by region and Red Hat sells through regional storefronts. Check the price at checkout, not in a blog post. Red Hat's FAQ does say the restructure did not change exam prices.
• Number of tasks and passing score. Red Hat has never published these, and still does not. The passing score for RHCSA has long been reported as 210 out of 300. Treat that as folklore that has held up, not as a published fact.
• "20 to 25 percent of the content changed." That figure is circulating on several sites. It has no source. The verifiable diff is the one above: one domain removed, one added, two objectives reworded.

Build a lab that matches the new blueprint, at zero cost

The cheapest correct answer is the Red Hat Developer Subscription for Individuals: free, real RHEL 10, and it entitles you to register systems with subscription-manager. That last part matters, because "install and update software packages from the Red Hat Content Delivery Network" is an objective and a rebuild distro cannot reproduce it. AlmaLinux 10, Rocky Linux 10 and CentOS Stream 10 are fine for 90 percent of the drills and cost nothing either, they just cannot teach you the subscription workflow. Two VMs beat one, because NFS and autofs objectives need a server and a client.

If you are standing up that lab from scratch, my initial server setup guide for AlmaLinux 10 and Rocky Linux 10 covers the users, SSH keys, firewalld and SELinux baseline in the same order the exam expects you to know it.

1. Drill the Flatpak objective

Install the tooling and look at what remotes exist:

# dnf install -y flatpak
Installed:
  flatpak.x86_64  (plus its dependencies)
Complete!

# flatpak remotes
# no output at all: no remote is configured yet

An empty listing is the state you will most likely be handed. Adding a remote is a single command. Against a network repository it looks like this:

# flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

# flatpak remotes
Name     Options
flathub  system

Here is the nuance that most study material misses: the exam has no internet. So practice the offline shape too, pointing at a local repository directory or a repo served over HTTP from your second VM, and get comfortable with the flags:

# flatpak remote-add --no-gpg-verify labrepo /srv/flatpak-repo
# flatpak remote-ls labrepo
# flatpak install labrepo org.example.App
# flatpak list --app
# flatpak uninstall org.example.App

Know the difference between --system (default, root, everyone on the box) and --user (per account, no root). If a task says "available to all users", it is a system installation. That is exactly the kind of detail a grading script checks.

2. Drill systemd timers

Two files. The service does the work, the timer decides when. Write them by hand until you can do it without looking:

# cat /etc/systemd/system/lab-report.service
[Unit]
Description=Lab report job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/lab-report.sh

# cat /etc/systemd/system/lab-report.timer
[Unit]
Description=Run the lab report job daily at 03:00

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

Check the calendar expression before you enable anything. systemd-analyze tells you whether your syntax means what you think it means:

# systemd-analyze calendar '*-*-* 03:00:00'
  Original form: *-*-* 03:00:00
Normalized form: *-*-* 03:00:00
    Next elapse: (the next 03:00 in the system timezone)
       From now: (time remaining)

Then load, enable and verify. Note that you enable the timer, never the service:

# systemctl daemon-reload
# systemctl enable --now lab-report.timer
Created symlink /etc/systemd/system/timers.target.wants/lab-report.timer → /etc/systemd/system/lab-report.timer.

# systemctl list-timers lab-report.timer
NEXT                        LEFT     LAST  PASSED  UNIT              ACTIVATES
...                         ...      ...   ...     lab-report.timer  lab-report.service

Persistent=true is the one that catches people: it runs a missed job after a reboot instead of silently skipping it. Given that the exam reboots your machine, that flag is not decoration. And at and cron are still in the objective, so keep at now + 5 minutes, atq, crontab -e and /etc/cron.d/ in the rotation.

3. Drill privileged access

Never edit /etc/sudoers directly. Drop-in file, validated:

# visudo -f /etc/sudoers.d/ops
# write, for example:  %ops ALL=(ALL) NOPASSWD: /usr/bin/systemctl

# visudo -cf /etc/sudoers.d/ops
/etc/sudoers.d/ops: parsed OK

# sudo -lU alice
User alice may run the following commands on rhel10lab:
    (ALL) ALL

sudo -lU is the verification step. Do not assume group membership took effect: check it from the outside.

4. Do not economize on SELinux

The security domain still asks for enforcing and permissive modes, listing and identifying file and process contexts, restoring default contexts, managing SELinux port labels and flipping booleans. Every one of those is a command you either know cold or lose points on. The workflow I use in production is the same one that passes exam tasks: read the denial with ausearch, understand it, then fix the label, the port or the boolean. I wrote that whole loop up in SELinux troubleshooting: fixing AVC denials without disabling SELinux, and it doubles as the study path for this domain.

# ls /etc/sysconfig/network-scripts/
(empty)

# nmcli -f NAME,DEVICE,TYPE connection show
NAME    DEVICE  TYPE
ens192  ens192  ethernet

# ls /etc/NetworkManager/system-connections/
ens192.nmconnection

Bottom line

If you were preparing for RHCSA on RHEL 9, you did not waste your time: nine of the ten domains carried over nearly intact. Delete the container chapter, add two evenings for Flatpak and systemd timers, move your lab to RHEL 10, and re-read the sudoers material. The bigger decision is the one above the exam, where the Enterprise Linux track now points at EX342 for the Engineer level and EX294 has moved to Ansible. Choose that path on purpose.

And the oldest advice still holds, because the format never changed: the exam is not about remembering commands, it is about repairing systems under time pressure. Build the lab, break it, fix it, reboot, verify.

Primary sources, all read on 3 August 2026: Red Hat's EX200 exam page (current objectives and the RHEL 10 basis), Red Hat's certification update announcement (tracks and levels, effective 11 May 2026), the Red Hat Certified Engineer in Enterprise Linux requirements (EX342), the training and certification FAQ (three-year validity, no price change), and the RHEL 10 removed features documentation. No affiliate links in this post, and no paid course or lab platform is recommended anywhere in it.