EX200 Operate running systems Practice Question
A storage administrator has added a new 10 GiB disk (/dev/vdb) to a Red Hat Enterprise Linux 9 server. The requirement is to create a single XFS filesystem on the entire disk and mount it persistently at /data. The administrator runs mkfs.xfs /dev/vdb and then adds the line '/dev/vdb /data xfs defaults 0 0' to /etc/fstab. After running mount -a, the mount succeeds and df -h shows the expected size. However, after a reboot the system drops into emergency mode and reports that /data cannot be mounted. The administrator verifies that the disk is still present and the filesystem is intact. Which of the following is the most likely cause of the failure?
⚠ Common exam trap
The trap here is assuming that a mount that works interactively will always work after a reboot, overlooking that kernel device names are not stable identifiers.
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 /etc/fstab entry relies on the kernel device name /dev/vdb, which is not guaranteed to be stable across reboots; a persistent identifier such as a UUID or label should be used instead.
Persistent mounts should reference a stable identifier rather than a kernel-assigned device name. When /etc/fstab uses /dev/vdb, a reboot that reorders block devices can cause the mount unit to fail and the system to enter emergency mode. Querying the filesystem UUID with blkid and substituting UUID=... in /etc/fstab makes the entry resilient to device renaming and restores normal boot behavior.
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 XFS filesystem was created directly on /dev/vdb instead of on a partition such as /dev/vdb1, so the kernel cannot resolve the device at boot.
Why it's wrong here
Creating a filesystem directly on a whole block device is fully supported by XFS and the kernel; the device node /dev/vdb exists at boot just as it did during the interactive mount. The failure is not caused by the absence of a partition table, so this option does not explain why an interactive mount -a succeeded while the rebooted system failed to mount the same device.
- ✓
The /etc/fstab entry relies on the kernel device name /dev/vdb, which is not guaranteed to be stable across reboots; a persistent identifier such as a UUID or label should be used instead.
Why this is correct
Kernel-assigned names like /dev/vdb are not guaranteed to remain the same across reboots, especially when other devices are added or removed. If the device is renumbered, the fstab entry points at the wrong block device and the mount fails, dropping the system into emergency mode. Using the filesystem UUID or a label makes the entry stable and is the recommended practice for persistent mounts.
- ✗
The XFS filesystem must be registered with the kernel using xfs_admin before it can be mounted automatically at boot.
Why it's wrong here
xfs_admin is used to change parameters of an existing XFS filesystem, such as its label or UUID. It is not a registration step required for mounting at boot, and it does not influence how the system locates the device. No such registration exists for XFS or for any standard Linux filesystem, so this option misrepresents how mount units resolve devices.
- ✗
The XFS filesystem must be mounted with the 'nofail' option in /etc/fstab, otherwise any filesystem mount failure will always halt the boot process.
Why it's wrong here
The 'nofail' option only changes how systemd handles a failing mount unit; it does not fix the underlying cause of the mount failure. Even with nofail, if the device reference is wrong the filesystem still will not be mounted at /data, so the administrative requirement to have the storage persistently available would not be satisfied. It masks the symptom rather than resolving it.
Go deeper
Related to this question
About these practice questions
This EX200 question is part of Courseiva's 427-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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 Red Hat exam blueprint
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.