LFCS Storage Management Practice Question
An administrator manages a server with several iSCSI LUNs attached. The server reboots after a kernel update, and one of the LUNs, which previously appeared as /dev/sdc, is now enumerated as /dev/sdd, breaking an /etc/fstab entry that references /dev/sdc. The administrator wants to make the mount configuration resilient to device-name changes and to avoid boot delays if the LUN is temporarily missing. Which two actions should the administrator take? (Choose two.)
⚠ Common exam trap
The trap here is believing that a udev rename or a device-mapper path provides stable naming, when the supported and reliable approach is to use the existing by-uuid or by-path symlinks plus nofail.
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
✓
Add the nofail mount option to the /etc/fstab entry for that filesystem.
Persistent identifiers such as UUIDs or by-path symlinks decouple the mount configuration from the kernel's enumeration order, and nofail prevents a temporarily missing iSCSI LUN from delaying or blocking boot. Together they make the fstab entry resilient to device renumbering. Changing to a device-mapper path, adding _netdev, or forcing a udev rename do not address enumeration stability and can introduce new problems.
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 mount option to the /etc/fstab entry for that filesystem.
Why this is correct
The nofail option tells systemd and mount to treat a missing device as a non-fatal condition during boot. Without it, a temporarily absent iSCSI LUN can drop the system into emergency mode or cause long timeouts. With nofail, the boot continues and the mount is simply skipped, which is the desired behavior for storage that may not always be present at boot time. It is commonly paired with persistent identifiers.
- ✗
Add the _netdev mount option to the /etc/fstab entry and rely on the device name /dev/sdc.
Why it's wrong here
_netdev tells the mount system that the filesystem requires network access, which is relevant for NFS and CIFS mounts. It does not make a block device name persistent, nor does it prevent boot failure when a device is missing. iSCSI block devices are handled by the iSCSI initiator and systemd ordering, not by _netdev semantics, so this option leaves the enumeration problem unsolved.
- ✓
Replace the /dev/sdc reference in /etc/fstab with a persistent identifier such as /dev/disk/by-uuid/<uuid> or /dev/disk/by-path/<path>.
Why this is correct
Persistent device identifiers are exactly what solve enumeration-order changes. UUIDs are stored in the filesystem superblock and remain stable regardless of which SCSI target or bus order the kernel assigns. The by-path symlinks encode the physical or iSCSI path, which is also stable for a given LUN. Using either in /etc/fstab ensures the correct filesystem is mounted even if the kernel now calls the device /dev/sdd instead of /dev/sdc.
- ✗
Change the mount point to use the device-mapper path /dev/mapper/sdc1 instead of /dev/sdc.
Why it's wrong here
/dev/mapper entries are created by device-mapper for LVM logical volumes, multipath devices, or dm-crypt mappings, not for plain SCSI disk partitions. A raw iSCSI LUN partition would not appear there unless it was wrapped in LVM or multipath. Even if a mapper name existed, it would not protect against SCSI enumeration reordering, so this does not address the underlying problem.
- ✗
Create a udev rule that renames the LUN to /dev/sdc every time it is detected.
Why it's wrong here
Forcing a specific kernel name with a udev rule is fragile and generally discouraged. It can conflict with the kernel's own enumeration, race with other devices, and break when hardware or targets change. The supported approach for stable naming is to use the by-uuid or by-path symlinks that udev already maintains, rather than overriding the kernel-assigned name. This option does not provide a robust solution.
Go deeper
Related to this question
About these practice questions
One of 406 original LFCS 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 Linux Foundation exam blueprint
This LFCS practice question is part of Courseiva's free Linux Foundation 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 LFCS exam.