Courseiva

CCNA Local Storage Questions

73 questions · Local Storage topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
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 →
2
Matchingmedium

Match each cron syntax field to its meaning.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

0-59

0-23

1-31

1-12 or Jan-Dec

Why these pairings

The five fields in a cron syntax are (in order): minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7). Common confusions include swapping the minute and hour ranges.

Practice this question →
3
MCQmedium

A system administrator needs to extend a logical volume 'lv_data' in volume group 'vg_data' by adding a new 50GB disk. Which sequence of commands should be used (assuming the filesystem is XFS)?

A.pvcreate, vgextend, lvextend, resize2fs
B.vgextend, lvcreate, pvcreate, xfs_growfs
C.vgextend, pvcreate, lvextend, xfs_growfs
D.pvcreate, vgextend, lvextend, xfs_growfs
E.pvcreate, lvextend, vgextend, fsck
AnswerD

This is the correct sequence for extending an XFS logical volume: pvcreate initializes the new disk or partition as a physical volume; vgextend adds that PV to the existing volume group, making new extents available; lvextend extends the logical volume into the free extents; and finally xfs_growfs expands the XFS filesystem to fill the larger LV. Because XFS can be grown online and does not support shrinking, xfs_growfs is the proper tool rather than resize2fs. This order ensures every prerequisite is satisfied before the next operation.

Why this answer

The proper sequence to extend an XFS logical volume is: first, initialize the new disk as a physical volume with `pvcreate`; second, add it to the volume group with `vgextend`; third, extend the logical volume with `lvextend`; and finally, grow the XFS filesystem with `xfs_growfs`. XFS does not support shrinking and requires `xfs_growfs` (not `resize2fs`) for online growth.

Exam trap

The trap here is that candidates confuse `resize2fs` (for ext4) with `xfs_growfs` (for XFS), or incorrectly order the commands by adding the disk to the volume group before initializing it as a physical volume.

How to eliminate wrong answers

Option A is wrong because `resize2fs` is used for ext2/3/4 filesystems, not XFS; XFS uses `xfs_growfs`. Option B is wrong because `lvcreate` creates a new logical volume, not extends an existing one, and `pvcreate` must precede `vgextend`. Option C is wrong because `pvcreate` must be run before `vgextend` to initialize the disk as a physical volume.

Option E is wrong because `lvextend` cannot be done before adding the physical volume to the volume group (`vgextend`), and `fsck` is a filesystem check, not a resize tool.

Practice this question →
4
MCQmedium

A system administrator runs the following command: # vgextend mydata-vg /dev/sdc. After successfully extending the volume group, what is the next step to make the additional space available in the logical volume mydata-lv?

A.xfs_growfs /data
B.lvextend -l +100%FREE /dev/mydata-vg/mydata-lv
C.resize2fs /dev/mydata-vg/mydata-lv
D.lvextend -L +10G /dev/mydata-vg/mydata-lv
AnswerB

lvextend -l +100%FREE /dev/mydata-vg/mydata-lv is correct because it extends the logical volume by all free extents present in the volume group, ensuring the LV consumes every unused physical extent. The -l option uses logical extent counts rather than a fixed size, and +100%FREE is a relative allocation that dynamically calculates the total free space in the VG. By using all free extents, this command maximizes the LV size without requiring you to know the exact amount of free capacity, which is ideal after a vgextend operation.

Why this answer

After extending the volume group with vgextend, you must extend the logical volume to use the new free space. The command lvextend -l +100%FREE /dev/mydata-vg/mydata-lv allocates all remaining free extents in the volume group to the logical volume, making the additional space available for the filesystem.

Exam trap

The trap here is that candidates often confuse the order of operations and try to grow the filesystem directly (option A or C) without first extending the logical volume, or they use a specific size (option D) instead of the '100%FREE' syntax to consume all new space.

How to eliminate wrong answers

Option A is wrong because xfs_growfs /data is used to grow an XFS filesystem, but the logical volume itself has not been extended yet; you must first run lvextend to allocate the space to the LV. Option C is wrong because resize2fs is for ext2/ext3/ext4 filesystems, not XFS, and again the LV must be extended first. Option D is wrong because lvextend -L +10G adds a specific amount of space (10 GiB) rather than using all available free space in the volume group, which may not match the full extent of the newly added physical volume.

Practice this question →
5
MCQhard

A system fails to mount an XFS filesystem at boot. The /etc/fstab entry is: UUID=abc123 /mnt xfs defaults 0 0. Running mount -a shows: 'mount: wrong fs type, bad option, bad superblock on /dev/sdb1'. Which is the most likely cause?

A.The UUID specified in fstab does not match the actual UUID of /dev/sdb1.
B.The mount point /mnt does not exist.
C.The kernel does not have XFS support enabled.
D.The filesystem on /dev/sdb1 is not XFS but ext4.
AnswerD

If /dev/sdb1 actually contains an ext4 filesystem, the mount command would report "wrong fs type, bad option, bad superblock" only when the fstab entry specifies `xfs` and the filesystem type is inconsistent. However, a UUID mismatch prevents the mount from even locating the device — the error occurs during device resolution, before the kernel reads the superblock — so the failure described in the question would happen regardless of whether the filesystem type were ext4 or XFS. Moreover, an ext4 filesystem mounted with the correct UUID would succeed, so merely having ext4 on the device does not inherently cause a boot-time mount failure.

Why this answer

The error 'wrong fs type, bad option, bad superblock' occurs when the device exists but the filesystem type does not match or the superblock is unreadable. Since the error explicitly mentions /dev/sdb1, the UUID must have resolved to that device. Therefore, a UUID mismatch would produce a different error like 'can't find UUID=abc123' or 'no such device'.

The most likely cause is that /dev/sdb1 is not formatted as XFS (e.g., it is ext4). A missing mount point gives 'No such file or directory', and kernel XFS support issues typically produce 'unknown filesystem type'.

Exam trap

A UUID mismatch results in 'mount: can't find UUID=...' or 'no such device', not a 'wrong fs type' error. The error 'wrong fs type, bad option, bad superblock' points to an actual device that cannot be mounted with the specified filesystem type, so candidates should suspect a filesystem type mismatch.

How to eliminate wrong answers

Option B is wrong because if the mount point /mnt did not exist, the error would be 'mount point does not exist' or 'No such file or directory', not a filesystem type error. Option C is wrong because if the kernel lacked XFS support, the error would be 'mount: unknown filesystem type 'xfs'' or similar, not a 'wrong fs type' message that implies the filesystem is recognized but mismatched. Option D is wrong because if the filesystem were ext4, the error would still be 'wrong fs type' only if the fstab explicitly specified 'xfs' and the kernel tried to mount it as XFS; however, the error message 'bad superblock' is more specific to a superblock mismatch, and the UUID mismatch is a more direct and common cause than a filesystem type mismatch, which would also produce a different error (e.g., 'mount: /dev/sdb1 is not a valid XFS filesystem').

Practice this question →
6
Multi-Selecteasy

Which THREE of the following are valid utilities for creating partitions on a disk in Red Hat Enterprise Linux?

Select 3 answers
A.mkfs
B.mount
C.fdisk
D.gdisk
E.parted
AnswersC, D, E

fdisk is the traditional interactive text-based utility for creating, modifying, and deleting partitions on MBR (DOS) partition tables, and modern versions also support GPT with a compatible interface. It writes partition entries that define start and end sectors, partition type, and boot flag, but it cannot directly create a filesystem without a separate mkfs step. fdisk is well-suited for manual partition planning and small disks.

Why this answer

C is correct because `fdisk` is a traditional command-line utility for creating, deleting, and managing MBR (Master Boot Record) partition tables on disks in Red Hat Enterprise Linux. It supports interactive and scripted partitioning, making it a valid tool for local storage configuration.

Exam trap

The trap here is that candidates often confuse filesystem creation (`mkfs`) or mounting (`mount`) with actual partition creation, leading them to select those invalid options instead of the correct partitioning utilities.

Practice this question →
7
MCQhard

Refer to the exhibit. A user tries to execute a script located in /data/script.sh but gets 'Permission denied'. The script has execute permissions. What is the most likely cause?

A.The filesystem is mounted with noexec
B.The filesystem is full
C.SELinux is blocking execution
D.The script is in a directory with noexec
AnswerA

A `noexec` mount option on the filesystem is the direct cause: the kernel refuses to execute any file (binary or script) from that mount, even if the file has executable permissions set. This is enforced at the VFS layer, so attempting to run the script with `./script.sh` will return `Permission denied` or `Operation not permitted`, matching the reported symptom. The option is set in `/etc/fstab` (or via `mount -o noexec`), and it overrides normal execute-bit checks.

Why this answer

The most likely cause is that the filesystem where /data resides is mounted with the 'noexec' option. This mount option prevents the execution of any binary or script directly from that filesystem, regardless of the file's individual execute permissions. The 'noexec' flag is commonly set on partitions like /tmp or /var for security reasons, and it overrides the file's permission bits.

Exam trap

Red Hat often tests the distinction between file-level permissions and filesystem-level mount options, where candidates mistakenly think execute permissions alone guarantee execution, ignoring that mount options like 'noexec' can override them.

How to eliminate wrong answers

Option B is wrong because a full filesystem would produce a 'No space left on device' error, not 'Permission denied'. Option C is wrong because SELinux blocking execution typically produces an 'Operation not permitted' or AVC denial message, not a generic 'Permission denied', and the question states the script has execute permissions. Option D is wrong because directories themselves do not have a 'noexec' attribute; the 'noexec' option is a mount-level filesystem flag, not a directory-level attribute.

Practice this question →
8
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 →
9
MCQhard

A system administrator is managing a Red Hat Enterprise Linux 9 server that uses LVM for storage. The volume group 'vgdata' contains two 500 GB physical volumes (sdb and sdc) with a logical volume 'lvdata' of 800 GB formatted with XFS and mounted at /data. The administrator adds a new 200 GB disk /dev/sdd and intends to use all of its capacity to extend lvdata. The following commands are executed in order: pvcreate /dev/sdd, vgextend vgdata /dev/sdd, lvextend -l +100%FREE /dev/vgdata/lvdata. The lvextend command completes successfully, but running 'df -h /data' still shows 800 GB. What is the most likely reason?

A.The volume group 'vgdata' is not active, so the new space is ignored.
B.The logical volume was extended using a snapshot instead of the original.
C.The filesystem has not been grown after extending the logical volume.
D.The physical volume was not created correctly and the space is not available.
AnswerC

Extending a logical volume with lvextend only increases the size of the block device; the filesystem on top of it remains unchanged until explicitly resized. For XFS filesystems, the resize must be performed with xfs_growfs, which can only grow the filesystem online to fill the additional space in the LV. Since the administrator has presumably not run xfs_growfs (or did not mount the filesystem with a tool that auto-grows it), the new space is allocated but not yet available to files, which exactly matches the symptom.

Why this answer

After extending the logical volume with `lvextend`, the underlying block device has more space, but the filesystem still sees the original size. For XFS, you must run `xfs_growfs /data` (or `xfs_growfs /dev/vgdata/lvdata`) to expand the filesystem to use the newly allocated extents. Without this step, `df -h` continues to report the old filesystem size.

Exam trap

The trap here is that candidates assume `lvextend` automatically resizes the filesystem, but Red Hat exams specifically test that you must run a separate filesystem-specific command (e.g., `xfs_growfs` or `resize2fs`) after extending the logical volume.

How to eliminate wrong answers

Option A is wrong because the volume group must be active for `lvextend` to succeed; the command completed successfully, confirming vgdata is active. Option B is wrong because snapshots are separate logical volumes; extending the original LV does not involve snapshots, and no snapshot was created in the scenario. Option D is wrong because `pvcreate /dev/sdd` and `vgextend vgdata /dev/sdd` both succeeded, and the `lvextend` command used `+100%FREE`, which would have failed if the PV were not available.

Practice this question →
10
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 →
11
MCQmedium

An administrator wants to extend an XFS filesystem that resides on an LVM logical volume. The volume group has free physical extents. Which is the correct sequence?

A.lvextend, then xfs_growfs
B.lvextend, then resize2fs
C.xfs_growfs, then lvextend
D.resize2fs, then lvextend
AnswerA

Extending the logical volume first is required because XFS can only be grown, and the filesystem growth depends on the block device's new capacity. After lvextend allocates the additional storage to the LV, the mounted XFS filesystem is still the old size; running xfs_growfs on the mount point resizes it online to consume the newly available space. This is the only correct sequence for an XFS filesystem on LVM.

Why this answer

To extend an XFS filesystem on an LVM logical volume, you must first extend the logical volume with `lvextend` to allocate additional physical extents from the volume group, then grow the XFS filesystem to use the new space with `xfs_growfs`. XFS does not support online shrinking and requires the filesystem to be mounted for `xfs_growfs` to work. This sequence ensures the block device has sufficient capacity before the filesystem is expanded.

Exam trap

The trap here is that candidates confuse the filesystem type and apply `resize2fs` (for ext4) to XFS, or incorrectly assume the filesystem can be grown before the logical volume is extended.

How to eliminate wrong answers

Option B is wrong because `resize2fs` is used for ext2/ext3/ext4 filesystems, not XFS; using it on an XFS filesystem would fail. Option C is wrong because `xfs_growfs` cannot expand the filesystem if the underlying logical volume has not been extended first; the filesystem cannot grow beyond the block device size. Option D is wrong because `resize2fs` is not applicable to XFS, and attempting to resize the filesystem before extending the logical volume would also fail due to insufficient block device space.

Practice this question →
12
MCQmedium

A production server runs RHEL 8 with a software RAID 5 array (/dev/md0) composed of three disks: /dev/sda, /dev/sdb, /dev/sdc. The array is used to store database files. The server experiences a disk failure on /dev/sdc. The admin replaces /dev/sdc with an identical disk and wants to rebuild the array. He runs: mdadm /dev/md0 --add /dev/sdc. The command completes without error, but the array shows a degraded state after several hours. What should the admin do next?

A.Run mdadm --detail /dev/md0 to check the status and rebuild progress.
B.Rebuild will happen automatically; just wait longer.
C.Recreate the array using mdadm --create with the same parameters.
D.Format /dev/sdc with a filesystem before adding to the array.
AnswerA

Running `mdadm --detail /dev/md0` is the correct first step because it reports the array state (`clean`, `degraded`, or `recovering`) and shows per-device status, including whether `/dev/sdc` is present as an active or spare device. It also displays a rebuild progress percentage and estimated time when a reshape or reconstruction is in progress, allowing you to confirm that recovery is actually underway and to spot device errors or mismatches. Without this command, you cannot distinguish a healthy rebuild from one that has stalled or failed.

Why this answer

After adding a replacement disk to a RAID 5 array, the rebuild process begins automatically but may take hours depending on disk size and I/O load. Running `mdadm --detail /dev/md0` allows the admin to check the current state, rebuild progress (e.g., percentage complete), and any errors that might have stalled the rebuild. This is the first diagnostic step to determine if the rebuild is still ongoing, has failed, or is degraded for another reason.

Exam trap

The trap here is that candidates assume the rebuild is always automatic and instantaneous, or they panic and choose destructive options like recreating the array, instead of first verifying the rebuild status with a simple diagnostic command.

How to eliminate wrong answers

Option B is wrong because while the rebuild does start automatically, it can stall or fail due to issues like bad sectors on the new disk, I/O errors, or a mismatch in superblock information; simply waiting longer without checking progress may waste time if the rebuild has stopped. Option C is wrong because recreating the array with `mdadm --create` would destroy all existing data on the array, which is unnecessary and catastrophic for a production database server; the correct approach is to add the disk to the existing array. Option D is wrong because adding a filesystem to /dev/sdc before adding it to the array would corrupt the RAID metadata and prevent the disk from being recognized as a spare; mdadm expects a raw block device without a filesystem.

Practice this question →
13
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 →
14
MCQmedium

A system administrator needs to create a point-in-time backup of a logical volume 'lv_home' that is currently mounted. Which LVM feature should be used?

A.lvreduce
B.lvchange
C.lvextend
D.lvcreate -s
E.pvmove
AnswerD

lvcreate -s is correct because it creates a snapshot logical volume, which provides a point-in-time image of the origin LV. LVM snapshots use copy-on-write (CoW) technology: when the original LV is modified, the old data is preserved in the snapshot's allocated extents. This allows the snapshot to serve as a consistent backup target for subsequent operations like mounting or archiving.

Why this answer

The 'lvcreate -s' command creates a snapshot of a logical volume, which provides a point-in-time backup without unmounting the volume. Snapshots are a native LVM feature that allow consistent backups of mounted filesystems by capturing the state of the logical volume at the moment the snapshot is created.

Exam trap

The trap here is that candidates may confuse 'lvcreate -s' with other LVM commands like 'lvreduce' or 'lvextend', mistakenly thinking those can create backups, or they may assume that a mounted volume must be unmounted before any backup operation, which is not required with LVM snapshots.

How to eliminate wrong answers

Option A is wrong because 'lvreduce' reduces the size of a logical volume, which is unrelated to creating backups and can cause data loss if not done carefully. Option B is wrong because 'lvchange' modifies attributes of an existing logical volume (e.g., activation, permissions) and does not create point-in-time copies. Option C is wrong because 'lvextend' increases the size of a logical volume, which is used for capacity expansion, not backup creation.

Option E is wrong because 'pvmove' moves physical extents from one physical volume to another within a volume group, which is used for storage migration or maintenance, not for creating backups.

Practice this question →
15
MCQmedium

Refer to the exhibit. An administrator needs to create a new logical volume named 'data' of size 3GB. Which command should be used?

A.lvcreate -n data -L 3G vg01
B.lvcreate -n data -L 3G vg00
C.lvcreate -n data -L 3G /dev/sda1
D.lvcreate -n data -l 100 vg01
E.lvcreate -n data -l 100 vg00
AnswerA

This command correctly creates a new logical volume named 'data' with a size of 3GiB (using the -L option, where 'G' denotes GiB) within volume group vg01. Since vg01 has 5GiB of free space, the allocation request is satisfied and the LV is created successfully with default linear mapping. The -n flag assigns the name, and the final positional argument correctly specifies the volume group, which is the only valid target for lvcreate.

Why this answer

The `lvcreate` command with `-n data` names the logical volume 'data', `-L 3G` sets its size to 3 gigabytes, and `vg01` specifies the volume group that contains the physical volumes. This matches the requirement exactly, assuming the volume group `vg01` exists and has sufficient free extents.

Exam trap

Red Hat often tests the distinction between the `-L` (size in units) and `-l` (number of extents) options, and the requirement to specify a volume group name rather than a device path, to catch candidates who confuse LVM syntax with standard partition commands.

How to eliminate wrong answers

Option B is wrong because it specifies `vg00` instead of `vg01`, which does not match the volume group referenced in the exhibit (the exhibit shows `vg01`). Option C is wrong because `lvcreate` requires a volume group name, not a device path like `/dev/sda1`; using a device path would attempt to create a logical volume directly on a physical volume, which is invalid syntax. Option D is wrong because `-l 100` allocates 100 logical extents, not a fixed size of 3GB; the size in extents depends on the extent size of the volume group, which may not equal 3GB.

Option E is wrong because it uses `-l 100` (extents, not a fixed size) and specifies `vg00` instead of `vg01`.

Practice this question →
16
MCQhard

Refer to the exhibit. After extending the logical volume, why does the df output still show 5.0G?

A.The lvextend command failed silently.
B.The filesystem type is ext4 and requires resize2fs.
C.The mount point /data is not accessible.
D.The filesystem needs to be resized with xfs_growfs.
AnswerD

After lvextend expands the logical volume, the XFS filesystem still occupies only the original space, because the kernel only updates the block device size, not the filesystem metadata. Running xfs_growfs /data on the mounted filesystem instructs the kernel to expand the filesystem to fill the entire logical volume. This is the mandatory step for XFS filesystems, analogous to resize2fs for ext4. Without it, the added capacity remains invisible to applications and users.

Why this answer

The output shows the logical volume was extended (e.g., from 5G to 10G), but the filesystem itself has not been resized to use the new space. For XFS filesystems, the `xfs_growfs` command must be run to expand the filesystem to match the logical volume size. The `df` command reports filesystem usage, not block device size, so it still shows 5.0G until the filesystem is grown.

Exam trap

The trap here is that candidates assume extending the logical volume automatically resizes the filesystem, but XFS requires a separate `xfs_growfs` step, unlike ext4 which can be resized with `resize2fs` after lvextend.

How to eliminate wrong answers

Option A is wrong because the lvextend command did not fail silently; the logical volume was successfully extended (as seen in the lvs output), but the filesystem was not resized. Option B is wrong because the filesystem type is XFS (not ext4), and ext4 uses `resize2fs`, not `xfs_growfs`. Option C is wrong because the mount point /data is accessible (the df output shows it mounted), and inaccessibility would cause an error, not a stale size.

Practice this question →
17
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 →
18
MCQeasy

After creating a new partition on /dev/sdc, the administrator runs 'partprobe' to inform the kernel of the change. What is the primary purpose of partprobe?

A.To create a filesystem label
B.To repair a damaged partition table
C.To format the partition with a filesystem
D.To make the kernel re-read the partition table
AnswerD

partprobe, from the parted suite, is specifically designed to make the Linux kernel re-read the partition table from a disk. After partitioning /dev/sdc, the kernel may still have the old view, so partprobe triggers a revalidation so that the new partition appears as a block device (e.g., /dev/sdc1) without requiring a reboot. This is the correct and intended purpose of the command, though in cases where the disk is in use, a reboot or partx may be needed.

Why this answer

The `partprobe` command is used to inform the operating system kernel of changes to the partition table without requiring a system reboot. After creating a new partition on `/dev/sdc`, running `partprobe` makes the kernel re-read the partition table from the disk, ensuring the new partition is recognized and accessible. This is essential for the kernel to update its in-memory representation of the disk's partitions.

Exam trap

The trap here is that candidates often confuse `partprobe` with `partx` or `mkfs`, mistakenly thinking it formats or repairs partitions, when its sole purpose is to synchronize the kernel's partition table with the disk's actual partition layout.

How to eliminate wrong answers

Option A is wrong because creating a filesystem label is done with commands like `e2label` or `tune2fs`, not `partprobe`. Option B is wrong because repairing a damaged partition table is typically performed with tools like `gdisk` or `fdisk` in recovery mode, not `partprobe`. Option C is wrong because formatting a partition with a filesystem is accomplished using commands like `mkfs.ext4` or `mkfs.xfs`, not `partprobe`.

Practice this question →
19
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 →
20
Multi-Selecthard

Which TWO commands can be used to list block devices and their attributes? (Choose exactly two.)

Select 2 answers
A.fdisk -l
B.lsblk
C.du
D.df
E.blkid
AnswersB, E

lsblk reads the sysfs filesystem to present all available block devices as a hierarchical tree, showing essential attributes like name, size, type, and mount point, and with the -f flag adds filesystem type, UUID, and label. It is the canonical, dependency-free command for listing block devices quickly, and it runs without root for basic output. This directly answers the request to list block devices, making it the correct choice.

Why this answer

B (lsblk) is correct because it lists all block devices (e.g., /dev/sda, /dev/nvme0n1) and displays their attributes such as size, type, mount point, and model in a tree-like format by reading the sysfs filesystem. E (blkid) is correct because it shows block device attributes like UUID, filesystem type, and LABEL by querying the libblkid library, which reads metadata directly from the device.

Exam trap

Red Hat often tests the distinction between commands that list block devices (lsblk, blkid) versus commands that manage partitions (fdisk) or report filesystem usage (df, du), causing candidates to confuse 'block device attributes' with 'partition table' or 'disk usage' information.

Practice this question →
21
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 →
22
Multi-Selectmedium

Which TWO of the following are valid reasons to use LVM in a Red Hat Enterprise Linux environment?

Select 2 answers
A.Improved disk I/O performance over direct partitions
B.Ability to resize logical volumes without repartitioning
C.Support for snapshots for backup purposes
D.Simplification of disk partitioning by removing the need for partitions
E.Ability to create RAID arrays without mdadm
AnswersB, C

LVM decouples the filesystem from the underlying physical partition layout by using physical volumes, volume groups, and logical volumes. This logical abstraction enables administrators to grow or shrink logical volumes on-the-fly (with filesystem support) without the need to delete/recreate partitions or disrupt running systems. This flexibility is a fundamental advantage over static partition-based layouts.

Why this answer

LVM allows you to resize logical volumes (LVs) online or offline without needing to repartition the underlying disk, which is a key advantage over traditional partitions. Option C is correct because LVM provides snapshot functionality, which creates a point-in-time copy of a logical volume for consistent backups or testing, without requiring additional backup software.

Exam trap

The trap here is that candidates often confuse LVM's flexibility features (like resizing and snapshots) with performance improvements or RAID capabilities, leading them to select options A or E, which are not inherent LVM benefits.

Practice this question →
23
Multi-Selecteasy

Which TWO commands can be used to create a filesystem on a new partition? (Choose two.)

Select 2 answers
A.mount /dev/sdb1 /mnt
B.mkfs /dev/sdb1
C.parted /dev/sdb
D.mkfs.ext4 /dev/sdb1
E.fdisk /dev/sdb
AnswersB, D

mkfs is the standard command-line front-end that builds a filesystem on a device, writing the superblock, inode table, and other metadata. With no -t option, it defaults to ext2, but it silently calls the appropriate mkfs.<type> binary. This command correctly initializes /dev/sdb1 for use, so it is a valid answer.

Why this answer

B is correct because `mkfs` is the generic command to create a filesystem on a partition. D is correct because `mkfs.ext4` is a specific variant of `mkfs` that creates an ext4 filesystem. Both commands write the filesystem metadata to the partition, making it ready for mounting.

Exam trap

The trap here is that candidates confuse partition management commands (fdisk, parted) with filesystem creation commands (mkfs), or think that mounting a partition will automatically create a filesystem on it.

Practice this question →
24
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 →
25
MCQeasy

Which file contains the list of filesystems to be mounted at system startup?

A./etc/fstab
B./etc/rc.local
C./etc/filesystems
D./etc/mtab
AnswerA

/etc/fstab is the correct answer because it is the system's permanent filesystem table. Each line defines a filesystem to be mounted at boot, specifying the device or UUID, the mount point, the filesystem type, mount options, and dump/fsck flags. The systemd mount mechanism and the mount -a command both read this file to bring up all persistent filesystems. Without /etc/fstab, manually configured mounts would be lost after every reboot, so this file is the canonical location for mount definitions.

Why this answer

The /etc/fstab file is the system configuration file that defines static filesystem information, including devices, mount points, filesystem types, mount options, dump frequency, and fsck pass order. During system startup, the mount -a command (typically run by systemd or init scripts) reads /etc/fstab to mount all filesystems listed there, making it the definitive source for automatic mounting at boot.

Exam trap

Red Hat often tests the distinction between /etc/fstab (static boot-time configuration) and /etc/mtab (dynamic current mount state), leading candidates to confuse the two because both contain mount information.

How to eliminate wrong answers

Option B is wrong because /etc/rc.local is a legacy script executed at the end of the boot process for custom commands, not a file that lists filesystems to be mounted; it is not read by the mount command for automatic mounting. Option C is wrong because /etc/filesystems is a deprecated file that lists supported filesystem types (e.g., ext4, xfs) for the mount command to probe, not a list of filesystems to mount at startup. Option D is wrong because /etc/mtab is a dynamically updated file showing currently mounted filesystems, maintained by the mount command, and is not used for boot-time mounting; it is often a symlink to /proc/mounts on modern systems.

Practice this question →
26
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 →
27
MCQeasy

Refer to the exhibit. An administrator runs lsblk and sees the above output. The administrator wants to mount /dev/sdb1 at /mnt/data. What should be done first?

A.Create the directory /mnt/data and then run mount
B.Run mount /dev/sdb1 /mnt/data
C.Run partprobe to detect the partition
D.Run mkfs.xfs /dev/sdb1
E.Edit /etc/fstab and add an entry
AnswerA

The mount point directory must exist as a directory in the current root filesystem before any device can be attached to it. Creating /mnt/data with mkdir provides that directory, after which mount /dev/sdb1 /mnt/data associates the block device's filesystem with that path. Without this step, the kernel has no inode to anchor the mounted filesystem to, and the mount syscall will fail with ENOENT.

Why this answer

Before mounting a filesystem, the mount point directory must exist. Option A correctly instructs to create /mnt/data with mkdir -p /mnt/data and then run mount /dev/sdb1 /mnt/data. Without the directory, the mount command will fail with a 'mount point does not exist' error.

Exam trap

Red Hat often tests the prerequisite of creating the mount point directory, tricking candidates who assume mount will create it automatically or who jump to formatting or fstab editing without verifying the directory exists.

How to eliminate wrong answers

Option B is wrong because it attempts to mount to a non-existent directory /mnt/data, which will fail. Option C is wrong because partprobe is used to inform the kernel of partition table changes, but the partition /dev/sdb1 already appears in lsblk output, so it is already detected. Option D is wrong because mkfs.xfs would create a new filesystem, potentially destroying existing data; the question only asks to mount the partition, not format it.

Option E is wrong because editing /etc/fstab is for persistent mounts across reboots, but the immediate step before mounting is to ensure the mount point exists.

Practice this question →
28
MCQhard

Which of the following is true regarding shrinking logical volumes?

A.You can reduce a volume while it is mounted if you use resize2fs
B.XFS filesystems cannot be shrunk
C.Reducing an LVM volume is a simple process
D.Ext4 filesystems support online shrinking
AnswerB

XFS was architecturally designed for high scalability and only supports growing a filesystem, not shrinking it. The extent-based B-tree structure and lack of any shrink mechanism in the on-disk format make reducing an XFS filesystem impossible even when unmounted. This is why a logical volume with XFS must be backed up and recreated at a smaller size if space needs to be reclaimed.

Why this answer

B is correct because XFS filesystems do not support shrinking. The XFS design is based on allocation groups and a log-structured metadata layout that makes online or offline shrinking infeasible without significant filesystem restructuring. This is a fundamental limitation of XFS, unlike ext4 which can be shrunk offline.

Exam trap

Red Hat often tests the misconception that all filesystems can be shrunk similarly, but the trap here is that XFS is fundamentally unshrinkable, and candidates confuse online resizing (which XFS supports for growth) with shrinking.

How to eliminate wrong answers

Option A is wrong because resize2fs can only shrink ext2/3/4 filesystems while unmounted; shrinking a mounted ext4 filesystem is not supported and will cause corruption. Option C is wrong because reducing an LVM volume is not a simple process; it requires multiple steps: unmounting the filesystem, running fsck, shrinking the filesystem with resize2fs (for ext4), then reducing the logical volume with lvreduce, and finally remounting. Option D is wrong because ext4 filesystems do not support online shrinking; they can only be shrunk when unmounted, and resize2fs requires the filesystem to be offline for shrink operations.

Practice this question →
29
Multi-Selecteasy

Which two commands can be used to create a new partition on a disk without erasing existing partitions? (Choose two.)

Select 2 answers
A.mkswap
B.fdisk
C.dd
D.parted
E.wipefs
AnswersB, D

fdisk is an interactive partitioning utility that can create new partitions by manipulating the partition table on a disk such as /dev/sda. Using its interactive 'n' command, you specify a partition type and size, then use 'w' to write the new partition table entry. It supports MBR and, in modern versions, GPT, making it a correct tool for creating partitions.

Why this answer

The `fdisk` command is a disk partitioning tool that allows you to create, delete, and modify partitions on a disk without erasing existing partitions, as long as there is unallocated space. It operates on the MBR or GPT partition table and writes changes only when explicitly saved, preserving existing partition entries.

Exam trap

The trap here is that candidates may confuse `mkswap` or `wipefs` as partition-creation tools because they are commonly used in storage setup workflows, but neither actually creates a partition entry in the partition table.

Practice this question →
30
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 →
31
MCQeasy

An administrator needs to add a new 20GB disk /dev/sdb to a RHEL 9 server and mount it permanently at /data. The disk is unpartitioned. Which sequence of commands correctly accomplishes this?

A.fdisk /dev/sdb → mkfs.ext4 /dev/sdb1 → mount /dev/sdb1 /data
B.mkfs.ext4 /dev/sdb → mount /dev/sdb /data
C.parted /dev/sdb → mkfs.ext4 /dev/sdb1 → mount /dev/sdb1 /data
D.fdisk /dev/sdb → mkfs.ext4 /dev/sdb1 → echo '/dev/sdb1 /data ext4 defaults 0 0' >> /etc/fstab → mount -a
AnswerD

This sequence is complete: fdisk creates a partition (/dev/sdb1), mkfs.ext4 places a filesystem on it, the echo appends a persistent entry to /etc/fstab with mount options 'defaults' and dump/pass flags, and mount -a reads fstab and mounts all filesystems listed there. As long as the /data mount point directory exists, this will mount /dev/sdb1 immediately and automatically at every boot. The fstab entry is what makes the configuration persistent and distinguishes this from the temporary-mount-only alternatives.

Why this answer

It follows the proper sequence for adding a new unpartitioned disk: create a partition with fdisk, format the partition with mkfs.ext4, add an entry to /etc/fstab for permanent mounting, and then use mount -a to mount all filesystems from fstab. This ensures the disk is mounted persistently across reboots, which is required by the question.

Exam trap

The trap here is that candidates often forget the fstab step for permanent mounting, assuming mount alone makes it persistent, or they attempt to format the whole disk without partitioning, which is not the standard procedure for a new disk in RHEL.

How to eliminate wrong answers

Option A is wrong because it omits the critical step of adding the mount to /etc/fstab, so the mount is not permanent; after reboot, /data would not be mounted. Option B is wrong because it attempts to create a filesystem directly on the whole disk (/dev/sdb) without partitioning, which is not standard practice and may cause issues with tools expecting a partition table; also, it lacks the fstab entry for permanent mounting. Option C is wrong because while parted can create partitions, the sequence shown does not include creating the partition (only launching parted) and then directly formatting /dev/sdb1, which does not exist; additionally, it lacks the fstab entry.

Practice this question →
32
MCQmedium

Refer to the exhibit. If the system administrator wants to create a new logical volume of size 2GB in the 'rhel' volume group, what is the first command that must be executed?

A.pvcreate /dev/sdb
B.pvcreate /dev/sdb1
C.lvcreate -L 2G -n lvdata rhel
D.vgextend rhel /dev/sdb
AnswerB

The pvcreate /dev/sdb1 command is correct because it initializes the partition /dev/sdb1 as a physical volume, making it available to be added to an LVM volume group. After this step, the administrator would typically extend the volume group rhel with vgextend rhel /dev/sdb1, and only then can they create a logical volume. This aligns with the correct sequence of LVM operations: partition, pvcreate, vgextend, lvcreate.

Why this answer

Before a new logical volume can be created in the 'rhel' volume group, the physical volume must be prepared. The exhibit shows that /dev/sdb is not yet partitioned; the first step is to create a partition (e.g., /dev/sdb1) and then initialize it as a physical volume using `pvcreate /dev/sdb1`. Only after this can the volume group be extended and the logical volume created.

Exam trap

Red Hat often tests the misconception that you can directly extend a volume group with an uninitialized disk or create a logical volume without first ensuring the VG has free space, leading candidates to skip the essential `pvcreate` step.

How to eliminate wrong answers

Option A is wrong because `pvcreate /dev/sdb` would attempt to initialize the entire disk without a partition table, which is not the standard practice for adding a new disk to LVM; a partition (e.g., /dev/sdb1) is typically required first. Option C is wrong because `lvcreate -L 2G -n lvdata rhel` cannot succeed until the volume group has enough free physical extents, which requires first adding a physical volume and extending the VG. Option D is wrong because `vgextend rhel /dev/sdb` would fail if /dev/sdb is not yet a physical volume; the PV must be created before extending the VG.

Practice this question →
33
MCQmedium

A volume group vg_data has no free extents. An admin adds a new disk /dev/sdc and wants to extend the logical volume lv_data (ext4 filesystem) by 5GB. Which sequence of commands is correct?

A.pvcreate /dev/sdc → vgextend vg_data /dev/sdc → lvextend -L+5G /dev/vg_data/lv_data
B.pvcreate /dev/sdc → vgextend vg_data /dev/sdc → lvextend -L+5G /dev/vg_data/lv_data → resize2fs /dev/vg_data/lv_data
C.lvextend -L+5G /dev/vg_data/lv_data → pvcreate /dev/sdc → vgextend vg_data /dev/sdc
D.fdisk /dev/sdc → mkfs.ext4 /dev/sdc1 → pvcreate /dev/sdc1 → vgextend vg_data /dev/sdc1 → lvextend -L+5G /dev/vg_data/lv_data
AnswerB

This is the complete and correct workflow: pvcreate initializes the new disk for LVM, vgextend adds that capacity to the volume group, lvextend allocates the extra extents to lv_data, and resize2fs expands the ext4 filesystem to fill the enlarged LV. Each step operates on the next layer, and because ext4 supports online resizing, resize2fs can be run while the filesystem is mounted. The result is that both the logical volume and the filesystem now use the full 5G.

Why this answer

It follows the proper sequence: first create the physical volume with pvcreate, then extend the volume group with vgextend, then extend the logical volume with lvextend, and finally resize the ext4 filesystem with resize2fs. Since the filesystem is ext4, the resize2fs command is required after lvextend to make the additional space available to the filesystem.

Exam trap

The trap here is that candidates often forget the filesystem resize step for ext4, assuming lvextend alone is sufficient, or they incorrectly add unnecessary partitioning and filesystem creation steps, which wastes time and can cause errors in a real environment.

How to eliminate wrong answers

Option A is wrong because it omits the resize2fs step; after extending an ext4 logical volume, the filesystem must be resized to use the new space, otherwise the filesystem remains at its original size. Option C is wrong because it attempts to extend the logical volume before adding the physical volume and extending the volume group; the volume group has no free extents, so lvextend will fail immediately. Option D is wrong because it unnecessarily partitions the disk with fdisk and creates a filesystem with mkfs.ext4 on the partition before creating the physical volume; pvcreate expects a block device (partition or whole disk) without a filesystem, and the mkfs.ext4 step is redundant and incorrect for LVM.

Practice this question →
34
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 →
35
MCQhard

Which of the following is the correct way to persistently mount a filesystem using its UUID?

A.LABEL=1234 /mnt xfs defaults 0 0
B.UUID=1234 /mnt xfs defaults 0 0
C./dev/disk/by-uuid/1234 /mnt xfs defaults 0 0
D.PARTUUID=1234 /mnt xfs defaults 0 0
AnswerB

This is the correct fstab entry because UUID= directly references the filesystem's unique identifier, which is stored in the XFS superblock. The first field of an fstab line may use UUID= to make the mount permanent and independent of device names like /dev/sdb1, which can change across reboots. The remaining fields specify the mount point (/mnt), filesystem type (xfs), options (defaults), dump (0), and fsck pass (0), exactly as required.

Why this answer

The /etc/fstab entry uses the 'UUID=' prefix followed by the actual UUID value to persistently mount a filesystem. The kernel reads this line at boot time and resolves the UUID to the corresponding block device, ensuring the mount is consistent regardless of device name changes.

Exam trap

The trap here is that candidates confuse the 'UUID=' fstab syntax with the /dev/disk/by-uuid/ path, or mistakenly think 'LABEL=' or 'PARTUUID=' are interchangeable with UUID for filesystem identification.

How to eliminate wrong answers

Option A is wrong because it uses 'LABEL=' with a numeric string that looks like a UUID, but LABEL expects a filesystem label, not a UUID; the correct syntax for a label mount is 'LABEL=labelname'. Option C is wrong because it uses a device path under /dev/disk/by-uuid/ which is not a valid fstab format; fstab requires either 'UUID=' or 'LABEL=' for persistent identification, not a full path. Option D is wrong because 'PARTUUID=' refers to the partition table UUID (GPT partition unique identifier), not the filesystem UUID; while PARTUUID can be used for mounting, the question specifically asks for the filesystem UUID.

Practice this question →
36
MCQeasy

Which command initializes a disk partition as a physical volume for LVM?

A.fdisk
B.vgcreate
C.lvcreate
D.pvcreate
AnswerD

pvcreate is the correct command because it initializes a disk or partition as an LVM physical volume by writing an LVM label and metadata area at a specific offset on the device. This action assigns a unique PV ID and records the device in LVM's configuration, allowing it to later be added to a volume group with vgcreate. Without this initialization, other LVM tools cannot recognize the device, so pvcreate always precedes vgcreate and lvcreate in the LVM workflow.

Why this answer

`pvcreate` is the LVM command specifically designed to initialize a disk partition as a physical volume (PV), which is the first step in creating an LVM logical volume. Without a PV, LVM cannot manage the underlying block device. The command writes LVM metadata to the partition, marking it as available for inclusion in a volume group.

Exam trap

The trap here is that candidates confuse the LVM creation sequence and select `fdisk` (which only partitions the disk) instead of `pvcreate` (which initializes the partition for LVM use), or select `vgcreate` or `lvcreate` which operate on already-initialized physical volumes.

How to eliminate wrong answers

Option A is wrong because `fdisk` is a partitioning tool used to create or modify partition tables on a disk, not to initialize a partition as an LVM physical volume. Option B is wrong because `vgcreate` creates a volume group from one or more existing physical volumes, not initializes a partition as a PV. Option C is wrong because `lvcreate` creates a logical volume within an existing volume group, which requires physical volumes and a volume group to already exist.

Practice this question →
37
MCQeasy

An administrator adds a new 100GB disk to a RHEL 9 server. Which command should be used first to verify that the kernel has detected the new disk?

A.udevadm trigger
B.dmesg | grep sd
C.fdisk -l
D.lsblk
E.partprobe
AnswerD

lsblk reads block device information directly from sysfs and the kernel device model, listing every attached disk, partition, and relevant attributes such as size, type, and mountpoint. It works without elevated privileges and produces a clean, easily parseable tree that immediately shows the newly added 100GB disk via its NAME and SIZE columns. Because it reflects the live kernel view, lsblk is the standard, first-line tool for verifying that a disk is detected.

Why this answer

The `lsblk` command lists all block devices detected by the kernel, including newly added disks, by reading the sysfs filesystem. It is the safest and most direct way to verify kernel detection without requiring root privileges or triggering side effects. Option D is correct because it immediately shows whether the 100GB disk appears in the device list.

Exam trap

The trap here is that candidates often choose `dmesg | grep sd` (Option B) because they recall kernel messages for SCSI disks, but this fails for non-SCSI devices (e.g., NVMe, virtio) and may miss the disk if the buffer has rotated, making `lsblk` the universal and correct first check.

How to eliminate wrong answers

Option A is wrong because `udevadm trigger` forces the kernel to re-evaluate device events, but it does not verify detection; it is used to reprocess rules or simulate hotplug events, not to check current state. Option B is wrong because `dmesg | grep sd` may show kernel messages about SCSI disk detection, but it is not a reliable first verification step—messages can scroll off the ring buffer, and the new disk might use a different driver (e.g., nvme, vd) not matching 'sd'. Option C is wrong because `fdisk -l` requires root privileges and may not show the disk if the partition table is unreadable or the disk is not yet partitioned; it also risks modifying the disk if used incorrectly.

Option E is wrong because `partprobe` informs the kernel of partition table changes, not disk detection; it is used after partitioning, not to verify initial kernel recognition.

Practice this question →
38
MCQeasy

A system administrator needs to add a new 10GB disk to an existing volume group 'vgdata' to extend logical volumes. Which of the following is the correct sequence of commands?

A.pvcreate /dev/sdb, vgextend vgdata /dev/sdb, lvextend
B.vgextend vgdata /dev/sdb, pvcreate /dev/sdb, lvextend
C.pvcreate /dev/sdb, lvextend, vgextend vgdata /dev/sdb
D.lvextend, vgextend vgdata /dev/sdb, pvcreate /dev/sdb
AnswerA

pvcreate initializes /dev/sdb with LVM metadata, making it a physical volume that LVM can recognize. vgextend then adds that PV to the existing volume group vgdata, increasing its total allocatable space. Only after the VG has free physical extents can lvextend allocate from them to grow a logical volume, followed by a filesystem resize if needed. This dependency chain makes the order mandatory.

Why this answer

The proper sequence to add a new disk to an existing volume group is: first create a physical volume with `pvcreate /dev/sdb`, then extend the volume group with `vgextend vgdata /dev/sdb`, and finally extend the logical volume with `lvextend`. This order ensures the disk is initialized as a PV before it can be added to the VG, and the VG must have the new PV before the LV can be extended.

Exam trap

The trap here is that candidates may think `vgextend` can automatically initialize the disk, or that the order of commands does not matter, but LVM strictly requires `pvcreate` before `vgextend` and `vgextend` before `lvextend`.

How to eliminate wrong answers

Option B is wrong because `vgextend` is attempted before `pvcreate`, but a disk must be initialized as a physical volume before it can be added to a volume group. Option C is wrong because `lvextend` is performed before `vgextend`, but the volume group does not yet contain the new physical volume, so the extension would fail. Option D is wrong because both `lvextend` and `vgextend` are attempted before `pvcreate`, violating the dependency that the disk must first be a PV, then added to the VG, then used to extend the LV.

Practice this question →
39
MCQeasy

Refer to the exhibit. When the system boots, which filesystem will be mounted after the root filesystem?

A.None
B.Swap
C.Both /boot and swap
D./boot
AnswerD

According to the exhibit, /etc/fstab has the root filesystem (/) as its first entry and /boot as the second. Once the kernel mounts root, systemd processes the fstab entries in order, mounting /boot next. /boot is a dedicated filesystem that holds the kernel and initramfs, so it must be available for the boot process to continue.

Why this answer

According to the default boot process in RHEL 8/9, the initramfs mounts the root filesystem first, then the systemd-based init process mounts the /boot filesystem (if it is a separate partition) as specified in the /etc/fstab file. The root filesystem is mounted by the kernel or initramfs, and subsequent filesystems like /boot are mounted by systemd based on fstab entries.

Exam trap

The trap here is that candidates often confuse swap with a filesystem, but swap is a raw block device for memory paging and is not mounted; it is activated via swapon, so it does not count as a mounted filesystem in this context.

How to eliminate wrong answers

Option A is wrong because the system does mount additional filesystems after root, such as /boot, as defined in /etc/fstab. Option B is wrong because swap is not a filesystem in the traditional sense; it is a swap area that is activated by swapon, not mounted as a filesystem, and it is typically activated after filesystem mounts. Option C is wrong because while /boot is mounted, swap is not mounted as a filesystem; it is activated separately, and the question specifically asks about filesystem mounting.

Practice this question →
40
MCQhard

The /data filesystem is at 99% capacity. The LVM setup shows that the volume group has 50GB free space, but the logical volume is only 100GB. What is the correct sequence of commands to increase the filesystem to use all available space in the volume group?

A.lvextend -L 50G /dev/mapper/vg01-data && xfs_growfs /dev/mapper/vg01-data
B.lvextend -L +50G /dev/mapper/vg01-data && xfs_growfs /data
C.lvextend -L +50G /dev/mapper/vg01-data && resize2fs /dev/mapper/vg01-data
D.xfs_growfs /dev/mapper/vg01-data && lvextend -L +50G /dev/mapper/vg01-data
AnswerB

This is correct because `lvextend -L +50G` explicitly adds 50G of space to the existing logical volume, expanding the LV to accommodate more data. After the LV is enlarged, `xfs_growfs /data` is executed against the mount point, which is the proper way to grow an XFS filesystem online. `xfs_growfs` automatically expands the filesystem to fill the entire LV, so no size argument is required, and the order is correct because the filesystem can only be grown after the underlying block device has been extended.

Why this answer

The volume group has 50GB free space, so you need to extend the logical volume by +50GB (not to 50GB) using `lvextend -L +50G`, and then grow the XFS filesystem with `xfs_growfs /data` (the mount point, not the block device). The `+` sign indicates an addition to the current size, while omitting it would set an absolute size.

Exam trap

The trap here is that candidates confuse the `-L` syntax (absolute vs. relative size) and mistakenly use `resize2fs` for XFS, or reverse the order of commands.

How to eliminate wrong answers

Option A is wrong because `lvextend -L 50G` sets the logical volume to exactly 50GB, which would shrink it from 100GB to 50GB, losing data and not using the free space; also `xfs_growfs` should target the mount point, not the block device. Option C is wrong because `resize2fs` is for ext2/3/4 filesystems, not XFS; XFS requires `xfs_growfs`. Option D is wrong because the order is reversed: you must extend the logical volume first with `lvextend` before growing the filesystem with `xfs_growfs`.

Practice this question →
41
Multi-Selectmedium

Which two are required to create a logical volume? (Choose two.)

Select 2 answers
A.Physical volume
B.Mount point
C.Filesystem
D.Partition
E.Volume group
AnswersA, E

A physical volume (PV) is a disk or partition that has been initialized with LVM metadata using pvcreate. This raw storage device provides the fundamental capacity that LVM pools into a volume group. Without at least one PV, there is no physical storage for LVM to manage, and creating a logical volume directly from a raw disk is impossible—the disk must first be a PV.

Why this answer

A physical volume (PV) is required because it is the underlying storage device (e.g., a disk or partition) that LVM uses as a building block. Without a PV, there is no raw storage to allocate to a volume group. The volume group (VG) is then created from one or more PVs, and logical volumes (LVs) are carved from the VG.

Both are mandatory steps in the LVM workflow.

Exam trap

The trap here is that candidates confuse the steps of creating a logical volume with the steps of making it usable (mount point and filesystem), leading them to select options B or C as required prerequisites.

Practice this question →
42
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 →
43
MCQeasy

A junior admin receives a ticket: 'The /var partition is filling up quickly. The server has an extra 100GB disk /dev/sdb. The /var filesystem is on logical volume lv_var in volume group vg_system. Currently, vg_system has no free extents. The admin's plan: create a new physical volume on /dev/sdb, extend vg_system, extend lv_var, and resize the filesystem. He runs: pvcreate /dev/sdb; vgextend vg_system /dev/sdb; lvextend -L+100G /dev/vg_system/lv_var; resize2fs /dev/vg_system/lv_var. The system reports error: 'resize2fs: Invalid argument while trying to open /dev/vg_system/lv_var'. What is the most likely mistake?

A.He should have used lvresize instead of lvextend.
B.He forgot to run partprobe after pvcreate.
C.The lvextend command failed because vg_system has no free extents.
D.He used resize2fs instead of xfs_growfs because /var is typically XFS.
AnswerD

On RHEL 8 and RHEL 9, the default filesystem for /var (and other directories) is XFS, not ext4. After extending the logical volume, the filesystem must be grown to use the new space, and the proper command for that is xfs_growfs, not resize2fs—resize2fs only works on ext2/ext3/ext4 filesystems and will fail or do nothing against XFS. Therefore, the admin's use of resize2fs is exactly the mistake that would leave /var appearing full even though the LV was successfully expanded.

Why this answer

The error 'resize2fs: Invalid argument while trying to open /dev/vg_system/lv_var' indicates that the filesystem on lv_var is not ext2/3/4 but likely XFS. RHEL 8/9 defaults to XFS for /var, and XFS requires xfs_growfs (which operates on a mount point, not a block device) instead of resize2fs. Using resize2fs on an XFS filesystem produces this exact error.

Exam trap

The trap here is that candidates assume all Linux filesystems use resize2fs, but EX200 tests the RHEL default of XFS, which requires xfs_growfs and a mount point argument, not a block device.

How to eliminate wrong answers

Option A is wrong because lvextend and lvresize are functionally equivalent for extending a logical volume; lvextend is a subset of lvresize and does not cause the error. Option B is wrong because partprobe is unnecessary after pvcreate on a whole disk (no partition table); pvcreate directly writes LVM metadata to /dev/sdb, and the kernel recognizes it without partprobe. Option C is wrong because the lvextend command would have failed with a 'no free extents' error before reaching resize2fs; the admin successfully extended lv_var (as shown by the error occurring at resize2fs), meaning vgextend provided free extents.

Practice this question →
44
MCQhard

An administrator wants to encrypt a new partition /dev/sdc1 using LUKS. Which command sequence is correct?

A.mkfs.ext4 /dev/sdc1; cryptsetup luksFormat /dev/sdc1; cryptsetup open /dev/sdc1 secret; mount /dev/mapper/secret /mnt
B.cryptsetup open /dev/sdc1 secret; mkfs.ext4 /dev/mapper/secret; cryptsetup luksFormat /dev/mapper/secret; mount /dev/mapper/secret /mnt
C.cryptsetup luksFormat /dev/sdc1; mkfs.ext4 /dev/sdc1; cryptsetup open /dev/sdc1 secret; mount /dev/mapper/secret /mnt
D.cryptsetup open /dev/sdc1 secret; cryptsetup luksFormat /dev/mapper/secret; mkfs.ext4 /dev/mapper/secret; mount /dev/mapper/secret /mnt
E.cryptsetup luksFormat /dev/sdc1; cryptsetup open /dev/sdc1 secret; mkfs.ext4 /dev/mapper/secret; mount /dev/mapper/secret /mnt
AnswerE

This is the correct sequence. First, cryptsetup luksFormat /dev/sdc1 writes the LUKS header and initial encryption metadata to the raw partition, binding it to a passphrase. Next, cryptsetup open /dev/sdc1 secret authenticates the passphrase and creates /dev/mapper/secret as a decrypted block device that transparently encrypts all writes and decrypts all reads. Then mkfs.ext4 on /dev/mapper/secret creates a normal ext4 filesystem inside the encrypted container, so every filesystem block is stored on /dev/sdc1 in ciphertext; finally, mount /dev/mapper/secret /mnt attaches that decrypted filesystem. The order is essential: format the raw device first, map it, and only then create the filesystem on the mapped device.

Why this answer

The proper sequence for encrypting a new partition with LUKS is: first initialize the LUKS header on the block device with `cryptsetup luksFormat`, then open the encrypted device to create a mapping under `/dev/mapper/`, then create a filesystem on the mapped device (not the raw block device), and finally mount the mapped device. This ensures the filesystem is built on top of the encrypted layer, not on the unencrypted partition.

Exam trap

Red Hat often tests the misconception that you can create a filesystem directly on the raw partition after `luksFormat` (Option C) or that you should open the device before formatting it with LUKS (Option B), leading candidates to confuse the order of operations for LUKS encryption.

How to eliminate wrong answers

Option A is wrong because it creates a filesystem on the raw `/dev/sdc1` before LUKS encryption, which would leave the filesystem unencrypted and the subsequent `luksFormat` would overwrite it. Option B is wrong because it attempts to open a LUKS device that hasn't been formatted yet (`cryptsetup open` before `luksFormat`), and then tries to `luksFormat` the mapper device instead of the raw block device. Option C is wrong because it creates a filesystem directly on `/dev/sdc1` after `luksFormat`, which would destroy the LUKS header and leave data unencrypted.

Option D is wrong because it opens a non-existent LUKS container (no `luksFormat` first) and then tries to `luksFormat` the mapper device, which is not the correct target for initialization.

Practice this question →
45
Drag & Dropmedium

Order the steps to create a new LVM logical volume of 5 GiB named 'lv_data' in volume group 'vg_data'.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence for creating an LVM logical volume is: first create physical volumes (PVs) with pvcreate, then the volume group (VG) with vgcreate, then the logical volume (LV) with lvcreate, then a filesystem on the LV with mkfs, and finally mount it. Any deviation from this order will fail because each step depends on the previous ones.

Practice this question →
46
MCQeasy

A RHEL 8 system has an ext4 filesystem on /dev/sdb1 mounted at /backup. The admin runs out of space and wants to extend the filesystem. He adds a new disk /dev/sdc, creates a partition /dev/sdc1 (all space), adds it to LVM by creating a PV and extending the VG that contains the LV for /backup. He then extends the logical volume with lvextend -L+20G /dev/vg_backup/lv_backup. The command succeeds, but the filesystem still shows the old size. What did he forget to do?

A.Reboot the system to recognize the new space.
B.Resize the filesystem using resize2fs.
C.Run lvchange -ay to activate the logical volume.
D.Unmount the filesystem before extending the LV.
AnswerB

Running resize2fs on the logical volume is the mandatory second step because lvextend only expands the block device, not the filesystem. The ext4 superblock's block count is still set to the old capacity, and the resize2fs utility updates the on-disk metadata and grows the filesystem to consume the newly available blocks. Because the filesystem is already mounted, the online resize can be done with no downtime, using the device path such as /dev/vg/lv.

Why this answer

When extending an LVM logical volume, the `lvextend` command only expands the logical volume's block device, not the filesystem residing on it. After extending the LV, the admin must run `resize2fs` (for ext4) to resize the filesystem to match the new LV size. Without this step, the kernel still sees the old filesystem metadata, so `df -h` reports the original size.

Exam trap

The trap here is that candidates assume `lvextend` automatically resizes the filesystem, but it only extends the logical volume; a separate filesystem resize command is required for non-LVM-aware filesystems like ext4.

How to eliminate wrong answers

Option A is wrong because rebooting is unnecessary; the kernel recognizes the new LV size immediately after `lvextend`, but the filesystem itself must be resized with `resize2fs`. Option C is wrong because `lvchange -ay` activates the LV, but the LV is already active (the `lvextend` succeeded), so this command is irrelevant. Option D is wrong because ext4 filesystems can be resized online (mounted) with `resize2fs`; unmounting is not required for extending, only for shrinking.

Practice this question →
47
Multi-Selecthard

Which THREE options are valid when creating a new partition with the 'parted' command? (Choose three.)

Select 3 answers
A.Setting the partition's UUID
B.Setting the partition's bootable flag
C.Setting the partition's name (GPT only)
D.Mounting the partition to a directory
E.Setting the partition type (e.g., ext4)
AnswersB, C, E

Setting the partition's bootable flag is a valid operation when creating a partition with parted, as the 'set' command can toggle flags such as 'boot' on MBR partitions. This flag marks the partition as active, which is required for legacy BIOS booting to find the boot loader. It is purely a partition table attribute and does not affect the filesystem, so it can be done during or after partition creation without any formatting implications.

Why this answer

The 'parted' command can set the bootable flag on a partition using the 'set' command (e.g., 'set 1 boot on'). This flag is used by legacy BIOS bootloaders to identify the active partition, and it is a standard operation in MBR and GPT partition tables.

Exam trap

The trap here is that candidates confuse setting the partition type label (e.g., 'ext4') in parted with actually formatting the partition, or they assume parted can mount or assign UUIDs, which are filesystem-level tasks outside parted's scope.

Practice this question →
48
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 →
49
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 →
50
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 →
51
MCQhard

A system administrator tries to mount a filesystem but receives the error: 'mount: /dev/sdb1 is already mounted or /data busy'. The filesystem is not listed in the mount output. What is the most likely cause?

A.The kernel does not have the filesystem driver loaded
B.The mount point /data is in use by a process
C.The device is already mounted on another mount point
D.The filesystem is corrupted
AnswerB

The kernel refuses to mount over a directory that is currently being used as a process's current working directory or that has open file descriptors referencing it. Mounting would hide the existing directory contents, creating a security and consistency risk, so the kernel returns a 'mount point is busy' (EBUSY) error. This matches the administrator's symptom, making it the correct explanation.

Why this answer

The error message 'mount: /dev/sdb1 is already mounted or /data busy' indicates that the mount point /data is currently in use by a process, preventing the mount operation. Even though the filesystem is not listed in the mount output, a process may have an open file descriptor or be using /data as its current working directory, which keeps the directory busy. The 'lsof' or 'fuser' commands can be used to identify the offending process.

Exam trap

Red Hat often tests the distinction between 'device busy' (device already mounted elsewhere) and 'mount point busy' (directory in use), leading candidates to incorrectly assume the device is already mounted when the error actually points to the mount point being active.

How to eliminate wrong answers

Option A is wrong because if the kernel lacked the filesystem driver, the error would be something like 'mount: unknown filesystem type' or 'mount: /dev/sdb1: can't read superblock', not a 'busy' message. Option C is wrong because if the device were already mounted on another mount point, it would appear in the mount output (e.g., via 'mount' or 'findmnt'), and the error would typically say 'device is busy' or 'already mounted', but the specific mention of '/data busy' points to the mount point, not the device. Option D is wrong because a corrupted filesystem would produce errors like 'mount: /dev/sdb1: can't read superblock' or 'mount: wrong fs type, bad option, bad superblock', not a 'busy' condition.

Practice this question →
52
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 →
53
Multi-Selecthard

Which TWO of the following are required steps when migrating a logical volume from one physical volume to another in the same volume group?

Select 2 answers
A.Delete and recreate the logical volume on the new physical volume
B.Add the new physical volume to the volume group with vgextend if not already present
C.Remove the source physical volume from the volume group with vgreduce after migration
D.Use pvmove to relocate the physical extents from the source to the target PV
E.Extend the logical volume to include the new physical volume
AnswersC, D

After pvmove has successfully relocated all allocated physical extents off the source PV, that PV becomes empty and can be removed from the volume group with vgreduce. This step is essential to shrink the VG's member list and to permanently detach the old physical volume without affecting logical volumes that now reside elsewhere. Without vgreduce, the empty PV would remain part of the VG, preventing its physical removal from the system.

Why this answer

After using pvmove to relocate all physical extents from the source physical volume to the target, you must remove the source PV from the volume group using vgreduce to clean up the volume group metadata and free the device for other use. This step ensures the volume group no longer references the now-empty source PV.

Exam trap

Red Hat often tests the misconception that you must extend the logical volume (Option E) or delete/recreate it (Option A) to move data between PVs, when in fact pvmove handles the migration transparently without LV modification.

Practice this question →
54
MCQeasy

Which command creates a 2GB logical volume named 'lvdata' in the volume group 'vgdata'?

A.lvcreate -L 2G -n lvdata vgdata
B.lvcreate -n vgdata -L 2G lvdata
C.lvcreate -n lvdata -s 2G vgdata
D.lvcreate -l 2G -n lvdata vgdata
AnswerA

This is the correct invocation. The -L 2G option explicitly sets the logical volume's size to 2 gigabytes, -n lvdata assigns the logical volume name, and vgdata is the volume group from which the space is allocated. The syntax matches lvcreate(8): lvcreate [options] volume_group.

Why this answer

The `lvcreate` command with `-L 2G` specifies the size in gigabytes, `-n lvdata` sets the logical volume name, and `vgdata` is the volume group in which the logical volume is created. This syntax follows the standard LVM2 command structure for creating a logical volume of a specified size within an existing volume group.

Exam trap

The trap here is confusing the `-L` (size in units) and `-l` (number of extents) flags, leading candidates to incorrectly use `-l` with a size suffix, which is syntactically invalid in LVM2.

How to eliminate wrong answers

Option B is wrong because the arguments are reversed: `-n vgdata` incorrectly assigns the volume group name as the logical volume name, and `lvdata` is placed as the volume group argument, which would cause a syntax error or create a logical volume in the wrong context. Option C is wrong because `-s 2G` is used for creating a snapshot (`-s` flag) or specifying a size in a different context, not for creating a standard logical volume with a size of 2GB; the correct flag for size is `-L`. Option D is wrong because `-l 2G` uses the lowercase `-l` flag, which expects extents (number of logical extents), not a size in gigabytes; using `-l` with a unit like `G` is invalid and would result in an error.

Practice this question →
55
MCQeasy

Which single command shows the UUID of a filesystem on /dev/sdb1?

A.df -h
B.mount
C.blkid /dev/sdb1
D.fdisk -l
AnswerC

blkid is the util-linux utility that directly reads the superblock of a block device to display its UUID, filesystem type, and label. Running blkid /dev/sdb1 causes it to inspect that specific partition and print the filesystem UUID, making it the only command here that accomplishes the task. This works whether or not /dev/sdb1 is mounted, because blkid queries the raw device metadata.

Why this answer

The `blkid /dev/sdb1` command queries the libblkid library to read the filesystem metadata directly from the block device, displaying attributes including the UUID (Universally Unique Identifier) stored in the superblock. This is the standard, single-purpose command to retrieve the UUID of a specific partition.

Exam trap

The trap here is that candidates often confuse partition table tools like `fdisk` with filesystem metadata tools, or assume `mount` shows UUIDs by default, when in fact only `blkid` (or `lsblk -f`) directly queries the filesystem superblock for the UUID.

How to eliminate wrong answers

Option A is wrong because `df -h` shows human-readable disk space usage for mounted filesystems, not UUIDs. Option B is wrong because `mount` (without options) lists currently mounted filesystems and their mount points, but does not display UUIDs unless combined with `-l` or `-U` flags, and even then it is not the direct command for UUID retrieval. Option D is wrong because `fdisk -l` lists partition tables (sizes, types, start/end sectors) but does not show filesystem UUIDs, which are stored in the filesystem superblock, not the partition table.

Practice this question →
56
MCQmedium

Refer to the exhibit. An administrator runs 'mount -o remount,ro /data' and then 'mount' shows /data as read-only. Later, the system is rebooted. What is the state of /data after reboot?

A./data will be mounted read-write because fstab specifies defaults (rw).
B./data will be mounted read-only because the remount persists across reboots.
C./data will not be mounted because the filesystem is marked as read-only.
D./data will be mounted read-only because the kernel remembers the last mount state.
AnswerA

The mount -o remount command reapplies the options currently listed in /etc/fstab for that filesystem without fully unmounting it. Since fstab for /data contains the defaults option, which implies rw (read-write), the remounted filesystem will be writable. This is a runtime operation only — fstab is the persistent source of truth, so after a reboot the same rw state would be applied again anyway.

Why this answer

The `mount -o remount,ro /data` command changes the mount state only for the current session; it does not modify the `/etc/fstab` entry. The `defaults` mount option in fstab implies `rw` (read-write). After a reboot, the system reads fstab and mounts `/data` according to its persistent configuration, which is read-write.

Exam trap

Red Hat often tests the misconception that runtime mount options persist after a reboot, leading candidates to forget that `/etc/fstab` is the authoritative source for mount behavior at boot.

How to eliminate wrong answers

Option B is wrong because `remount` does not persist across reboots; mount options applied at runtime are lost after a reboot unless they are written to `/etc/fstab` or a systemd mount unit. Option C is wrong because a read-only remount does not mark the filesystem itself as read-only; it only changes the current mount's access mode, and the filesystem remains fully functional for a subsequent read-write mount. Option D is wrong because the kernel does not remember mount states across reboots; mount information is ephemeral and is re-established from fstab or initramfs during boot.

Practice this question →
57
MCQhard

Refer to the exhibit. An administrator attempts to mount all filesystems using 'mount -a' and receives an error. What is the most likely cause?

A.The ext4 filesystem on /dev/vdb1 is corrupted.
B.The filesystem type specified in /etc/fstab is incorrect.
C.The entry for /dev/vdb1 in /etc/fstab uses a device name that does not exist.
D.The mount point /mnt/data does not exist.
AnswerC

The fstab entry specifies the device path /dev/vdb1, but that block device is not present in the system (e.g., the disk was removed, or the kernel assigned a different name after a reboot). The error message 'can't find /dev/vdb1' directly states that the kernel cannot resolve that device path, which is why mount -a fails. This demonstrates a common pitfall of using static device names in fstab; using persistent identifiers like UUID= or LABEL= would avoid this issue.

Why this answer

The error occurs because the entry in /etc/fstab for /dev/vdb1 references a device name that does not exist on the system. When 'mount -a' is executed, it reads /etc/fstab and attempts to mount each filesystem; if the device node is missing (e.g., due to a typo, incorrect kernel name, or the device not being attached), the mount fails with an error like 'mount: special device /dev/vdb1 does not exist'. This is the most likely cause given the scenario.

Exam trap

Red Hat RHCSA often tests the distinction between errors caused by a missing device node versus a missing mount point or filesystem corruption, and candidates mistakenly assume the error is due to a missing mount point or a corrupted filesystem without reading the exact error message.

How to eliminate wrong answers

Option A is wrong because a corrupted ext4 filesystem would produce a different error (e.g., 'mount: /dev/vdb1: can't read superblock' or 'wrong fs type'), not a 'device does not exist' message. Option B is wrong because an incorrect filesystem type in /etc/fstab would result in an error like 'mount: wrong fs type, bad option, bad superblock', not a missing device error. Option D is wrong because if the mount point /mnt/data did not exist, the error would be 'mount: mount point /mnt/data does not exist', which is a distinct message from the device-not-found error.

Practice this question →
58
Matchingmedium

Match each systemd unit type to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Manages a daemon or service process

Groups units to define system states (runlevels)

Enables socket-based activation for services

Triggers activation of other units on a schedule

Why these pairings

Systemd unit types define system resources: service (daemons), socket (IPC), target (group/synchronization), timer (scheduled activation). Common confusions involve mixing mount with service and target with timer.

Practice this question →
59
MCQmedium

An administrator wants to create a swap partition on /dev/sdb1. After creating the partition with fdisk, which command sets up the swap area?

A.mkswap /dev/sdb1
B.mkfs.swap /dev/sdb1
C.swapon /dev/sdb1
D.swapoff /dev/sdb1
AnswerA

mkswap /dev/sdb1 is the correct initial step because it writes the swap signature (UUID and swap superblock) onto the partition, turning it into a usable swap area. Once this initialization is complete, the swap space can be activated with swapon. Without mkswap, the partition lacks the metadata required for the kernel to recognize it as swap.

Why this answer

The correct command to set up a swap area on a partition is `mkswap /dev/sdb1`. This command initializes the partition with a swap signature, writing the necessary metadata (such as the swap superblock and version information) so the kernel can later use it as swap space. Without running `mkswap`, the partition is not recognized as a valid swap device.

Exam trap

Red Hat often tests the distinction between preparing a swap area (`mkswap`) and activating it (`swapon`), so candidates mistakenly choose `swapon` thinking it both creates and enables the swap.

How to eliminate wrong answers

Option B is wrong because `mkfs.swap` is not a valid command; the proper tool for creating a swap filesystem is `mkswap`, not a `mkfs.*` variant. Option C is wrong because `swapon` activates an already-prepared swap area; it does not set up or initialize the swap signature on the partition. Option D is wrong because `swapoff` deactivates an active swap device, which is the opposite of what is needed to prepare a new swap area.

Practice this question →
60
MCQeasy

Which command shows the amount of disk space used and available on each mounted filesystem?

A.fdisk -l
B.df -h
C.du -sh
D.lsblk
AnswerB

The df command, with the -h (human-readable) flag, is the standard RHCSA tool for reporting disk space usage and availability. It reads the filesystem superblock and kernel tables for every mounted filesystem, outputting total, used, available, and mount point columns (e.g., /dev/sda1 50G 20G 30G /). This directly answers the question: it shows both the amount of space used and the amount still available, which is why it is the correct choice.

Why this answer

The `df -h` command displays disk space usage for all mounted filesystems, showing total, used, and available space in human-readable format (e.g., GB, MB). This directly answers the question about disk space on each mounted filesystem.

Exam trap

The trap here is that candidates confuse `df` (filesystem-level space) with `du` (directory-level usage) or `fdisk` (partition table), leading them to pick a command that does not report available space on mounted filesystems.

How to eliminate wrong answers

Option A is wrong because `fdisk -l` lists partition tables on block devices, not disk space usage on mounted filesystems; it shows partition geometry and types, not available space. Option C is wrong because `du -sh` summarizes disk usage of files and directories, not filesystem-level available space; it reports space consumed by specific paths, not mounted filesystems. Option D is wrong because `lsblk` lists block devices and their attributes (e.g., size, type, mount point) but does not show used or available disk space on mounted filesystems; it omits usage percentages and available space.

Practice this question →
61
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 →
62
Multi-Selecteasy

Which TWO commands can be used to create a physical volume for LVM? (Choose exactly two.)

Select 2 answers
A.mkfs.ext4
B.pvcreate /dev/sdb1
C.pvcreate /dev/sdb
D.lvcreate
E.vgcreate
AnswersB, C

pvcreate /dev/sdb1 is the correct command to initialize a specific partition as a physical volume. It writes a PV label to the partition and records its metadata, allowing it to be later added to a volume group with vgcreate or vgextend. This is the standard approach when you want to dedicate only a portion of a disk to LVM while keeping other partitions for different purposes.

Why this answer

The `pvcreate` command initializes a block device (such as a partition or an entire disk) for use as a physical volume in LVM. Option B targets a partition `/dev/sdb1`, and option C targets the whole disk `/dev/sdb` — both are valid devices that can be initialized as physical volumes, as LVM can operate on either.

Exam trap

Red Hat often tests the distinction between initializing a partition (`/dev/sdb1`) versus a whole disk (`/dev/sdb`) — both are valid with `pvcreate`, but candidates may incorrectly think only partitions can be used, or that `mkfs.ext4` can somehow create an LVM physical volume.

Practice this question →
63
Multi-Selectmedium

Which TWO statements about Logical Volume Manager (LVM) metadata are correct?

Select 2 answers
A.The 'pvck' command can be used to check physical volume metadata.
B.The 'pvs' command can repair corrupted metadata.
C.The 'fsck' tool is used to verify LVM metadata.
D.Metadata is stored in the volume group descriptor area (VGDA) on each physical volume.
E.LVM metadata is stored in /etc/lvm directory.
AnswersA, D

The pvck command is a specialized LVM utility designed to verify the consistency and integrity of physical volume metadata located in the metadata areas on a PV. It can also dump the raw metadata contents for debugging purposes, but it only checks and displays; it does not repair or rewrite the metadata. Use it when you suspect corruption on a PV.

Why this answer

The 'pvck' command is specifically designed to check the metadata of physical volumes in LVM. It verifies the consistency and integrity of the PV metadata, including the volume group descriptor area (VGDA), without making changes. This is a diagnostic tool used before attempting repairs.

Exam trap

The trap here is that candidates confuse the role of 'pvs' (a display tool) with a repair tool, or mistakenly think LVM metadata is stored in a configuration directory like /etc/lvm, when it is actually stored on the physical volumes themselves.

Practice this question →
64
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 →
65
Drag & Dropmedium

Put the steps to configure a new swap partition of 2 GiB on /dev/sdc1 and enable it in order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Swap configuration involves partitioning, formatting, enabling, and making persistent in fstab.

Practice this question →
66
MCQmedium

After adding a new disk to a volume group, which command is used to extend a logical volume by 2GB?

A.vgextend vg /dev/sdb
B.resize2fs /dev/vg/lv
C.lvextend -L +2G /dev/vg/lv
D.pvcreate /dev/sdb
AnswerC

lvextend -L +2G /dev/vg/lv is the correct command because it directly increases the size of the logical volume by 2 GiB, consuming free physical extents from the volume group that were made available after adding the new disk. This is the LVM-level operation needed to make the additional disk space usable. After extending the LV, you must separately resize the filesystem to actually use the new space.

Why this answer

After adding a new disk to a volume group, the `lvextend -L +2G /dev/vg/lv` command extends the logical volume by exactly 2 GB. The `-L +2G` syntax specifies the additional size to add, and the target is the logical volume path. This is the standard LVM command for increasing logical volume size without specifying a physical extent range.

Exam trap

The trap here is that candidates confuse the commands for extending a logical volume (`lvextend`) with those for adding a disk to a volume group (`vgextend`) or initializing a disk (`pvcreate`), and they often forget that `resize2fs` operates on the filesystem, not the logical volume itself.

How to eliminate wrong answers

Option A is wrong because `vgextend vg /dev/sdb` adds a physical volume to a volume group, but it does not extend a logical volume; it only makes the new disk's space available to the volume group. Option B is wrong because `resize2fs /dev/vg/lv` resizes an ext2/ext3/ext4 filesystem, not the logical volume itself; it is used after extending the logical volume to make the filesystem aware of the new space. Option D is wrong because `pvcreate /dev/sdb` initializes the disk as a physical volume, but it does not extend a logical volume; it is a prerequisite step before adding the disk to a volume group.

Practice this question →
67
MCQmedium

A filesystem reports 0% free space in df -h, but when checking the directory size with du -sh, it shows much less usage. What is the most likely cause?

A.Filesystem is corrupted
B.The disk has bad sectors
C.Deleted files still held open by processes
D.Filesystem is mounted with noexe
AnswerC

When a file is deleted (unlinked) but a process still holds an open file descriptor to it, the inode and its data blocks remain allocated on disk. The filesystem does not reclaim those blocks until the last open handle is closed, yet the directory entry is removed immediately, so df still shows the space as consumed while `ls` no longer lists the file. This commonly occurs with log files or temporary files that are unlinked while still being written; running `lsof +L1` will reveal such deleted-but-open files and their associated processes.

Why this answer

When a file is deleted while a process still holds an open file descriptor to it, the file's data blocks remain allocated on disk and are not freed until the process closes the descriptor. The `df` command reports disk usage based on the filesystem's block allocation, which still counts those blocks as used, while `du` calculates usage by walking the directory tree and cannot see the deleted file's data, leading to the discrepancy.

Exam trap

Red Hat often tests the misconception that `df` and `du` should always match, leading candidates to suspect corruption or hardware failure, when the real cause is the classic 'deleted but open file' scenario.

How to eliminate wrong answers

Option A is wrong because filesystem corruption typically causes errors or inconsistencies in `df` or `du` output, not a specific mismatch where `df` shows 0% free while `du` shows less usage; corruption would likely produce I/O errors or unmountable filesystems. Option B is wrong because bad sectors are a hardware issue that causes read/write errors and data loss, not a discrepancy between `df` and `du`; the filesystem would still report allocated blocks correctly. Option D is wrong because the `noexec` mount option prevents execution of binaries on the filesystem but has no effect on disk space reporting or file allocation; it does not cause `df` to show full usage while `du` shows less.

Practice this question →
68
MCQhard

Refer to the exhibit. After re-adding the disk, the recovery process shows 0% progress and remains at 0. What is the most likely cause?

A.The array is in a degraded state and the recovery is waiting for the resync to start, but the event count is zero; the array may need to be forced to start recovery.
B.The recovery is complete because the data is already synchronized.
C.The device /dev/sdb1 was not properly removed; it still holds old metadata that conflicts.
D.The new disk /dev/sdb1 has a different size than the original, causing the recovery to stall.
AnswerC

This option is wrong because the device was intentionally removed and re-added: the mdadm --remove operation successfully detached /dev/sdb1 and cleared its slot in the array. When a disk is re-added, mdadm treats it as a new device and writes fresh metadata to it, so there is no old conflicting metadata left behind. The output shows the re-added disk as device number 2, which is consistent with a clean addition rather than a metadata conflict. A conflicting device would typically be rejected with an 'mdadm --add' error, not accepted and left waiting for recovery.

Why this answer

When a disk is re-added to a RAID array without first being properly removed (e.g., no mdadm --remove), it retains old superblock metadata. This conflicting metadata prevents mdadm from automatically starting the resync, leaving recovery at 0%. Clearing the superblock with mdadm --zero-superblock and then adding the disk as a new device will allow recovery to proceed.

Exam trap

A common mistake is to assume the array is faulty or needs force assembly, but the usual reason is stale metadata from the missing device.

How to eliminate wrong answers

Option B is wrong because if recovery were complete, the progress would show 100% or the array would be in a clean state, not 0% stuck; the data is not synchronized as the event count mismatch prevents any resync. Option C is wrong because old metadata on /dev/sdb1 would cause the array to reject the disk or show a mismatch error, not a stalled 0% recovery; mdadm would typically refuse to add the disk or require `--force` to overwrite metadata. Option D is wrong because a different disk size would cause a failure to add the disk or a size mismatch error, not a stalled recovery at 0%; mdadm checks size compatibility before adding and would report an error if sizes differ.

Practice this question →
69
Multi-Selectmedium

Which THREE filesystem types are natively supported in RHEL 8/9 for local storage? (Choose exactly three.)

Select 3 answers
A.vfat
B.ntfs
C.xfs
D.btrfs
E.ext4
AnswersA, C, E

vfat is natively supported in RHEL because the kernel includes the vfat driver, primarily for compatibility with EFI System Partitions and Windows-formatted removable media. It supports long filenames but lacks advanced features like permissions and journaling. This support is maintained specifically for interoperability, not as a primary data filesystem.

Why this answer

A is correct because vfat (FAT32) is natively supported in RHEL 8/9 for local storage, primarily for compatibility with UEFI boot partitions and removable media. The kernel includes the vfat module, and mkfs.vfat is available from the dosfstools package, allowing creation and mounting of FAT32 filesystems without additional software.

Exam trap

The trap here is that candidates often assume Btrfs is supported because it is common in other distributions, but Red Hat explicitly deprecated and removed it from RHEL 8/9, making ext4 and XFS the correct choices alongside vfat for UEFI boot.

Practice this question →
70
MCQhard

During a system audit, an administrator finds that a filesystem mounted at /srv/data with ext4 is not showing in /etc/fstab. Further investigation reveals that the underlying device is an LVM logical volume lv_data in vg_data. The administrator wants to ensure the filesystem is mounted at boot. He adds an entry to /etc/fstab using the device path /dev/vg_data/lv_data. On reboot, the system fails to mount the filesystem and enters emergency mode. The logical volume and filesystem are intact. What is the most likely reason for the failure?

A.The device path /dev/vg_data/lv_data is a symlink that may not be available; use /dev/mapper/vg_data-lv_data or UUID.
B.The mount point /srv/data does not exist.
C.The filesystem type specified in fstab is incorrect.
D.The logical volume is not activated at boot because lvm2-lvmetad is not running.
AnswerA

The path /dev/vg_data/lv_data is not a static device node but a symlink created by LVM's udev rules after the volume group is activated. In early boot, especially when the root filesystem is on an initramfs, activation may occur after the mount attempt, leaving that symlink unavailable; /dev/mapper/vg_data-lv_data is created by device-mapper itself and is more reliable, and a filesystem UUID avoids device-name dependence altogether.

Why this answer

The device path /dev/vg_data/lv_data is a symbolic link created by LVM that may not be available early in the boot process because the device mapper nodes are not yet created. The correct approach is to use the stable /dev/mapper/vg_data-lv_data path or the filesystem UUID in /etc/fstab to ensure reliable mounting at boot.

Exam trap

The trap here is that candidates assume /dev/vg_data/lv_data is a stable device path, but it is actually a symlink that may not be available at boot time, leading them to overlook the correct /dev/mapper/ path or UUID.

How to eliminate wrong answers

Option B is wrong because the mount point /srv/data already exists (the filesystem was mounted there before the audit), and the system would fail with a different error if it didn't. Option C is wrong because the filesystem type ext4 is correct and would not cause a boot failure if specified properly; the issue is the device path, not the type. Option D is wrong because lvm2-lvmetad is a caching daemon for LVM metadata and is not required for logical volume activation at boot; activation is handled by lvm2-activation-generator and systemd.

Practice this question →
71
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 →
72
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 →
73
Multi-Selecteasy

Which TWO commands can be used to view the current disk usage of a filesystem?

Select 2 answers
A.blkid
B.du
C.fdisk
D.df
E.lsblk
AnswersB, D

du estimates file and directory space usage by walking the directory tree and summing the sizes of files and directories, reporting blocks used using -h for human-readable output and -sh for a total. It measures disk space consumed by a given path, not the capacity of the filesystem itself, so it's the correct tool when you need per-directory usage. Invoking du with arguments like du -sh /var would show the aggregate disk usage of that directory.

Why this answer

The `du` command (disk usage) estimates file and directory space usage, allowing you to view disk usage at the file or directory level. The `df` command (disk free) reports the amount of available and used disk space on mounted filesystems, showing overall filesystem usage. Both are standard Linux tools for examining disk consumption.

Exam trap

Red Hat often tests the distinction between commands that show block device information (like `lsblk` or `blkid`) versus those that report actual disk usage (`du` and `df`), trapping candidates who confuse device listing with usage reporting.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Local Storage questions.

Start 20-question session