EX200 Create and configure file systems Practice Question
A Red Hat Enterprise Linux 8 server is used as a file server. It has a 1 TB disk /dev/sdc formatted as XFS and mounted at /srv/files. The /etc/fstab entry uses the device name /dev/sdc. After a hardware replacement, the new disk is detected as /dev/sdd, and the server fails to boot because /srv/files cannot be mounted. The administrator used 'blkid' and found the new disk's filesystem UUID is 'abc-123'. What is the best course of action to ensure reliable mounting after future reboots?
⚠ Common exam trap
Test-takers frequently think using the device name is sufficient because it worked before, or they may overcomplicate the fix with symlinks or PARTUUID, failing to recognize that the filesystem UUID is the simplest and most robust persistent identifier for mounting filesystems in Red Hat Enterprise Linux 8.
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
✓
Change the /etc/fstab entry to use UUID=abc-123 and run mount -a
Using the filesystem UUID in /etc/fstab provides a persistent identifier that remains constant regardless of the device name assigned by the kernel. After the hardware replacement, the disk is detected as /dev/sdd, but its UUID ('abc-123') is unchanged. Changing the fstab entry to UUID=abc-123 ensures the system can reliably mount the filesystem on every boot, as the UUID is tied to the filesystem itself, not the kernel's device enumeration order.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add the 'nofail' option to the /etc/fstab entry and reboot
Why it's wrong here
Adding 'nofail' to the /etc/fstab entry only tells systemd to not hang at boot if the filesystem cannot be mounted, but it does not fix the underlying problem that the device node name /dev/sdc may point to a different disk at the next boot. If the device name changes to /dev/sdd, the mount will either fail or mount the wrong filesystem, and 'nofail' simply lets the boot continue with that filesystem unavailable. It also does not provide a stable mount point, so this option does not solve the problem.
- ✓
Change the /etc/fstab entry to use UUID=abc-123 and run mount -a
Why this is correct
Switching the /etc/fstab entry to use the filesystem's UUID (e.g., UUID=abc-123) makes the mount independent of the kernel's device node naming order, because the UUID is burned into the filesystem superblock and remains constant regardless of which /dev/sdX node the disk acquires. After editing the file, running 'mount -a' mounts all entries listed in /etc/fstab that are not already mounted, applying the new configuration immediately without needing a reboot. This is the standard, reliable way to handle devices whose /dev names are not stable.
- ✗
Create a symbolic link /dev/sdc pointing to /dev/sdd
Why it's wrong here
Creating a symbolic link such as /dev/sdc -> /dev/sdd appears to work in the current session, but /dev is a devtmpfs populated and managed by udev; udev can remove or recreate the node at boot, and the symlink is not persistent because it is lost when /dev is re-created during early boot. Moreover, this reverses the naming: if the actual device is /dev/sdd, linking /dev/sdc to it may conflict with a real device that later appears as /dev/sdc, causing the fstab entry to target the wrong disk. It is a fragile workaround, not a robust solution.
- ✗
Use PARTUUID instead of UUID in /etc/fstab
Why it's wrong here
Using PARTUUID in /etc/fstab is not equivalent to using the filesystem UUID; PARTUUID identifies a partition by its unique GUID in the GPT partition table, not by the filesystem content, so it doesn't guarantee that the right filesystem is mounted if the partition is reformatted or the table is altered. While a partition GUID is often stable, it can change if the partition table is rewritten, cloned, or the disk geometry changes, which means it does not provide the same device-independent persistence as a filesystem UUID. Therefore, for this scenario, PARTUUID is an incorrect remedy.
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.