EX200 Configure local storage Practice Question
A system fails to mount an XFS filesystem at boot. The /etc/fstab entry is: UUID=abc123 /mnt xfs defaults 0 0. Running mount -a shows: 'mount: wrong fs type, bad option, bad superblock on /dev/sdb1'. Which is the most likely cause?
⚠ Common exam trap
A UUID mismatch results in 'mount: can't find UUID=...' or 'no such device', not a 'wrong fs type' error. The error 'wrong fs type, bad option, bad superblock' points to an actual device that cannot be mounted with the specified filesystem type, so candidates should suspect a filesystem type mismatch.
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
✓
The filesystem on /dev/sdb1 is not XFS but ext4.
The error 'wrong fs type, bad option, bad superblock' occurs when the device exists but the filesystem type does not match or the superblock is unreadable. Since the error explicitly mentions /dev/sdb1, the UUID must have resolved to that device. Therefore, a UUID mismatch would produce a different error like 'can't find UUID=abc123' or 'no such device'. The most likely cause is that /dev/sdb1 is not formatted as XFS (e.g., it is ext4). A missing mount point gives 'No such file or directory', and kernel XFS support issues typically produce 'unknown filesystem type'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The UUID specified in fstab does not match the actual UUID of /dev/sdb1.
Why it's wrong here
The UUID in /etc/fstab acts as a persistent, unique identifier for the filesystem. When it does not match the actual UUID of /dev/sdb1 — for example, after recreating the filesystem with mkfs.xfs, which generates a new UUID — the boot-time mount routine cannot resolve the source device, and mount fails with an error such as "UUID=... does not exist" or "no such device." Running `blkid` or `lsblk -f` reveals the true UUID, and the permanent fix is to update the corresponding UUID in /etc/fstab.
- ✗
The mount point /mnt does not exist.
Why it's wrong here
If /mnt were missing, the mount command would fail with a highly specific diagnostic immediately: "mount: mount point /mnt does not exist." This error is visibly different from a UUID mismatch error, because mount can still locate the device but cannot find the directory on which to attach it. On a standard RHEL system, /mnt is created as part of the Filesystem Hierarchy Standard, so its absence is unlikely and would reflect an earlier administrative misconfiguration, not a problem with UUID resolution.
- ✗
The kernel does not have XFS support enabled.
Why it's wrong here
XFS has been a fully supported filesystem in RHEL for many years, and the kernel is built with XFS support either statically (CONFIG_XFS_FS=y) or as a loadable module. If the kernel lacked XFS support, attempting to mount an XFS filesystem would produce a "wrong fs type, bad option, bad superblock" error or explicitly mention "unknown filesystem type." Because the system is expected to mount an XFS filesystem at boot on RHEL, the kernel's XFS driver is virtually always present, so this option does not explain why the mount fails due to a UUID mismatch.
- ✓
The filesystem on /dev/sdb1 is not XFS but ext4.
Why this is correct
If /dev/sdb1 actually contains an ext4 filesystem, the mount command would report "wrong fs type, bad option, bad superblock" only when the fstab entry specifies `xfs` and the filesystem type is inconsistent. However, a UUID mismatch prevents the mount from even locating the device — the error occurs during device resolution, before the kernel reads the superblock — so the failure described in the question would happen regardless of whether the filesystem type were ext4 or XFS. Moreover, an ext4 filesystem mounted with the correct UUID would succeed, so merely having ext4 on the device does not inherently cause a boot-time mount failure.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX200 question from scratch — 427 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX200 practice question is part of Courseiva's free Red Hat 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 EX200 exam.