Complete Home-Study Curriculum, Laboratory Manual & Exam Preparation Guide

2026 Edition — RHEL 10.2

1. EXECUTIVE SUMMARY

Exam: EX342
Current official title: Red Hat Certified Advanced System Administrator in Enterprise Linux exam
Credential earned: Red Hat Certified Advanced System Administrator in Enterprise Linux
Technology: Red Hat Enterprise Linux 10.2
Exam type: Performance-based, hands-on
Duration: 4 hours
Primary competency: Diagnosing, troubleshooting, correcting, and documenting complex RHEL problems.

This is not an ordinary Linux administration exam.

The central skill is:

Given a broken or degraded RHEL system, systematically determine what is wrong, collect evidence, correct the problem, and prove that the system works again.

The current public Red Hat objectives cover eight major areas:

General troubleshooting methodology
System startup troubleshooting
File-system troubleshooting
Package-management troubleshooting
Network troubleshooting
Application troubleshooting
Authentication troubleshooting
Gathering information for third-party investigation

The public objectives also explicitly include RHEL Web Console, Ansible, centralized logging, AIDE, kernel modules, LVM, encrypted filesystems, RPM database recovery, network traffic inspection, library dependencies, memory leaks, SELinux, PAM, local account policies, kernel crash dumps, and system-information collection.

2. THE 2026 EX342 FACT-CHECK

2.1 What is EX342?

EX342 is the examination for the:

Red Hat Certified Advanced System Administrator in Enterprise Linux

credential.

Red Hat describes the certification as validating the ability to diagnose and correct common problems affecting RHEL systems.

The current Red Hat certification framework introduced in May 2026 places this credential within the Enterprise Linux specialization.

3. VERY IMPORTANT 2026 TERMINOLOGY CHANGE

Older documentation and certification records may show EX342 as:

Red Hat Certified Specialist in Linux Diagnostics and Troubleshooting

That is historical terminology.

As of the May 2026 framework update, Red Hat renamed the credential to:

Red Hat Certified Advanced System Administrator in Enterprise Linux

Red Hat explicitly states that the underlying exam SKU/content was not changed merely because of the framework/title update.

Therefore:

Do not build a 2026 curriculum around the old title.

Use:

EX342 → Red Hat Certified Advanced System Administrator in Enterprise Linux

4. CURRENT RHEL VERSION

The current EX342 exam page states:

The exam is based on Red Hat Enterprise Linux 10.2.

The tasks are therefore designed around RHEL 10.2.

Home-lab recommendation

Use:

RHEL 10.x, preferably the current 10.2 environment corresponding to the exam documentation.

Do not build the primary lab around RHEL 8 merely because older EX342 material or old candidate transcripts mention RHEL 8.

Historical candidate verification pages can still show previous EX342 attempts using RHEL 8. Those records describe historical exams, not the current public EX342 environment.

5. EX342 PREREQUISITES

Requirement	Mandatory for taking EX342?	Current Red Hat position
RHCSA certification	No	Red Hat recommends RHCSA or equivalent experience
EX200	No	EX200 is required for the RHCE Enterprise Linux credential
Linux administration experience	No formal exam prerequisite stated	Strongly recommended
RH342 course	No	Recommended preparation
Red Hat Learning Subscription	No	Optional
Training course completion	No	Red Hat states courses are not required for exam eligibility
Another certification	No	Not required merely to sit EX342

Red Hat’s current exam page recommends either RH342 or equivalent troubleshooting experience and RHCSA or equivalent systems-administration experience.

Red Hat’s FAQ also explicitly says that candidates are not required to complete specific courses before taking a certification exam.

6. THE RHCSA / EX200 QUESTION

This is one of the most important distinctions.

Can you take EX342 without passing EX200?

Yes.

The current Red Hat framework says specialist exams can be taken independently, and Red Hat’s current certification framework allows credentials to be earned without completing the lower-level certification first.

However:

Can EX342 alone make you RHCE Enterprise Linux?

No.

Red Hat currently lists:

EX200 + EX342 → Red Hat Certified Engineer in Enterprise Linux

The current Enterprise Linux certification page explicitly identifies EX200 and EX342 as the requirements for RHCE Enterprise Linux.

Therefore:

                 EX342
                   │
                   ▼
Red Hat Certified Advanced System
Administrator in Enterprise Linux
                   │
                   │
                   ▼
        With EX200 as required
                   │
                   ▼
     Red Hat Certified Engineer
        in Enterprise Linux

Practical conclusion

You may independently study and sit EX342.

But if your ultimate goal is the current RHCE Enterprise Linux designation, you need EX200 as well.

7. TRAINING VS EXAM VS CERTIFICATION

These are three different things.

Red Hat Training
       ≠
Certification Exam
       ≠
Certification

Training

Example:

RH342 — Red Hat Enterprise Linux Diagnostics and Troubleshooting

Training is preparation.

EX342

This is the actual performance-based certification exam.

Certification

This is the credential awarded after passing.

Red Hat explicitly states that completion of courses is not required to become eligible for a certification exam.

Therefore this curriculum intentionally supports:

100% independent home preparation without purchasing RH342.

8. CURRENT EX342 EXAM FORMAT

Attribute	Current information
Exam	EX342
Format	Performance-based
Questions	Not traditional multiple-choice
Environment	Live system
Duration	4 hours
RHEL version	RHEL 10.2
Documentation	Relevant product documentation provided during test
Outside assistance	Not permitted
Scoring	Total score
Individual item scores	Not reported

Red Hat states that EX342 requires candidates to perform tasks on a live system against objective criteria.

9. EX342 PERFORMANCE RULE

A crucial Red Hat performance-exam rule is:

Configurations and services must persist and remain functional through the normal lifecycle of the platform without manual intervention.

In practical terms:

Configure
   ↓
Test
   ↓
Reboot
   ↓
Test again
   ↓
Service works
   ↓
Configuration persists

Do not consider a task complete merely because:

systemctl start service

works once.

You must understand:

systemctl enable service

when persistence is required.

The current EX342 page explicitly highlights this performance rule.

10. OFFICIAL EX342 OBJECTIVE MATRIX

The current public Red Hat objectives can be represented as follows.

#	Official objective area	Current subskills
1	General troubleshooting	Documentation, monitoring, Web Console, Ansible, centralized logging, AIDE
2	System startup	Service failures, root recovery, boot troubleshooting, hardware, kernel modules
3	Filesystems	Corruption recovery, LVM recovery, encrypted filesystem recovery
4	Package management	Dependencies, RPM DB recovery, changed-file identification
5	Networking	Connectivity testing, fixing connectivity, traffic inspection
6	Applications	Libraries, memory leaks, debugging, SELinux
7	Authentication	PAM, local account policies
8	Third-party investigation	Kernel crash dumps, system-information collection

These are the current public objectives published by Red Hat.

11. OBJECTIVE 1 — GENERAL TROUBLESHOOTING

Official skills

You must be able to:

Consult documentation resources
Monitor vital system characteristics
Monitor systems with RHEL Web Console
Configure systems using Ansible
Configure centralized logging
Monitor files/directories using AIDE

11.1 Troubleshooting methodology

The core EX342 methodology should be:

Problem
   ↓
Define symptoms
   ↓
Collect evidence
   ↓
Form hypothesis
   ↓
Test hypothesis
   ↓
Identify root cause
   ↓
Apply correction
   ↓
Verify
   ↓
Persist
   ↓
Document

Do not randomly execute commands.

11.2 Essential diagnostic commands

hostnamectl
uname -a
cat /etc/os-release

uptime
date
timedatectl

top
ps aux
free -h
vmstat
iostat
sar

df -h
df -i
du -xh

lsblk
blkid
findmnt

systemctl --failed
systemctl status <service>

journalctl -b
journalctl -p err
journalctl -xe

dmesg

12. RHEL WEB CONSOLE

RHEL 10’s Web Console is based on Cockpit and can be used for system administration, logs, storage, networking, services, diagnostics, and monitoring.

Basic lab:

dnf install cockpit
systemctl enable --now cockpit.socket

If necessary:

firewall-cmd --add-service=cockpit --permanent
firewall-cmd --reload

Default port:

TCP/9090

Verification:

systemctl status cockpit.socket
ss -lntp | grep 9090

13. ANSIBLE

Ansible is explicitly listed in the current EX342 general troubleshooting objectives.

The goal is not to turn EX342 into EX294.

Study only enough Ansible to perform the current EX342-related administration tasks.

Minimum mastery:

Inventory
↓
SSH connectivity
↓
Ad-hoc commands
↓
Playbooks
↓
Variables
↓
Modules
↓
Idempotence
↓
Verification

Example:

ansible all -m ping

Example playbook:

---
- name: Configure troubleshooting environment
  hosts: all
  become: true

  tasks:
    - name: Ensure rsyslog is installed
      ansible.builtin.dnf:
        name: rsyslog
        state: present

    - name: Ensure rsyslog is running
      ansible.builtin.service:
        name: rsyslog
        state: started
        enabled: true

14. CENTRALIZED LOGGING

Build at least:

RHEL01
   │
   │ logs
   ▼
RHEL02
   │
   └── Central log host

Study:

journalctl
rsyslog
logger

Useful investigation:

journalctl -b
journalctl -p warning
journalctl -u sshd
journalctl --since "1 hour ago"

Generate a test event:

logger "EX342 test message"

15. AIDE

AIDE is explicitly part of the current objective list.

RHEL documentation describes AIDE as a file-integrity checking mechanism.

Install:

dnf install aide

Initialize:

aide --init

Activate database:

mv /var/lib/aide/aide.db.new.gz \
   /var/lib/aide/aide.db.gz

Run check:

aide --check

Important configuration:

/etc/aide.conf

Lab

Initialize AIDE.
Modify a monitored file.
Run aide --check.
Identify the changed object.
Restore the correct state.
Verify again.

16. OBJECTIVE 2 — SYSTEM STARTUP

Official skills:

Identify and resolve service failures affecting boot
Regain root control
Troubleshoot boot issues
Identify hardware problems
Manage kernel modules and parameters

17. SYSTEMD FAILURE LAB

Break a service intentionally.

Example:

systemctl stop sshd

Investigate:

systemctl status sshd
journalctl -u sshd
systemctl --failed

Then recover:

systemctl start sshd
systemctl enable sshd

Verify:

systemctl is-active sshd
systemctl is-enabled sshd

18. BOOT TROUBLESHOOTING

Master:

journalctl -b
journalctl -b -1
systemctl --failed
systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain

Understand:

Firmware
   ↓
Bootloader
   ↓
Kernel
   ↓
initramfs
   ↓
systemd
   ↓
target
   ↓
services

19. ROOT RECOVERY

You must be comfortable with the RHEL recovery process.

Study:

GRUB
kernel command line
emergency mode
rescue mode
root filesystem
rd.break
mount
chroot
SELinux relabeling where appropriate
password/root recovery
filesystem state

Practice in a disposable VM.

20. KERNEL MODULES

Essential commands:

lsmod
modinfo <module>
modprobe <module>
modprobe -r <module>
modprobe -c

Persistent module configuration may involve:

/etc/modprobe.d/

Investigate:

journalctl -k
dmesg

Lab:

Identify a loaded module.
Inspect its parameters.
Change a safe parameter.
Make the change persistent.
Reboot.
Verify.

21. OBJECTIVE 3 — FILESYSTEM TROUBLESHOOTING

Official skills:

Recover corrupted filesystems
Recover broken/misconfigured LVM
Recover data from encrypted filesystems

22. FILESYSTEM MASTER LAB

Know:

lsblk
blkid
findmnt
mount
umount
df
du
fsck
xfs_repair

Understand the difference between:

Filesystem corruption
       ≠
Filesystem not mounted
       ≠
Wrong mount configuration
       ≠
Disk full
       ≠
Inode exhaustion

23. LVM RECOVERY

Master:

pvs
vgs
lvs

pvdisplay
vgdisplay
lvdisplay

lvscan
vgscan
pvscan

Practice:

PV
 ↓
VG
 ↓
LV
 ↓
Filesystem
 ↓
Mount point

Failure scenarios:

Scenario A

LV exists but filesystem does not mount.

Scenario B

Incorrect /etc/fstab.

Scenario C

VG is not activated.

Scenario D

Filesystem is corrupted.

Scenario E

Storage is present but not discovered.

24. ENCRYPTED FILESYSTEM RECOVERY

Study:

cryptsetup
lsblk
blkid
mount
findmnt

Understand:

Block device
   ↓
LUKS
   ↓
Decryption
   ↓
Filesystem
   ↓
Mount

Practice recovery without destroying the original data.

25. OBJECTIVE 4 — PACKAGE MANAGEMENT

Official skills:

Resolve package dependency issues
Recover corrupted RPM database
Identify/report changed files

26. DNF MASTERY

Know:

dnf search
dnf info
dnf list
dnf provides
dnf install
dnf remove
dnf reinstall
dnf update
dnf history

Dependency investigation:

dnf repoquery
dnf provides
rpm -q
rpm -qi
rpm -ql
rpm -qf

27. RPM DATABASE RECOVERY

Know how to recognize:

rpmdb corruption

Useful investigation:

rpm -qa
rpm -q <package>
dnf check

Understand the appropriate RPM database recovery workflow for the RHEL release being used in the lab.

Do not blindly run recovery commands against a production system.

28. CHANGED FILES

Use RPM verification:

rpm -V <package>

Understand output indicators for:

size
mode
checksum
owner
group
modification time
missing files

Example:

rpm -V openssh-server

29. OBJECTIVE 5 — NETWORK TROUBLESHOOTING

Official skills:

Use standard tools to verify network connectivity
Identify and fix connectivity issues
Inspect network traffic

30. NETWORK TROUBLESHOOTING MODEL

Use:

Application
    ↓
Socket
    ↓
TCP/UDP
    ↓
IP
    ↓
Routing
    ↓
Interface
    ↓
Link

And separately:

DNS

Do not assume a DNS problem is a network problem.

31. NETWORK COMMAND MASTERY

ip addr
ip link
ip route

nmcli device
nmcli connection
nmcli general

ping
tracepath
ss
dig
host
resolvectl

ethtool
tcpdump

32. NETWORK FAILURE LAB

Break:

Failure 1

Incorrect IP address.

Failure 2

Incorrect route.

Failure 3

Incorrect DNS.

Failure 4

NetworkManager connection failure.

Failure 5

Firewall blocking traffic.

Failure 6

Application listening on wrong address.

Failure 7

Application listening on wrong port.

For each:

Symptom
↓
Evidence
↓
Layer
↓
Root cause
↓
Fix
↓
Verification

33. TCP TRAFFIC INSPECTION

Use:

tcpdump

Examples:

tcpdump -i any

Filter:

tcpdump -i any port 443

Host:

tcpdump -i any host 10.0.0.10

Learn to distinguish:

SYN
SYN/ACK
ACK
RST
FIN

You do not need to become a packet-analysis specialist.

You need to use packet evidence to troubleshoot an application/network problem.

34. OBJECTIVE 6 — APPLICATION TROUBLESHOOTING

Official skills:

Identify library dependencies
Identify memory leaks
Use standard tools to debug applications
Identify/fix SELinux issues

35. LIBRARY DEPENDENCIES

Master:

ldd
ldconfig
ldconfig -p
rpm -qf
dnf provides

Example:

ldd /path/to/application

Failure scenario:

Application won't start
        ↓
Binary exists
        ↓
Executable permissions correct
        ↓
Library missing
        ↓
Identify provider
        ↓
Install package
        ↓
Verify

36. MEMORY LEAK INVESTIGATION

Understand:

ps
top
free
vmstat
pmap

Useful process inspection:

ps -eo pid,ppid,%mem,rss,vsz,cmd --sort=-%mem

Monitor over time.

The important skill is distinguishing:

High memory usage
       ≠
Memory leak

A memory leak requires evidence of continuously growing memory consumption without corresponding release.

37. APPLICATION DEBUGGING

Study standard Linux tools appropriate to the problem, including:

strace
lsof
ps
top
gdb
journalctl

Example:

strace -f <command>

Use debugging tools to answer:

“Why does this application fail?”

rather than merely learning command syntax.

38. SELINUX TROUBLESHOOTING

This is an EX342 application objective.

Master:

getenforce
sestatus

ls -Z
ps -Z

ausearch
sealert
audit2why
restorecon
semanage

Core model:

Application fails
      ↓
Check normal logs
      ↓
Check SELinux state
      ↓
Check AVC
      ↓
Determine context/policy issue
      ↓
Correct the actual problem
      ↓
Verify

Do not solve every SELinux problem by:

setenforce 0

That is a diagnostic experiment, not a proper final solution.

39. OBJECTIVE 7 — AUTHENTICATION

Current public EX342 objectives explicitly cover:

PAM issues
Local user account policies

40. PAM

Understand:

Authentication request
        ↓
PAM
        ↓
module stack
        ↓
authentication/account/session

Inspect:

/etc/pam.d/

Investigate:

journalctl
/var/log/

Understand the consequences of changing PAM configuration.

A single incorrect PAM rule can prevent users from logging in.

41. LOCAL ACCOUNT POLICIES

Master:

passwd
chage
usermod
useradd
userdel
id
getent passwd

Investigate:

/etc/passwd
/etc/shadow
/etc/group

Useful:

chage -l username

Practice:

password expiration
account expiration
password aging
locked accounts
inactive accounts
login restrictions

42. OBJECTIVE 8 — THIRD-PARTY INVESTIGATION

Official skills:

Create kernel crash dumps
Collect system information for troubleshooting

43. KDUMP

RHEL 10 documentation provides current procedures for configuring and testing kdump.

Know:

kdumpctl status
kdumpctl estimate
systemctl status kdump

Important files:

/etc/kdump.conf
/etc/sysconfig/kdump

Understand:

Production kernel
      ↓
Crash
      ↓
Capture kernel
      ↓
vmcore
      ↓
Forensic analysis

RHEL documentation warns that crash testing causes data loss and should never be performed on a production system.

44. SYSTEM INFORMATION COLLECTION

Build a repeatable diagnostic collection process.

Useful tools:

sos
sos report
journalctl
dmesg
uname
hostnamectl
lscpu
lsblk
lspci
lsusb
ip
ss
df
free

The objective is not to dump every command output.

The objective is:

Collect information that allows another engineer to understand the failure.

45. MASTER EX342 HOME LAB

Recommended topology

A practical home lab can be:

                    INTERNET
                       |
                     NAT
                       |
              +----------------+
              |  LAB-HOST      |
              | Mac/Windows/   |
              | Linux           |
              +-------+--------+
                      |
               LAB MANAGEMENT
                      |
       +--------------+--------------+
       |              |              |
    RHEL01          RHEL02         RHEL03
 Diagnostic       Application      Log/Ansible
    Node             Node           Node
       |              |              |
       +--------------+--------------+
                 LAB NETWORK

Minimum

3 RHEL VMs

46. VM RESOURCES

For a normal laptop:

Resource	Minimum	Recommended
RHEL VMs	3	4
CPU per VM	2 vCPU	2–4 vCPU
RAM per VM	2 GB	4 GB
Disk	25 GB	40–60 GB
Network	NAT	NAT + isolated lab network
Host	16 GB RAM	32 GB+

For advanced troubleshooting labs, additional memory is useful.

You do not need enterprise hardware.

47. HOME LAB SOFTWARE

Windows

Use one of:

Hyper-V
VMware
VirtualBox

Red Hat’s current Developer documentation specifically identifies VirtualBox, VMware, Hyper-V and KVM/libvirt as legitimate virtualization approaches.

Linux

Preferred:

KVM
libvirt
virt-manager

macOS

Use an appropriate supported VM platform for the Mac architecture.

For Apple Silicon, pay attention to:

Architecture
        ↓
RHEL architecture
        ↓
VM hypervisor support
        ↓
Nested virtualization requirements

Do not blindly use x86_64 VM images on ARM hardware.

48. RHEL LICENSING FOR HOME STUDY

Red Hat currently provides a no-cost Red Hat Developer Subscription for Individuals for personal use.

Current Red Hat material states that the individual subscription supports up to 16 physical or virtual nodes.

That is more than enough for this curriculum.

Use official Red Hat sources.

Do not use:

pirated ISO images
unofficial modified RHEL images
leaked subscription credentials
unauthorized repositories

49. SNAPSHOT STRATEGY

Create:

SNAPSHOT-00-CLEAN
SNAPSHOT-01-RHEL-CONFIGURED
SNAPSHOT-02-NETWORK
SNAPSHOT-03-STORAGE
SNAPSHOT-04-BROKEN

Before destructive experiments:

Snapshot
   ↓
Break
   ↓
Troubleshoot
   ↓
Fix
   ↓
Verify

50. THE EX342 LEARN → BUILD → BREAK → FIX MODEL

Every subject must follow:

LEARN
  ↓
BUILD
  ↓
VERIFY
  ↓
BREAK
  ↓
INVESTIGATE
  ↓
FIX
  ↓
VERIFY
  ↓
REBOOT
  ↓
VERIFY AGAIN
  ↓
TIMED TASK

This is the central learning model of this curriculum.

51. PROGRESSIVE LAB LEVELS

Level 1 — Foundation

One problem.

Example:

SSH service is down.

Level 2 — Intermediate

Two interacting problems.

Example:

SSH service fails because of a configuration problem and firewall rule.

Level 3 — Advanced

Multiple systems.

Example:

Application server cannot reach database because of DNS/routing/firewall.

Level 4 — Troubleshooting

You receive only symptoms.

You determine the root cause.

Level 5 — Exam Simulation

No tutorial.

No hints.

Timed.

52. STANDARD TROUBLESHOOTING WORKSHEET

For every lab, record:

Incident:
Date:

Symptoms:

Expected behavior:

Observed behavior:

Initial hypothesis:

Evidence:

Commands used:

Findings:

Root cause:

Fix:

Verification:

Reboot verification:

Permanent configuration:

Lessons learned:

This develops actual troubleshooting discipline.

53. EX342 COMMAND MASTERY

Area	Commands
System	`hostnamectl`, `uname`, `uptime`, `timedatectl`
Processes	`ps`, `top`, `pgrep`, `pmap`
Memory	`free`, `vmstat`, `sar`
Services	`systemctl`, `journalctl`
Boot	`journalctl -b`, `systemd-analyze`
Kernel	`dmesg`, `lsmod`, `modinfo`, `modprobe`
Storage	`lsblk`, `blkid`, `findmnt`, `df`, `du`
LVM	`pvs`, `vgs`, `lvs`, `pvscan`, `vgscan`
Filesystem	`fsck`, `xfs_repair`, `mount`
Encryption	`cryptsetup`
Packages	`dnf`, `rpm`
Network	`ip`, `nmcli`, `ss`, `ping`
DNS	`dig`, `host`
Traffic	`tcpdump`
Applications	`ldd`, `strace`, `lsof`, `gdb`
SELinux	`getenforce`, `sestatus`, `ausearch`, `restorecon`, `semanage`
Users	`id`, `getent`, `passwd`, `chage`, `usermod`
Logs	`journalctl`, `logger`
Integrity	`aide`
Crash	`kdumpctl`
Information	`sos report`
Automation	`ansible`

This is intentionally not a generic Linux command encyclopedia.

54. CONFIGURATION FILE MASTERY

File	Purpose
`/etc/fstab`	Persistent filesystem mounts
`/etc/default/grub` / boot configuration	Boot configuration
`/etc/modprobe.d/`	Kernel module configuration
`/etc/systemd/`	systemd configuration
`/etc/ssh/`	SSH configuration
`/etc/NetworkManager/`	NetworkManager configuration
`/etc/hosts`	Local hostname resolution
`/etc/resolv.conf`	Resolver configuration
`/etc/rsyslog.conf`	rsyslog configuration
`/etc/rsyslog.d/`	rsyslog drop-ins
`/etc/aide.conf`	AIDE configuration
`/etc/lvm/`	LVM configuration
`/etc/crypttab`	Encrypted-device configuration
`/etc/yum.repos.d/`	DNF repositories
`/etc/pam.d/`	PAM configuration
`/etc/passwd`	User accounts
`/etc/shadow`	Password/account aging data
`/etc/group`	Groups
`/etc/selinux/`	SELinux configuration
`/etc/kdump.conf`	kdump configuration
`/etc/sysconfig/kdump`	kdump kernel parameters
`/etc/cockpit/`	Web Console configuration

Only study a configuration file deeply when it supports an actual EX342 objective.

55. TROUBLESHOOTING PLAYBOOKS

Playbook A — Service failure

systemctl status
       ↓
journalctl -u
       ↓
configuration
       ↓
dependency
       ↓
port
       ↓
SELinux
       ↓
filesystem
       ↓
resource availability

Playbook B — Network failure

Interface
↓
IP
↓
Route
↓
DNS
↓
Firewall
↓
Socket
↓
Application

Playbook C — Filesystem failure

Device
↓
Partition
↓
LVM
↓
Encryption
↓
Filesystem
↓
Mount
↓
fstab

Playbook D — Application failure

Process
↓
Executable
↓
Libraries
↓
Configuration
↓
Permissions
↓
SELinux
↓
Network
↓
Memory/CPU
↓
Logs

Playbook E — Login failure

User
↓
Account status
↓
Password
↓
PAM
↓
Authentication
↓
Authorization
↓
Shell
↓
SELinux

56. ENTERPRISE SCENARIOS

Scenario 01 — Production service fails

Required investigation:

systemctl status
journalctl
ss
ps

Determine root cause.

Scenario 02 — Disk appears full

Check:

df -h
df -i
du
lsof

Distinguish:

blocks full
vs
inodes full
vs
deleted-open files

Scenario 03 — Application unreachable

Investigate:

ip
ss
ping
dig
firewall-cmd
tcpdump

Scenario 04 — SELinux denial

Find:

ausearch
journalctl

Determine:

context problem
policy problem
port labeling problem
file labeling problem

Scenario 05 — Works before reboot, fails after reboot

Investigate:

systemctl enable
fstab
NetworkManager
SELinux
mounts
kernel modules
boot target

Scenario 06 — LVM volume unavailable

Investigate:

pvs
vgs
lvs
pvscan
vgscan
lvscan

Scenario 07 — Application memory continuously grows

Establish:

baseline
↓
monitor
↓
trend
↓
process identification
↓
memory evidence
↓
diagnostic collection

57. ORIGINAL EXAM-STYLE TASKS

These are practice tasks, not real Red Hat exam questions.

TASK 01 — Failed SSH Service

Scenario

A RHEL server has stopped accepting SSH connections.

Requirements

Determine whether sshd is running.
Identify the root cause.
Correct the problem.
Verify SSH.
Reboot.
Verify persistence.

Time target

20 minutes.

Completion

systemctl is-active sshd
systemctl is-enabled sshd
ss -lnt

58. TASK 02 — Broken Filesystem Mount

Scenario

A filesystem fails to mount during boot.

Requirements

Identify the device.
Inspect filesystem metadata.
Inspect /etc/fstab.
Determine root cause.
Correct it.
Test mount.
Reboot.
Verify automatic mounting.

Time:

30 minutes

59. TASK 03 — DNS Failure

Scenario

An application can reach an IP address but cannot resolve its hostname.

Requirements:

Identify DNS problem
↓
Inspect resolver configuration
↓
Test DNS
↓
Correct configuration
↓
Verify application

Time:

20 minutes

60. TASK 04 — SELinux Application Failure

Scenario

An application works when SELinux is permissive but fails when enforcing.

You must:

Confirm SELinux state.
Find denial evidence.
Determine the actual problem.
Apply a proper permanent correction.
Re-enable enforcing.
Verify application.

Time:

35 minutes

61. TASK 05 — RPM PACKAGE PROBLEM

Create a controlled package problem.

Candidate must:

Detect package inconsistency.
Identify affected files.
Determine correct package.
Repair.
Verify.

Time:

30 minutes

62. TASK 06 — AUTHENTICATION FAILURE

Break a disposable test VM’s local authentication configuration.

Candidate must:

Identify symptom
↓
Investigate PAM
↓
Review logs
↓
Determine cause
↓
Restore authentication
↓
Verify login

Time:

35 minutes

63. TASK 07 — KERNEL MODULE

Candidate must:

Identify module.
Inspect parameters.
Configure required behavior.
Persist configuration.
Reboot.
Verify.

Time:

25 minutes

64. TASK 08 — CENTRALIZED LOGGING

Configure:

Client → Log Server

Generate a test event:

logger "EX342 TEST"

Verify reception.

Time:

30 minutes

65. TASK 09 — AIDE

Candidate must:

Install AIDE.
Initialize database.
Modify monitored content.
Detect modification.
Report finding.
Restore state.

Time:

25 minutes

66. TASK 10 — KERNEL CRASH INFORMATION

Candidate must configure and verify kdump in a disposable environment.

Do not perform crash testing on production systems.

Time:

45 minutes

67. FIVE MOCK EXAMS

MOCK 1 — FOUNDATION

Time: 90 minutes

Tasks:

Service failure
Filesystem mount failure
Package verification
Network connectivity

Target:

≥80%

MOCK 2 — INTERMEDIATE

Time: 2 hours

Tasks:

systemd problem
LVM problem
DNS problem
SELinux problem
local-user policy

Target:

≥80%

MOCK 3 — ADVANCED

Time: 2.5 hours

Tasks:

Boot failure
LVM/filesystem problem
Network problem
application library problem
centralized logging
AIDE

Target:

≥85%

MOCK 4 — ENTERPRISE INCIDENT

Time: 3 hours

A fictional application platform is degraded.

Candidate receives only:

Users report application outage.
CPU appears normal.
Network connectivity appears intermittent.
Some services restarted overnight.

Candidate must independently investigate.

No hints.

Target:

≥85%

MOCK 5 — FULL EX342 SIMULATION

Time: 4 hours

Build a broken multi-system environment containing problems across the current objective families.

Example:

RHEL01
 ├── service failure
 ├── boot issue
 └── kernel module issue

RHEL02
 ├── filesystem problem
 ├── LVM problem
 ├── application problem
 └── SELinux problem

RHEL03
 ├── logging
 ├── networking
 ├── authentication
 └── diagnostic collection

Rules:

No notes
No tutorials
No internet
No hints
4 hours
Verification required
Reboot verification required

68. MOCK EXAM SCORING

Use:

Score	Readiness
<60%	Not ready
60–69%	Major gaps
70–79%	Developing
80–84%	Good
85–89%	Strong
90%+	Excellent

This is a personal preparation metric, not a Red Hat passing-score prediction.

Do not infer Red Hat’s confidential scoring algorithm from these numbers.

69. 30-DAY INTENSIVE PLAN

Days	Focus
1–3	Troubleshooting methodology
4	Monitoring
5	Web Console
6	Ansible
7	Logging
8	AIDE
9–11	Boot
12	Root recovery
13	Kernel modules
14–16	Filesystems
17	LVM
18	Encryption
19–20	Packages
21–23	Networking
24–26	Applications/SELinux
27	PAM/accounts
28	kdump/diagnostics
29	Mock exam
30	Full review

70. 45-DAY PLAN

Phase 1 — Days 1–10

Troubleshooting fundamentals.

Phase 2 — Days 11–18

Boot and recovery.

Phase 3 — Days 19–25

Storage/filesystems.

Phase 4 — Days 26–31

Packages and networking.

Phase 5 — Days 32–36

Applications/SELinux.

Phase 6 — Days 37–39

Authentication.

Phase 7 — Days 40–41

Diagnostics/kdump.

Phase 8 — Days 42–45

Mock exams.

71. 60-DAY PLAN

Study approximately:

2–3 hours/day

Structure:

45 min theory
60 min lab
30 min break/fix
15 min notes

Every seventh day:

No new theory
Only troubleshooting + revision

72. 90-DAY PART-TIME PLAN

Recommended for someone working full-time.

Monday–Thursday

60–90 minutes.

Friday

Revision.

Saturday

3–4 hour laboratory session.

Sunday

Troubleshooting simulation.

Each week:

Learn
↓
Build
↓
Break
↓
Fix
↓
Timed task

73. WHAT NOT TO STUDY

REQUIRED

Current EX342 objectives:

Troubleshooting methodology
Monitoring
Web Console
Ansible as required by EX342
Centralized logging
AIDE
Startup troubleshooting
Root recovery
Hardware troubleshooting
Kernel modules
Filesystem recovery
LVM recovery
Encrypted filesystem recovery
Package dependency issues
RPM DB recovery
Changed-file identification
Network troubleshooting
Traffic inspection
Library dependencies
Memory leak investigation
Application debugging
SELinux
PAM
Local account policies
kdump
System information collection

74. USEFUL BACKGROUND

Useful supporting knowledge includes:

Core RHCSA administration
systemd
networking fundamentals
storage fundamentals
SELinux fundamentals
shell fundamentals
package management
process management
logs
DNS
TCP/IP

These are supporting skills.

75. OUTSIDE THE CORE EX342 SYLLABUS

Do not spend hundreds of hours on unrelated technologies merely because they are important enterprise technologies.

Examples that should not automatically become major EX342 modules:

Kubernetes
OpenShift
Terraform
Jenkins
AWS
Kafka
Prometheus
Grafana
advanced Ansible Automation Platform
Satellite administration
Ceph
HA clustering

They may be excellent career skills.

They are not automatically EX342 objectives.

76. EX342 VS EX200 VS EX294 VS EX280 VS EX380

Exam	Current purpose
EX200	RHCSA / foundational RHEL administration
EX342	Advanced RHEL troubleshooting/system administration
EX294	Advanced RHEL automation with Ansible
EX280	OpenShift administration
EX380	Advanced OpenShift administration

EX342 should not be confused with EX294.

EX342 includes Ansible in its current public objectives, but that does not turn EX342 into the Ansible certification exam.

77. CURRENT ENTERPRISE LINUX PATH

Current framework:

Enterprise Linux
       │
       ▼
Administrator
       │
     EX200
       │
       ▼
Engineer
       │
     EX342
       │
       ▼
RHCE Enterprise Linux
       │
       ▼
Specialist exams
       │
       ▼
RHCA Enterprise Linux

Red Hat currently lists EX200 + EX342 as the Enterprise Linux Engineer requirements.

78. EX342 → RHCA

The current Enterprise Linux RHCA framework requires:

EX200
+
EX342
+
3 eligible Enterprise Linux Specialist exams

Current eligible specialist choices include:

EX210
EX260
EX358
EX362
EX403
EX415
EX436
EX442

Red Hat’s current certification catalog lists these as the Enterprise Linux specialist options.

This curriculum deliberately does not turn into a career-roadmap discussion.

79. CERTIFICATION VALIDITY

Current Red Hat policy:

Certifications are current for three years from the date earned.

Renewal must occur before expiration.

Expired certifications must be earned again rather than simply renewed.

Red Hat’s 2026 framework introduced more flexible renewal paths, including retaking the highest-level exam, earning another credential at the same level, or advancing to a higher level.

80. EXAM DELIVERY

Red Hat currently provides certification exams through remote and in-person/testing-center options, depending on exam availability and region.

For remote exams, Red Hat states that a mandatory compatibility test is required.

81. EXAM COST

Current verified result

I could verify the official Red Hat Japan purchasing pathway, but I could not verify a current publicly indexed EX342 Japan price from the official source.

Therefore:

Not officially specified in the currently retrieved Red Hat documentation.

Do not rely on old blog prices, Udemy prices, Reddit posts, or historical screenshots.

For Japan, check the current Red Hat Japan purchase/scheduling flow before buying.

82. RETAKE POLICY

Red Hat’s current FAQ states that candidates unsuccessful on their first individual certification attempt are eligible for a free exam retake after results are reported.

Always verify the terms applicable to the exact purchase method before booking.

83. EXAM-DAY STRATEGY

Rule 1 — Read the requirement twice

Do not start typing immediately.

Rule 2 — Identify the failure domain

Ask:

Boot?
Service?
Storage?
Network?
Package?
Application?
SELinux?
Authentication?

Rule 3 — Gather evidence first

Do not randomly change five things.

Rule 4 — Fix the root cause

Do not merely hide symptoms.

Rule 5 — Verify

Use objective evidence.

Rule 6 — Reboot when persistence matters

A solution that disappears after reboot is incomplete.

Rule 7 — Don’t spend forever on one problem

If stuck:

Record current state
Move forward
Return later

84. EXAM TROUBLESHOOTING DECISION TREE

SYSTEM FAILURE
      |
      +---- Won't boot?
      |        |
      |        +---- Bootloader
      |        +---- Kernel
      |        +---- initramfs
      |        +---- systemd
      |
      +---- Service failure?
      |        |
      |        +---- systemctl
      |        +---- journalctl
      |        +---- config
      |        +---- dependency
      |
      +---- Storage?
      |        |
      |        +---- lsblk
      |        +---- LVM
      |        +---- filesystem
      |        +---- encryption
      |
      +---- Network?
      |        |
      |        +---- IP
      |        +---- route
      |        +---- DNS
      |        +---- firewall
      |        +---- socket
      |
      +---- Application?
      |        |
      |        +---- libraries
      |        +---- process
      |        +---- memory
      |        +---- SELinux
      |
      +---- Login?
               |
               +---- account
               +---- password
               +---- PAM
               +---- policy

85. EX342 MASTER READINESS CHECKLIST

For every official objective, you should be able to answer:

[ ] I understand the concept.
[ ] I can configure it without notes.
[ ] I can verify it.
[ ] I can troubleshoot it.
[ ] I can recover from failure.
[ ] I can explain why the failure occurred.
[ ] I can make the fix persistent.
[ ] I can complete it under time pressure.

86. FINAL READINESS STANDARD

Do not call yourself EX342-ready because you watched tutorials.

You should reach:

Theory
   ✓
Configuration
   ✓
Verification
   ✓
Failure injection
   ✓
Troubleshooting
   ✓
Recovery
   ✓
Persistence
   ✓
Timed task
   ✓
Mock exams
   ✓

87. GOLD-STANDARD OBJECTIVE → LAB MATRIX

Objective	Theory	Commands	Lab	Break/Fix	Timed
General troubleshooting	✓	✓	✓	✓	✓
Monitoring	✓	✓	✓	✓	✓
Web Console	✓	✓	✓	✓	✓
Ansible	✓	✓	✓	✓	✓
Central logging	✓	✓	✓	✓	✓
AIDE	✓	✓	✓	✓	✓
Startup	✓	✓	✓	✓	✓
Root recovery	✓	✓	✓	✓	✓
Hardware	✓	✓	✓	✓	✓
Kernel modules	✓	✓	✓	✓	✓
Filesystems	✓	✓	✓	✓	✓
LVM	✓	✓	✓	✓	✓
Encryption	✓	✓	✓	✓	✓
Packages	✓	✓	✓	✓	✓
RPM DB	✓	✓	✓	✓	✓
Changed files	✓	✓	✓	✓	✓
Networking	✓	✓	✓	✓	✓
Traffic inspection	✓	✓	✓	✓	✓
Libraries	✓	✓	✓	✓	✓
Memory leaks	✓	✓	✓	✓	✓
Debugging	✓	✓	✓	✓	✓
SELinux	✓	✓	✓	✓	✓
PAM	✓	✓	✓	✓	✓
Account policies	✓	✓	✓	✓	✓
kdump	✓	✓	✓	✓	✓
System information	✓	✓	✓	✓	✓

88. OFFICIAL RESOURCE MAP

Use current Red Hat documentation as the primary technical reference.

Area	Official resource
EX342	Red Hat EX342 exam page
Certification framework	Red Hat Certifications
Certification policies	Red Hat Certification Program Guide
RHEL 10	Red Hat Enterprise Linux documentation
Web Console	RHEL 10 Web Console documentation
Security/AIDE	RHEL 10 Security Hardening
Kernel/kdump	RHEL 10 kernel documentation
Training reference	RH342
RHEL home lab	Red Hat Developer Program

The current EX342 page itself links to the certification objectives-by-version system, the certification program guide, RHEL documentation, and the Japan purchasing flow.

89. FINAL 2026 EX342 FACT-CHECK

[✓] EX342 currently exists
[✓] Current official title verified
[✓] Current credential relationship verified
[✓] Current RHEL version verified: RHEL 10.2
[✓] Exam duration verified: 4 hours
[✓] Performance-based format verified
[✓] Current public objectives verified
[✓] Current framework verified
[✓] RHCSA not required merely to sit EX342
[✓] EX200 required for RHCE Enterprise Linux
[✓] Training course not mandatory
[✓] Remote/in-person options verified
[✓] Three-year certification validity verified
[✓] Current retake policy verified
[!] Japan-specific EX342 price not independently verified

90. FINAL CURRICULUM PRINCIPLE

The learner should not study EX342 as:

“Advanced Linux commands.”

The learner should study EX342 as:

“Advanced RHEL incident diagnosis and recovery.”

The correct mental model is:

                 EX342
                   │
                   ▼
          SEE THE SYMPTOM
                   │
                   ▼
          COLLECT EVIDENCE
                   │
                   ▼
          IDENTIFY THE LAYER
                   │
                   ▼
          FIND ROOT CAUSE
                   │
                   ▼
             FIX IT
                   │
                   ▼
             VERIFY IT
                   │
                   ▼
          MAKE IT PERSIST
                   │
                   ▼
          DOCUMENT EVIDENCE

That is the skill this curriculum should build.

91. THE FINAL GOLD STANDARD

Before booking EX342, the learner should be able to enter a completely unfamiliar RHEL system and confidently answer:

“Something is broken. Where do I start?”

without immediately searching the internet.

They should instinctively move through:

1. What is the symptom?
2. What changed?
3. What does the system say?
4. What do the logs say?
5. What layer is failing?
6. What evidence confirms the hypothesis?
7. What is the safest correction?
8. Does the correction persist?
9. Does it survive reboot?
10. Can I prove that the system is healthy?

That is the EX342 mindset.

The objective is not memorizing 500 commands.

The objective is becoming the engineer who can take a broken RHEL system, investigate it methodically, restore it correctly, and provide defensible technical evidence for the result.

92. SOURCE-OF-TRUTH RULE

For this curriculum:

CURRENT RED HAT DOCUMENTATION
          ↓
        SOURCE
          ↓
   CURRICULUM DECISION

If an old book says something different:

Old book
   ✗

If an old YouTube course says something different:

YouTube
   ✗

If a historical EX342 page says something different:

Historical material
   ✗

If a Reddit post says something different:

Reddit
   ✗

Current official Red Hat documentation wins.

If a fact cannot be verified:

“Not officially specified in the current Red Hat documentation.”

Never fill the gap with an assumption.

END OF EX342 HOME-STUDY CURRICULUM

Target platform: RHEL 10.2
Target exam: EX342
Current credential: Red Hat Certified Advanced System Administrator in Enterprise Linux
Preparation philosophy: Learn → Build → Break → Diagnose → Fix → Verify → Persist → Time