EX342 Cheat Sheet 2026: One-Page Review of Must-Know Facts

What This Exam Actually Is

EX342 is the Red Hat Certified Advanced System Administrator in Enterprise Linux exam, delivered by Red Hat, Inc. It is a performance-based test: no multiple-choice questions, no drag-and-drop. You sit in front of live RHEL 10.2 systems that have been deliberately broken and you either fix them or gather the information a third party would need to investigate. The exam runs four hours, relevant product documentation is supplied, and outside assistance is prohibited.

The credential naming changed in the May 2026 framework. The current Red Hat Certified Advanced System Administrator in Enterprise Linux title replaced Specialist in Linux Diagnostics and Troubleshooting, but the exam code did not change. Passing EX342 alone earns the advanced administrator credential. Candidates who hold a current RHCSA (EX200) and then pass EX342 are on the RHCE in Enterprise Linux path. If you want the plain-language orientation first, see What Is EX342? and What Does EX342 Stand For?.

The One-Page Fact Sheet

Everything below is drawn from Red Hat's published exam and policy pages. Where Red Hat does not publish a figure, this sheet says so instead of guessing.

For deeper dives on individual rows, see the EX342 certification cost breakdown, the EX342 passing score guide and the EX342 requirements overview.

The Eight Domains at a Glance

The eight lines below mirror the current exam-objective groups. They are not a course syllabus and carry no official weighting, so treat them as a coverage checklist.

1. Understand and employ general methods for troubleshooting
2. Diagnose and troubleshoot system startup issues
3. Diagnose and troubleshoot file system issues
4. Resolve package management issues
5. Troubleshoot and fix network connectivity issues
6. Diagnose application issues
7. Identify and fix authentication issues
8. Gather information to aid third-party investigation of issues

Notice the shape of this list. Six domains are about breaking points in a system (boot, storage, packages, network, applications, authentication). Two are about process: how you reason through a fault, and how you document one you are not meant to fix. A full walkthrough lives in the EX342 exam domains guide.

Domain 1: The Diagnostic Loop

On a four-hour clock with several broken systems, discipline matters more than cleverness. Candidates who thrash lose time undoing their own changes. A fast habit is to spend the first minutes of each fault on read-only observation: service status, recent journal entries, listening ports, mounted file systems, and recently modified configuration. Only then form a hypothesis.

Startup and File System Faults

System startup (Domain 2)

Expect machines that do not reach their normal target. Your toolkit is the boot-time recovery path: interrupting the boot loader, reaching an emergency or rescue environment, and reading the journal from the failed boot. The key skills are identifying where in the boot sequence things stop (boot loader, kernel and initramfs, systemd unit ordering, or mount failures) and making the correction persistent. Remember that a fix applied only to a one-time boot entry will vanish on the next restart.

• Know how to read the previous boot's messages from the journal.
• Understand systemd targets and what each failing unit blocks.
• Be comfortable regenerating or repairing boot configuration from a rescue shell.
• Check SELinux context problems that surface only after relabeling or file restoration.

File systems (Domain 3)

Storage faults often masquerade as boot or application faults. A bad /etc/fstab entry can drop a system into emergency mode; a full or corrupted file system can silently break a service. Be ready to check mount state, capacity and inode usage, repair a damaged file system safely, and reconcile persistent mount definitions with what is actually present on disk. Understand the layers involved, including partitions, LVM and the file system itself, so you can tell which layer is at fault.

Package and Network Faults

Package management (Domain 4)

Package faults are usually about repositories, dependencies, integrity or a damaged package database. Verify that repository definitions are reachable and correct, that GPG key handling is sound, and that installed files match what the package manager expects. Know how to inspect what a package owns, what changed on disk compared with the packaged original, and how to recover from an interrupted transaction. Practice reading dependency errors literally; they usually name the exact conflict.

Network connectivity (Domain 5)

Work the stack from the bottom up: link state, addressing, routing, name resolution, then firewall and service reachability. A system can have a perfect interface configuration and still be unreachable because of a firewall zone or a service bound to the wrong address. Confirm NetworkManager connection profiles, DNS settings, and firewalld rules, and always test from both ends where possible. Prefer persistent profile changes over transient commands so the fix survives a restart.

• Layer-by-layer isolation beats guessing.
• Distinguish "port closed" from "service not listening" from "firewall dropping."
• Verify name resolution separately from raw IP connectivity.

Application and Authentication Faults

Application issues (Domain 6)

Here the failing component is a service or workload rather than the operating system underneath. Start with the unit status and journal output, then check configuration syntax, file permissions, SELinux denials, resource limits and dependencies. SELinux is a recurring cause of "it works until it does not": a service that starts fine in permissive testing but fails under enforcing mode. Know how to read denial records and apply the correct, minimal, persistent policy or context fix rather than disabling enforcement.

Authentication (Domain 7)

Authentication faults span local accounts, PAM configuration, SSH access, and directory-backed identity. Typical causes include locked or expired accounts, broken PAM stacks, wrong permissions on SSH key files, time skew affecting ticket-based logins, and misconfigured identity-service client settings. Work out whether the failure is identity lookup, credential verification, or access control, since each points to a different component.

Gathering Evidence for Third Parties

Domain 8 is the one that surprises candidates, because the objective is not always to fix. Sometimes the right outcome is collecting complete, well-organized diagnostic information so another party, such as a vendor or support team, can investigate. Practice producing a clean evidence set: system and package state, configuration files, relevant logs, kernel messages, and a clear statement of symptoms and timing.

• Capture information without altering the evidence you are trying to preserve.
• Know the standard diagnostic collection tools available on RHEL and what each gathers.
• Package the output so it is complete, readable and clearly labeled.
• Describe the problem factually: what happened, when, and what you already ruled out.

The Persistence Rule

Red Hat states that configurations and services must remain functional across the normal platform lifecycle without manual restoration. In practice this means a fix is only real if it survives a reboot, a service restart and ordinary system operation. Candidates lose points not because they failed to diagnose a problem but because their repair was temporary.

Build the habit of ending every repair with a restart test. If you cannot afford a full reboot for each fault, at least restart the affected service and confirm persistent configuration, then reboot once near the end to validate everything together.

Booking, Delivery, Results and Renewal

Cost and delivery

Red Hat's program-wide standard exam list price is USD 500, but the regional price shown in your booking cart controls what you pay. Remote, testing-center and classroom delivery depend on availability. Remote candidates need a LiveUSB, a successful compatibility test, and must pass the required identity and hardware checks, so run the compatibility test well ahead of exam day. See EX342 exam dates and scheduling for planning windows.

Results and retakes

Red Hat's sources differ slightly on timing: the exam page says results usually arrive in three U.S. business days, while the program guide allows five. Reporting gives a total score, and the handbook also describes objective-area feedback, but neither offers task-by-task detail. Eligible unsuccessful first individual attempts receive one free retake under Red Hat's training policies, subject to purchase or subscription eligibility periods and scheduling restrictions. The EX342 pass rate discussion explains why published pass statistics should be treated cautiously.

Renewal

Certifications are current for three years. You can renew before expiry through the original exam or through qualifying same-level or higher-level credentials under the current framework. For credentials earned before the framework change, the FAQ says updated renewal and mapping rules apply to the active transcript after you pass a new exam following May 11, 2026. Red Hat's older renewal page still uses legacy non-expiring terminology and narrower specialist exam-only wording, so check the current handbook, the dated framework and your active transcript rather than relying on that page alone.

Version and Naming Traps to Avoid

• Multiple exam versions exist. Confirm the designated version in your booking or LMS. Red Hat's version-objectives PDF was not retrievable during research for this article, so do not assume any version-specific objectives beyond the current RHEL 10.2 exam page.
• Legacy material does not override the current page. Older RHEL 7 or 8 courses and third-party notes may teach outdated tooling or defaults.
• Do not substitute other exams. OpenShift deployment objectives and EX442 performance tuning are separate topics and are not EX342 content.
• Course content is preparation, not the blueprint. The RH342 course is the recommended companion, but its outline does not establish exhaustive exam coverage or the exact exam version you purchased.
• Practice material must be original. Use self-built broken-system labs rather than anything claiming to be real or reconstructed exam content. The EX342 study guide covers how to build such labs.

A Domain-Ordered Prep Sequence

Because the exam rewards method first and breadth second, order your preparation so the diagnostic habit is built before the fault-specific skills. Here is one sequence tied to the domains, not a generic study plan.

For a sense of how demanding this is, read how hard the EX342 exam is. If you want timed practice, the EX342 practice test site is a good place to start, and our practice questions are written to test the same skills without reproducing exam content. For career context, see EX342 jobs, the EX342 salary guide and whether the certification is worth it; remember that no credential guarantees earnings or employment.

Frequently Asked Questions