EX342 logo
Focused certification exam prep
Start practice

EX342 Exam Domains 2026: Complete Guide to All 8 Content Areas

TL;DR
  • EX342 is the Red Hat Certified Advanced System Administrator in Enterprise Linux exam, a four-hour hands-on RHEL 10.2 troubleshooting assessment.
  • Red Hat lists eight objective groups, but publishes no official percentage weights for them.
  • Repairs must survive reboots and normal lifecycle events without manual restoration, so persistence matters as much as the fix.
  • Domain 8 tests evidence gathering for third parties, not just repairing the system yourself.

How the Eight Content Areas Fit Together

The EX342 exam is built around a single skill: finding out why a Red Hat Enterprise Linux system is misbehaving and restoring it to a durable, working state. Red Hat groups the exam objectives into eight areas, and this guide walks through each one using the exact domain names from the current objective list. If you are new to the credential itself, start with What Is EX342? and What Does EX342 Stand For? before returning here.

One important framing point: the eight domains reproduce the current exam-objective groups. They are not a percentage-weighted blueprint, and Red Hat does not publish official weights. That means you cannot safely skip a domain on the theory that it is "only worth a small slice." Because the exam is performance-based and task-driven, a weakness in startup repair or authentication can stall an entire scenario.

The current title, Red Hat Certified Advanced System Administrator in Enterprise Linux, replaced Specialist in Linux Diagnostics and Troubleshooting in the May 2026 framework. The exam code stayed EX342. Passing EX342 alone earns the advanced administrator credential, and combining a current RHCSA (EX200) with EX342 is the route to the RHCE in Enterprise Linux. For eligibility specifics, see EX342 Requirements 2026: Eligibility, Prerequisites & How to Qualify.

Exam Format and Booking Context

Before diving into the domains, it helps to understand the environment they are tested in. EX342 is a four-hour, hands-on exam on RHEL 10.2. You diagnose and repair problems, or in some cases gather evidence for a third-party investigation. Relevant product documentation is supplied, but outside assistance is prohibited. There are no multiple-choice items to guess your way through; you either fix the system or you do not.

The persistence rule: Red Hat requires that configurations and services remain functional across the normal platform lifecycle without manual restoration. A fix that works until the next reboot is not a fix. Every domain below should be practiced with a reboot-and-verify step at the end.
ItemWhat Red Hat Publishes
FormatFour-hour, hands-on troubleshooting exam on RHEL 10.2
ResourcesRelevant product documentation supplied; outside assistance prohibited
List priceProgram-wide standard list price of USD500; the regional booking-cart price controls
DeliveryRemote, testing-center and classroom, subject to booking availability
Remote requirementsLiveUSB, a successful compatibility test, and identity/hardware checks
Results timingExam page says usually three U.S. business days; program guide allows five business days
RetakeEligible unsuccessful first individual attempts receive one free retake, subject to eligibility periods and scheduling restrictions
ValidityCertifications are current for three years

For a fuller pricing discussion, read EX342 Certification Cost 2026: Complete Pricing Breakdown, and for scheduling mechanics see EX342 Exam Dates 2026: Testing Windows, Deadlines & Scheduling. Red Hat recommends RH342 or equivalent troubleshooting experience, plus RHCSA or equivalent administration experience, as preparation.

Domain 1: Understand and Employ General Methods for Troubleshooting

The first objective group is methodology, and it underpins every other domain. On a timed practical exam, the difference between a confident pass and a frantic scramble is often how systematically you narrow down a fault. This domain is about using a repeatable process rather than poking at symptoms.

Domain 1: General Troubleshooting Methods

Candidates must be able to observe, hypothesize, test and verify, using the tools already present on a RHEL system.

  • Reproduce and describe the symptom precisely before changing anything
  • Read logs with journalctl (filtering by unit, boot and priority) and check traditional log files where relevant
  • Compare a failing system against expected configuration and known-good behavior
  • Change one thing at a time and record what you changed so you can revert
  • Verify fixes survive a restart of the service and a full reboot

A habit worth building early: keep brief notes during practice sessions listing symptom, evidence, hypothesis, change and verification. On exam day this prevents you from re-testing the same dead end. Our EX342 Study Guide 2026: How to Pass on Your First Attempt covers how to fold this habit into lab practice.

Domain 2: Diagnose and Troubleshoot System Startup Issues

Startup problems are the most unforgiving category because a machine that will not boot offers little feedback and limited tooling. This domain expects you to understand the boot sequence well enough to identify where it breaks and to intervene from the right environment.

Domain 2: System Startup Issues

Know the path from firmware through bootloader, kernel, initramfs and systemd targets, and how to interrupt it safely.

  • Interrupt the GRUB 2 menu to edit kernel parameters for a single boot
  • Use rescue and emergency targets and understand what each one mounts and starts
  • Recognize failures caused by bad /etc/fstab entries, missing devices or broken unit dependencies
  • Inspect failed units with systemctl and boot-time messages with journalctl -b
  • Regenerate or repair bootloader configuration and initramfs when required
  • Reset or recover access when credentials block recovery work

Practice breaking your own lab machines in startup-related ways, then recovering them without reinstalling. Pay special attention to making recovery changes permanent; a one-time kernel parameter edit that solves the boot but is never persisted will not satisfy the persistence requirement.

Domain 3: Diagnose and Troubleshoot File System Issues

File system faults often masquerade as application or boot problems, so this domain overlaps with others. You must be comfortable with local storage layers, mounting behavior and the tools that expose corruption, space exhaustion and misconfiguration.

Domain 3: File System Issues

Understand how block devices, partitions, logical volumes and file systems stack, and where each layer can fail.

  • Distinguish full disks from exhausted inodes and from quota or reserved-block limits
  • Inspect and repair XFS file systems with the appropriate tools, noting the unmount requirement
  • Work with LVM: physical volumes, volume groups and logical volumes, including extending and recovering them
  • Correct mount options and persistent mounts using UUIDs or labels in /etc/fstab
  • Diagnose permission, ownership and SELinux context problems that block file access
  • Identify processes holding files open when a file system will not unmount
SELinux is a quiet culprit: A file that looks correct by mode and owner can still be denied because of a wrong security context. When a service fails despite correct permissions, check audit messages and file contexts before assuming the configuration file is wrong.

Domain 4: Resolve Package Management Issues

Package problems on RHEL 10.2 usually surface as failed installs, broken updates, unreachable repositories or modified files that no longer match what the package database expects. This domain tests whether you can restore a healthy software state using the platform's native tooling.

Domain 4: Package Management Issues

Be fluent with DNF, RPM and repository configuration, and with verifying what is installed against what should be.

  • Diagnose repository definitions, GPG key problems and unreachable or misconfigured baseurls
  • Use rpm -V to detect altered files and rpm -qf to map files to packages
  • Resolve dependency conflicts and inspect transaction history to undo or understand changes
  • Reinstall or repair damaged packages and restore configuration files appropriately
  • Understand subscription and content-access behavior that can block package operations

Remember that the supplied documentation is current RHEL 10.2 material. Habits formed on older releases may point you toward commands or behaviors that have changed, so rehearse against the right platform version.

Domain 5: Troubleshoot and Fix Network Connectivity Issues

Networking faults on a single host can sit at the interface, addressing, routing, name resolution or firewall layer. This domain rewards candidates who work upward from the physical and link layers rather than jumping straight to the firewall.

Domain 5: Network Connectivity Issues

Build a layered mental model and test each layer in order.

  • Inspect and correct connections with NetworkManager tools such as nmcli
  • Verify addresses, default routes and DNS settings, including resolver configuration
  • Use ip, ss and name-resolution tests to separate connectivity from service problems
  • Diagnose firewalld zones, services, ports and rich rules that silently drop traffic
  • Distinguish a service that is not listening from one that is blocked or mis-bound
  • Make connection changes persistent so they survive restarts

A reliable drill is to confirm each layer in sequence: link up, address present, route correct, name resolves, port reachable, service listening. Writing that sequence down as a personal checklist saves minutes under pressure.

Domain 6: Diagnose Application Issues

Application issues are where the exam moves from the operating system to the services running on it. Rather than assuming a particular application stack, treat this domain as testing your ability to find why a service fails and prove the cause with evidence.

Domain 6: Application Issues

Connect symptoms in a running or failing service back to configuration, resources, permissions or dependencies.

  • Read unit status and journal output to find why a service will not start or keeps restarting
  • Trace system calls and open files to see what a process is actually doing
  • Check resource limits, memory pressure and process behavior for misbehaving applications
  • Correct configuration syntax errors, wrong paths and missing dependencies
  • Account for SELinux denials, ports labeled incorrectly and permission mismatches
  • Confirm the service is enabled so it returns after a reboot

Key Takeaway

When a service fails, work from the unit status and journal first, then examine file access, ports and security contexts. Most application faults on the exam trace back to a small set of root causes you can rule in or out quickly with disciplined evidence gathering.

Domain 7: Identify and Fix Authentication Issues

Authentication problems lock users out of systems, and on an exam they can lock you out of the very machine you are repairing. This domain covers local and centralized authentication, and the layers between a login attempt and a granted session.

Domain 7: Authentication Issues

Understand the chain from credentials through PAM, name-service lookups and any remote identity provider.

  • Diagnose failed local logins, locked accounts, expired passwords and bad shells
  • Inspect PAM configuration and understand how changes to it can break logins
  • Troubleshoot SSH access, including key permissions, daemon configuration and host key issues
  • Examine SSSD behavior, caching and name-service configuration for centrally managed identities
  • Work through time synchronization, since skew can break Kerberos-style authentication
  • Verify sudo rules and group membership that control privilege

Be careful here: editing authentication configuration carelessly can strand you. Keep a privileged session open while testing changes so you can revert if a new login fails.

Domain 8: Gather Information to Aid Third-Party Investigation of Issues

The final objective group is the one most candidates underestimate. Not every problem is meant to be fixed in place. Sometimes the correct outcome is to collect clear, complete evidence so another party, such as a vendor or support team, can investigate. The exam page explicitly says the task may be to diagnose and repair problems or gather evidence for third-party investigation.

Domain 8: Information Gathering for Third-Party Investigation

Capture accurate, relevant and well-organized system information without altering the evidence.

  • Collect logs, configuration, version and package information relevant to the reported symptom
  • Use diagnostic collection tooling provided on RHEL to produce a reviewable report
  • Capture kernel and crash-related data where a task requires it
  • Describe the problem, environment and reproduction steps clearly
  • Avoid destructive changes when the task calls for preservation of the current state
Read the task, not just the symptom: If a scenario asks you to gather information, rushing to "fix" it can lose points. Identify whether you are being asked to repair, to collect evidence, or both, before you touch the system.

Sequencing Your Preparation Around the Domains

Because the domains build on one another, the order you study them matters more than any generic schedule. Foundational skills such as log reading, boot recovery and storage come first because later domains depend on them. A sensible progression is shown below.

Week 1

Domains 1 and 2

  • Build your troubleshooting routine and note-taking habit
  • Practice GRUB edits, rescue and emergency targets, and persistent boot fixes
Week 2

Domains 3 and 4

  • Break and repair XFS, LVM, mounts and SELinux contexts
  • Rebuild broken repositories and verify packages with RPM
Week 3

Domains 5 and 6

  • Walk the network layers on deliberately faulty hosts
  • Diagnose failing services from journals, traces and contexts
Week 4

Domains 7 and 8, then full timed runs

  • Repair authentication faults without locking yourself out
  • Practice evidence collection, then run mixed four-hour scenarios

Stretch or compress this plan to suit your experience. If you already administer RHEL daily, you may spend longer on Domain 8 and the persistence discipline; if you are coming from RHCSA study, expect to spend more on boot and authentication recovery. When you are ready to test yourself, work through original scenarios on the main EX342 practice test site, and see the EX342 Cheat Sheet 2026: One-Page Review of Must-Know Facts for a quick refresher before exam day.

Version and Policy Cautions

Red Hat notes that multiple exam versions are in use, so confirm which version you have been designated in your booking or LMS before you settle on study materials. The linked Red Hat document listing objectives by version could not be retrieved during our review, so we do not infer any version-specific objectives from it. Treat the current RHEL 10.2 exam page as the authority, and do not let legacy RHEL 7/8 courses or third-party material override it. Course material such as RH342 is helpful preparation but does not establish exhaustive exam coverage or the exact version you purchased.

Also avoid mixing in adjacent Red Hat topics. OpenShift deployment objectives and EX442 performance tuning belong to different exams and are not part of these eight areas.

On results, the exam page and the program guide describe different timeframes, and the handbook describes objective-area feedback in addition to total scores. Neither offers task-by-task detail, so plan to infer your weak areas from your own preparation rather than counting on a detailed breakdown. Our EX342 Passing Score 2026 article covers what is and is not published, and How Hard Is the EX342 Exam? discusses how the practical format feels in practice.

Renewal is also worth understanding early. Certifications are current for three years, and you can renew through the original exam or through qualifying same-level or higher-level credentials under the current framework. For pre-framework credentials, the FAQ says updated renewal and mapping rules apply to the active transcript after you pass a new exam following May 11, 2026. A legacy Red Hat renewal page still uses older non-expiring terminology, so consult the current handbook, the dated framework and your active transcript rather than relying on that page alone. If you are weighing the credential's career value, see Is the EX342 Certification Worth It? and EX342 Jobs, keeping in mind that no certification guarantees a particular salary or job outcome.

Frequently Asked Questions

How many domains does the EX342 exam cover?

The current objective list contains eight groups, from general troubleshooting methods through gathering information for third-party investigation. Red Hat does not publish official percentage weights for them, so prepare for all eight rather than prioritizing by assumed weight.

Is EX342 a multiple-choice exam?

No. It is a four-hour, hands-on exam on RHEL 10.2 in which you diagnose and repair problems or gather evidence for third-party investigation. Product documentation is supplied, but outside assistance is prohibited.

Do my fixes need to survive a reboot?

Yes. Red Hat requires configurations and services to remain functional across the normal platform lifecycle without manual restoration. Always verify your repairs after a service restart and a full reboot.

What is the relationship between EX342 and the RHCE?

EX342 alone earns the Red Hat Certified Advanced System Administrator in Enterprise Linux credential. A current RHCSA (EX200) plus EX342 is the path to the RHCE in Enterprise Linux. See the EX342 certification overview for more detail.

Should I study from older RHEL 7 or 8 troubleshooting material?

Use it cautiously. Legacy material does not override the current RHEL 10.2 exam page, and commands or behaviors may differ. Confirm your designated exam version in the booking or LMS, and practice on RHEL 10.2 systems whenever possible.

Ready to pass your EX342 exam?

Put this into practice with free EX342 questions across every exam domain.