Gold-Standard Self-Study Textbook + Laboratory Manual + Exam Preparation Roadmap

Research cut-off: 6 October 2026
Primary authority: current Red Hat official EX342, certification, policy, and RHEL 10 documentation
Learner model: 100% home self-study; Red Hat training courses are optional preparation, not assumed

Accuracy rule: If the live Red Hat EX342 page, the candidate’s assigned LMS exam version, or newer official Red Hat documentation differs from this guide, the current Red Hat source wins.

Executive Verification — What EX342 Is Right Now

As of this guide’s research cut-off:

Item	Current verified status
Exam code	EX342
Exact exam name	Red Hat Certified Advanced System Administrator in Enterprise Linux exam
Credential earned by passing EX342	Red Hat Certified Advanced System Administrator in Enterprise Linux (RHCASA — Enterprise Linux)
Exam style	Hands-on, practical / performance-based
Current public exam platform	Red Hat Enterprise Linux 10.2
Time limit	4 hours
Outside assistance	Not permitted; relevant product documentation is provided in the exam environment
Multiple exam versions	Yes. Red Hat states multiple versions may be in use; candidates should check the assigned version/objectives in the Red Hat LMS
RHCSA required merely to earn the EX342 credential	Not listed as a mandatory exam-registration prerequisite on the current EX342 page. RHCSA or equivalent systems-administration experience is listed under Recommended Preparation
RHCSA required for RHCE in Enterprise Linux	Yes. Current RHCE-Enterprise Linux requirements are EX200 + EX342
Training course RH342 mandatory	No. Red Hat recommends RH342 or similar troubleshooting experience
Standard list price	USD $500 in the current Red Hat Certification Program Guide; actual regional price may differ
Japan-specific price	Not verified as a fixed public JPY amount. Check the live Red Hat Japan purchase/cart page
Free retake	Current policy provides one free retake after an unsuccessful paid first attempt, subject to policy terms
Certification currency	Current Red Hat certifications are current for 3 years and must be renewed before becoming non-current

The 2026 certification relationship

EX342 passed
    |
    v
Red Hat Certified Advanced System Administrator
in Enterprise Linux
    |
    +----------------------------+
                                 |
EX200 / RHCSA -------------------+
                                 |
                                 v
                Red Hat Certified Engineer
                in Enterprise Linux

Important: EX342 is not the same exam as EX294. EX342 is the advanced Enterprise Linux troubleshooting credential. EX294 is the advanced Ansible administration credential in the Ansible track.

2026 name/framework change

On 11 May 2026, Red Hat moved to a specialization-based framework. The credential previously named Red Hat Certified Specialist in Linux Diagnostics and Troubleshooting was renamed Red Hat Certified Advanced System Administrator in Enterprise Linux. Red Hat explicitly states that for these mapped certifications the name changed but the exam SKU, content, description, and difficulty did not change solely because of the framework restructuring.

Official sources:

EX342: https://www.redhat.com/en/services/training/ex342-red-hat-certified-specialist-linux-diagnostics-and-troubleshooting
Certification framework/catalog: https://www.redhat.com/en/services/certifications
Framework FAQ: https://www.redhat.com/en/services/training-and-certification/faq
RHCE in Enterprise Linux: https://www.redhat.com/en/services/certification/red-hat-certified-engineer-in-enterprise-linux
Certification Program Guide: https://docs.redhat.com/en/documentation/red_hat_learning_subscription/1-latest/html/red_hat_certification_program_guide/index

PART 1 — What Is EX342?

1.1 Exact current exam

EX342 — Red Hat Certified Advanced System Administrator in Enterprise Linux exam

The exam measures the ability to analyze RHEL systems for common issues that can cause degradation or loss of performance, correct those issues when appropriate, or gather forensic/diagnostic information for escalation.

It is a performance-based exam: candidates work on live systems rather than answering conventional multiple-choice questions.

The current public EX342 page states that the exam tasks are based on RHEL 10.2 and the time limit is 4 hours. Red Hat also warns that multiple versions of the exam are in use. Always verify the assigned version and objectives in the LMS before the test.

1.2 What certification do you receive?

Passing EX342 earns:

Red Hat Certified Advanced System Administrator in Enterprise Linux

That credential stands on its own.

To earn Red Hat Certified Engineer in Enterprise Linux, the current certification catalog requires both:

EX200 / RHCSA, and
EX342 / RHCASA in Enterprise Linux

Therefore:

Pass EX342 only
= RHCASA in Enterprise Linux

Pass EX200 + EX342
= RHCE in Enterprise Linux

1.3 What EX342 validates

The current Red Hat scope is heavily centered on diagnosis and recovery:

troubleshooting methodology and documentation
live monitoring
RHEL web console
Ansible-based system configuration
centralized logging
file-integrity monitoring with AIDE
startup and boot recovery
hardware and kernel-module troubleshooting
filesystem, LVM, and encrypted-storage recovery
package/RPM database troubleshooting
networking and packet inspection
application dependency, memory, tracing, and SELinux diagnosis
PAM and local account policy
kernel crash dumps
support/diagnostic data collection

This is not a generic “advanced Linux” exam. Every module in this guide maps back to one or more official EX342 objectives.

PART 2 — EX342 Prerequisites

Requirement	Mandatory?	Current official Red Hat position	Practical interpretation
RHCSA certification	Not listed as mandatory to sit/pass EX342 itself	Listed under Recommended Preparation as “earned RHCSA or equivalent systems administration experience”	Strongly recommended baseline; required if your final goal is RHCE in Enterprise Linux
EX200	Not listed as mandatory for the standalone EX342 credential	EX200 + EX342 are required for RHCE-Enterprise Linux	You can treat EX342 as its own advanced credential, but RHCE requires both
Work experience	No fixed duration published	Red Hat recommends RH342 or similar troubleshooting experience	Practical troubleshooting experience matters; no official number of years is specified
RH342 training course	No	Recommended or similar experience	Self-study is possible
Another certification	No mandatory certification shown for EX342 credential itself	The EX342 page awards RHCASA on passing	RHCSA remains the foundation for RHCE-Enterprise Linux
Another exam	No mandatory prior exam shown for EX342 itself	EX200 is a separate RHCE requirement	Do not confuse certification stacking with exam-registration prerequisites

Mandatory prerequisite vs recommended preparation vs optional training

Mandatory prerequisite means Red Hat explicitly requires it before the credential can be awarded.

Recommended preparation means Red Hat recommends a background such as RHCSA-level skill or equivalent experience, but the exam page does not list it as a mandatory standalone EX342 prerequisite.

Optional training means a Red Hat course can help, but is not a requirement to self-study or sit the exam unless a future official page explicitly says otherwise.

Current public-page conclusion: The current EX342 page does not list RHCSA as a mandatory prerequisite for the standalone EX342/RHCASA credential; it recommends RHCSA or equivalent experience. The RHCE-Enterprise Linux credential, however, requires EX200 + EX342.

PART 3 — Current Official EX342 Objectives

The wording below follows the current Red Hat EX342 objective page. These are the source-of-truth domains used throughout this curriculum.

#	Official objective	Skills represented	Command/tool families	Lab priority
1	Understand and employ general methods for troubleshooting	Consult documentation resources to aid in troubleshooting; Monitor systems for vital characteristics; Monitor systems with the RHEL Web console; Configure systems using Ansible; Configure systems to send log messages to a centralized host; Configure systems to monitor files and directories using AIDE	man/journalctl/top/Cockpit/Ansible/rsyslog/AIDE	Critical
2	Diagnose and troubleshoot system startup issues	Identify and resolve service failures affecting boot; Regain root control of a system; Troubleshoot boot issues; Identify hardware and hardware problems; Manage kernel modules and their parameters	systemctl/journalctl/rescue/grubby/kmod tools	Critical
3	Diagnose and troubleshoot file system issues	Recover corrupted file systems; Recover misconfigured or broken LVM configurations; Recover data from encrypted file systems	xfs_repair/e2fsck/LVM/cryptsetup	Critical
4	Resolve package management issues	Resolve package management dependency issues; Recover a corrupted RPM database; Identify and report changed files	dnf/rpm/rpmdb/package verification	Critical
5	Troubleshoot and fix network connectivity issues	Use standard tools to verify network connectivity; Identify and fix network connectivity issues; Inspect network traffic to aid troubleshooting	ip/nmcli/ss/tcpdump/name-resolution tools	Critical
6	Diagnose application issues	Identify library dependencies for third-party software; Identify if an application suffers from memory leaks; Use standard tools to debug an application; Identify and fix issues related to SELinux	ldd/readelf/strace/ltrace/valgrind/SELinux tools	Critical
7	Identify and fix authentication issues	Identify and fix pluggable authentication module (PAM) issues; Identify and enforce local user account policies	authselect/PAM/faillock/chage/account tools	Critical
8	Gather information to aid third-party investigation of issues	Create kernel crash dumps; Collect system information to aid in troubleshooting	kdump/sos/journal/kernel/system inventory	Critical

Objective coverage check

1. Understand and employ general methods for troubleshooting

[ ] Consult documentation resources to aid in troubleshooting
[ ] Monitor systems for vital characteristics
[ ] Monitor systems with the RHEL Web console
[ ] Configure systems using Ansible
[ ] Configure systems to send log messages to a centralized host
[ ] Configure systems to monitor files and directories using AIDE

2. Diagnose and troubleshoot system startup issues

[ ] Identify and resolve service failures affecting boot
[ ] Regain root control of a system
[ ] Troubleshoot boot issues
[ ] Identify hardware and hardware problems
[ ] Manage kernel modules and their parameters

3. Diagnose and troubleshoot file system issues

[ ] Recover corrupted file systems
[ ] Recover misconfigured or broken LVM configurations
[ ] Recover data from encrypted file systems

4. Resolve package management issues

[ ] Resolve package management dependency issues
[ ] Recover a corrupted RPM database
[ ] Identify and report changed files

5. Troubleshoot and fix network connectivity issues

[ ] Use standard tools to verify network connectivity
[ ] Identify and fix network connectivity issues
[ ] Inspect network traffic to aid troubleshooting

6. Diagnose application issues

[ ] Identify library dependencies for third-party software
[ ] Identify if an application suffers from memory leaks
[ ] Use standard tools to debug an application
[ ] Identify and fix issues related to SELinux

7. Identify and fix authentication issues

[ ] Identify and fix pluggable authentication module (PAM) issues
[ ] Identify and enforce local user account policies

8. Gather information to aid third-party investigation of issues

[ ] Create kernel crash dumps
[ ] Collect system information to aid in troubleshooting

PART 4 — Objective-by-Objective Breakdown

Objective 1 — Understand and employ general methods for troubleshooting

What does this objective mean?

Build a repeatable troubleshooting method. Begin with the reported symptom, establish scope and timeline, collect evidence, compare actual state with intended state, test one hypothesis at a time, make the smallest safe correction, then verify persistence. EX342 explicitly includes monitoring, the RHEL web console, Ansible configuration, centralized logging, and AIDE.

What must the candidate know and be able to do?

Consult documentation resources to aid in troubleshooting
Monitor systems for vital characteristics
Monitor systems with the RHEL Web console
Configure systems using Ansible
Configure systems to send log messages to a centralized host
Configure systems to monitor files and directories using AIDE

Core command families

man, info, journalctl, dmesg, systemctl, ps, top, vmstat, free, uptime, iostat, ss, lsof, cockpit, ansible, ansible-playbook, logger, rsyslogd -N1, aide --init, aide --check, aide --update

Configuration and evidence locations

/etc/rsyslog.conf, /etc/rsyslog.d/*.conf, /etc/aide.conf, /var/lib/aide/, /etc/ansible/ansible.cfg, inventory files

Hands-on lab sequence

Monitor CPU, memory, processes, storage, and network activity from both CLI and RHEL web console.
Prepare a small Ansible control node and make an idempotent change on two managed nodes.
Configure node2 as a centralized rsyslog receiver and send logs from node1; verify by generating messages with logger.
Initialize AIDE, modify monitored files, detect the change, update the approved baseline, and verify a clean result.

Verification standard

Do not stop at ‘the command completed.’ Verify the requested service/state, review logs for residual errors, and—where persistence matters—reboot or restart the relevant lifecycle component and verify again.

Troubleshooting drill

Break rsyslog forwarding, corrupt an Ansible inventory entry, stop cockpit.socket, and change an AIDE-monitored file. Diagnose each from observable evidence.

Original exam-style practice task

A managed system is not forwarding logs, a required configuration differs from the desired Ansible state, and AIDE reports a file change. Restore and verify all three.

Completion criteria

[ ] I can recognize the symptom without being told the root cause.
[ ] I can collect useful evidence before changing the system.
[ ] I can repair the fault without unrelated changes.
[ ] I can verify the final state.
[ ] I can make the fix persistent where required.
[ ] I can repeat the task from a fresh snapshot without notes.

Objective 2 — Diagnose and troubleshoot system startup issues

What does this objective mean?

Startup troubleshooting requires distinguishing boot-loader, kernel/initramfs, systemd target, mount, and service failures. RHEL 10 documentation also provides installation-media rescue mode for systems that cannot boot normally. Kernel-module tasks include inspecting loaded modules, parameters, dependencies, loading/unloading, and persistent configuration.

What must the candidate know and be able to do?

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

Core command families

systemctl --failed, systemctl status, systemctl list-dependencies, journalctl -b, journalctl -b -1, dmesg, grubby, lsmod, modinfo, modprobe, modprobe -r, depmod, lspci, lsusb, lscpu, lsblk, fdisk -l, chroot

Configuration and evidence locations

/etc/systemd/system/, /usr/lib/systemd/system/, /etc/modules-load.d/.conf, /etc/modprobe.d/.conf, /boot/loader/entries/, /etc/default/grub

Hands-on lab sequence

Create a boot failure caused by a bad systemd dependency and recover from it.
Boot RHEL installation media into rescue mode, mount the installed system, chroot, inspect logs and configuration, then exit safely.
Load and unload a harmless kernel module, inspect its parameters, configure persistent loading, reboot, and verify.
Blacklist a lab-safe module temporarily and permanently, then reverse the change.

Verification standard

Troubleshooting drill

Introduce an invalid persistent mount or failed required service; recover using console/rescue access. Simulate a wrong kernel-module setting and confirm the effect after reboot.

Original exam-style practice task

A VM stops during startup because of a configuration fault. Regain administrative control, identify the failure from evidence, correct it, boot normally, and prove the fix survives another reboot.

Completion criteria

[ ] I can recognize the symptom without being told the root cause.
[ ] I can collect useful evidence before changing the system.
[ ] I can repair the fault without unrelated changes.
[ ] I can verify the final state.
[ ] I can make the fix persistent where required.
[ ] I can repeat the task from a fresh snapshot without notes.

Objective 3 — Diagnose and troubleshoot file system issues

What does this objective mean?

EX342 is recovery-focused rather than merely creation-focused. You must be able to recognize filesystem damage, choose the correct filesystem-specific recovery tool, recover LVM metadata carefully, and diagnose encrypted-volume problems without destroying recoverable data.

What must the candidate know and be able to do?

Recover corrupted file systems
Recover misconfigured or broken LVM configurations
Recover data from encrypted file systems

Core command families

lsblk -f, blkid, findmnt, mount, umount, xfs_repair, e2fsck, xfs_metadump, pvs, vgs, lvs, pvscan, vgscan, lvscan, lvmdump, vgcfgbackup, vgcfgrestore, pvcreate --uuid --restorefile, lvchange, cryptsetup luksDump, cryptsetup open, cryptsetup close

Configuration and evidence locations

/etc/fstab, /etc/crypttab, /etc/lvm/lvm.conf, /etc/lvm/backup/, /etc/lvm/archive/

Hands-on lab sequence

Create XFS and ext4 lab filesystems, take snapshots, then practice safe unmount/check/repair procedures appropriate to each filesystem.
Back up LVM metadata, damage only the disposable lab PV metadata, recover it from /etc/lvm/archive, activate the LV, and verify data.
Create a LUKS volume, record identifiers safely, break only its boot-time mapping configuration, recover access, and verify files.
Practice collecting evidence before running destructive repair options; document when a last-resort option would risk data loss.

Verification standard

Troubleshooting drill

Wrong UUID in fstab, missing PV metadata, inactive VG/LV, damaged XFS metadata in a disposable filesystem, incorrect crypttab entry.

Original exam-style practice task

Restore three storage failures: a filesystem that will not mount, an LVM stack that is incomplete, and an encrypted volume whose data must remain intact.

Completion criteria

[ ] I can recognize the symptom without being told the root cause.
[ ] I can collect useful evidence before changing the system.
[ ] I can repair the fault without unrelated changes.
[ ] I can verify the final state.
[ ] I can make the fix persistent where required.
[ ] I can repeat the task from a fresh snapshot without notes.

Objective 4 — Resolve package management issues

What does this objective mean?

The objective is not generic package installation. It is diagnosing dependency problems, recovering an unusable RPM database, and identifying files that differ from package metadata. Practice DNF dependency reasoning, package ownership queries, package verification, and database recovery on disposable snapshots.

What must the candidate know and be able to do?

Resolve package management dependency issues
Recover a corrupted RPM database
Identify and report changed files

Core command families

dnf repolist, dnf list, dnf info, dnf repoquery, dnf provides, dnf install, dnf reinstall, dnf remove, dnf clean all, rpm -qa, rpm -qf, rpm -ql, rpm -V, rpm -Va, rpm --rebuilddb

Configuration and evidence locations

/etc/dnf/dnf.conf, /etc/yum.repos.d/*.repo, RPM database under /var/lib/rpm/

Hands-on lab sequence

Create a repository/dependency failure and determine whether the root cause is repository availability, architecture, version, or missing dependency.
Modify a packaged configuration/binary copy and use RPM verification to identify the change.
On a snapshot-only lab clone, simulate RPM database trouble, preserve evidence/backups, rebuild the database, and verify rpm/dnf operation.
Reinstall a package to restore changed package-owned files and confirm with verification.

Verification standard

Troubleshooting drill

Disable a needed repository, create an impossible package dependency in a lab RPM scenario, change a package-owned file, and damage a disposable copy of the RPM database.

Original exam-style practice task

Restore package management to a working state and produce evidence identifying which package-owned files had changed.

Completion criteria

[ ] I can recognize the symptom without being told the root cause.
[ ] I can collect useful evidence before changing the system.
[ ] I can repair the fault without unrelated changes.
[ ] I can verify the final state.
[ ] I can make the fix persistent where required.
[ ] I can repeat the task from a fresh snapshot without notes.

Objective 5 — Troubleshoot and fix network connectivity issues

What does this objective mean?

Troubleshoot systematically from link state and addressing through route selection, name resolution, socket/listener state, firewall, and application reachability. Packet inspection is explicitly in scope, so you must know when tcpdump evidence proves where traffic stops.

What must the candidate know and be able to do?

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

Core command families

ip link, ip addr, ip route, ip neigh, nmcli, ping, tracepath, getent hosts, resolvectl, ss -lntup, ethtool, tcpdump, curl, nc, firewall-cmd, journalctl -u NetworkManager

Configuration and evidence locations

/etc/NetworkManager/system-connections/*.nmconnection, /etc/hosts, /etc/resolv.conf, /etc/firewalld/

Hands-on lab sequence

Create two static lab networks and verify L2/L3 connectivity and routes.
Break DNS while leaving IP connectivity intact; diagnose by comparing address-based and name-based tests.
Create a wrong gateway or prefix and diagnose route selection.
Capture ICMP and TCP handshakes with tcpdump; distinguish no route, filtered traffic, connection refused, and successful handshake.

Verification standard

Troubleshooting drill

Wrong IP/prefix, missing route, incorrect DNS, stopped listener, firewall block, duplicate address, disabled NetworkManager profile.

Original exam-style practice task

A service is reachable from localhost but not from another VM. Identify the failing layer using standard tools and packet capture, fix it, and verify persistence.

Completion criteria

[ ] I can recognize the symptom without being told the root cause.
[ ] I can collect useful evidence before changing the system.
[ ] I can repair the fault without unrelated changes.
[ ] I can verify the final state.
[ ] I can make the fix persistent where required.
[ ] I can repeat the task from a fresh snapshot without notes.

Objective 6 — Diagnose application issues

What does this objective mean?

EX342 expects operational application diagnosis. You should be able to inspect dynamic-library dependencies, identify memory-growth problems, trace process behavior, work with core dumps where useful, and prove whether SELinux is the cause rather than disabling it reflexively.

What must the candidate know and be able to do?

Identify library dependencies for third-party software
Identify if an application suffers from memory leaks
Use standard tools to debug an application
Identify and fix issues related to SELinux

Core command families

ldd, readelf, objdump, file, strace, ltrace, gdb, coredumpctl, pgrep, ps, top, vmstat, valgrind, ausearch, journalctl -t setroubleshoot, getenforce, setenforce, restorecon, semanage

Configuration and evidence locations

/etc/ld.so.conf, /etc/ld.so.conf.d/*.conf, /var/log/audit/audit.log, SELinux file-context policy database

Hands-on lab sequence

Build or install a small test binary, inspect shared-library requirements, and diagnose a missing-library scenario.
Run a deliberately leaky test program under valgrind memcheck and correlate increasing memory with process monitoring.
Use strace to identify a failed file open or permission error.
Create an SELinux denial using a nonstandard content path, identify the AVC record, correct the labeling/policy-compatible configuration, and verify while enforcing.

Verification standard

Troubleshooting drill

Missing shared object, wrong library path, application permission failure, memory leak in a disposable test program, wrong SELinux label.

Original exam-style practice task

Diagnose why a third-party service fails after relocation to a nonstandard path, prove the root cause with tracing/log evidence, and restore operation without disabling SELinux.

Completion criteria

[ ] I can recognize the symptom without being told the root cause.
[ ] I can collect useful evidence before changing the system.
[ ] I can repair the fault without unrelated changes.
[ ] I can verify the final state.
[ ] I can make the fix persistent where required.
[ ] I can repeat the task from a fresh snapshot without notes.

Objective 7 — Identify and fix authentication issues

What does this objective mean?

Authentication faults can lock administrators out, so use snapshots and console access. Understand PAM stack order and control behavior at an operational level, authselect-generated configuration, local account aging/locking policy, and how to distinguish authentication failure from authorization or account-expiry failure.

What must the candidate know and be able to do?

Identify and fix pluggable authentication module (PAM) issues
Identify and enforce local user account policies

Core command families

authselect current, authselect check, authselect select, passwd, chage, faillock, getent passwd, getent shadow, su, loginctl, journalctl, grep

Configuration and evidence locations

/etc/pam.d/, /etc/security/, /etc/login.defs, /etc/passwd, /etc/shadow, /etc/nsswitch.conf, authselect profiles

Hands-on lab sequence

Inspect the active authselect profile and map generated PAM/NSS configuration.
Create a test account with password aging and expiration constraints; verify the resulting login behavior.
Trigger and clear a lab account lockout safely.
Create a custom authselect lab profile, introduce a controlled PAM problem, diagnose it from logs and stack behavior, then restore.

Verification standard

Troubleshooting drill

Expired account, locked user, invalid PAM module reference in a disposable profile, inconsistent authselect state.

Original exam-style practice task

A valid local user cannot authenticate. Determine whether the cause is account policy, lockout, PAM stack, or identity lookup; fix only the actual cause and verify.

Completion criteria

[ ] I can recognize the symptom without being told the root cause.
[ ] I can collect useful evidence before changing the system.
[ ] I can repair the fault without unrelated changes.
[ ] I can verify the final state.
[ ] I can make the fix persistent where required.
[ ] I can repeat the task from a fresh snapshot without notes.

Objective 8 — Gather information to aid third-party investigation of issues

What does this objective mean?

EX342 includes creating kernel crash dumps and collecting system information for escalation. Learn the purpose of kdump and the capture kernel, how to verify configuration, where crash data goes, and how to create a diagnostic archive with sos. The goal is to preserve useful evidence for a third party, not merely ‘make the error disappear’.

What must the candidate know and be able to do?

Create kernel crash dumps
Collect system information to aid in troubleshooting

Core command families

kdumpctl status, systemctl status kdump, journalctl -u kdump, sysctl, grubby, sos report, uname -a, lsmod, rpm -qa, dmesg, journalctl

Configuration and evidence locations

/etc/kdump.conf, boot/kernel command-line configuration, /var/crash/, /var/tmp/ (sos archives)

Hands-on lab sequence

Enable and verify kdump in a disposable VM with enough memory; inspect reserved crash-kernel configuration.
Create an sos report on a healthy node and inventory what kinds of data it collects.
Boot a lab node into RHEL rescue mode and generate an sos report from the installed system.
Practice preserving logs and diagnostic data before making repairs.

Verification standard

Troubleshooting drill

kdump service not ready, invalid dump target in a disposable configuration, insufficient/incorrect crash-kernel setup, sos unable to collect a chosen plugin due to missing package.

Original exam-style practice task

Prepare a failing host for escalation: verify crash-dump capability, gather a complete diagnostic archive, and document the minimum evidence needed to reproduce the incident.

Completion criteria

[ ] I can recognize the symptom without being told the root cause.
[ ] I can collect useful evidence before changing the system.
[ ] I can repair the fault without unrelated changes.
[ ] I can verify the final state.
[ ] I can make the fix persistent where required.
[ ] I can repeat the task from a fresh snapshot without notes.

PART 5 — Complete EX342 Curriculum

Module 0 — RHCSA Baseline and Safe Troubleshooting Habits

Mapping: Prerequisite/background, not a separate EX342 objective

Concepts

EX342 assumes you can already administer RHEL and then diagnose failures. Before beginning advanced work, you should be comfortable with users, permissions, systemd, basic storage, DNF, SELinux, NetworkManager, SSH, text editing, shell redirection, and the normal boot process. This is preparation, not a new official EX342 objective.

Commands

man, info, apropos, systemctl, journalctl, dmesg, ps, top, ip, ss, nmcli, lsblk, findmnt, mount, dnf, rpm, getenforce, ausearch

Important configuration/evidence

/etc/fstab, /etc/default/grub, /etc/systemd/system/, /etc/NetworkManager/system-connections/, /etc/selinux/config

Required labs

Build a clean RHEL 10.2 VM and record a baseline: services, mounts, routes, repositories, SELinux state, kernel, packages.
Create a rollback point, intentionally misconfigure one noncritical service, diagnose it, repair it, and document the evidence chain.
Practice collecting facts first and changing configuration only after forming a hypothesis.

Break/fix drill

Introduce a wrong mount, disabled service, incorrect DNS entry, and SELinux denial one at a time. For every incident, record symptom → evidence → root cause → fix → verification.

Timed task

Given a host with three independent faults, restore normal operation without reinstalling the OS and write down the exact verification commands.

Module 1 — General Troubleshooting, Monitoring, Cockpit, Ansible, Logging, and AIDE

Mapping: Understand and employ general methods for troubleshooting

Concepts

Commands

Important configuration/evidence

/etc/rsyslog.conf, /etc/rsyslog.d/*.conf, /etc/aide.conf, /var/lib/aide/, /etc/ansible/ansible.cfg, inventory files

Required labs

Monitor CPU, memory, processes, storage, and network activity from both CLI and RHEL web console.
Prepare a small Ansible control node and make an idempotent change on two managed nodes.
Configure node2 as a centralized rsyslog receiver and send logs from node1; verify by generating messages with logger.
Initialize AIDE, modify monitored files, detect the change, update the approved baseline, and verify a clean result.

Break/fix drill

Break rsyslog forwarding, corrupt an Ansible inventory entry, stop cockpit.socket, and change an AIDE-monitored file. Diagnose each from observable evidence.

Timed task

A managed system is not forwarding logs, a required configuration differs from the desired Ansible state, and AIDE reports a file change. Restore and verify all three.

Module 2 — Startup, Boot Recovery, Hardware, and Kernel Modules

Mapping: Diagnose and troubleshoot system startup issues

Concepts

Commands

Important configuration/evidence

/etc/systemd/system/, /usr/lib/systemd/system/, /etc/modules-load.d/.conf, /etc/modprobe.d/.conf, /boot/loader/entries/, /etc/default/grub

Required labs

Create a boot failure caused by a bad systemd dependency and recover from it.
Boot RHEL installation media into rescue mode, mount the installed system, chroot, inspect logs and configuration, then exit safely.
Load and unload a harmless kernel module, inspect its parameters, configure persistent loading, reboot, and verify.
Blacklist a lab-safe module temporarily and permanently, then reverse the change.

Break/fix drill

Introduce an invalid persistent mount or failed required service; recover using console/rescue access. Simulate a wrong kernel-module setting and confirm the effect after reboot.

Timed task

A VM stops during startup because of a configuration fault. Regain administrative control, identify the failure from evidence, correct it, boot normally, and prove the fix survives another reboot.

Module 3 — Filesystem, LVM, and Encrypted-Storage Recovery

Mapping: Diagnose and troubleshoot file system issues

Concepts

Commands

Important configuration/evidence

/etc/fstab, /etc/crypttab, /etc/lvm/lvm.conf, /etc/lvm/backup/, /etc/lvm/archive/

Required labs

Create XFS and ext4 lab filesystems, take snapshots, then practice safe unmount/check/repair procedures appropriate to each filesystem.
Back up LVM metadata, damage only the disposable lab PV metadata, recover it from /etc/lvm/archive, activate the LV, and verify data.
Create a LUKS volume, record identifiers safely, break only its boot-time mapping configuration, recover access, and verify files.
Practice collecting evidence before running destructive repair options; document when a last-resort option would risk data loss.

Break/fix drill

Wrong UUID in fstab, missing PV metadata, inactive VG/LV, damaged XFS metadata in a disposable filesystem, incorrect crypttab entry.

Timed task

Restore three storage failures: a filesystem that will not mount, an LVM stack that is incomplete, and an encrypted volume whose data must remain intact.

Module 4 — Package and RPM Database Troubleshooting

Mapping: Resolve package management issues

Concepts

Commands

Important configuration/evidence

/etc/dnf/dnf.conf, /etc/yum.repos.d/*.repo, RPM database under /var/lib/rpm/

Required labs

Create a repository/dependency failure and determine whether the root cause is repository availability, architecture, version, or missing dependency.
Modify a packaged configuration/binary copy and use RPM verification to identify the change.
On a snapshot-only lab clone, simulate RPM database trouble, preserve evidence/backups, rebuild the database, and verify rpm/dnf operation.
Reinstall a package to restore changed package-owned files and confirm with verification.

Break/fix drill

Disable a needed repository, create an impossible package dependency in a lab RPM scenario, change a package-owned file, and damage a disposable copy of the RPM database.

Timed task

Restore package management to a working state and produce evidence identifying which package-owned files had changed.

Module 5 — Network Connectivity and Packet Inspection

Mapping: Troubleshoot and fix network connectivity issues

Concepts

Commands

Important configuration/evidence

/etc/NetworkManager/system-connections/*.nmconnection, /etc/hosts, /etc/resolv.conf, /etc/firewalld/

Required labs

Create two static lab networks and verify L2/L3 connectivity and routes.
Break DNS while leaving IP connectivity intact; diagnose by comparing address-based and name-based tests.
Create a wrong gateway or prefix and diagnose route selection.
Capture ICMP and TCP handshakes with tcpdump; distinguish no route, filtered traffic, connection refused, and successful handshake.

Break/fix drill

Wrong IP/prefix, missing route, incorrect DNS, stopped listener, firewall block, duplicate address, disabled NetworkManager profile.

Timed task

A service is reachable from localhost but not from another VM. Identify the failing layer using standard tools and packet capture, fix it, and verify persistence.

Module 6 — Application Dependencies, Memory Leaks, Debugging, and SELinux

Mapping: Diagnose application issues

Concepts

Commands

Important configuration/evidence

/etc/ld.so.conf, /etc/ld.so.conf.d/*.conf, /var/log/audit/audit.log, SELinux file-context policy database

Required labs

Build or install a small test binary, inspect shared-library requirements, and diagnose a missing-library scenario.
Run a deliberately leaky test program under valgrind memcheck and correlate increasing memory with process monitoring.
Use strace to identify a failed file open or permission error.
Create an SELinux denial using a nonstandard content path, identify the AVC record, correct the labeling/policy-compatible configuration, and verify while enforcing.

Break/fix drill

Missing shared object, wrong library path, application permission failure, memory leak in a disposable test program, wrong SELinux label.

Timed task

Diagnose why a third-party service fails after relocation to a nonstandard path, prove the root cause with tracing/log evidence, and restore operation without disabling SELinux.

Module 7 — PAM and Local Account Policy Troubleshooting

Mapping: Identify and fix authentication issues

Concepts

Commands

authselect current, authselect check, authselect select, passwd, chage, faillock, getent passwd, getent shadow, su, loginctl, journalctl, grep

Important configuration/evidence

/etc/pam.d/, /etc/security/, /etc/login.defs, /etc/passwd, /etc/shadow, /etc/nsswitch.conf, authselect profiles

Required labs

Inspect the active authselect profile and map generated PAM/NSS configuration.
Create a test account with password aging and expiration constraints; verify the resulting login behavior.
Trigger and clear a lab account lockout safely.
Create a custom authselect lab profile, introduce a controlled PAM problem, diagnose it from logs and stack behavior, then restore.

Break/fix drill

Expired account, locked user, invalid PAM module reference in a disposable profile, inconsistent authselect state.

Timed task

A valid local user cannot authenticate. Determine whether the cause is account policy, lockout, PAM stack, or identity lookup; fix only the actual cause and verify.

Module 8 — Kernel Crash Dumps and Support Data Collection

Mapping: Gather information to aid third-party investigation of issues

Concepts

Commands

kdumpctl status, systemctl status kdump, journalctl -u kdump, sysctl, grubby, sos report, uname -a, lsmod, rpm -qa, dmesg, journalctl

Important configuration/evidence

/etc/kdump.conf, boot/kernel command-line configuration, /var/crash/, /var/tmp/ (sos archives)

Required labs

Enable and verify kdump in a disposable VM with enough memory; inspect reserved crash-kernel configuration.
Create an sos report on a healthy node and inventory what kinds of data it collects.
Boot a lab node into RHEL rescue mode and generate an sos report from the installed system.
Practice preserving logs and diagnostic data before making repairs.

Break/fix drill

kdump service not ready, invalid dump target in a disposable configuration, insufficient/incorrect crash-kernel setup, sos unable to collect a chosen plugin due to missing package.

Timed task

Prepare a failing host for escalation: verify crash-dump capability, gather a complete diagnostic archive, and document the minimum evidence needed to reproduce the incident.

Module 9 — Integrated Enterprise Troubleshooting

Mapping: All official EX342 objectives

Concepts

Real incidents cross subsystem boundaries. A boot symptom can be storage; an application symptom can be SELinux or networking; an authentication symptom can be account policy rather than PAM. This module trains evidence-driven isolation across layers.

Commands

All commands from Modules 1–8, selected by evidence rather than habit

Important configuration/evidence

All relevant configuration from Modules 1–8

Required labs

Multi-fault incident: failed boot + LVM issue + bad service dependency.
Application outage: DNS + SELinux + package file drift.
Authentication outage: PAM/profile issue + account lockout.
Support escalation: collect packet capture, sos report, relevant logs, RPM verification, and a concise incident timeline.

Break/fix drill

Use random-but-documented fault injection from your own lab catalog. Never stack more faults than you can independently verify and reverse.

Timed task

Complete a timed four-host incident set while preserving persistence, documenting verification, and avoiding unnecessary configuration changes.

PART 6 — Home Lab Architecture

Recommended minimum practical topology

The following is a curriculum design recommendation, not an official Red Hat exam requirement.

                         HOME LAB
                            |
                    NAT / Internet Access
                            |
                    Host-only Lab Network
                            |
        ------------------------------------------------
        |                      |                       |
   mgmt01.lab.local       node01.lab.local        node02.lab.local
   192.168.56.10          192.168.56.11           192.168.56.12
        |                      |                       |
 Ansible control          Primary break/fix        Logging/peer
 Central rsyslog          Extra virtual disks      Network peer
 Documentation host       LVM/LUKS/filesystems     Secondary target

Why three VMs?

A single VM can teach many commands, but current EX342 objectives explicitly include:

configuring systems using Ansible;
sending logs to a centralized host;
networking and packet inspection;
advanced recovery.

Three VMs make those objectives realistic without requiring a corporate environment.

Suggested resources

VM	vCPU	RAM	System disk	Extra disks	Purpose
mgmt01	2	3–4 GB	40 GB	optional	Ansible + log server
node01	2	4 GB	50–60 GB	2–3 × 8–12 GB	primary recovery target
node02	2	3–4 GB	40 GB	1 × 8–12 GB	peer/log/client target

Host recommendation: 16 GB RAM works for a careful three-VM lab; 24–32 GB is more comfortable. CPU/RAM figures are study-lab recommendations, not Red Hat exam requirements.

Networking

Use two adapters per VM where practical:

NAT — registration, package downloads, documentation access.
Host-only/internal network — deterministic private addressing and safe break/fix networking.

Bridged networking is optional and should be used only when you understand the impact on your real LAN.

Snapshot strategy

Maintain at least:

00-clean-rhel10
10-baseline-tools
20-storage-ready
30-network-ready
before-dangerous-lab

Snapshot before filesystem corruption, LVM metadata recovery, PAM changes, bootloader work, or RPM database recovery.

Lab reset discipline

After an advanced failure lab:

verify the recovery;
export your notes;
restore the clean snapshot;
repeat without notes;
rebuild from scratch periodically so snapshot dependence does not hide gaps.

PART 7 — Home Lab Options

Official RHEL access

Red Hat currently provides a no-cost Red Hat Developer Subscription for Individuals, which includes RHEL for individual development, testing, experimentation, and permitted individual use. Review current terms before use.

Official information: https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux

Windows host

Practical hypervisor choices include Hyper-V (where available), VMware Workstation, and VirtualBox. The hypervisor is not part of EX342; use whichever reliably supports multiple RHEL VMs, snapshots, multiple NICs, and extra disks.

Avoid using WSL as the primary EX342 lab because EX342 requires boot, kernel, storage, systemd, crash-dump, and recovery exercises that need a real VM environment.

macOS host

On Intel Mac, VMware Fusion or another x86_64-capable hypervisor can run x86_64 RHEL.

On Apple Silicon, use a hypervisor capable of running the current supported RHEL aarch64/ARM64 image where available. Keep in mind that some low-level device behavior can differ by architecture; use Red Hat’s current RHEL documentation for your architecture.

Linux host

KVM/libvirt is the most natural Linux-host choice. GNOME Boxes or virt-manager can simplify management. VMware/VirtualBox may also be options depending on the host distribution.

Licensing rule

Use official RHEL downloads, valid subscriptions/evaluations, or other legally licensed RHEL access. Do not use unauthorized images.

PART 8 — Learn → Configure → Verify → Break → Troubleshoot → Fix

Use the same cycle for every major technology:

LEARN
  ↓
CONFIGURE
  ↓
VERIFY
  ↓
BREAK
  ↓
COLLECT EVIDENCE
  ↓
FORM HYPOTHESIS
  ↓
FIX
  ↓
VERIFY AGAIN
  ↓
REBOOT / LIFECYCLE TEST
  ↓
TIMED TASK
Code language: PHP (php)

Lab 1 — Basic implementation

Build the feature correctly from a clean baseline.

Lab 2 — Enterprise scenario

Use at least two hosts or multiple dependent services.

Lab 3 — Intentional failure

Inject exactly one documented failure first. Later combine faults.

Lab 4 — Troubleshooting

Do not look at your fault-injection note until after you have diagnosed the problem from evidence.

Lab 5 — Timed exam-style task

Start from a snapshot that hides the root cause. Work against a result requirement, not a command recipe.

PART 9 — Advanced Troubleshooting Curriculum

Scenario	First evidence	Diagnostic path	Typical root-cause classes	Verification
Boot stops/degrades	console + journalctl -b + failed units	boot stage → mounts → units → dependencies	fstab, failed unit, module/driver, boot configuration	normal reboot; no failed required units
Filesystem will not mount	mount error + dmesg + filesystem metadata	identify FS → unmount → read-only check → safe repair	corruption, wrong UUID/type/options	mount + file read/write + reboot
VG/LV missing	pvs/vgs/lvs + /etc/lvm/archive	device presence → PV UUID → metadata → activation	missing/damaged PV metadata, activation	LV active and data readable
Encrypted volume unavailable	cryptsetup status/luksDump + crypttab/fstab	device → LUKS header → mapping → FS → mount	wrong mapping/config, unavailable key	mapping + mount + persistence
DNF transaction fails	dnf error + repo state	repo availability → package/version/arch → dependencies	disabled repo, version conflict, damaged metadata	clean transaction
RPM database fails	rpm query errors + db files	backup/evidence → database recovery → verify package manager	rpmdb corruption	rpm/dnf queries
Network timeout	ip/nmcli/route/ss/tcpdump	link → address → route → DNS → socket → firewall → packet	bad IP/route/DNS/firewall/listener	remote connection + packet evidence
App fails to start	systemd status/journal + strace/ldd	service → dependency → file access → SELinux → resource	library, permission, config, AVC	process healthy + logs clean
Memory grows	ps/top/vmstat + valgrind	confirm growth → reproduce → instrument	leak or workload/cache misunderstanding	reproducible evidence
Login fails	journal + faillock/chage/authselect	identity → account state → PAM → policy	lockout, expiry, PAM/profile	successful intended auth
SELinux denial	audit.log + ausearch	prove AVC → inspect context/boolean → persistent correction	wrong label, nonstandard path, policy mismatch	enforcing + app works
Need vendor escalation	sos + journal + package/kernel/network state	collect before repair	insufficient evidence	archive + timeline + reproduction notes

Universal incident worksheet

Problem statement:
Expected state:
Observed state:
Scope:
When did it start?
Recent change?
Evidence collected:
Hypothesis 1:
Test:
Result:
Root cause:
Fix:
Verification:
Persistence/reboot verification:
Evidence retained for escalation:

PART 10 — EX342 Command Mastery

Command	Purpose	Example	Common mistake	Verification
man / info / apropos	Find local documentation	man 5 fstab; apropos kdump	Using memory instead of available documentation	Can explain source used
journalctl	Query systemd journal	journalctl -b; journalctl -u sshd	Looking only at current terminal error	Find exact failure timestamp
dmesg	Kernel ring buffer	dmesg -T	Ignoring kernel/device evidence	Correlate device/kernel event
systemctl	Service/unit state	systemctl –failed; status UNIT	Restarting before collecting evidence	Unit healthy after fix
ps / top / vmstat / free	Process and resource monitoring	ps aux; top; vmstat 1	Treating free RAM as only memory metric	Baseline + changed metric
ss	Socket/listener state	ss -lntup	Testing firewall before checking listener	Correct process listening
cockpit.socket	RHEL web console access	systemctl enable –now cockpit.socket	Assuming GUI state differs from system state	CLI and web state agree
ansible / ansible-playbook	Configure managed systems	ansible all -m ping; ansible-playbook site.yml	Non-idempotent shell-only playbooks	Second run has no unintended changes
logger / rsyslogd	Central logging tests	logger TAG; rsyslogd -N1	Changing config without syntax validation	Remote message arrives
aide	File integrity	aide –init; –check; –update	Approving suspicious drift blindly	Expected drift only
grubby	Inspect/manage boot entries	grubby –info=ALL	Editing boot config without rollback	Expected kernel/entry
lsmod / modinfo / modprobe	Kernel modules	modinfo MOD; modprobe MOD	Using insmod without dependency awareness	Module/parameters correct
xfs_repair	XFS diagnosis/repair	xfs_repair -n DEV	Repairing mounted FS or using -L casually	FS mounts and data checks
e2fsck	ext-family check/repair	e2fsck -f DEV	Using filesystem-wrong tool	FS healthy
pvs/vgs/lvs	LVM state	lvs -a -o +devices	Changing metadata before identifying missing device	Topology understood
vgcfgrestore / pvcreate –restorefile	LVM metadata recovery	vgcfgrestore VG	Wrong PV UUID/device	LV restored with data
cryptsetup	LUKS inspection/open	cryptsetup luksDump DEV	Reformatting instead of recovering mapping	Existing data accessible
dnf	Package/repo/dependency management	dnf repolist; repoquery; reinstall	Forcing RPM operations before understanding deps	Clean transaction
rpm	Package ownership/verification/db	rpm -qf FILE; rpm -V PKG; rpm –rebuilddb	Interpreting all rpm -V differences as compromise	Changed files correctly reported
ip / nmcli	Network state and config	ip route; nmcli con show	Changing DNS when route is broken	Correct state + persistence
tcpdump	Packet evidence	tcpdump -ni IFACE host X	Capturing too broadly and missing signal	Can explain handshake/failure
ldd / readelf / objdump	ELF/library dependencies	ldd APP; readelf -d APP	Installing random packages to chase .so errors	All dependencies resolve
strace / ltrace	Runtime tracing	strace -f -o trace APP	Tracing without filtering or interpreting errors	Failure syscall/library call identified
valgrind	Memory error/leak evidence	valgrind –leak-check=full APP	Calling normal cache use a leak	Reproducible leak evidence
ausearch / restorecon / semanage	SELinux diagnosis/fix	ausearch -m AVC -ts recent; restorecon -Rv PATH	Disabling SELinux	Works in enforcing
authselect / faillock / chage	Authentication/account policy	authselect current; faillock –user U; chage -l U	Editing generated PAM files blindly	Login state matches policy
kdumpctl	Kdump readiness	kdumpctl status	Assuming service active means fully ready	Ready/target validated
sos report	Support data	sos report	Collecting only after changing system	Archive preserves pre-fix evidence

PART 11 — Configuration File Mastery

File/directory	Purpose	Related objective
/etc/rsyslog.conf, /etc/rsyslog.d/*.conf	local/remote logging	general troubleshooting
/etc/aide.conf, /var/lib/aide/	AIDE rules/database	general troubleshooting
/etc/ansible/ansible.cfg + inventory	Ansible behavior/targets	general troubleshooting
/etc/systemd/system/, /usr/lib/systemd/system/	units, overrides, dependencies	startup/services
/etc/modules-load.d/*.conf	persistent module loading	kernel modules
/etc/modprobe.d/*.conf	module options/denylisting	kernel modules
/boot/loader/entries/, bootloader config	boot entries	startup
/etc/fstab	persistent mounts	filesystem/startup
/etc/crypttab	encrypted mappings	encrypted storage
/etc/lvm/lvm.conf	LVM behavior	LVM recovery
/etc/lvm/backup/, /etc/lvm/archive/	LVM metadata backups	LVM recovery
/etc/dnf/dnf.conf	DNF global config	package management
/etc/yum.repos.d/*.repo	repositories	package management
/etc/NetworkManager/system-connections/*.nmconnection	persistent network profiles	networking
/etc/hosts, /etc/resolv.conf	name resolution inputs	networking
/etc/ld.so.conf, /etc/ld.so.conf.d/*.conf	dynamic linker paths	application dependencies
/var/log/audit/audit.log	SELinux/audit evidence	application/SELinux
/etc/pam.d/*	PAM service stacks	authentication
/etc/security/*	PAM/account policy parameters	authentication
/etc/login.defs	local account defaults	authentication
/etc/passwd, /etc/shadow	local identity/account state	authentication
/etc/nsswitch.conf	identity lookup order	authentication
/etc/kdump.conf	crash dump target/config	third-party investigation
/var/crash/	kernel crash dump output	third-party investigation
/var/tmp/	common sos report output location	third-party investigation

PART 12 — Security Curriculum

Current EX342 security-relevant objectives are narrower than a full Linux security certification.

Officially in scope

AIDE file integrity
SELinux troubleshooting
PAM troubleshooting
local user account policy
secure recovery of encrypted filesystems
logging/evidence collection

Useful background, but not separately named EX342 objectives

sudo administration
firewalld as a possible network fault source
file permissions/ACLs when diagnosing application/authentication issues
SSH when reproducing remote-access problems

Not justified as a standalone EX342 requirement by the current public objectives

comprehensive compliance frameworks
full auditd rule design
cryptographic policy engineering
advanced Identity Management/FreeIPA server deployment
advanced firewall architecture
security hardening baselines beyond the troubleshooting objectives

The rule is simple: learn enough background to diagnose an official EX342 objective, but do not turn this into EX415.

PART 13 — Storage Curriculum

Required storage outcomes

You must be able to:

identify the actual block-device/filesystem/LVM/LUKS topology;
distinguish filesystem corruption from mount/configuration problems;
use filesystem-specific repair workflows;
recover LVM metadata from backups/archives safely;
preserve existing encrypted data while repairing mapping/configuration failures;
prove data is intact after recovery;
verify persistence where applicable.

Mandatory lab chain

Create disposable storage
   ↓
Put test data on it
   ↓
Record UUID/PV/VG/LV/LUKS facts
   ↓
Snapshot VM
   ↓
Break one layer
   ↓
Diagnose layer-by-layer
   ↓
Recover
   ↓
Mount
   ↓
Verify checksums/files
   ↓
Reboot
   ↓
Verify persistence
Code language: PHP (php)

Safety: never practice destructive metadata recovery on important data.

PART 14 — Networking Curriculum

Use a layer-by-layer workflow:

Link
 ↓
Interface state
 ↓
Address / Prefix
 ↓
Route
 ↓
Neighbor resolution
 ↓
DNS
 ↓
Listener/socket
 ↓
Firewall
 ↓
Packet capture
 ↓
Application
Code language: PHP (php)

A good EX342 learner should be able to explain the difference between:

no route to host;
name-resolution failure;
SYN sent but no reply;
TCP reset / connection refused;
listener bound only to localhost;
firewall drop;
wrong source route;
service-level failure after transport succeeds.

Do not memorize tcpdump filters without learning to read basic TCP handshakes.

PART 15 — Services & System Management

Current service-related scope appears mainly through:

startup failures affecting boot;
monitoring and logs;
application issues;
logging services;
cockpit;
kdump;
services changed by Ansible.

Practice:

systemctl status
systemctl --failed
unit dependencies
drop-in overrides
enable/disable vs start/stop distinction
journal correlation
persistence after reboot
finding the first causal failure rather than restarting everything

Creating complex custom systemd services is useful practice, but the current EX342 objectives do not separately state “write arbitrary systemd unit files” as an objective. Treat that as supporting skill, not a standalone exam claim.

PART 16 — Automation

Automation is explicitly in scope through:

Configure systems using Ansible.

This does not make EX342 an EX294 substitute.

For EX342, focus on Ansible as an administration/troubleshooting tool:

inventories;
managed-node connectivity;
idempotent configuration;
playbook syntax;
variables sufficient for practical configuration;
service/package/file configuration;
RHEL system roles where useful;
troubleshooting SSH/inventory/privilege/module failures.

Do not spend disproportionate time on advanced Automation Platform architecture, controller administration, custom collections, or large-scale event-driven automation unless a newer EX342 objective explicitly adds them.

PART 17 — Performance & Troubleshooting

The EX342 page says the exam tests issues that may cause degradation or loss of performance, and the objectives explicitly require monitoring vital characteristics and identifying application memory leaks.

Use this workflow:

Observe symptom
   ↓
Measure current state
   ↓
Create/reproduce workload
   ↓
Identify constrained resource
   ↓
Determine whether problem is system-wide or process-specific
   ↓
Make smallest justified change
   ↓
Measure again

Useful current-RHEL tools include top, ps, vmstat, iostat, free, ss, perf, and Valgrind. Do not turn EX342 preparation into the separate EX442 Performance Tuning curriculum; use performance tools to diagnose EX342-style faults.

PART 18 — Enterprise Scenarios

Scenario 1 — Production service failing

Service starts manually but fails during normal boot. Determine unit ordering/dependency or environmental difference and restore persistent startup.

Scenario 2 — Storage full / filesystem unhealthy

A service stops writing. Distinguish space exhaustion, inode exhaustion, read-only remount, underlying LVM issue, and filesystem damage.

Scenario 3 — Network service unavailable

Local checks pass, remote checks fail. Use socket state, route, firewall, and packet capture to isolate failure.

Scenario 4 — SELinux blocks an application

App runs only in permissive mode. Prove AVC denial and correct persistent labels/allowed configuration while returning enforcing.

Scenario 5 — Service works now but fails after reboot

Find nonpersistent command-line changes, missing enablement, wrong fstab/crypttab/module/network profile, or unit ordering.

Scenario 6 — Filesystem does not mount

Determine whether root cause is wrong device/UUID, encryption mapping, LVM activation, filesystem corruption, or mount options.

Scenario 7 — Performance incident

A process consumes growing memory. Confirm actual leak behavior and capture reproducible evidence.

Scenario 8 — Authentication outage

One group of local users cannot log in after policy change. Separate identity lookup, account status, PAM, and authorization.

Scenario 9 — Package integrity incident

A package-owned binary changed and DNF transactions fail. Report drift, fix repository/dependency/database state, restore supported files.

Scenario 10 — Vendor escalation

Before changing the host, create sos report, gather relevant journals, package state, kernel/module state, network evidence, and a concise timeline.

PART 19 — Original EX342-Style Practical Tasks

These are original self-study tasks. They are not Red Hat exam questions and do not reproduce confidential exam content.

TASK 01 — Troubleshooting method

Scenario: A service is reported ‘slow’ but not down.

Requirements: Collect CPU, memory, I/O, process and log evidence; identify the bottleneck; make only an evidence-backed correction.

Time target: 25 min

Verification: Record before/after metrics and service health.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 02 — Documentation

Scenario: A utility is unfamiliar and outside your memorized command set.

Requirements: Use local man/info/help and provided documentation to determine safe syntax; perform the requested change.

Time target: 15 min

Verification: Show the command result and relevant help/man reference.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 03 — RHEL web console

Scenario: CLI metrics and web-console view disagree after a service change.

Requirements: Enable/access the web console, reconcile the state, and identify what changed.

Time target: 15 min

Verification: cockpit.socket active; web view matches CLI.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 04 — Ansible

Scenario: Two RHEL nodes drift from a required service configuration.

Requirements: Create inventory/playbook, apply idempotently, run twice, and show no unintended second-run changes.

Time target: 25 min

Verification: Second play is idempotent; target state confirmed.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 05 — Central logging

Scenario: node1 messages do not arrive on loghost.

Requirements: Fix rsyslog path/transport/listener/firewall as needed and verify with logger.

Time target: 25 min

Verification: Unique test message visible on loghost.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 06 — AIDE

Scenario: Integrity monitoring reports one legitimate and one suspicious change.

Requirements: Identify both, approve only the legitimate change, update baseline, and leave suspicious change reported.

Time target: 25 min

Verification: AIDE output reflects intended baseline.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 07 — Boot service failure

Scenario: A required local service causes degraded boot.

Requirements: Identify the failed unit and dependency chain; repair and reboot.

Time target: 20 min

Verification: No failed unit after reboot.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 08 — Regain root control

Scenario: Normal login is unavailable on a disposable lab VM.

Requirements: Use a current supported rescue path to regain administrative control and repair the cause.

Time target: 25 min

Verification: Normal boot/login restored.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 09 — Boot issue

Scenario: The OS drops to emergency/rescue behavior because a persistent mount is wrong.

Requirements: Find the exact mount failure and correct persistent configuration.

Time target: 20 min

Verification: Normal boot and mount verified.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 10 — Hardware evidence

Scenario: A NIC/disk is allegedly ‘missing’.

Requirements: Use kernel/hardware tools and logs to determine whether hardware is absent, driver is missing, or interface is simply down.

Time target: 20 min

Verification: Root cause documented with evidence.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 11 — Kernel modules

Scenario: A required module is not loaded after reboot.

Requirements: Inspect module availability/parameters, configure persistent loading, reboot and verify.

Time target: 20 min

Verification: Module loaded after reboot with intended parameter state.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 12 — Filesystem recovery

Scenario: A disposable XFS/ext4 filesystem does not mount after simulated corruption.

Requirements: Use filesystem-appropriate diagnostic and repair workflow.

Time target: 30 min

Verification: Filesystem mounts and test data is accessible.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 13 — LVM recovery

Scenario: A VG references a missing or damaged PV in the lab.

Requirements: Use LVM metadata backups/archives to recover the mapping carefully.

Time target: 40 min

Verification: LV active and test data verified.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 14 — Encrypted storage

Scenario: A LUKS-backed filesystem no longer opens automatically.

Requirements: Identify mapping/configuration problem without recreating the filesystem.

Time target: 30 min

Verification: Volume opens; data intact; persistence restored.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 15 — DNF dependencies

Scenario: Package installation fails because of dependency/repository state.

Requirements: Determine the exact dependency chain and fix repository/package state.

Time target: 20 min

Verification: dnf transaction succeeds cleanly.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 16 — RPM database

Scenario: rpm/dnf queries fail on a disposable snapshot because the rpmdb is damaged.

Requirements: Preserve evidence, recover/rebuild the database, and verify package queries.

Time target: 25 min

Verification: rpm -qa and dnf operations work.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 17 — Changed package files

Scenario: An application binary/configuration may have been modified.

Requirements: Use package ownership and RPM verification to report changes.

Time target: 15 min

Verification: Produce exact changed-file evidence.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 18 — Connectivity

Scenario: Two hosts cannot communicate after a network change.

Requirements: Check link, address, route, DNS, socket, firewall; fix the actual fault.

Time target: 25 min

Verification: Bidirectional test succeeds.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 19 — Packet inspection

Scenario: A TCP connection times out.

Requirements: Capture packets and classify whether SYN leaves, reply returns, reset occurs, or firewall silently drops.

Time target: 20 min

Verification: tcpdump evidence supports conclusion.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 20 — Library dependencies

Scenario: A third-party executable fails with a missing shared library.

Requirements: Identify required soname/library and restore supported loader visibility.

Time target: 20 min

Verification: Executable starts; dependency resolution shown.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 21 — Memory leak

Scenario: A test application grows in resident memory.

Requirements: Confirm growth and use valgrind/memcheck or appropriate tooling to identify leak evidence.

Time target: 30 min

Verification: Report contains reproducible leak evidence.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 22 — Application tracing

Scenario: An app returns permission denied but file mode looks correct.

Requirements: Trace file/syscall behavior and correlate with logs.

Time target: 20 min

Verification: Root cause proven, not guessed.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 23 — SELinux

Scenario: A service works in permissive mode but not enforcing.

Requirements: Find AVC denial, correct label/boolean/policy-compatible config, return enforcing.

Time target: 25 min

Verification: Service works with SELinux enforcing.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 24 — PAM

Scenario: A local login fails after authentication configuration was changed.

Requirements: Inspect authselect/PAM state and logs; repair the stack safely.

Time target: 30 min

Verification: Login succeeds and authselect consistency check passes.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 25 — Account policy

Scenario: One user cannot log in; other users can.

Requirements: Determine expiration/lockout/password aging state and apply the intended policy.

Time target: 15 min

Verification: User works; policy verified.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 26 — Kdump

Scenario: A host must be ready to capture a kernel crash.

Requirements: Configure/verify kdump and its target; do not trigger unsafe crash outside disposable VM.

Time target: 30 min

Verification: kdump ready/status and dump target verified.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

TASK 27 — Support data

Scenario: A vendor requests diagnostic information before changes are made.

Requirements: Create sos report and collect targeted logs, package state, kernel, modules, and network evidence.

Time target: 20 min

Verification: Archive exists and evidence checklist complete.

Common mistakes: changing multiple subsystems at once; skipping evidence collection; using a destructive shortcut; failing to verify persistence.

Expected final state: the stated service/system outcome works, the root cause is identified, and the final configuration is stable across the relevant lifecycle/reboot test.

PART 20 — Progressive Labs

Level 1 — Foundation

Run tasks 01–06 with notes. Goal: build the troubleshooting method and the instrumentation/logging foundation.

Level 2 — Intermediate

Run tasks 07–18. Use snapshots but no step-by-step notes. Goal: recover boot, storage, packages, and networking safely.

Level 3 — Advanced

Run tasks 19–27 and combine two dependent faults. Goal: diagnose applications, security/authentication, kdump, and support data.

Level 4 — Troubleshooting

Randomize fault injection:

one symptom, one root cause;
one symptom, two independent root causes;
misleading symptom where the obvious subsystem is not the cause;
recovery where data preservation matters.

Level 5 — Exam Simulation

Use a clean copy of all VMs, hide your fault-injection notes, set a strict timer, and require final-state/reboot verification.

PART 21 — Five Full Original Mock Exams

Mock Exam 1 — Foundation

Time limit: 90 minutes

Tasks

Task 01 — Troubleshooting method: A service is reported ‘slow’ but not down. Collect CPU, memory, I/O, process and log evidence; identify the bottleneck; make only an evidence-backed correction.
Task 05 — Central logging: node1 messages do not arrive on loghost. Fix rsyslog path/transport/listener/firewall as needed and verify with logger.
Task 07 — Boot service failure: A required local service causes degraded boot. Identify the failed unit and dependency chain; repair and reboot.
Task 11 — Kernel modules: A required module is not loaded after reboot. Inspect module availability/parameters, configure persistent loading, reboot and verify.
Task 15 — DNF dependencies: Package installation fails because of dependency/repository state. Determine the exact dependency chain and fix repository/package state.
Task 18 — Connectivity: Two hosts cannot communicate after a network change. Check link, address, route, DNS, socket, firewall; fix the actual fault.

Scoring guidance

60 points total; 8 points per task + 12 points for verification/persistence. Suggested pass mark for self-study: 80%.

Solution method

Solutions are intentionally method-oriented rather than command-copy recipes: collect evidence → isolate layer → perform smallest safe repair → verify final state → reboot/lifecycle-check where relevant. Use the matching task’s verification criterion above as the answer key.

Failure rule

If a storage recovery task destroys data, SELinux is disabled instead of fixed, a PAM task locks out all administrative access without recovery, or persistence is not verified, mark that task failed even if the symptom temporarily disappears.

Mock Exam 2 — Intermediate

Time limit: 150 minutes

Tasks

Task 04 — Ansible: Two RHEL nodes drift from a required service configuration. Create inventory/playbook, apply idempotently, run twice, and show no unintended second-run changes.
Task 06 — AIDE: Integrity monitoring reports one legitimate and one suspicious change. Identify both, approve only the legitimate change, update baseline, and leave suspicious change reported.
Task 09 — Boot issue: The OS drops to emergency/rescue behavior because a persistent mount is wrong. Find the exact mount failure and correct persistent configuration.
Task 12 — Filesystem recovery: A disposable XFS/ext4 filesystem does not mount after simulated corruption. Use filesystem-appropriate diagnostic and repair workflow.
Task 17 — Changed package files: An application binary/configuration may have been modified. Use package ownership and RPM verification to report changes.
Task 20 — Library dependencies: A third-party executable fails with a missing shared library. Identify required soname/library and restore supported loader visibility.
Task 23 — SELinux: A service works in permissive mode but not enforcing. Find AVC denial, correct label/boolean/policy-compatible config, return enforcing.
Task 25 — Account policy: One user cannot log in; other users can. Determine expiration/lockout/password aging state and apply the intended policy.

Scoring guidance

80 points total; 8 points per task + 16 points for verification, evidence quality, and persistence. Suggested pass mark: 80%.

Solution method

Failure rule

Mock Exam 3 — Advanced

Time limit: 180 minutes

Tasks

Task 05 — Central logging: node1 messages do not arrive on loghost. Fix rsyslog path/transport/listener/firewall as needed and verify with logger.
Task 08 — Regain root control: Normal login is unavailable on a disposable lab VM. Use a current supported rescue path to regain administrative control and repair the cause.
Task 13 — LVM recovery: A VG references a missing or damaged PV in the lab. Use LVM metadata backups/archives to recover the mapping carefully.
Task 14 — Encrypted storage: A LUKS-backed filesystem no longer opens automatically. Identify mapping/configuration problem without recreating the filesystem.
Task 16 — RPM database: rpm/dnf queries fail on a disposable snapshot because the rpmdb is damaged. Preserve evidence, recover/rebuild the database, and verify package queries.
Task 19 — Packet inspection: A TCP connection times out. Capture packets and classify whether SYN leaves, reply returns, reset occurs, or firewall silently drops.
Task 21 — Memory leak: A test application grows in resident memory. Confirm growth and use valgrind/memcheck or appropriate tooling to identify leak evidence.
Task 24 — PAM: A local login fails after authentication configuration was changed. Inspect authselect/PAM state and logs; repair the stack safely.
Task 27 — Support data: A vendor requests diagnostic information before changes are made. Create sos report and collect targeted logs, package state, kernel, modules, and network evidence.

Scoring guidance

90 points total; 8 points per task + 18 points for safe recovery, persistence, and evidence. Suggested pass mark: 80%.

Solution method

Failure rule

Mock Exam 4 — Enterprise Scenario

Time limit: 210 minutes

Tasks

Task 02 — Documentation: A utility is unfamiliar and outside your memorized command set. Use local man/info/help and provided documentation to determine safe syntax; perform the requested change.
Task 04 — Ansible: Two RHEL nodes drift from a required service configuration. Create inventory/playbook, apply idempotently, run twice, and show no unintended second-run changes.
Task 05 — Central logging: node1 messages do not arrive on loghost. Fix rsyslog path/transport/listener/firewall as needed and verify with logger.
Task 10 — Hardware evidence: A NIC/disk is allegedly ‘missing’. Use kernel/hardware tools and logs to determine whether hardware is absent, driver is missing, or interface is simply down.
Task 12 — Filesystem recovery: A disposable XFS/ext4 filesystem does not mount after simulated corruption. Use filesystem-appropriate diagnostic and repair workflow.
Task 13 — LVM recovery: A VG references a missing or damaged PV in the lab. Use LVM metadata backups/archives to recover the mapping carefully.
Task 18 — Connectivity: Two hosts cannot communicate after a network change. Check link, address, route, DNS, socket, firewall; fix the actual fault.
Task 19 — Packet inspection: A TCP connection times out. Capture packets and classify whether SYN leaves, reply returns, reset occurs, or firewall silently drops.
Task 22 — Application tracing: An app returns permission denied but file mode looks correct. Trace file/syscall behavior and correlate with logs.
Task 23 — SELinux: A service works in permissive mode but not enforcing. Find AVC denial, correct label/boolean/policy-compatible config, return enforcing.
Task 26 — Kdump: A host must be ready to capture a kernel crash. Configure/verify kdump and its target; do not trigger unsafe crash outside disposable VM.
Task 27 — Support data: A vendor requests diagnostic information before changes are made. Create sos report and collect targeted logs, package state, kernel, modules, and network evidence.

Scoring guidance

120 points total; score both restoration and diagnostic reasoning. Suggested pass mark: 85%.

Solution method

Failure rule

Mock Exam 5 — Full EX342 Simulation

Time limit: 240 minutes

Tasks

Task 01 — Troubleshooting method: A service is reported ‘slow’ but not down. Collect CPU, memory, I/O, process and log evidence; identify the bottleneck; make only an evidence-backed correction.
Task 03 — RHEL web console: CLI metrics and web-console view disagree after a service change. Enable/access the web console, reconcile the state, and identify what changed.
Task 04 — Ansible: Two RHEL nodes drift from a required service configuration. Create inventory/playbook, apply idempotently, run twice, and show no unintended second-run changes.
Task 05 — Central logging: node1 messages do not arrive on loghost. Fix rsyslog path/transport/listener/firewall as needed and verify with logger.
Task 06 — AIDE: Integrity monitoring reports one legitimate and one suspicious change. Identify both, approve only the legitimate change, update baseline, and leave suspicious change reported.
Task 07 — Boot service failure: A required local service causes degraded boot. Identify the failed unit and dependency chain; repair and reboot.
Task 08 — Regain root control: Normal login is unavailable on a disposable lab VM. Use a current supported rescue path to regain administrative control and repair the cause.
Task 11 — Kernel modules: A required module is not loaded after reboot. Inspect module availability/parameters, configure persistent loading, reboot and verify.
Task 12 — Filesystem recovery: A disposable XFS/ext4 filesystem does not mount after simulated corruption. Use filesystem-appropriate diagnostic and repair workflow.
Task 13 — LVM recovery: A VG references a missing or damaged PV in the lab. Use LVM metadata backups/archives to recover the mapping carefully.
Task 15 — DNF dependencies: Package installation fails because of dependency/repository state. Determine the exact dependency chain and fix repository/package state.
Task 16 — RPM database: rpm/dnf queries fail on a disposable snapshot because the rpmdb is damaged. Preserve evidence, recover/rebuild the database, and verify package queries.
Task 18 — Connectivity: Two hosts cannot communicate after a network change. Check link, address, route, DNS, socket, firewall; fix the actual fault.
Task 19 — Packet inspection: A TCP connection times out. Capture packets and classify whether SYN leaves, reply returns, reset occurs, or firewall silently drops.
Task 20 — Library dependencies: A third-party executable fails with a missing shared library. Identify required soname/library and restore supported loader visibility.
Task 21 — Memory leak: A test application grows in resident memory. Confirm growth and use valgrind/memcheck or appropriate tooling to identify leak evidence.
Task 23 — SELinux: A service works in permissive mode but not enforcing. Find AVC denial, correct label/boolean/policy-compatible config, return enforcing.
Task 24 — PAM: A local login fails after authentication configuration was changed. Inspect authselect/PAM state and logs; repair the stack safely.
Task 25 — Account policy: One user cannot log in; other users can. Determine expiration/lockout/password aging state and apply the intended policy.
Task 26 — Kdump: A host must be ready to capture a kernel crash. Configure/verify kdump and its target; do not trigger unsafe crash outside disposable VM.
Task 27 — Support data: A vendor requests diagnostic information before changes are made. Create sos report and collect targeted logs, package state, kernel, modules, and network evidence.

Scoring guidance

Practice-only scoring: 210 points, 8 per task plus 42 points for persistence, reboot verification, no destructive shortcuts, and complete final-state checks. Target 85%+ twice before booking.

Solution method

Failure rule

PART 22 — 30 / 45 / 60 / 90 Day Study Plans

30-Day Intensive

Recommended for learners who can spend roughly 3–5 focused hours per day.

Day	Objective/topic	Theory	Lab	Troubleshooting	Revision
1	Official scope + baseline	Verify EX342 objectives; baseline RHCSA skills	Build/clone lab	Baseline facts	Review
2	Troubleshooting method	Evidence-first workflow, documentation	Task 01-02	Misleading symptom drill	Commands
3	Monitoring	CPU/memory/I/O/process/log interpretation	Task 01	Resource bottleneck	Metrics
4	RHEL web console	Cockpit monitoring/admin	Task 03	cockpit unavailable	Web+CLI
5	Ansible	Inventory, playbooks, idempotent config	Task 04	inventory/SSH failure	Syntax
6	Central logging	rsyslog client/server	Task 05	listener/firewall/config fault	Logs
7	Review: AIDE	baseline/check/update	Task 06 + repeat one earlier lab	legit vs suspicious drift	Timed command/file recall
8	Startup services	systemd failed units/dependencies	Task 07	boot-affecting unit	Journals
9	Rescue/root control	rescue workflow, chroot	Task 08	no normal login	Recovery
10	Boot troubleshooting	mount/initramfs/boot evidence	Task 09	bad persistent mount	Boot
11	Hardware	device/driver evidence	Task 10	missing NIC/disk	dmesg
12	Kernel modules	lsmod/modinfo/modprobe/persistence	Task 11	module absent after reboot	Modules
13	Filesystem recovery	XFS/ext4 safe repair	Task 12	corruption	Repair
14	Review: LVM recovery	metadata archives/restore	Task 13 + repeat one earlier lab	missing PV metadata	Timed command/file recall
15	Encrypted storage	LUKS evidence and recovery	Task 14	mapping failure	LUKS
16	DNF dependencies	repositories/dependency resolution	Task 15	transaction failure	DNF
17	RPM database	database recovery	Task 16	rpmdb failure	RPM
18	Package verification	ownership and changed files	Task 17	file drift	rpm -V
19	Networking	link/address/route/DNS/socket/firewall	Task 18	multi-layer failure	Network
20	Packet capture	tcpdump diagnosis	Task 19	timeout/refused/drop	Packets
21	Review: Libraries	ELF/shared dependencies	Task 20 + repeat one earlier lab	missing soname	Timed command/file recall
22	Memory leaks	process memory + valgrind	Task 21	leaky app	Memory
23	App debugging	strace/ltrace/coredumps	Task 22	permission/path failure	Tracing
24	SELinux	AVC evidence and correction	Task 23	label/boolean issue	SELinux
25	PAM	authselect/PAM stack	Task 24	login failure	PAM
26	Account policy	aging/expiration/lockout	Task 25	single-user failure	Accounts
27	Kdump	crash-dump readiness	Task 26	kdump not ready	Kernel crash
28	Review: Support data	sos report + evidence bundle	Task 27 + repeat one earlier lab	escalation drill	Timed command/file recall
29	Integrated incident	cross-domain troubleshooting	Mock subset	3 faults	Weak areas
30	Full simulation	4-hour integrated work	Mock 5	reboot/persistence	Final review

45-Day Balanced

Balanced path with more repeat labs and recovery practice.

Day	Objective/topic	Theory	Lab	Troubleshooting	Revision
1	Official scope + baseline	Verify EX342 objectives; baseline RHCSA skills	Build/clone lab	Baseline facts	Review
2	Official scope + baseline	Verify EX342 objectives; baseline RHCSA skills	Build/clone lab	Baseline facts	Review
3	Troubleshooting method	Evidence-first workflow, documentation	Task 01-02	Misleading symptom drill	Commands
4	Monitoring	CPU/memory/I/O/process/log interpretation	Task 01	Resource bottleneck	Metrics
5	Monitoring	CPU/memory/I/O/process/log interpretation	Task 01	Resource bottleneck	Metrics
6	RHEL web console	Cockpit monitoring/admin	Task 03	cockpit unavailable	Web+CLI
7	Review: Ansible	Inventory, playbooks, idempotent config	Task 04 + repeat one earlier lab	inventory/SSH failure	Timed command/file recall
8	Ansible	Inventory, playbooks, idempotent config	Task 04	inventory/SSH failure	Syntax
9	Central logging	rsyslog client/server	Task 05	listener/firewall/config fault	Logs
10	AIDE	baseline/check/update	Task 06	legit vs suspicious drift	Files
11	AIDE	baseline/check/update	Task 06	legit vs suspicious drift	Files
12	Startup services	systemd failed units/dependencies	Task 07	boot-affecting unit	Journals
13	Rescue/root control	rescue workflow, chroot	Task 08	no normal login	Recovery
14	Review: Rescue/root control	rescue workflow, chroot	Task 08 + repeat one earlier lab	no normal login	Timed command/file recall
15	Boot troubleshooting	mount/initramfs/boot evidence	Task 09	bad persistent mount	Boot
16	Hardware	device/driver evidence	Task 10	missing NIC/disk	dmesg
17	Hardware	device/driver evidence	Task 10	missing NIC/disk	dmesg
18	Kernel modules	lsmod/modinfo/modprobe/persistence	Task 11	module absent after reboot	Modules
19	Filesystem recovery	XFS/ext4 safe repair	Task 12	corruption	Repair
20	Filesystem recovery	XFS/ext4 safe repair	Task 12	corruption	Repair
21	Review: LVM recovery	metadata archives/restore	Task 13 + repeat one earlier lab	missing PV metadata	Timed command/file recall
22	Encrypted storage	LUKS evidence and recovery	Task 14	mapping failure	LUKS
23	Encrypted storage	LUKS evidence and recovery	Task 14	mapping failure	LUKS
24	DNF dependencies	repositories/dependency resolution	Task 15	transaction failure	DNF
25	RPM database	database recovery	Task 16	rpmdb failure	RPM
26	RPM database	database recovery	Task 16	rpmdb failure	RPM
27	Package verification	ownership and changed files	Task 17	file drift	rpm -V
28	Review: Networking	link/address/route/DNS/socket/firewall	Task 18 + repeat one earlier lab	multi-layer failure	Timed command/file recall
29	Networking	link/address/route/DNS/socket/firewall	Task 18	multi-layer failure	Network
30	Packet capture	tcpdump diagnosis	Task 19	timeout/refused/drop	Packets
31	Libraries	ELF/shared dependencies	Task 20	missing soname	Libraries
32	Libraries	ELF/shared dependencies	Task 20	missing soname	Libraries
33	Memory leaks	process memory + valgrind	Task 21	leaky app	Memory
34	App debugging	strace/ltrace/coredumps	Task 22	permission/path failure	Tracing
35	Review: App debugging	strace/ltrace/coredumps	Task 22 + repeat one earlier lab	permission/path failure	Timed command/file recall
36	SELinux	AVC evidence and correction	Task 23	label/boolean issue	SELinux
37	PAM	authselect/PAM stack	Task 24	login failure	PAM
38	PAM	authselect/PAM stack	Task 24	login failure	PAM
39	Account policy	aging/expiration/lockout	Task 25	single-user failure	Accounts
40	Kdump	crash-dump readiness	Task 26	kdump not ready	Kernel crash
41	Kdump	crash-dump readiness	Task 26	kdump not ready	Kernel crash
42	Review: Support data	sos report + evidence bundle	Task 27 + repeat one earlier lab	escalation drill	Timed command/file recall
43	Integrated incident	cross-domain troubleshooting	Mock subset	3 faults	Weak areas
44	Integrated incident	cross-domain troubleshooting	Mock subset	3 faults	Weak areas
45	Full simulation	4-hour integrated work	Mock 5	reboot/persistence	Final review

60-Day Moderate

Moderate daily load with deliberate troubleshooting repetition.

Day	Objective/topic	Theory	Lab	Troubleshooting	Revision
1	Official scope + baseline	Verify EX342 objectives; baseline RHCSA skills	Build/clone lab	Baseline facts	Review
2	Official scope + baseline	Verify EX342 objectives; baseline RHCSA skills	Build/clone lab	Baseline facts	Review
3	Troubleshooting method	Evidence-first workflow, documentation	Task 01-02	Misleading symptom drill	Commands
4	Troubleshooting method	Evidence-first workflow, documentation	Task 01-02	Misleading symptom drill	Commands
5	Monitoring	CPU/memory/I/O/process/log interpretation	Task 01	Resource bottleneck	Metrics
6	Monitoring	CPU/memory/I/O/process/log interpretation	Task 01	Resource bottleneck	Metrics
7	Review: RHEL web console	Cockpit monitoring/admin	Task 03 + repeat one earlier lab	cockpit unavailable	Timed command/file recall
8	RHEL web console	Cockpit monitoring/admin	Task 03	cockpit unavailable	Web+CLI
9	Ansible	Inventory, playbooks, idempotent config	Task 04	inventory/SSH failure	Syntax
10	Ansible	Inventory, playbooks, idempotent config	Task 04	inventory/SSH failure	Syntax
11	Central logging	rsyslog client/server	Task 05	listener/firewall/config fault	Logs
12	Central logging	rsyslog client/server	Task 05	listener/firewall/config fault	Logs
13	AIDE	baseline/check/update	Task 06	legit vs suspicious drift	Files
14	Review: AIDE	baseline/check/update	Task 06 + repeat one earlier lab	legit vs suspicious drift	Timed command/file recall
15	Startup services	systemd failed units/dependencies	Task 07	boot-affecting unit	Journals
16	Startup services	systemd failed units/dependencies	Task 07	boot-affecting unit	Journals
17	Rescue/root control	rescue workflow, chroot	Task 08	no normal login	Recovery
18	Rescue/root control	rescue workflow, chroot	Task 08	no normal login	Recovery
19	Boot troubleshooting	mount/initramfs/boot evidence	Task 09	bad persistent mount	Boot
20	Boot troubleshooting	mount/initramfs/boot evidence	Task 09	bad persistent mount	Boot
21	Review: Hardware	device/driver evidence	Task 10 + repeat one earlier lab	missing NIC/disk	Timed command/file recall
22	Hardware	device/driver evidence	Task 10	missing NIC/disk	dmesg
23	Kernel modules	lsmod/modinfo/modprobe/persistence	Task 11	module absent after reboot	Modules
24	Kernel modules	lsmod/modinfo/modprobe/persistence	Task 11	module absent after reboot	Modules
25	Filesystem recovery	XFS/ext4 safe repair	Task 12	corruption	Repair
26	Filesystem recovery	XFS/ext4 safe repair	Task 12	corruption	Repair
27	LVM recovery	metadata archives/restore	Task 13	missing PV metadata	LVM
28	Review: LVM recovery	metadata archives/restore	Task 13 + repeat one earlier lab	missing PV metadata	Timed command/file recall
29	Encrypted storage	LUKS evidence and recovery	Task 14	mapping failure	LUKS
30	Encrypted storage	LUKS evidence and recovery	Task 14	mapping failure	LUKS
31	DNF dependencies	repositories/dependency resolution	Task 15	transaction failure	DNF
32	DNF dependencies	repositories/dependency resolution	Task 15	transaction failure	DNF
33	RPM database	database recovery	Task 16	rpmdb failure	RPM
34	RPM database	database recovery	Task 16	rpmdb failure	RPM
35	Review: Package verification	ownership and changed files	Task 17 + repeat one earlier lab	file drift	Timed command/file recall
36	Package verification	ownership and changed files	Task 17	file drift	rpm -V
37	Networking	link/address/route/DNS/socket/firewall	Task 18	multi-layer failure	Network
38	Networking	link/address/route/DNS/socket/firewall	Task 18	multi-layer failure	Network
39	Packet capture	tcpdump diagnosis	Task 19	timeout/refused/drop	Packets
40	Packet capture	tcpdump diagnosis	Task 19	timeout/refused/drop	Packets
41	Libraries	ELF/shared dependencies	Task 20	missing soname	Libraries
42	Review: Libraries	ELF/shared dependencies	Task 20 + repeat one earlier lab	missing soname	Timed command/file recall
43	Memory leaks	process memory + valgrind	Task 21	leaky app	Memory
44	Memory leaks	process memory + valgrind	Task 21	leaky app	Memory
45	App debugging	strace/ltrace/coredumps	Task 22	permission/path failure	Tracing
46	App debugging	strace/ltrace/coredumps	Task 22	permission/path failure	Tracing
47	SELinux	AVC evidence and correction	Task 23	label/boolean issue	SELinux
48	SELinux	AVC evidence and correction	Task 23	label/boolean issue	SELinux
49	Review: PAM	authselect/PAM stack	Task 24 + repeat one earlier lab	login failure	Timed command/file recall
50	PAM	authselect/PAM stack	Task 24	login failure	PAM
51	Account policy	aging/expiration/lockout	Task 25	single-user failure	Accounts
52	Account policy	aging/expiration/lockout	Task 25	single-user failure	Accounts
53	Kdump	crash-dump readiness	Task 26	kdump not ready	Kernel crash
54	Kdump	crash-dump readiness	Task 26	kdump not ready	Kernel crash
55	Support data	sos report + evidence bundle	Task 27	escalation drill	sos
56	Review: Support data	sos report + evidence bundle	Task 27 + repeat one earlier lab	escalation drill	Timed command/file recall
57	Integrated incident	cross-domain troubleshooting	Mock subset	3 faults	Weak areas
58	Integrated incident	cross-domain troubleshooting	Mock subset	3 faults	Weak areas
59	Full simulation	4-hour integrated work	Mock 5	reboot/persistence	Final review
60	Full simulation	4-hour integrated work	Mock 5	reboot/persistence	Final review

90-Day Part-Time

Part-time path emphasizing repetition, rebuilds, and retention.

Day	Objective/topic	Theory	Lab	Troubleshooting	Revision
1	Official scope + baseline	Verify EX342 objectives; baseline RHCSA skills	Build/clone lab	Baseline facts	Review
2	Official scope + baseline	Verify EX342 objectives; baseline RHCSA skills	Build/clone lab	Baseline facts	Review
3	Official scope + baseline	Verify EX342 objectives; baseline RHCSA skills	Build/clone lab	Baseline facts	Review
4	Troubleshooting method	Evidence-first workflow, documentation	Task 01-02	Misleading symptom drill	Commands
5	Troubleshooting method	Evidence-first workflow, documentation	Task 01-02	Misleading symptom drill	Commands
6	Troubleshooting method	Evidence-first workflow, documentation	Task 01-02	Misleading symptom drill	Commands
7	Review: Monitoring	CPU/memory/I/O/process/log interpretation	Task 01 + repeat one earlier lab	Resource bottleneck	Timed command/file recall
8	Monitoring	CPU/memory/I/O/process/log interpretation	Task 01	Resource bottleneck	Metrics
9	Monitoring	CPU/memory/I/O/process/log interpretation	Task 01	Resource bottleneck	Metrics
10	RHEL web console	Cockpit monitoring/admin	Task 03	cockpit unavailable	Web+CLI
11	RHEL web console	Cockpit monitoring/admin	Task 03	cockpit unavailable	Web+CLI
12	RHEL web console	Cockpit monitoring/admin	Task 03	cockpit unavailable	Web+CLI
13	Ansible	Inventory, playbooks, idempotent config	Task 04	inventory/SSH failure	Syntax
14	Review: Ansible	Inventory, playbooks, idempotent config	Task 04 + repeat one earlier lab	inventory/SSH failure	Timed command/file recall
15	Ansible	Inventory, playbooks, idempotent config	Task 04	inventory/SSH failure	Syntax
16	Central logging	rsyslog client/server	Task 05	listener/firewall/config fault	Logs
17	Central logging	rsyslog client/server	Task 05	listener/firewall/config fault	Logs
18	Central logging	rsyslog client/server	Task 05	listener/firewall/config fault	Logs
19	AIDE	baseline/check/update	Task 06	legit vs suspicious drift	Files
20	AIDE	baseline/check/update	Task 06	legit vs suspicious drift	Files
21	Review: AIDE	baseline/check/update	Task 06 + repeat one earlier lab	legit vs suspicious drift	Timed command/file recall
22	Startup services	systemd failed units/dependencies	Task 07	boot-affecting unit	Journals
23	Startup services	systemd failed units/dependencies	Task 07	boot-affecting unit	Journals
24	Startup services	systemd failed units/dependencies	Task 07	boot-affecting unit	Journals
25	Rescue/root control	rescue workflow, chroot	Task 08	no normal login	Recovery
26	Rescue/root control	rescue workflow, chroot	Task 08	no normal login	Recovery
27	Rescue/root control	rescue workflow, chroot	Task 08	no normal login	Recovery
28	Review: Boot troubleshooting	mount/initramfs/boot evidence	Task 09 + repeat one earlier lab	bad persistent mount	Timed command/file recall
29	Boot troubleshooting	mount/initramfs/boot evidence	Task 09	bad persistent mount	Boot
30	Boot troubleshooting	mount/initramfs/boot evidence	Task 09	bad persistent mount	Boot
31	Hardware	device/driver evidence	Task 10	missing NIC/disk	dmesg
32	Hardware	device/driver evidence	Task 10	missing NIC/disk	dmesg
33	Hardware	device/driver evidence	Task 10	missing NIC/disk	dmesg
34	Kernel modules	lsmod/modinfo/modprobe/persistence	Task 11	module absent after reboot	Modules
35	Review: Kernel modules	lsmod/modinfo/modprobe/persistence	Task 11 + repeat one earlier lab	module absent after reboot	Timed command/file recall
36	Kernel modules	lsmod/modinfo/modprobe/persistence	Task 11	module absent after reboot	Modules
37	Filesystem recovery	XFS/ext4 safe repair	Task 12	corruption	Repair
38	Filesystem recovery	XFS/ext4 safe repair	Task 12	corruption	Repair
39	Filesystem recovery	XFS/ext4 safe repair	Task 12	corruption	Repair
40	LVM recovery	metadata archives/restore	Task 13	missing PV metadata	LVM
41	LVM recovery	metadata archives/restore	Task 13	missing PV metadata	LVM
42	Review: LVM recovery	metadata archives/restore	Task 13 + repeat one earlier lab	missing PV metadata	Timed command/file recall
43	Encrypted storage	LUKS evidence and recovery	Task 14	mapping failure	LUKS
44	Encrypted storage	LUKS evidence and recovery	Task 14	mapping failure	LUKS
45	Encrypted storage	LUKS evidence and recovery	Task 14	mapping failure	LUKS
46	DNF dependencies	repositories/dependency resolution	Task 15	transaction failure	DNF
47	DNF dependencies	repositories/dependency resolution	Task 15	transaction failure	DNF
48	DNF dependencies	repositories/dependency resolution	Task 15	transaction failure	DNF
49	Review: RPM database	database recovery	Task 16 + repeat one earlier lab	rpmdb failure	Timed command/file recall
50	RPM database	database recovery	Task 16	rpmdb failure	RPM
51	RPM database	database recovery	Task 16	rpmdb failure	RPM
52	Package verification	ownership and changed files	Task 17	file drift	rpm -V
53	Package verification	ownership and changed files	Task 17	file drift	rpm -V
54	Package verification	ownership and changed files	Task 17	file drift	rpm -V
55	Networking	link/address/route/DNS/socket/firewall	Task 18	multi-layer failure	Network
56	Review: Networking	link/address/route/DNS/socket/firewall	Task 18 + repeat one earlier lab	multi-layer failure	Timed command/file recall
57	Networking	link/address/route/DNS/socket/firewall	Task 18	multi-layer failure	Network
58	Packet capture	tcpdump diagnosis	Task 19	timeout/refused/drop	Packets
59	Packet capture	tcpdump diagnosis	Task 19	timeout/refused/drop	Packets
60	Packet capture	tcpdump diagnosis	Task 19	timeout/refused/drop	Packets
61	Libraries	ELF/shared dependencies	Task 20	missing soname	Libraries
62	Libraries	ELF/shared dependencies	Task 20	missing soname	Libraries
63	Review: Libraries	ELF/shared dependencies	Task 20 + repeat one earlier lab	missing soname	Timed command/file recall
64	Memory leaks	process memory + valgrind	Task 21	leaky app	Memory
65	Memory leaks	process memory + valgrind	Task 21	leaky app	Memory
66	Memory leaks	process memory + valgrind	Task 21	leaky app	Memory
67	App debugging	strace/ltrace/coredumps	Task 22	permission/path failure	Tracing
68	App debugging	strace/ltrace/coredumps	Task 22	permission/path failure	Tracing
69	App debugging	strace/ltrace/coredumps	Task 22	permission/path failure	Tracing
70	Review: SELinux	AVC evidence and correction	Task 23 + repeat one earlier lab	label/boolean issue	Timed command/file recall
71	SELinux	AVC evidence and correction	Task 23	label/boolean issue	SELinux
72	SELinux	AVC evidence and correction	Task 23	label/boolean issue	SELinux
73	PAM	authselect/PAM stack	Task 24	login failure	PAM
74	PAM	authselect/PAM stack	Task 24	login failure	PAM
75	PAM	authselect/PAM stack	Task 24	login failure	PAM
76	Account policy	aging/expiration/lockout	Task 25	single-user failure	Accounts
77	Review: Account policy	aging/expiration/lockout	Task 25 + repeat one earlier lab	single-user failure	Timed command/file recall
78	Account policy	aging/expiration/lockout	Task 25	single-user failure	Accounts
79	Kdump	crash-dump readiness	Task 26	kdump not ready	Kernel crash
80	Kdump	crash-dump readiness	Task 26	kdump not ready	Kernel crash
81	Kdump	crash-dump readiness	Task 26	kdump not ready	Kernel crash
82	Support data	sos report + evidence bundle	Task 27	escalation drill	sos
83	Support data	sos report + evidence bundle	Task 27	escalation drill	sos
84	Review: Support data	sos report + evidence bundle	Task 27 + repeat one earlier lab	escalation drill	Timed command/file recall
85	Integrated incident	cross-domain troubleshooting	Mock subset	3 faults	Weak areas
86	Integrated incident	cross-domain troubleshooting	Mock subset	3 faults	Weak areas
87	Integrated incident	cross-domain troubleshooting	Mock subset	3 faults	Weak areas
88	Full simulation	4-hour integrated work	Mock 5	reboot/persistence	Final review
89	Full simulation	4-hour integrated work	Mock 5	reboot/persistence	Final review
90	Full simulation	4-hour integrated work	Mock 5	reboot/persistence	Final review

PART 23 — EX342 Readiness Checklist

1. Understand and employ general methods for troubleshooting

Consult documentation resources to aid in troubleshooting

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Monitor systems for vital characteristics

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Monitor systems with the RHEL Web console

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Configure systems using Ansible

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Configure systems to send log messages to a centralized host

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Configure systems to monitor files and directories using AIDE

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

2. Diagnose and troubleshoot system startup issues

Identify and resolve service failures affecting boot

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Regain root control of a system

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Troubleshoot boot issues

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Identify hardware and hardware problems

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Manage kernel modules and their parameters

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

3. Diagnose and troubleshoot file system issues

Recover corrupted file systems

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Recover misconfigured or broken LVM configurations

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Recover data from encrypted file systems

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

4. Resolve package management issues

Resolve package management dependency issues

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Recover a corrupted RPM database

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Identify and report changed files

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

5. Troubleshoot and fix network connectivity issues

Use standard tools to verify network connectivity

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Identify and fix network connectivity issues

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Inspect network traffic to aid troubleshooting

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

6. Diagnose application issues

Identify library dependencies for third-party software

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Identify if an application suffers from memory leaks

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Use standard tools to debug an application

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Identify and fix issues related to SELinux

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

7. Identify and fix authentication issues

Identify and fix pluggable authentication module (PAM) issues

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Identify and enforce local user account policies

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

8. Gather information to aid third-party investigation of issues

Create kernel crash dumps

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Collect system information to aid in troubleshooting

[ ] Understand the concept
[ ] Can configure/recover it without notes
[ ] Can verify it
[ ] Can troubleshoot it from symptoms
[ ] Can recover from an intentional failure
[ ] Can complete a practical task under time pressure
[ ] Can explain persistence/reboot implications

Final readiness gate

[ ] Two full four-hour simulations completed at 85%+ using the practice scoring model
[ ] No destructive shortcuts used in storage recovery
[ ] SELinux problems solved while returning to enforcing mode
[ ] Can use documentation efficiently instead of relying on memorization
[ ] Can collect evidence before restarting/changing services
[ ] Can identify the first causal failure in boot/service chains
[ ] Can perform final reboot/persistence checks within the timer

PART 24 — Exam-Day Strategy

Officially verified exam facts

EX342 is hands-on/practical.
Current public time limit: 4 hours.
Current public base: RHEL 10.2.
Relevant product documentation is provided in the exam environment.
Outside assistance is not allowed.
Multiple versions can be in use; review your assigned LMS version/objectives.
Configurations/services must remain functional through the normal platform lifecycle without manual intervention.
Current Certification Program Guide says Red Hat exams are graded on the final state and persistence matters.

Practical time-management method — study guidance, not an official Red Hat scoring rule

Read all instructions and environment information carefully.
Identify dependent tasks before changing foundational networking/storage/authentication.
Complete high-confidence tasks first if dependencies allow.
Reserve time to troubleshoot and to verify persistence.
Keep a short scratch list: task → state → verification → reboot check.
When stuck, stop random changes. Re-read the requirement, collect fresh evidence, and move to another independent task if necessary.
Perform a final state review.
Reboot only when appropriate and when you still have time to recover if a hidden persistence problem appears.

Do not infer unpublished scoring weights or confidential task structures from practice material.

PART 25 — What Not to Study

Required for EX342 — officially supported by current objectives

troubleshooting methodology and documentation
system monitoring
RHEL web console
Ansible-based system configuration
centralized logging
AIDE
boot/startup/service recovery
root/admin recovery mechanisms
hardware diagnosis
kernel modules and parameters
filesystem recovery
LVM recovery
encrypted-filesystem data recovery
DNF/package dependency troubleshooting
corrupted RPM database recovery
RPM changed-file identification/reporting
network troubleshooting
packet inspection
application library dependencies
memory leaks
application debugging
SELinux issue diagnosis/fix
PAM troubleshooting
local account policies
kernel crash dumps
support/diagnostic data collection

Useful background — do not mistake for a separate objective

firewalld mechanics
SSH administration
normal RHCSA storage/network/user/systemd skills
shell scripting for small diagnostic helpers
basic C compilation to create safe debugging lab programs
sudo and ACLs
DNS server internals
detailed performance tooling beyond what is needed to diagnose a fault

Outside the current public EX342 objective list unless needed only as lab background

OpenShift/Kubernetes administration
Ceph architecture
high-availability clustering
Satellite deployment
full Identity Management/FreeIPA server deployment
advanced Ansible Automation Platform controller architecture
container orchestration
advanced Linux security hardening certification material
deep performance-tuning specialization
enterprise storage products beyond LVM/filesystem/encryption recovery
cloud-provider administration

Those topics may be useful professionally or appear in other Red Hat certifications, but they should not displace time from current EX342 objectives.

PART 26 — EX342 vs Other Red Hat Exams

Exam	Current role in 2026 framework	What it is primarily about
EX200	Red Hat Certified System Administrator (RHCSA); foundational requirement for Enterprise Linux RHCE	Core RHEL system administration
EX342	Red Hat Certified Advanced System Administrator in Enterprise Linux; combines with EX200 for RHCE-Enterprise Linux	Advanced RHEL diagnosis, troubleshooting, recovery, evidence collection
EX294	Red Hat Certified Advanced System Administrator in Ansible; combines with EX200 for RHCE-Ansible	Ansible-based administration/automation
EX280	OpenShift administrator credential/foundation of OpenShift Engineer path	OpenShift administration
EX380	Advanced System Administrator in OpenShift; combines with EX280 for RHCE-OpenShift	Advanced OpenShift administration

Do not study EX294 playbook breadth, EX280 cluster administration, or EX380 OpenShift objectives as substitutes for EX342. EX342 has its own current objective list.

PART 27 — Training vs Certification Exam

Red Hat training course
        ≠
Certification exam
        ≠
Certification credential

RH342 is Red Hat’s recommended diagnostics/troubleshooting training course.
EX342 is the certification exam.
Passing EX342 awards the Red Hat Certified Advanced System Administrator in Enterprise Linux credential.
RHCE in Enterprise Linux requires the matching foundational RHCSA/EX200 plus EX342.

The current EX342 page recommends RH342 or similar troubleshooting experience. This guide is designed around the second route: independent study and hands-on practice.

PART 28 — Cost & Exam Registration

Pricing

The current Red Hat Certification Program Guide publishes a standard list price of USD $500 for a Red Hat certification exam and states that the actual price can vary by region and is shown in the shopping cart.

For Japan:

Check the current Red Hat Japan exam purchase page/cart for the applicable JPY price.

A fixed Japan-specific EX342 price was not verified from a public official page during this research pass, so this guide does not guess one.

Delivery methods

Current Red Hat information supports:

remote individual exams;
individual testing stations / testing centers;
classroom/on-site formats where offered.

Availability can depend on exam/region/scheduler.

Remote exam

Current policies require using Red Hat’s remote exam environment and completing the compatibility test. Hardware and technical requirements can change, so use the current booking/remote-exam documentation rather than a static third-party checklist.

Retake

Current policy provides one free retake after an unsuccessful paid first attempt for eligible Individual/Preliminary exams. The program guide states no waiting period after the first failed attempt, but the same exam may not be taken more than once in the same calendar day. Further attempts require a new paid registration and may be subject to a waiting period.

Purchase flow

Choose the correct current exam/version.
Purchase through Red Hat or an authorized channel.
Receive scheduling instructions.
Choose eligible delivery format/date/location.
For remote testing, complete the current compatibility test before exam day.

Official:

PART 29 — Certification Validity / Currency

Red Hat’s current policy says certifications are current for three years from the date earned.

The 2026 framework introduced more flexible renewal behavior. Current official documentation describes these broad paths:

retake the exam associated with your highest-level certification;
earn another certification at the same level;
advance to a higher-level certification;
retake the original exam to renew that specific credential where applicable.

Renewal must be completed while the credential is still current; expired/non-current credentials may need to be earned again according to the current policy.

For RHCE-Enterprise Linux, remember the stacking model:

RHCSA / EX200
    +
RHCASA Enterprise Linux / EX342
    =
RHCE in Enterprise Linux

Always check the live Certification Portal for the exact current-until date on your transcript.

Official framework/renewal sources:

PART 30 — Official Resource Map

Topic	Official Red Hat source	Purpose
EX342 current exam page	https://www.redhat.com/en/services/training/ex342-red-hat-certified-specialist-linux-diagnostics-and-troubleshooting	Exam name, RHEL version, duration, exact objectives, recommended preparation
RHCASA Enterprise Linux	https://www.redhat.com/en/services/certification/rhcs-red-hat-enterprise-linux-diagnostics-and-troubleshooting	Credential description and scope
RHCE Enterprise Linux	https://www.redhat.com/en/services/certification/red-hat-certified-engineer-in-enterprise-linux	EX200 + EX342 Engineer relationship
Certification catalog	https://www.redhat.com/en/services/certifications	Current 2026 framework and requirements
Certification FAQ	https://www.redhat.com/en/services/training-and-certification/faq	May 2026 changes, renamed credentials, renewal rules
Certification Program Guide	https://docs.redhat.com/en/documentation/red_hat_learning_subscription/1-latest/html/red_hat_certification_program_guide/index	Pricing, format, exam policies, retake, persistence
RHEL 10 documentation	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10	Current product documentation index
System monitoring/performance	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/monitoring_and_managing_system_status_and_performance/index	Monitoring, performance tools, memory diagnostics
RHEL web console	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/managing_systems_in_the_rhel_web_console/getting-started-with-the-rhel-web-console	Cockpit install/use/monitoring
RHEL system roles/Ansible	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/automating_system_administration_by_using_rhel_system_roles/index	Ansible control/managed-node configuration
Remote/centralized logging	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/risk_reduction_and_recovery_operations/configuring-a-remote-logging-solution	rsyslog forwarding/receiving
Security hardening/AIDE	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/security_hardening/index	AIDE installation, baseline, checks, updates
RHEL rescue mode	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/interactively_installing_rhel_from_installation_media/troubleshooting-after-installation	Boot-media rescue, chroot, sos in rescue
Kernel modules	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/managing_monitoring_and_updating_the_kernel/managing-kernel-modules	lsmod/modinfo/modprobe/persistent module config
Filesystem checking/repair	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/managing_file_systems/checking-and-repairing-a-file-system_	XFS and filesystem repair guidance
LVM troubleshooting	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_logical_volumes/troubleshooting-lvm	LVM diagnostics and metadata restore
DNF software management	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/managing_software_with_the_dnf_tool/managing_software_with_the_dnf_tool	Repositories/packages/dependencies
RHEL networking	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html-single/configuring_and_managing_networking/index	NetworkManager and network configuration/troubleshooting
SELinux troubleshooting	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/troubleshooting-problems-related-to-selinux	AVC evidence and SELinux diagnosis
Authentication/authselect	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect	PAM/NSS/authselect behavior
Application debugging	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/developing_c_and_cpp_applications_in_rhel_10/debugging-applications	strace/ltrace/core/debug tooling
Kdump	https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/managing_monitoring_and_updating_the_kernel/supported-kdump-configurations-and-targets	Crash dump configuration and targets
Developer Subscription	https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux	No-cost individual RHEL access

PART 31 — Final Master Curriculum Matrix

Module	Official EX342 objective	Knowledge	Commands	Configuration	Lab	Troubleshooting	Exam practice
1	Understand and employ general methods for troubleshooting	Consult documentation resources to aid in troubleshooting; Monitor systems for vital characteristics; Monitor systems with the RHEL Web console; Configure systems using Ansible; Configure systems to send log messages to a centralized host; Configure systems to monitor files and directories using AIDE	man, info, journalctl, dmesg, systemctl, ps…	/etc/rsyslog.conf…	4 required labs	Break rsyslog forwarding, corrupt an Ansible inventory entry, stop cockpit.socket, and change an AIDE-monitored file. Diagnose each from observable evidence.	A managed system is not forwarding logs, a required configuration differs from the desired Ansible state, and AIDE reports a file change. Restore and verify all three.
2	Diagnose and troubleshoot system startup issues	Identify and resolve service failures affecting boot; Regain root control of a system; Troubleshoot boot issues; Identify hardware and hardware problems; Manage kernel modules and their parameters	systemctl –failed, systemctl status, systemctl list-dependencies, journalctl -b, journalctl -b -1, dmesg…	/etc/systemd/system/…	4 required labs	Introduce an invalid persistent mount or failed required service; recover using console/rescue access. Simulate a wrong kernel-module setting and confirm the effect after reboot.	A VM stops during startup because of a configuration fault. Regain administrative control, identify the failure from evidence, correct it, boot normally, and prove the fix survives another reboot.
3	Diagnose and troubleshoot file system issues	Recover corrupted file systems; Recover misconfigured or broken LVM configurations; Recover data from encrypted file systems	lsblk -f, blkid, findmnt, mount, umount, xfs_repair…	/etc/fstab…	4 required labs	Wrong UUID in fstab, missing PV metadata, inactive VG/LV, damaged XFS metadata in a disposable filesystem, incorrect crypttab entry.	Restore three storage failures: a filesystem that will not mount, an LVM stack that is incomplete, and an encrypted volume whose data must remain intact.
4	Resolve package management issues	Resolve package management dependency issues; Recover a corrupted RPM database; Identify and report changed files	dnf repolist, dnf list, dnf info, dnf repoquery, dnf provides, dnf install…	/etc/dnf/dnf.conf…	4 required labs	Disable a needed repository, create an impossible package dependency in a lab RPM scenario, change a package-owned file, and damage a disposable copy of the RPM database.	Restore package management to a working state and produce evidence identifying which package-owned files had changed.
5	Troubleshoot and fix network connectivity issues	Use standard tools to verify network connectivity; Identify and fix network connectivity issues; Inspect network traffic to aid troubleshooting	ip link, ip addr, ip route, ip neigh, nmcli, ping…	/etc/NetworkManager/system-connections/*.nmconnection…	4 required labs	Wrong IP/prefix, missing route, incorrect DNS, stopped listener, firewall block, duplicate address, disabled NetworkManager profile.	A service is reachable from localhost but not from another VM. Identify the failing layer using standard tools and packet capture, fix it, and verify persistence.
6	Diagnose application issues	Identify library dependencies for third-party software; Identify if an application suffers from memory leaks; Use standard tools to debug an application; Identify and fix issues related to SELinux	ldd, readelf, objdump, file, strace, ltrace…	/etc/ld.so.conf…	4 required labs	Missing shared object, wrong library path, application permission failure, memory leak in a disposable test program, wrong SELinux label.	Diagnose why a third-party service fails after relocation to a nonstandard path, prove the root cause with tracing/log evidence, and restore operation without disabling SELinux.
7	Identify and fix authentication issues	Identify and fix pluggable authentication module (PAM) issues; Identify and enforce local user account policies	authselect current, authselect check, authselect select, passwd, chage, faillock…	/etc/pam.d/*…	4 required labs	Expired account, locked user, invalid PAM module reference in a disposable profile, inconsistent authselect state.	A valid local user cannot authenticate. Determine whether the cause is account policy, lockout, PAM stack, or identity lookup; fix only the actual cause and verify.
8	Gather information to aid third-party investigation of issues	Create kernel crash dumps; Collect system information to aid in troubleshooting	kdumpctl status, systemctl status kdump, journalctl -u kdump, sysctl, grubby, sos report…	/etc/kdump.conf…	4 required labs	kdump service not ready, invalid dump target in a disposable configuration, insufficient/incorrect crash-kernel setup, sos unable to collect a chosen plugin due to missing package.	Prepare a failing host for escalation: verify crash-dump capability, gather a complete diagnostic archive, and document the minimum evidence needed to reproduce the incident.
9	All objectives	Cross-domain incident isolation	All as evidence requires	All relevant	Integrated multi-fault labs	Cross-layer root cause	Four-hour simulation

Coverage audit

[x] 1. Understand and employ general methods for troubleshooting
- [x] Consult documentation resources to aid in troubleshooting
- [x] Monitor systems for vital characteristics
- [x] Monitor systems with the RHEL Web console
- [x] Configure systems using Ansible
- [x] Configure systems to send log messages to a centralized host
- [x] Configure systems to monitor files and directories using AIDE
[x] 2. Diagnose and troubleshoot system startup issues
- [x] Identify and resolve service failures affecting boot
- [x] Regain root control of a system
- [x] Troubleshoot boot issues
- [x] Identify hardware and hardware problems
- [x] Manage kernel modules and their parameters
[x] 3. Diagnose and troubleshoot file system issues
- [x] Recover corrupted file systems
- [x] Recover misconfigured or broken LVM configurations
- [x] Recover data from encrypted file systems
[x] 4. Resolve package management issues
- [x] Resolve package management dependency issues
- [x] Recover a corrupted RPM database
- [x] Identify and report changed files
[x] 5. Troubleshoot and fix network connectivity issues
- [x] Use standard tools to verify network connectivity
- [x] Identify and fix network connectivity issues
- [x] Inspect network traffic to aid troubleshooting
[x] 6. Diagnose application issues
- [x] Identify library dependencies for third-party software
- [x] Identify if an application suffers from memory leaks
- [x] Use standard tools to debug an application
- [x] Identify and fix issues related to SELinux
[x] 7. Identify and fix authentication issues
- [x] Identify and fix pluggable authentication module (PAM) issues
- [x] Identify and enforce local user account policies
[x] 8. Gather information to aid third-party investigation of issues
- [x] Create kernel crash dumps
- [x] Collect system information to aid in troubleshooting

PART 32 — Final Gold-Standard Fact Check

Exam accuracy

[x] EX342 currently exists
[x] Exact current exam name verified
[x] EX342 credential relationship verified
[x] RHCE-Enterprise Linux EX200 + EX342 relationship verified
[x] Current public objectives verified
[x] Current public RHEL version verified as RHEL 10.2
[x] Current time limit verified as 4 hours
[x] Performance-based format verified
[x] Multiple-version/LMS warning included
[x] Recommended preparation distinguished from mandatory certification stacking
[x] Current standard list price verified; regional/Japan caveat included
[x] Current free-retake policy verified
[x] Three-year certification currency policy verified

Curriculum accuracy

[x] Every current public top-level EX342 objective covered
[x] Every current public sub-objective mapped to labs
[x] No historical RHCE objective inserted as a current EX342 requirement
[x] Ansible included only because current EX342 explicitly lists it
[x] SELinux/PAM/AIDE/logging included because current EX342 explicitly lists them
[x] OpenShift, Ceph, HA clustering, Satellite, deep performance tuning excluded as standalone EX342 requirements
[x] Labs use original scenarios
[x] Mock exams do not claim to reproduce Red Hat exam questions
[x] Dangerous storage/recovery exercises explicitly restricted to disposable/snapshotted lab systems

Integrity

[x] No confidential exam content
[x] No leaked questions
[x] No unpublished scoring algorithm claimed
[x] No guarantee of passing
[x] No Red Hat training course presented as mandatory
[x] Official objectives remain the final authority

Final Beginner → EX342 Ready Roadmap

RHCSA-Level Administration Baseline
            ↓
Troubleshooting Method + Evidence
            ↓
Monitoring + Cockpit
            ↓
Ansible + Central Logging + AIDE
            ↓
Boot / Startup / Rescue
            ↓
Hardware + Kernel Modules
            ↓
Filesystem + LVM + LUKS Recovery
            ↓
DNF + RPM Database + File Verification
            ↓
Network Troubleshooting + Packet Capture
            ↓
Application Dependencies + Memory + Tracing
            ↓
SELinux
            ↓
PAM + Local Account Policies
            ↓
Kdump + SOS / Support Evidence
            ↓
Integrated Break/Fix Labs
            ↓
Timed Original Practice Tasks
            ↓
Five Mock Exams
            ↓
Two Clean 4-Hour Simulations
            ↓
EX342 READY
Code language: PHP (php)

Final rule

Do not memorize fixes. Learn to produce evidence, isolate the failing layer, make the smallest safe repair, and prove the final state.

That is the central skill pattern behind the current EX342 objective set.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.

Find Trusted Cardiac Hospitals

Compare heart hospitals by city and services — all in one place.

Explore Hospitals

Find the Best Cosmetic Hospitals

Gold-Standard Self-Study Textbook + Laboratory Manual + Exam Preparation Roadmap

Executive Verification — What EX342 Is Right Now

The 2026 certification relationship

2026 name/framework change

PART 1 — What Is EX342?

1.1 Exact current exam

1.2 What certification do you receive?

1.3 What EX342 validates

PART 2 — EX342 Prerequisites

Mandatory prerequisite vs recommended preparation vs optional training

PART 3 — Current Official EX342 Objectives

Objective coverage check

PART 4 — Objective-by-Objective Breakdown

Objective 1 — Understand and employ general methods for troubleshooting

What does this objective mean?

What must the candidate know and be able to do?

Core command families

Configuration and evidence locations

Hands-on lab sequence

Verification standard

Troubleshooting drill

Original exam-style practice task

Completion criteria

Objective 2 — Diagnose and troubleshoot system startup issues

What does this objective mean?

What must the candidate know and be able to do?

Core command families

Configuration and evidence locations

Hands-on lab sequence

Verification standard

Troubleshooting drill

Original exam-style practice task

Completion criteria

Objective 3 — Diagnose and troubleshoot file system issues

What does this objective mean?

What must the candidate know and be able to do?

Core command families

Configuration and evidence locations

Hands-on lab sequence

Verification standard

Troubleshooting drill

Original exam-style practice task

Completion criteria

Objective 4 — Resolve package management issues

What does this objective mean?

What must the candidate know and be able to do?

Core command families

Configuration and evidence locations

Hands-on lab sequence

Verification standard

Troubleshooting drill

Original exam-style practice task

Completion criteria

Objective 5 — Troubleshoot and fix network connectivity issues

What does this objective mean?

What must the candidate know and be able to do?

Core command families

Configuration and evidence locations

Hands-on lab sequence

Verification standard

Troubleshooting drill

Original exam-style practice task

Completion criteria

Objective 6 — Diagnose application issues

What does this objective mean?

What must the candidate know and be able to do?

Core command families

Configuration and evidence locations

Hands-on lab sequence

Verification standard

Troubleshooting drill

Original exam-style practice task

Completion criteria

Objective 7 — Identify and fix authentication issues

What does this objective mean?

What must the candidate know and be able to do?

Core command families

Configuration and evidence locations

Hands-on lab sequence