Create and configure file systems →hardMultiple ChoiceObjective-mapped

EX200 Create and configure file systems Practice Question

Exhibit

Refer to the exhibit.
```
$ cat /etc/fstab
/dev/mapper/rhel-root     /                       xfs     defaults        0 0
UUID=1234-5678            /boot                   xfs     defaults        0 0
/dev/sdb1                 /mydata                 ext4    defaults        0 0
```
The /mydata directory does not exist on the system.

After adding the last line to /etc/fstab, the system fails to boot with an error. What is the most likely cause?

⚠ Common exam trap

The trap here is that candidates often focus on device or filesystem issues (UUID, formatting, type) and overlook the simple prerequisite that the mount point directory must exist, which is a fundamental step tested in the EX200.

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 mount point /mydata does not exist

When a mount point directory specified in /etc/fstab does not exist, the systemd mount unit will fail during boot because the mount operation cannot find the target directory. This is a common misconfiguration: the fstab entry references /mydata, but the directory has not been created with mkdir. The boot process halts with an error indicating the mount point is missing, not that the device or filesystem is invalid.

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 for /boot is invalid
Why it's wrong here
The UUID for /boot is provided in the scenario without any indication that it is invalid; in fact, it appears as a legitimate placeholder. If the UUID were invalid, the systemd mount unit would fail with a device-not-found error such as "UUID=... not found" or "No such device," not a missing-directory error. Since the failure is attributed to the nonexistent /mydata directory, an invalid /boot UUID cannot be the cause.
✓
The mount point /mydata does not exist
Why this is correct
The scenario explicitly states that /mydata does not exist, and systemd requires the mount point directory to be present before mounting any filesystem defined in /etc/fstab. For each fstab entry, systemd generates a mount unit that will fail if the target directory is absent, reporting an error like "mount: mount point /mydata does not exist." Because this directory is missing, the mount unit for /mydata fails, causing the boot to enter emergency mode. The solution is to create the directory with mkdir -p /mydata and then run mount -a to verify.
✗
The device /dev/sdb1 is not formatted
Why it's wrong here
While an unformatted /dev/sdb1 could indeed cause a mount failure, this is speculative because the scenario provides no evidence that the device lacks a filesystem. If /dev/sdb1 were unformatted, the mount attempt would fail with errors such as "wrong fs type, bad option, bad superblock" or "no valid superblock," which are distinct from the missing-mount-point error. The stated fact that /mydata does not exist is a direct and documented cause, making this option less likely and not the primary fault.
✗
The filesystem type ext4 is incorrect for /dev/sdb1
Why it's wrong here
The actual filesystem type of /dev/sdb1 is never disclosed in the scenario, so claiming ext4 is incorrect is pure conjecture. Even if the filesystem type were mismatched, the failure would manifest as a kernel-level filesystem error (e.g., "wrong fs type" or "invalid superblock"), not as a missing-directory issue. Since the question states clearly that /mydata does not exist, this concrete problem overrides any speculative filesystem mismatch, making this option incorrect.

Go deeper

EX200 Create and configure file systems Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question