EX200 Configure local storage Practice Question
A system administrator is setting up storage for a new application server. The application requires two separate filesystems: one for the database (needs to be at least 10GiB) and one for logs (needs at least 5GiB). The server has a single 20GiB disk /dev/sda. The administrator plans to use LVM and a single volume group 'vg_app'. They create physical volume on /dev/sda, create the volume group, and then create two logical volumes: 'lv_db' of 10GiB and 'lv_logs' of 5GiB. They format lv_db as ext4 and lv_logs as xfs, and mount them at /db and /logs respectively. After rebooting, the system fails to mount /logs. What is the most likely cause?
⚠ Common exam trap
Red Hat often tests the misconception that LVM volumes are automatically mounted after creation, when in fact only the logical volumes are activated; the filesystem mount must be explicitly configured in /etc/fstab.
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 /logs entry is missing from /etc/fstab.
The most likely cause is that the /logs entry is missing from /etc/fstab. After reboot, the system relies on /etc/fstab to mount filesystems automatically. Since the administrator created and mounted the filesystem manually, but did not add an entry for /logs in /etc/fstab, the mount fails on reboot. The database mount may succeed if it was added, but the logs mount fails due to the missing fstab entry.
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 logical volume 'lv_logs' overlaps with 'lv_db'.
Why it's wrong here
LVM manages physical extents inside a volume group and records their allocation in on-disk metadata. The lvcreate and vgcreate commands refuse to allocate the same physical extent to more than one logical volume, so overlapping LVs cannot be created accidentally. If the metadata were manually corrupted to create an overlap, LVM would refuse to activate the volume group, and the system would show a different failure, not simply missing files under /logs. Therefore, an overlap is not a plausible explanation for this mount problem.
- ✓
The /logs entry is missing from /etc/fstab.
Why this is correct
The /etc/fstab file is the persistent mount table that systemd reads at boot via fstab-generator to create mount units. Without an entry for /dev/vg_app/lv_logs (or its UUID) pointing to /logs, the filesystem will not be mounted automatically after a reboot. The storage device exists and is formatted, but the mount point is empty because no fstab line tells the system to mount it. This is the classic cause of a filesystem that is reachable manually but unavailable after the server restarts.
- ✗
The physical volume /dev/sda is not recognized by LVM after reboot.
Why it's wrong here
Physical volumes are identified by an LVM metadata label containing a unique UUID, not by the kernel device name such as /dev/sda. During boot, udev and lvm2-pvscan scan all available block devices and recognize a PV by that metadata, even if the device node name changed. A reboot alone would not make LVM forget a PV unless the device is physically removed, the metadata is wiped, or the device is genuinely unavailable. Since the scenario does not describe hardware loss or metadata corruption, this option is not a plausible cause of the missing /logs mount.
- ✗
The volume group 'vg_app' is not automatically activated.
Why it's wrong here
By default, LVM activates all volume groups automatically during system startup through the lvm2-activation systemd units. For vg_app not to be activated, the administrator would have to set auto_activation_volume_list in /etc/lvm/lvm.conf or the VG would need to be marked as foreign or have a missing PV. If vg_app were truly inactive, the logical volume would not appear under /dev/mapper, and any fstab entry for it would fail with 'device not found'. Because the described problem is a missing persistent mount, not an inactive device, the VG-activation issue is unlikely and also subordinate to the missing fstab entry.
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX200 question from scratch — 127 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.