XK0-006 Troubleshooting Practice Question
A server running RHEL 8 fails to boot with a 'Dependency failed for /data' error. The /data filesystem is an ext4 partition on /dev/sdb1. Which sequence of steps should be taken to repair the filesystem?
⚠ Common exam trap
XK0-006 often tests the rule that fsck must run on an unmounted filesystem — candidates pick 'run fsck from the running system' or 'remount read-only' not realizing fsck needs full unmount and that rescue mode is required.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Boot into rescue mode, run 'umount /dev/sdb1', then 'fsck.ext4 -f /dev/sdb1'
To repair an ext4 filesystem that failed to mount at boot, you must boot into rescue mode (or single-user), ensure the filesystem is unmounted, then run 'fsck.ext4 -f /dev/sdb1' to force a check and repair. fsck must never run on a mounted read-write filesystem, and rescue mode gives you a clean environment where /data is not mounted. This is the standard RHEL recovery procedure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use 'xfs_repair /dev/sdb1' since it's ext4
Why it's wrong here
xfs_repair only understands XFS structures and will refuse or corrupt an ext4 partition. It is tempting because xfs_repair is the standard repair tool on RHEL, making it correct when the failing filesystem was created with mkfs.xfs rather than mkfs.ext4.
- ✗
Run 'fsck.ext4 -f /dev/sdb1' from the running system
Why it's wrong here
Running fsck.ext4 on a mounted, in-use filesystem risks metadata corruption, so it must be run from rescue mode with /data unmounted. It is tempting because fsck.ext4 is the correct ext4 repair tool, and would be right if the partition were already unmounted.
- ✗
Remount the filesystem as read-only and run fsck
Why it's wrong here
Remounting read-only still leaves the filesystem mounted, so fsck cannot safely rewrite metadata; a full unmount or rescue-mode boot is required. It is tempting because read-only remounting is the standard pre-check step for root filesystems, correct when repairing / itself rather than a separate data partition.
- ✓
Boot into rescue mode, run 'umount /dev/sdb1', then 'fsck.ext4 -f /dev/sdb1'
Why this is correct
Rescue mode boots a minimal environment where /data stays unmounted, allowing 'umount /dev/sdb1' to ensure no active references remain before 'fsck.ext4 -f' forces a full check and repair of the ext4 partition, satisfying the need to fix the dependency failure safely.
Go deeper
Related to this question
Learn chapter
System Backup and Recovery
Key term
fsck
fsck is a command-line tool that checks and repairs inconsistencies in a file system, ensuring data integrity.
Key term
Procedure
A documented set of step-by-step instructions for performing a specific task or handling a particular situation in an IT environment.
About these practice questions
One of 781 original XK0-006 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This XK0-006 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the XK0-006 exam.