Courseiva

CCNA Configure local storage Questions

23 questions · Configure local storage · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
Multi-Selecthard

Which three fields are present in every /etc/fstab entry? (Choose three.)

Select 3 answers
A.Mount point
B.Device
C.Dump field
D.Filesystem type
E.UUID
AnswersA, B, C

Correct. The mount point specifies where the filesystem will be attached to the directory tree and is required.

Why this answer

Every /etc/fstab entry consists of six whitespace-separated fields: device, mount point, filesystem type, options, dump, and pass. Although dump and pass can be omitted and default to 0, the dump field is considered present in every entry due to its default value. The question asks for three fields that are present in every entry; these include the mount point (A), device (B), and dump field (C).

The filesystem type (D) is also present, but the question requires exactly three choices, and the dump field is often overlooked. UUID (E) is not a separate field; it is a method to specify the device.

Exam trap

Candidates often think the dump field is optional and thus not present in every entry, but it defaults to 0, making it a field present in all entries. The question asks for fields present, not only mandatory ones.

Practice this question →
2
MCQhard

An administrator attempts to mount an XFS filesystem from /dev/sdc1 to /mnt/archive but receives the error: 'mount: /mnt/archive: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error.' The output of 'dumpe2fs /dev/sdc1' shows 'dumpe2fs: Bad magic number in super-block while trying to open /dev/sdc1'. What is the most likely problem?

A.The mount point /mnt/archive does not exist
B.The filesystem on /dev/sdc1 is XFS, not ext4
C.The XFS kernel module is not loaded
D.The partition /dev/sdc1 does not exist
AnswerB

dumpe2fs is designed for ext2, ext3, and ext4 filesystems; it looks for the ext family superblock magic (0xEF53) at offset 1024 on the device. XFS uses its own superblock format with the ASCII magic "XFSB" at a different offset. When dumpe2fs reads /dev/sdc1, it does not find the ext magic and prints "bad magic number in super-block," which simply means the device does not contain an ext filesystem, not that it is corrupt. The device likely holds a valid XFS filesystem, so running mount -t xfs /dev/sdc1 /mnt/archive will succeed. This is the correct diagnosis because the tool was incompatible with the actual filesystem type.

Why this answer

The error message 'wrong fs type' combined with 'dumpe2fs: Bad magic number in super-block' indicates that the filesystem on /dev/sdc1 is not an ext2/3/4 filesystem. dumpe2fs is designed to read ext2/3/4 superblocks, and the 'bad magic number' error means it cannot find a valid ext superblock. Since the administrator is trying to mount an XFS filesystem, the correct tool to examine it is xfs_db or xfs_info, not dumpe2fs. Therefore, the most likely problem is that the filesystem is XFS, not ext4.

Exam trap

The trap here is that candidates see 'bad superblock' and immediately think of ext4 superblock corruption or backup superblock recovery, when in fact the error is simply due to using an ext4-specific tool (dumpe2fs) on a non-ext4 filesystem.

How to eliminate wrong answers

Option A is wrong because if the mount point /mnt/archive did not exist, the error would be 'mount point does not exist' rather than 'wrong fs type' or 'bad superblock'. Option C is wrong because if the XFS kernel module were not loaded, the error would typically be 'mount: unknown filesystem type 'xfs'' or a similar message, not a 'bad superblock' error from dumpe2fs. Option D is wrong because if /dev/sdc1 did not exist, the error would be 'mount: special device /dev/sdc1 does not exist' or 'no such device', not a superblock-related error.

Practice this question →
3
MCQmedium

Refer to the exhibit. An administrator wants to create an LVM logical volume using /dev/sdb3. What is the first step to complete this task?

A.Format the partition with mkfs.ext4 /dev/sdb3
B.Create a physical volume with pvcreate /dev/sdb3
C.Create a logical volume with lvcreate -L 10G -n lv01 vg01
D.Create a volume group with vgcreate vg01 /dev/sdb3
AnswerC

The exhibit confirms that the physical volume /dev/sdb3 and the volume group vg01 already exist, so the only remaining prerequisite is to create the logical volume itself. The command lvcreate -L 10G -n lv01 vg01 allocates a 10 GiB logical volume named lv01 from the free extents in vg01, which is exactly the correct next step. Afterward, a filesystem can be created on /dev/vg01/lv01.

Why this answer

Based on the exhibit, /dev/sdb3 is already initialized as a physical volume and belongs to a volume group. Therefore, the first step to create a logical volume is to use lvcreate directly, as the PV and VG are already in place. Option B is incorrect because pvcreate is not needed when the partition is already a PV.

Exam trap

The trap is that candidates may assume they must always run pvcreate first, but the exhibit shows the PV already exists. Always verify the current state of the disk before deciding the next step.

How to eliminate wrong answers

Option A is wrong because formatting the partition with mkfs.ext4 creates a filesystem directly on the block device, which bypasses LVM entirely and prevents its use as a physical volume. Option C is wrong because lvcreate requires an existing volume group (vg01) that already contains physical volumes; attempting this step first would fail as vg01 does not exist. Option D is wrong because vgcreate requires at least one initialized physical volume as an argument; /dev/sdb3 must first be a PV via pvcreate before it can be added to a volume group.

Practice this question →
4
MCQeasy

An administrator needs to add a 2GB swap partition to an existing disk (/dev/sdc) that already has one partition. The administrator creates a second primary partition using fdisk and sets the type to Linux swap (82). Which command completes the setup to enable swap?

A.swapon /dev/sdc2
B.mkfs.swap /dev/sdc2 && swapon /dev/sdc2
C.mkswap /dev/sdc2 && swapon /dev/sdc2
D.mkswap /dev/sdc && swapon /dev/sdc
AnswerC

mkswap /dev/sdc2 writes the swap signature and metadata to the /dev/sdc2 partition, preparing it for use as swap space. Then swapon /dev/sdc2 activates it immediately, making the kernel use it for paging. This two-step sequence is the correct procedure, and you can verify that it worked with swapon --show or by checking the output of free.

Why this answer

After creating the partition with fdisk and setting the type to 82 (Linux swap), the partition must be formatted as a swap area using `mkswap` before it can be activated. The `swapon` command then enables the swap space. Option C correctly chains `mkswap /dev/sdc2` to initialize the swap signature and `swapon /dev/sdc2` to activate it.

Exam trap

Red Hat often tests the distinction between formatting a filesystem (`mkfs`) and initializing swap (`mkswap`), leading candidates to mistakenly use `mkfs.swap` or skip the initialization step entirely.

How to eliminate wrong answers

Option A is wrong because `swapon` alone cannot activate a partition that has not been initialized as a swap area; it requires a valid swap signature written by `mkswap`. Option B is wrong because `mkfs.swap` is not a valid command; the correct command is `mkswap`. Option D is wrong because it targets the whole disk `/dev/sdc` instead of the specific partition `/dev/sdc2`, and the disk itself cannot be used as swap without a partition table and proper initialization.

Practice this question →
5
MCQhard

An administrator replaces a failed disk in a RAID 10 array /dev/md0. The new disk is /dev/sdc. The admin runs: mdadm /dev/md0 --add /dev/sdc. The command succeeds, but the array does not start rebuilding. What is the most likely reason?

A.The new disk must be partitioned with the same layout as the failed disk.
B.The --add command should have been --re-add instead.
C.The array is still clean and does not need the new disk yet.
D.The failed disk was not removed from the array first; you need to mark it as failed and remove it.
AnswerD

Use mdadm --manage /dev/md0 --fail /dev/sdX and --remove before adding new disk.

Why this answer

When a disk in a RAID array fails, the array marks it as faulty but does not automatically remove it. The administrator must first explicitly mark the failed disk as failed with `mdadm --fail` and then remove it with `mdadm --remove` before adding a replacement. Without removing the failed device, the array still considers the old disk as part of the array, and the new disk is not recognized as a replacement, so no rebuild starts.

Exam trap

The trap here is that candidates assume a failed disk is automatically removed from the array, but mdadm requires explicit removal before a new disk can be added to trigger a rebuild.

How to eliminate wrong answers

Option A is wrong because mdadm can add a whole disk (e.g., /dev/sdc) directly to a RAID array without requiring partitions; the array will use the entire disk as a component. Option B is wrong because --re-add is used to re-add a disk that was previously part of the array and was removed but not failed, not for a new replacement disk. Option C is wrong because a RAID 10 array with a missing or failed disk is degraded and will immediately start rebuilding once a spare or new disk is added; the array's 'clean' state is irrelevant to the rebuild trigger.

Practice this question →
6
MCQmedium

A database server experiences high disk I/O wait times. The administrator runs 'iostat -x 1' and sees that the avgqu-sz for /dev/sda is 25 and await is 200 ms. The disk is a single 7200 RPM SATA drive. Which action is most likely to improve performance?

A.Increase the read-ahead buffer using blockdev --setra
B.Change the I/O scheduler from CFQ to noop
C.Run 'fsck -f' on the filesystem to check for fragmentation
D.Replace the drive with an SSD or add additional drives in RAID 10
AnswerD

Replacing a mechanical drive with an SSD or deploying RAID 10 directly attacks the root cause of high disk i/o wait: excessive per-request latency and insufficient IOPS. SSDs eliminate rotational seek times and provide thousands of IOPS, while RAID 10 combines striping for parallel reads and writes with mirroring for redundancy, allowing multiple spindles to serve requests concurrently. This decreases both service time and queue depth, thereby reducing the await metric and iowait experienced by the database server.

Why this answer

The high avgqu-sz (25) and await (200 ms) indicate the single 7200 RPM SATA drive is saturated, as its maximum IOPS is typically around 75-100 random I/O operations per second. Replacing it with an SSD (which can handle thousands of IOPS) or adding drives in RAID 10 (which increases IOPS through parallelism) directly addresses the hardware bottleneck. No software tuning can overcome the physical limitations of a single spinning disk under heavy I/O load.

Exam trap

The trap here is that candidates assume software tuning (scheduler, read-ahead) can fix a hardware saturation issue, but Red Hat exams emphasize that when a single spinning disk is the bottleneck, only a hardware upgrade or RAID configuration will improve performance.

How to eliminate wrong answers

Option A is wrong because increasing the read-ahead buffer (--setra) only helps sequential I/O patterns, not the random I/O causing high wait times, and can actually waste memory and increase latency for random workloads. Option B is wrong because changing the I/O scheduler from CFQ to noop reduces CPU overhead but does not increase the disk's maximum IOPS; the disk is already saturated, so the scheduler choice has negligible impact on throughput. Option C is wrong because fsck checks filesystem metadata integrity, not fragmentation; even if the filesystem were fragmented, defragmentation would provide minimal benefit on a modern filesystem like ext4 and cannot resolve a hardware throughput bottleneck.

Practice this question →
7
MCQhard

A storage administrator is asked to increase the size of an ext4 filesystem mounted at /data. The underlying logical volume /dev/mapper/vg01-lv01 is currently 10GB and the volume group has 5GB of free extents. After extending the logical volume by 2GB using lvextend -L +2G /dev/mapper/vg01-lv01, what command must be run to resize the filesystem?

A.resize2fs /dev/mapper/vg01-lv01
B.lvextend -r -L +2G /dev/mapper/vg01-lv01
C.xfs_growfs /data
D.fsck -f /dev/mapper/vg01-lv01
AnswerA

resize2fs /dev/mapper/vg01-lv01 is correct because the logical volume was already extended with lvextend (without -r), leaving the ext4 filesystem still sized for the old smaller LV. Running resize2fs online grows the ext4 filesystem to consume the newly added space in the enlarged block device, and since the filesystem type is ext4, resize2fs is the matching tool. Unlike shrinking, growing an ext4 filesystem with resize2fs can be done while the filesystem is mounted, which makes it the immediate follow-up command in this LVM workflow.

Why this answer

After extending the logical volume with `lvextend`, the filesystem does not automatically recognize the new space. For ext4 filesystems, the `resize2fs` command must be run to resize the filesystem to use the additional logical volume capacity. This command can be executed online (while the filesystem is mounted) and will expand the filesystem to fill the available space in the logical volume.

Exam trap

The trap here is that candidates may confuse filesystem-specific resize commands (resize2fs for ext4 vs. xfs_growfs for XFS) or assume that `lvextend` automatically resizes the filesystem without the `-r` flag.

How to eliminate wrong answers

Option B is wrong because `lvextend -r` automatically resizes the filesystem during the LV extension, but the question states the administrator already ran `lvextend` without the `-r` flag, so a separate resize command is required. Option C is wrong because `xfs_growfs` is used for XFS filesystems, not ext4; using it on an ext4 filesystem would fail. Option D is wrong because `fsck -f` performs a filesystem consistency check and repair, not a resize operation; it does not change the filesystem size.

Practice this question →
8
MCQeasy

An administrator wants to add an additional swap partition of 2GB on device /dev/sdb1. Which set of commands should be used to enable swap and make it persistent across reboots?

A.parted /dev/sdb set 1 swap on
B.swapadd /dev/sdb1
C.mkswap /dev/sdb1; swapon /dev/sdb1; echo '/dev/sdb1 swap swap defaults 0 0' >> /etc/fstab
D.mkfs.ext4 /dev/sdb1; mount /dev/sdb1 /swap
E.None of the above
AnswerC

This is the correct sequence: `mkswap` initializes the partition with a swap signature, `swapon` activates it immediately for use by the kernel, and appending the line to `/etc/fstab` ensures the swap partition is automatically enabled at boot. The fstab entry uses the correct fields: device, mount point specified as `swap`, filesystem type `swap`, and `defaults` as the mount options. This covers both immediate activation and persistence across reboots, satisfying the administrator's requirement.

Why this answer

It follows the proper sequence to prepare and activate a swap partition on /dev/sdb1. First, `mkswap` initializes the partition as a swap area by writing a swap signature. Then `swapon` activates it immediately.

Finally, adding an entry to /etc/fstab ensures the swap is automatically enabled at boot, making it persistent across reboots.

Exam trap

Red Hat often tests the distinction between filesystem creation (`mkfs.*`) and swap initialization (`mkswap`), and the trap here is that candidates may confuse `swapon` with a non-existent command like `swapadd` or think `parted` can enable swap directly.

How to eliminate wrong answers

Option A is wrong because `parted` does not have a 'swap on' subcommand; swap is enabled via `mkswap` and `swapon`, not through a parted flag. Option B is wrong because `swapadd` is not a valid Linux command; the correct command to activate swap is `swapon`. Option D is wrong because `mkfs.ext4` creates an ext4 filesystem, which is not suitable for swap; swap requires a raw partition formatted with `mkswap`, and mounting it is not how swap is used.

Option E is wrong because option C is correct.

Practice this question →
9
MCQhard

Refer to the exhibit. An administrator needs to create a 1.2 TiB logical volume named 'data' in volume group 'myvg' and mount it persistently at /data. Which sequence of commands should be used?

A.lvcreate -L 1.2T -n data myvg mkfs.ext4 /dev/myvg/data echo '/dev/myvg/data /data ext4 defaults 0 0' >> /etc/fstab mount -a
B.lvcreate -l 100%FREE -n data myvg mkfs.xfs /dev/myvg/data echo '/dev/mapper/myvg-data /data xfs defaults 0 0' >> /etc/fstab mount -a
C.lvcreate -L 1.2T -n data myvg mkfs.xfs /dev/myvg/data echo '/dev/myvg/data /data xfs defaults 0 0' >> /etc/fstab mount -a
D.lvcreate -L 1200G -n data myvg mkfs.ext4 /dev/myvg/data echo '/dev/myvg/data /data ext4 defaults 0 0' >> /etc/fstab mount -a
AnswerC

This is correct because lvcreate -L 1.2T allocates exactly 1.2 TiB—in LVM, an uppercase T suffix represents Tebibytes (2^40 bytes), not SI terabytes. Formatting with mkfs.xfs creates a modern, scalable filesystem appropriate for large volumes, and the fstab entry uses /dev/myvg/data, a stable LVM2 device-mapper path. Running mount -a then validates the configuration by actually mounting the new filesystem.

Why this answer

It creates a logical volume of exactly 1.2 TiB using the valid -L 1.2T size specification. LVM's -L option accepts floating-point values with suffixes like T for TiB. The volume is formatted with XFS (default for RHEL 8+), a correct fstab entry is added with /dev/myvg/data, and mount -a mounts it persistently.

Option D uses 1200G, which yields approximately 1.17 TiB, not the required 1.2 TiB.

Exam trap

A common pitfall on the RHCSA exam is assuming that -L does not accept fractional TiB values. In fact, lvcreate supports floating-point sizes (e.g., 1.2T). Candidates may incorrectly use an approximation like 1200G instead of the exact 1.2T.

How to eliminate wrong answers

Option A is wrong because lvcreate -L 1.2T uses an invalid size suffix; LVM does not accept fractional TiB values (e.g., 1.2T), which would cause a syntax error or unexpected behavior. Option B is wrong because -l 100%FREE creates a volume using all free space in the volume group, not a specific 1.2 TiB size, and it uses xfs instead of ext4 (though xfs is acceptable, the size requirement is not met). Option C is wrong because lvcreate -L 1.2T uses the invalid size suffix 1.2T, and it formats with xfs instead of ext4, but the primary failure is the invalid size specification.

Practice this question →
10
MCQhard

A system administrator is configuring a new RHEL 9 server with two 500GB SSDs. The requirement: create a 200GB XFS filesystem for /srv/data that is resilient to disk failure. The admin decides to create a RAID 1 (mirror) using mdadm with partitions on each disk: /dev/sda1 and /dev/sdb1, each 200GB. He creates the partitions with fdisk, then runs: mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1. The array is created and synced. He then creates a physical volume, volume group, and logical volume on top of /dev/md0, formats with XFS, and mounts. Later, a disk fails. After replacing the failed disk, he recreates the partition with identical size and runs: mdadm /dev/md0 --add /dev/sdb1. The command fails with 'Device /dev/sdb1 is busy'. What is the most likely cause?

A.The replacement disk was not initialized with an mdadm superblock before adding.
B.The kernel still sees the old partition table; need to run partprobe to reread the partition table.
C.The /dev/md0 array is still in a clean state and does not need the disk yet.
D.The /dev/sdb1 partition is already part of another md array.
AnswerB

After you create a new partition table entry on /dev/sdb, the kernel keeps using the old partition layout cached in memory. Running partprobe (or partx -a) forces a re-read of the partition table so that /dev/sdb1 actually appears. Without this step, mdadm will report that the partition does not exist, even though it is visible in fdisk output.

Why this answer

After replacing a failed disk and recreating the partition, the kernel's in-memory partition table still reflects the old state. The `mdadm --add` command fails with 'Device busy' because the kernel sees the old partition layout and may still hold references to the old partition. Running `partprobe` (or `partx -a`) forces the kernel to reread the partition table from the disk, clearing the stale state and allowing the new partition to be added to the RAID array.

Exam trap

The trap here is that candidates often assume the 'Device busy' error means the disk is already in use by another array or process, when in fact it is a stale partition table cache that prevents the kernel from recognizing the new partition.

How to eliminate wrong answers

Option A is wrong because mdadm does not require a separate superblock initialization on the replacement partition; the `--add` command will write the superblock automatically when the partition is added to the array. Option C is wrong because even if the array is in a clean state (e.g., degraded but functional), it still accepts a new disk to restore redundancy; the 'Device busy' error is unrelated to array state. Option D is wrong because there is no indication that /dev/sdb1 is part of another array; the error is due to the kernel's stale partition table, not membership in another md device.

Practice this question →
11
MCQhard

A server has a software RAID 5 array /dev/md0. One of its disks fails. The administrator wants to replace it without rebooting. Which command should be used to mark the disk as failed?

A.mdadm --fault /dev/md0 /dev/sdb
B.echo faulty > /sys/block/md0/md/dev-sdb/state
C.mdadm --set-faulty /dev/md0 /dev/sdb
D.mdadm --fail /dev/md0 /dev/sdb
AnswerD

This is the correct command: mdadm --manage --fail /dev/md0 /dev/sdb (the --manage action is implicit when using --fail) marks /dev/sdb as faulty in the RAID 5 array /dev/md0. Once marked, mdadm removes the device from the active array, and the array continues operating in a degraded state because RAID 5 tolerates a single disk failure. You can then remove the failed disk (mdadm --remove) and replace it (mdadm --add) to rebuild redundancy, which is the proper workflow for handling a failing disk.

Why this answer

The correct command to mark a disk as failed in a software RAID array without rebooting is `mdadm --fail /dev/md0 /dev/sdb`. This command tells the md driver to mark the specified disk as faulty, which triggers the RAID 5 array to degrade and allows the failed disk to be removed and replaced while the system remains online.

Exam trap

The trap here is that candidates confuse the valid `--fail` option with the non-existent `--fault` or `--set-faulty` options, or they incorrectly think the sysfs method is the standard command-line approach expected in the EX200 exam.

How to eliminate wrong answers

Option A is wrong because `mdadm --fault` is not a valid mdadm option; the correct option is `--fail` or `--set-faulty`. Option B is wrong because while writing 'faulty' to the sysfs attribute `/sys/block/md0/md/dev-sdb/state` can mark a disk as faulty, the correct string to write is 'faulty' (not 'faulty' with a typo, but the path uses 'dev-sdb' which is correct; however, the syntax shown is a valid alternative, but the question asks for the command, and this is a sysfs manipulation, not the standard mdadm command expected in the EX200 exam). Option C is wrong because `mdadm --set-faulty` is not a valid mdadm option; the correct option is `--fail`.

Practice this question →
12
MCQhard

An administrator wants to add the two 2G disks (sdc and sdd) as physical volumes, extend the 'data' logical volume in volume group 'vg' by 2G, and grow the filesystem. Which sequence of commands should be used?

A.pvcreate /dev/sdc /dev/sdd; vgextend vg /dev/sdc /dev/sdd; lvresize -L 2G /dev/vg/lv_data; xfs_growfs /data
B.pvcreate /dev/sdc /dev/sdd; vgextend vg /dev/sdc /dev/sdd; lvextend -L +2G /dev/vg/lv_data; resize2fs /dev/vg/lv_data
C.pvcreate /dev/sdc /dev/sdd; vgextend vg /dev/sdc; vgextend vg /dev/sdd; lvextend -L +2G /dev/vg/lv_data; xfs_growfs /dev/vg/lv_data
D.pvcreate /dev/sdc /dev/sdd; vgextend vg /dev/sdc /dev/sdd; lvextend -L +2G /dev/vg/lv_data; xfs_growfs /data
AnswerD

This command chain is fully correct. pvcreate initializes both /dev/sdc and /dev/sdd as physical volumes, then vgextend adds both to volume group vg in a single command. lvextend -L +2G grows lv_data by exactly 2 GiB (the plus sign means 'add' rather than 'set to'), and xfs_growfs /data expands the XFS filesystem that is mounted at /data to consume the additional space. This is the proper order: create PVs, extend the VG, extend the LV, and finally grow the filesystem online without needing to unmount.

Why this answer

It follows the correct sequence: create physical volumes on both disks, extend the volume group with both disks in a single command, extend the logical volume by exactly 2G using the `+` sign, and then grow the XFS filesystem using `xfs_growfs` with the mount point `/data`. The `+` in `lvextend -L +2G` is critical to add 2G rather than resize to 2G total, and `xfs_growfs` requires the mount point (or a block device) for XFS filesystems.

Exam trap

The trap here is that candidates often confuse the `-L` option with and without the `+` sign, and mistakenly use `resize2fs` for XFS filesystems, or use `lvresize` instead of `lvextend` without the correct syntax for adding space.

How to eliminate wrong answers

Option A is wrong because `lvresize -L 2G` (without the `+`) would resize the logical volume to exactly 2G, not add 2G, and it uses `lvresize` instead of `lvextend` (though functionally similar, the intent is extension). Option B is wrong because it uses `resize2fs` which is for ext2/3/4 filesystems, not XFS; the filesystem on `/data` is XFS, so `xfs_growfs` must be used. Option C is wrong because it splits the `vgextend` into two separate commands (which is redundant but not incorrect), but more critically it uses `xfs_growfs /dev/vg/lv_data` with the block device path instead of the mount point; while `xfs_growfs` can accept a block device, the mount point is the standard and safer approach, and the question explicitly states 'grow the filesystem' which implies using the mount point.

Practice this question →
13
MCQeasy

An administrator wants to mount an existing ext4 filesystem from /dev/sdb1 to /mnt/data at boot time. What entry should be added to /etc/fstab?

A./dev/sdb1 /mnt/data xfs defaults 0 0
B.LABEL=data ext4 defaults 0 0
C./dev/sdb1 /data ext4 defaults 0 0
D./dev/sdb1 /mnt/data ext4 defaults 0 0
AnswerD

This is a valid and correct fstab entry for mounting the ext4 filesystem on /dev/sdb1 to the /mnt/data mount point. It properly specifies all six required fields: the device file, the exact mount directory, the ext4 filesystem type matching the on-disk format, the defaults option set (rw, suid, dev, exec, auto, nouser, async), and 0 for both dump and fsck pass. When the system boots or mount -a is executed, this line will mount the filesystem at /mnt/data as requested.

Why this answer

It specifies the correct device (/dev/sdb1), the correct mount point (/mnt/data), the correct filesystem type (ext4), and the correct mount options (defaults) for an ext4 filesystem to be mounted at boot. The /etc/fstab entry must include all six fields in order: device, mount point, filesystem type, options, dump, and pass.

Exam trap

The trap here is that candidates may confuse the filesystem type (ext4 vs xfs) or misremember the required mount point path (/mnt/data vs /data), leading them to select an option that looks correct but has a subtle mismatch.

How to eliminate wrong answers

Option A is wrong because it specifies xfs as the filesystem type, but the question explicitly states the filesystem is ext4. Option B is wrong because it omits the mount point and the device identifier (it uses LABEL=data but does not include a mount point or the required six-field structure). Option C is wrong because it specifies /data as the mount point, but the question requires the mount point to be /mnt/data.

Practice this question →
14
MCQhard

An administrator needs to ensure that a specific LVM logical volume is automatically mounted at boot with the 'noexec' option. Which configuration file and entry should be used?

A./etc/fstab: /dev/vg/lv /mnt ext4 noexec 0 0
B./etc/rc.d/rc.local: mount /dev/vg/lv /mnt -o noexec
C./etc/fstab: /dev/vg/lv /mnt ext4 defaults,noexec 0 0
D./etc/rc.local: mount -o noexec /dev/vg/lv /mnt
AnswerC

Correct fstab entry.

Why this answer

/etc/fstab is the standard configuration file for defining filesystem mount points and options that are applied automatically at boot. The entry specifies the logical volume device, mount point, filesystem type, and mount options including 'noexec' to prevent execution of binaries on that filesystem. The 'defaults' keyword ensures standard mount behavior is applied before the 'noexec' option overrides the exec permission.

Exam trap

The trap here is that candidates often confuse the purpose of /etc/fstab with boot scripts like rc.local, or they forget that mount options in fstab must be comma-separated and include 'defaults' to ensure all standard options are explicitly set before overriding them.

How to eliminate wrong answers

Option A is wrong because the mount options field is missing the 'defaults' keyword or any other base options; while 'noexec' alone is syntactically valid, the entry omits the required comma-separated list format and does not include 'defaults' which is typically expected for clarity and to avoid missing default mount behaviors. Option B is wrong because /etc/rc.d/rc.local is a legacy script that runs at the end of the boot process, not a configuration file for automatic boot-time mounting; using a mount command there is unreliable and not the standard method for persistent mount definitions. Option D is wrong because /etc/rc.local is a script, not a configuration file for fstab-style entries, and the mount command syntax shown does not include the required device and mount point in the correct order for a persistent boot-time mount.

Practice this question →
15
MCQeasy

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?

A.The logical volume 'lv_logs' overlaps with 'lv_db'.
B.The /logs entry is missing from /etc/fstab.
C.The physical volume /dev/sda is not recognized by LVM after reboot.
D.The volume group 'vg_app' is not automatically activated.
AnswerB

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.

Why this answer

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.

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.

How to eliminate wrong answers

Option A is wrong because logical volumes in the same volume group do not overlap; LVM allocates distinct extents to each LV, so 'lv_db' and 'lv_logs' occupy separate non-overlapping regions on the physical volume. Option C is wrong because the physical volume /dev/sda is automatically recognized by LVM after reboot if the PV was created and the volume group was active; LVM stores metadata on the disk itself, so it persists across reboots. Option D is wrong because volume groups are automatically activated by default via the lvm2 systemd service or init script, unless explicitly deactivated or filtered in lvm.conf; a single VG on a single disk will activate normally.

Practice this question →
16
MCQmedium

A technician is configuring a new Red Hat Enterprise Linux 9 server with multiple disks. They need to create a RAID 1 array using /dev/sda and /dev/sdb for the /boot partition. Which tool can create the RAID array and enable booting from it?

A.Use mdadm to create a RAID1 device and install GRUB on both disks
B.Use parted to create a RAID array directly by specifying the RAID level
C.Use fdisk to create a RAID partition and then format with ext4
D.Use LVM to create a mirrored logical volume for /boot
AnswerA

mdadm is the standard RHEL tool for building software RAID, and RAID1 gives /boot redundancy without requiring GRUB to understand LVM. After creating /dev/md0 from a partition on each disk, run grub2-install on both /dev/sda and /dev/sdb so the BIOS can load GRUB from either disk if one fails. This is the only supported way to get a redundant boot path on a traditional BIOS system.

Why this answer

Mdadm is the standard Linux tool for creating software RAID arrays, including RAID 1 (mirroring). For the /boot partition, which must be readable by the bootloader, GRUB must be installed on both disks in the RAID 1 array to ensure bootability if one disk fails. mdadm creates the RAID device, and GRUB can then be installed on each disk's MBR or GPT partition.

Exam trap

The trap here is that candidates may think LVM mirroring is acceptable for /boot, but Red Hat exams emphasize that /boot must not use LVM or complex RAID levels; only RAID 1 with mdadm and GRUB on both disks is supported for bootability.

How to eliminate wrong answers

Option B is wrong because parted is a partition editor and cannot create RAID arrays; it can only create partitions, not configure RAID levels. Option C is wrong because fdisk can create RAID partitions (by setting the partition type to fd for Linux RAID), but it cannot create the RAID array itself; formatting with ext4 alone does not provide mirroring. Option D is wrong because LVM mirrored logical volumes are not recommended for /boot; the bootloader (GRUB) cannot read LVM metadata reliably, and /boot must reside on a non-LVM, non-RAID (or simple RAID 1) partition for boot compatibility.

Practice this question →
17
MCQhard

A system has a logical volume that is thinly provisioned. The thin pool has a size of 100GB and the thin volume has a virtual size of 500GB. The administrator notices that the thin pool has only 5GB of data written so far. Which command will display the current data usage of the thin volume?

A.df -h /dev/mapper/vg01-thinvol
B.lsblk /dev/mapper/vg01-thinvol
C.lvdisplay /dev/vg01/thinvol
D.lvs -o lv_name,data_percent
AnswerD

The lvs command with the -o lv_name,data_percent option is the direct LVM reporting mechanism for thin provisioning usage. It reads LVM metadata and displays, for each specified logical volume, its name and the percentage of the underlying thin pool's data area that the volume's stored data has consumed. This is the standard way to monitor how much of the shared thin pool each thin volume is actually using, and unlike df, it reflects device-mapper level allocation, not filesystem-level usage.

Why this answer

The `lvs -o lv_name,data_percent` command specifically displays the percentage of the thin pool that has been consumed by the thinly provisioned logical volume. For thin volumes, the `data_percent` field reports the actual data usage relative to the thin pool's capacity, which is exactly what the administrator needs to see the current 5GB usage against the 100GB pool.

Exam trap

The trap here is that candidates confuse filesystem-level usage (shown by `df`) with thin pool-level data usage, leading them to pick `df -h` which incorrectly reports the virtual size instead of the actual consumed space.

How to eliminate wrong answers

Option A is wrong because `df -h` shows filesystem usage from the perspective of the mounted filesystem, not the thin pool's data usage; it would report the virtual size (500GB) as the total capacity, not the actual 5GB of data written. Option B is wrong because `lsblk` displays block device attributes like size, type, and mount point, but it does not provide thin pool-specific metrics such as data percentage or actual consumption. Option C is wrong because `lvdisplay` shows general logical volume properties (e.g., size, status) but does not include the `data_percent` field; that field is only available via `lvs` with specific output columns.

Practice this question →
18
Multi-Selectmedium

Which command can be used to create a logical volume using all available free space in a volume group?

Select 1 answer
A.lvcreate --size 20G vgdata lvdata
B.lvcreate -l 100%FREE -n lvdata vgdata
C.lvcreate -L 20G -n lvdata vgdata
D.lvcreate -l 100%VG -n lvdata vgdata
E.lvcreate -L 100%FREE -n lvdata vgdata
AnswersB

The -l flag accepts percentage-based allocation, and 100%FREE specifically targets only the unallocated physical extents in the volume group, so the resulting LV consumes all remaining free space. In contrast to a fixed-size command, this scales automatically as the VG's free space changes. It is the canonical way to create an LV spanning the full free capacity without requiring the administrator to calculate extent counts.

Why this answer

The `-l 100%FREE` flag allocates all unallocated physical extents in the volume group, which is the precise way to use all available free space. Option D (`-l 100%VG`) is incorrect because it attempts to allocate 100% of the volume group's extents, including those already used by other logical volumes, causing the command to fail if any extents are already allocated. Therefore, only option B is correct.

Exam trap

Red Hat often tests the distinction between `-l` (extents/percentage) and `-L` (fixed size) flags, and candidates mistakenly use `-L 100%FREE` thinking it works like the `-l` percentage syntax.

Practice this question →
19
MCQmedium

A Red Hat Enterprise Linux 9 server has an LVM volume group 'vg01' that contains two physical volumes: /dev/sda2 and /dev/sdb1. After a reboot, the system fails to activate the volume group. The administrator runs 'pvdisplay' and sees one physical volume as 'unknown device'. What is the most likely cause?

A.The physical volume is corrupted and needs to be restored from backup
B.The LVM filter in /etc/lvm/lvm.conf is excluding /dev/sdb1
C.The filesystem on the logical volume has become corrupted, preventing LVM metadata access
D.The UUID of the physical volume has changed due to a disk replacement
AnswerB

The LVM filter in /etc/lvm/lvm.conf controls which block devices LVM scans when looking for physical volumes. A negative entry such as filter = ['r|/dev/sdb1|'] tells LVM to reject that device entirely, so its PV metadata is never read and the VG sees the missing PV as an 'unknown device.' Removing the rejection or using a positive filter that accepts /dev/sdb1 and running pvscan/vgscan restores visibility.

Why this answer

The LVM filter in /etc/lvm/lvm.conf controls which devices LVM scans during activation. If the filter excludes /dev/sdb1, LVM will not recognize that physical volume, causing the volume group to fail activation. The 'unknown device' status indicates LVM cannot access the device metadata, not that the device is missing or corrupted.

Exam trap

The trap here is that candidates often assume 'unknown device' means hardware failure or corruption, when in reality it is usually a configuration issue like an incorrect LVM filter or missing device-mapper entries.

How to eliminate wrong answers

Option A is wrong because a corrupted physical volume would typically show I/O errors or fail to read metadata, not appear as 'unknown device' — LVM would still detect the device but report corruption. Option C is wrong because filesystem corruption on the logical volume does not prevent LVM from accessing the physical volume metadata; LVM activation occurs at the block level, independent of the filesystem. Option D is wrong because a UUID change due to disk replacement would cause LVM to see a new device with a different UUID, not mark the existing device as 'unknown' — the 'unknown device' label means LVM cannot read the device at all, not that the UUID mismatches.

Practice this question →
20
MCQeasy

An administrator needs to mount the backup filesystem with the ‘exec’ option temporarily for a one-time script. Which command will remount the filesystem with exec without unmounting?

A.umount /mnt/backup && mount /mnt/backup
B.mount -o exec,remount /dev/sdc1 /mnt/backup
C.mount -o remount,exec /mnt/backup
D.mount -a -o exec
AnswerB, C

This command is correct. It uses the `remount` option to change mount options on an already-mounted filesystem, specifying both the device and mount point. The order of options (exec,remount or remount,exec) does not matter. The filesystem will be remounted with exec enabled.

Why this answer

Both options B and C are valid commands to remount a filesystem with the exec option without unmounting. Option B specifies both the device and mount point, which is accepted by the mount command when using the remount option. Option C uses only the mount point, which is also sufficient.

The remount option allows changing mount options on a live filesystem. Options A and D are invalid: A unmounts and remounts, which is not a single remount operation and could cause issues; D attempts to remount all filesystems with exec, which may not apply correctly and does not target the specific filesystem.

Exam trap

The key trap is that candidates may believe only one syntax is correct for remounting. In reality, both specifying the device and mount point (e.g., mount -o remount,exec /dev/sdc1 /mnt/backup) or just the mount point (mount -o remount,exec /mnt/backup) work. The mount command can identify the filesystem from either identifier.

How to eliminate wrong answers

Option A is wrong because `umount && mount` performs an unmount followed by a mount, which is not a remount operation and requires the filesystem to be unmounted first, potentially causing disruption if the filesystem is in use. Option B is wrong because `mount -o exec,remount /dev/sdc1 /mnt/backup` specifies both the device and mount point, which is redundant and can cause a syntax error or unexpected behavior; the `remount` option expects only one of them (typically the mount point or device) to identify the mount. Option D is wrong because `mount -a -o exec` attempts to remount all filesystems listed in `/etc/fstab` with the `exec` option, which is not a targeted remount of the backup filesystem and may fail or apply the option to unintended mounts.

Practice this question →
21
MCQmedium

An administrator wants to add 20GB of additional space to the root filesystem. The volume group vg01 has no free extents. Which action should be taken first?

A.Shrink the logical volume vg01-data and then extend vg01-root
B.Run vgextend vg01 /dev/sdc (assuming /dev/sdc is a new disk) but this command requires the PV to be created first
C.Use lvextend to extend the root logical volume into the free space of sdb1
D.Attach a new disk, create a physical volume on it, add it to vg01 with vgextend, then extend vg01-root
AnswerD

Attaching a new disk and initializing it as a physical volume is the cleanest way to add 20 GB: run pvcreate /dev/sdc (or a suitable partition), then vgextend vg01 /dev/sdc to make the new space free within the volume group, then lvextend -L +20G /dev/vg01/root to grow the root LV. Finally, the filesystem must be grown to fill the expanded LV—using xfs_growfs for XFS or resize2fs for ext4—and this can be done online. This sequence avoids any downtime and does not touch the existing vg01-data, so it is the correct answer.

Why this answer

To extend the root filesystem when the volume group has no free extents, you must first add a new physical volume to the volume group. This involves attaching a new disk, creating a physical volume on it with `pvcreate`, adding it to vg01 with `vgextend`, and then using `lvextend` followed by `resize2fs` (or `xfs_growfs` for XFS) to extend the logical volume and filesystem. This sequence ensures the volume group has available extents before extending the logical volume.

Exam trap

The trap here is that candidates may think they can directly extend a logical volume into free space on a disk that is not part of the volume group, or they may forget that `vgextend` requires a physical volume to be created first with `pvcreate`.

How to eliminate wrong answers

Option A is wrong because shrinking a logical volume (e.g., vg01-data) is risky, requires unmounting and checking filesystem consistency, and is not the standard first step; the correct approach is to add new physical storage. Option B is wrong because `vgextend` requires an existing physical volume as an argument, and the command as written would fail since `/dev/sdc` has not been initialized with `pvcreate` first. Option C is wrong because `lvextend` cannot use free space from a partition like `/dev/sdb1` unless that partition is already a physical volume in the volume group; the root logical volume can only be extended into free extents within the same volume group.

Practice this question →
22
MCQmedium

Refer to the exhibit. An administrator attempts to mount the partition but receives an error. Which command should be run first to resolve the issue?

A.xfs_repair /dev/sdc1
B.file -s /dev/sdc1
C.partprobe /dev/sdc
D.mkfs.xfs /dev/sdc1
AnswerB

The file -s /dev/sdc1 command reads the raw block device directly, bypassing the normal inode metadata, and displays the actual on-disk filesystem type (e.g., 'SGI XFS filesystem' or 'data'). This is the correct first diagnostic because the partition table entry or /etc/fstab may claim xfs, but the filesystem may have never been created or may have been overwritten. The mount error frequently occurs when there is no valid superblock, and file -s immediately reveals whether a real XFS filesystem is present or whether the partition is unformatted. This non-destructive check gives definitive evidence before any repair or mkfs action.

Why this answer

The error indicates that the partition /dev/sdc1 does not contain a recognized filesystem. Running 'file -s /dev/sdc1' displays the actual data on the partition, confirming whether a filesystem exists or if the partition is raw. This diagnostic step is essential before any repair or formatting action.

Exam trap

The trap here is that RHCSA candidates often jump to xfs_repair or mkfs.xfs without first checking if a filesystem exists using 'file -s'. In Red Hat Enterprise Linux, always diagnose before repairing or formatting.

How to eliminate wrong answers

Option A is wrong because xfs_repair is used to repair an existing XFS filesystem, but if no filesystem is present, the command will fail with an error indicating a 'bad superblock' or 'not an XFS filesystem'. Option C is wrong because partprobe /dev/sdc is used to inform the kernel of partition table changes, but the issue here is a missing filesystem, not a partition table that needs rereading. Option D is wrong because mkfs.xfs /dev/sdc1 would create a new filesystem, which is destructive and should only be done after confirming the partition is indeed empty and that no data needs to be recovered.

Practice this question →
23
MCQhard

Refer to the exhibit. The /proc/mdstat output shows a RAID1 array with two devices. One of the disks (/dev/sda1) fails. Which sequence of commands would be used to remove the failed disk and add a new replacement disk /dev/sdc1?

A.mdadm --fail /dev/md0 /dev/sda1; mdadm --remove /dev/md0 /dev/sda1; mdadm --add /dev/md0 /dev/sdc1
B.mdadm /dev/md0 --fail /dev/sda1; mdadm /dev/md0 --remove /dev/sda1; mdadm /dev/md0 --add /dev/sdc1
C.mdadm /dev/md0 --set-faulty /dev/sda1; mdadm /dev/md0 --remove /dev/sda1; mdadm /dev/md0 --add /dev/sdc1
D.mdadm /dev/md0 --remove /dev/sda1; mdadm /dev/md0 --add /dev/sdc1
E.mdadm /dev/md0 --replace /dev/sda1 --with /dev/sdc1
AnswerB

This is the proper procedure to replace a failed disk in a RAID1 array. '--fail' marks the current disk as faulty, allowing the kernel to stop using it and flag the array as degraded. '--remove' then detaches the faulty device from the array, and '--add' enlists the replacement disk, triggering a rebuild that copies data from the remaining healthy mirror.

Why this answer

It uses the proper mdadm syntax with the device name immediately after the command, followed by the action and the disk. The --fail flag marks the disk as faulty, --remove removes it from the array, and --add adds the new replacement disk. This sequence ensures the array remains in a degraded state before safely replacing the failed component.

Exam trap

Red Hat often tests the exact command syntax and flag order, and the trap here is that candidates confuse the valid flags (--fail vs --set-faulty) or assume --remove can be used directly without first marking the disk as failed.

How to eliminate wrong answers

Option A is wrong because it places the action flag before the array device, which is syntactically incorrect; mdadm requires the array device to come first, then the action. Option C is wrong because --set-faulty is not a valid mdadm flag; the correct flag is --fail. Option D is wrong because it attempts to remove the disk without first marking it as failed, which will fail if the disk is still active in the array.

Option E is wrong because --replace is not a standard mdadm operation for RAID1; it is used in RAID5/6 for device replacement and does not handle the required fail step.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Configure local storage questions.

Start 20-question session