Which three fields are present in every /etc/fstab entry? (Choose three.)
Select 3 answers
A.Mount point
B.Device
C.Dump field
D.Filesystem type
E.UUID
AnswersA, B, D
Correct. The mount point is the second field.
Why this answer
The /etc/fstab file defines filesystem mount points and options. Every entry must specify the device (or UUID), the mount point, and the filesystem type so the system knows what to mount, where to mount it, and how to interpret the filesystem. Without these three fields, the mount operation cannot proceed.
Exam trap
Red Hat often tests the misconception that UUID is a separate required field, but it is merely a common way to specify the device — the required field is the device identifier, which can be a UUID, label, or kernel device path.
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 for ext2/3/4; if it shows bad magic number, the device likely contains a different filesystem like XFS. Running mount with -t xfs would work.
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.
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
Correct. This is the proper sequence for extending an XFS LV.
Why this answer
Option D is correct because 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.
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
Extends LV to use all free extents.
Why this answer
Option B is correct because 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.
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.
AnswerA
Mismatched UUID is a common cause; verify with blkid.
Why this answer
The error message 'wrong fs type, bad option, bad superblock' typically indicates that the system cannot identify the filesystem on the device. Since the fstab entry uses UUID=abc123, the most likely cause is that the UUID specified does not match the actual UUID of /dev/sdb1, causing mount to attempt to mount a device that either does not exist or has a different filesystem signature. The mount command first resolves the UUID to a device, and if the UUID is incorrect, it may try to mount the wrong device or fail to find one.
Exam trap
Red Hat often tests the distinction between a missing mount point (which gives a clear 'No such file or directory' error) and a UUID mismatch (which produces a misleading 'wrong fs type' error), leading candidates to incorrectly suspect kernel support or filesystem type issues.
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').
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 a classic partitioning tool for MBR and GPT (with limitations).
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.
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
noexec prevents all execution from the filesystem.
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.
Which TWO commands can be used to view the current size and usage of an LVM logical volume? (Choose two.)
Select 2 answers
A.df -h
B.lsblk
C.vgdisplay
D.lvdisplay
E.lvs
AnswersD, E
Shows LV size and attributes.
Why this answer
D is correct because `lvdisplay` shows detailed attributes of LVM logical volumes, including size (LV Size) and current usage (Current LE, Allocated LE). E is correct because `lvs` provides a concise, tabular view of logical volumes with columns for size (LSize) and usage (Data% for thin volumes, or by comparing Allocated PE vs Total PE). Both commands directly query LVM metadata from the kernel device mapper.
Exam trap
Red Hat often tests the distinction between filesystem-level commands (`df`) and LVM metadata commands (`lvdisplay`, `lvs`), trapping candidates who think `df` shows LVM volume size rather than filesystem usage.
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
XFS requires xfs_growfs to resize the filesystem.
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.
After editing /etc/fstab to add a mount for /data, the system fails to boot and drops to a maintenance shell. Which recovery step should be taken first?
A.Remove the disk that contains the problematic mount
B.Boot into single-user mode and run 'mount -a' to list errors
C.Boot from installation media and reinstall the operating system
D.At the maintenance shell, run 'systemctl emergency' to drop to emergency mode
E.Boot into rescue mode and comment out or correct the problematic line in /etc/fstab
AnswerE
Correct. Rescue mode allows access to the system's root filesystem to edit fstab.
Why this answer
Option E is correct because when a misconfigured /etc/fstab entry prevents the system from booting, the first recovery step is to boot into rescue mode (or single-user mode if available) and edit /etc/fstab to comment out or correct the problematic line. This restores the ability to boot normally without reinstalling or removing hardware.
Exam trap
The trap here is that candidates may think 'mount -a' will show errors or that switching to emergency mode is a recovery step, when in fact the immediate fix is to edit /etc/fstab directly from the maintenance shell or rescue mode.
How to eliminate wrong answers
Option A is wrong because physically removing a disk is unnecessary and disruptive; the issue is a configuration error in /etc/fstab, not a hardware failure. Option B is wrong because 'mount -a' attempts to mount all filesystems listed in /etc/fstab and would fail again with the same error, not list errors in a helpful way; it does not fix the root cause. Option C is wrong because reinstalling the operating system is an extreme overreaction; the problem is a single misconfigured line that can be corrected with a text editor.
Option D is wrong because 'systemctl emergency' switches to emergency mode, which is even more restrictive than the maintenance shell and does not address the need to edit /etc/fstab; the system is already in a maintenance shell where editing is possible.
Refer to the exhibit. An administrator wants to create a logical volume named 'data' of size 5GB in volume group 'myvg' and mount it at /data. What is the correct sequence of commands?
A.vgcreate myvg /dev/sdb /dev/sdc
lvcreate -n data -L 5G myvg
mkfs.ext4 /dev/myvg/data
mount /dev/myvg/data /data
B.lvcreate -n data -L 5G myvg
mkfs.xfs /dev/myvg/data
mount /dev/myvg/data /data
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 prepares the partition for use as swap, and swapon activates it immediately.
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.
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
Correct: extend LV, then grow filesystem.
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.
An administrator has created a RAID 1 array using mdadm with two 1TB disks. After a disk failure, the array is in a degraded state. Which command should be used to replace the failed disk with a new one?
Option B is correct because it uses the `--manage` subcommand to first mark the failed disk (`/dev/sdb`) as failed with `--fail`, then remove it with `--remove`, and finally add the replacement disk (`/dev/sdc`) with `--add`. This is the proper sequence in mdadm to replace a failed disk in a RAID 1 array while the array is degraded.
Exam trap
The trap here is that candidates often think they can simply add a new disk with `--add` or remove the old disk directly without first marking it as failed, but mdadm requires the explicit `--fail` step to safely replace a failed disk in a degraded array.
How to eliminate wrong answers
Option A is wrong because `mdadm --add /dev/md0 /dev/sdc` attempts to add a new disk without first failing and removing the old failed disk, which can cause conflicts or be rejected by mdadm if the failed disk is still present in the array. Option C is wrong because `mdadm --remove /dev/md0 /dev/sdb --add /dev/sdc` tries to remove a disk without first marking it as failed; mdadm will refuse to remove an active or failed disk without the `--fail` step. Option D is wrong because `mdadm --replace` is not a valid mdadm command; the correct approach uses `--manage` with the `--fail`, `--remove`, and `--add` actions.
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
This shows the state of the array and any errors.
Why this answer
Option A is correct because 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.
An administrator replaces a failed disk in a RAID 10 array /dev/md0. The new disk is /dev/sdc. The admin runs: mdadm /dev/md0 --add /dev/sdc. The command succeeds, but the array does not start rebuilding. What is the most likely reason?
A.The new disk must be partitioned with the same layout as the failed disk.
B.The --add command should have been --re-add instead.
C.The array is still clean and does not need the new disk yet.
D.The failed disk was not removed from the array first; you need to mark it as failed and remove it.
AnswerD
Use mdadm --manage /dev/md0 --fail /dev/sdX and --remove before adding new disk.
Why this answer
Option D is correct because when a disk in a RAID array fails, the array marks it as faulty but does not automatically remove it. The administrator must first explicitly mark the failed disk as failed with `mdadm --fail` and then remove it with `mdadm --remove` before adding a replacement. Without removing the failed device, the array still considers the old disk as part of the array, and the new disk is not recognized as a replacement, so no rebuild starts.
Exam trap
The trap here is that candidates assume a failed disk is automatically removed from the array, but mdadm requires explicit removal before a new disk can be added to trigger a rebuild.
How to eliminate wrong answers
Option A is wrong because mdadm can add a whole disk (e.g., /dev/sdc) directly to a RAID array without requiring partitions; the array will use the entire disk as a component. Option B is wrong because --re-add is used to re-add a disk that was previously part of the array and was removed but not failed, not for a new replacement disk. Option C is wrong because a RAID 10 array with a missing or failed disk is degraded and will immediately start rebuilding once a spare or new disk is added; the array's 'clean' state is irrelevant to the rebuild trigger.
A system administrator adds a new 10GB disk (/dev/sdb) to a server. The requirement is to create a single ext4 filesystem on the entire disk for storing application data. Which sequence of commands should be used?
B.fdisk /dev/sdb (create one partition) -> mkfs.ext4 /dev/sdb1 -> mount /dev/sdb1 /data
C.mkfs.ext4 /dev/sdb && mount /dev/sdb /data
D.mkfs.ext4 /dev/sdb && mount /dev/sdb /data
AnswerB
This creates a partition, formats it, and mounts it; correct procedure for adding a new disk with a filesystem.
Why this answer
Option B is correct because it follows the proper sequence: first create a partition on /dev/sdb using fdisk, then format that partition (/dev/sdb1) with an ext4 filesystem using mkfs.ext4, and finally mount it to /data. Filesystems must be created on a partition (e.g., /dev/sdb1), not directly on the whole disk device (/dev/sdb), otherwise the system will not recognize the filesystem correctly for mounting and use.
Exam trap
The trap here is that candidates may think mkfs.ext4 can be applied directly to the whole disk (/dev/sdb) and still work, overlooking the requirement to create a partition first, which is a common misconception tested in EX200.
How to eliminate wrong answers
Option A is wrong because mkfs.ext4 is applied to /dev/sdb (the whole disk) instead of a partition like /dev/sdb1; creating a filesystem directly on a whole disk without a partition table is possible but not standard practice and can cause issues with tools expecting a partition table. Option C is wrong because mkfs.ext4 /dev/sdb attempts to create a filesystem on the whole disk without a partition, and mounting it directly is unreliable; the command also lacks a partition creation step. Option D is identical to C and thus wrong for the same reasons.
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
SSD or RAID provides higher IOPS and lower latency, directly addressing the high await.
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.
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
Correct. lvcreate with -s creates a snapshot of the LV.
Why this answer
Option D is correct because 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.
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
Correct. vg01 has 5GB free, sufficient for the LV.
Why this answer
Option A is correct because 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`.
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 is the correct tool to resize an ext4 filesystem to match the enlarged logical volume.
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.
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?
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`.
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?
Correct. This sequence prepares, activates, and persists swap.
Why this answer
Option C is correct because 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.
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
Lists block devices with details.
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.
Which THREE of the following are valid methods to identify a block device in /etc/fstab?
Select 3 answers
A.by-path
B.LABEL
C.PARTUUID
D.UUID
E./dev/sda1
AnswersB, D, E
Filesystem label is also commonly used.
Why this answer
LABEL is a valid method to identify a block device in /etc/fstab because the kernel can resolve filesystem labels (set with e2label or tune2fs) to the corresponding block device at mount time. This allows administrators to refer to a filesystem by its human-readable label, which remains stable even if the device name changes (e.g., from /dev/sda1 to /dev/sdb1).
Exam trap
Red Hat often tests the misconception that all udev by-* symlinks (like by-path or by-id) are valid fstab identifiers, but only UUID, LABEL, PARTUUID, and PARTLABEL are supported in the fstab format, while by-path is a udev symlink not parsed by mount.
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 allows online resizing of logical volumes, which is a major advantage.
Why this answer
Option B is correct because 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.
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 creates a filesystem (default ext2).
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.
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 recreating partition, the kernel may still have old info; partprobe updates it.
Why this answer
Option B is correct because 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.
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 defines persistent filesystem mounts.
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.
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
Correct: mdadm --manage with --fail.
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`.
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
Correct. The mount point must exist before mounting.
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.
Which command is used to display all block devices that have a filesystem of type XFS?
A.lsblk -f
B.findmnt -t xfs
C.blkid -t TYPE=xfs
D.df -t xfs
AnswerC
blkid -t filters by filesystem type.
Why this answer
The `blkid -t TYPE=xfs` command queries the libblkid library to list all block devices whose filesystem type is exactly XFS. It directly filters by the TYPE attribute, making it the most precise tool for this specific task.
Exam trap
The trap here is that candidates confuse commands that show mounted filesystems (findmnt, df) with commands that scan all block devices (blkid, lsblk), leading them to pick an option that only lists mounted XFS filesystems instead of all block devices with an XFS filesystem.
How to eliminate wrong answers
Option A is wrong because `lsblk -f` displays all block devices with their filesystem information (including type, label, UUID), but it does not filter by filesystem type; it shows everything, requiring manual inspection to find XFS devices. Option B is wrong because `findmnt -t xfs` lists mounted filesystems of type XFS, not all block devices with an XFS filesystem (unmounted devices are excluded). Option D is wrong because `df -t xfs` reports disk space usage for mounted XFS filesystems only, not all block devices with an XFS filesystem.
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 can only be grown, not shrunk.
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.
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
Correct. fdisk can add partitions interactively.
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.
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?
Option D is correct because 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.
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
Creates partition, filesystem, persistent mount, and mounts all.
Why this answer
Option D is correct because 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.
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
Initializes the partition as a physical volume.
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.
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?
Option B is correct because 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.
An admin is setting up a new RHEL 9 server. He has two disks: /dev/sda (500GB) and /dev/sdb (500GB). He wants to create a 300GB logical volume for application data, with the ability to take snapshots. He decides to use LVM thin provisioning. He creates a physical volume on /dev/sda, a volume group vg_data, and a thin pool with 300GB of data space and 10GB metadata. He then creates a thin volume lv_app of 300GB. Later, he wants to extend lv_app to 400GB as usage increases. He runs 'lvextend -L+100G /dev/vg_data/lv_app'. The command succeeds, but the application reports no additional space. What is the likely issue?
A.The thin pool has insufficient free space to accommodate the extension.
B.The thin volume must be unmounted to extend.
C.He should have used lvextend with the --resizefs option.
D.He forgot to resize the filesystem (e.g., xfs_growfs or resize2fs).
AnswerD
Extending the LV does not automatically resize the filesystem; a separate resize command is needed.
Why this answer
Option D is correct because when extending a thin volume, the underlying logical volume is extended, but the filesystem on top of it does not automatically grow. The admin must run a filesystem-specific command like xfs_growfs (for XFS) or resize2fs (for ext4) to make the additional space available to the application. Without this step, the filesystem remains at its original size, so the application sees no change.
Exam trap
The trap here is that candidates assume lvextend automatically resizes the filesystem, but in standard LVM (without the --resizefs flag, which does not exist), the filesystem must be resized separately, and this is a frequent point of confusion in the EX200 exam.
How to eliminate wrong answers
Option A is wrong because the thin pool was created with 300GB of data space, and the extension of lv_app by 100GB brings the total to 400GB, which exceeds the pool's data space; however, the lvextend command succeeded, indicating that the thin pool likely had enough free space (e.g., the pool may have been larger or the extension was allowed due to over-provisioning). Option B is wrong because LVM thin volumes can be extended while mounted; unmounting is not required for lvextend. Option C is wrong because --resizefs is not a valid option for lvextend; the correct approach is to use lvextend followed by a separate filesystem resize command.
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 fstab entry with device, mount point, filesystem type, and default options.
Why this answer
Option D is correct because 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.
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
Valid fstab entry using UUID.
Why this answer
Option B is correct because 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.
Which command initializes a disk partition as a physical volume for LVM?
A.fdisk
B.vgcreate
C.lvcreate
D.pvcreate
AnswerD
pvcreate initializes a physical volume.
Why this answer
Option D is correct because `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.
An administrator needs to create a new logical volume named 'lvdata' of size 5G in vgdata, format it with ext4, and mount it persistently at /mnt/data. The system currently has /dev/sdc as a physical volume in vgdata. Which command sequence accomplishes this?
A.lvcreate -L 5G -n lvdata vgdata; mkfs.ext4 /dev/vgdata/lvdata; echo '/dev/vgdata/lvdata /mnt/data ext4 defaults 0 0' >> /etc/fstab; mount -a
Option A is correct because it assumes the volume group vgdata and physical volume /dev/sdc already exist, so only the lvcreate command is needed to create the logical volume. It then formats the LV with ext4, adds a persistent mount entry to /etc/fstab, and uses mount -a to mount all filesystems from fstab, including the new entry. This sequence efficiently meets all requirements without redundant or incorrect steps.
Exam trap
Red Hat often tests the assumption that the volume group and physical volume already exist, tricking candidates into adding unnecessary pvcreate/vgcreate steps that would disrupt existing configurations.
How to eliminate wrong answers
Option B is wrong because it unnecessarily recreates the physical volume and volume group (pvcreate and vgcreate) that already exist, which could destroy existing data or cause conflicts. Option C is wrong because it mounts the filesystem directly with mount before adding the entry to /etc/fstab, but it does not use mount -a; while the mount command works immediately, the persistent mount is only established after the fstab entry, and the sequence lacks the final mount -a to ensure the fstab entry is tested. Option D is wrong because it attempts to create a filesystem directly on /dev/sdc (the physical volume) instead of on the logical volume, which would corrupt the LVM metadata and fail to create the LV correctly.
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
Correct. lsblk displays all block devices and their attributes.
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.
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?
Option A is correct because 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.
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
/boot is the next filesystem listed in fstab.
Why this answer
Option D is correct because, 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.
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?
lvextend expands the LV, then xfs_growfs expands the filesystem to fill the LV.
Why this answer
Option B is correct because 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`.
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
Correct. A PV is needed as storage for the VG.
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.
A database server requires a filesystem that supports very large files (over 2TB) and online defragmentation. Which filesystem type should be used?
A.ext4
B.vfat
C.swap
D.xfs
E.btrfs
AnswerD
Correct. XFS handles large files and offers online defragmentation.
Why this answer
XFS is the correct choice because it supports filesystem sizes up to 8 exabytes and individual file sizes up to 8 exabytes, easily exceeding the 2TB requirement. It also supports online defragmentation via the `xfs_fsr` command, allowing defragmentation while the filesystem is mounted and in use.
Exam trap
Red Hat often tests the misconception that ext4 is the default or most capable filesystem for large files, but the trap here is that ext4 does not support online defragmentation, while XFS is the default in RHEL 8/9 and explicitly supports both large files and online defragmentation.
How to eliminate wrong answers
Option A is wrong because ext4 supports individual file sizes up to 16TB (with 4k blocks) but does not support online defragmentation; defragmentation requires unmounting or using `e4defrag` with limitations. Option B is wrong because vfat (FAT32) has a maximum file size of 4GB and no defragmentation support, making it unsuitable for large files. Option C is wrong because swap is a dedicated swap space, not a general-purpose filesystem, and does not support files or defragmentation.
Option E is wrong because btrfs supports large files and online defragmentation, but it is not the standard choice for Red Hat Enterprise Linux (RHEL) 8/9; XFS is the default and recommended filesystem for such workloads in the EX200 exam context.
An administrator needs to ensure that a specific LVM logical volume is automatically mounted at boot with the 'noexec' option. Which configuration file and entry should be used?
A./etc/fstab: /dev/vg/lv /mnt ext4 noexec 0 0
B./etc/rc.d/rc.local: mount /dev/vg/lv /mnt -o noexec
Option C is correct because /etc/fstab is the standard configuration file for defining filesystem mount points and options that are applied automatically at boot. The entry specifies the logical volume device, mount point, filesystem type, and mount options including 'noexec' to prevent execution of binaries on that filesystem. The 'defaults' keyword ensures standard mount behavior is applied before the 'noexec' option overrides the exec permission.
Exam trap
The trap here is that candidates often confuse the purpose of /etc/fstab with boot scripts like rc.local, or they forget that mount options in fstab must be comma-separated and include 'defaults' to ensure all standard options are explicitly set before overriding them.
How to eliminate wrong answers
Option A is wrong because the mount options field is missing the 'defaults' keyword or any other base options; while 'noexec' alone is syntactically valid, the entry omits the required comma-separated list format and does not include 'defaults' which is typically expected for clarity and to avoid missing default mount behaviors. Option B is wrong because /etc/rc.d/rc.local is a legacy script that runs at the end of the boot process, not a configuration file for automatic boot-time mounting; using a mount command there is unreliable and not the standard method for persistent mount definitions. Option D is wrong because /etc/rc.local is a script, not a configuration file for fstab-style entries, and the mount command syntax shown does not include the required device and mount point in the correct order for a persistent boot-time mount.
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
Without an fstab entry, the filesystem won't mount automatically at boot.
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.
You are a Red Hat administrator at a company that runs a critical database server. The server has a single 500GB SSD (/dev/sda) with a default partition layout: /boot (1GB), swap (8GB), and / (491GB) using LVM. The database stores data in /var/lib/mysql, which is on the root logical volume. Recently, the /var/lib/mysql directory has been growing rapidly and is now at 95% usage. The server has an additional 1TB HDD (/dev/sdb) installed but not configured. You need to provide additional storage to /var/lib/mysql without downtime. The database is currently running and must remain accessible. You have root access via SSH. Which of the following is the best course of action?
A.Create a physical volume on /dev/sdb, create a new volume group named vgdb, create a logical volume lvdb of 900GB, format with XFS, mount temporarily at /mnt, copy /var/lib/mysql to /mnt using rsync while the database is running, then unmount and remount at /var/lib/mysql after updating /etc/fstab and stopping the database momentarily.
B.Add /dev/sdb as a physical volume, extend the root volume group, extend the root logical volume, and grow the filesystem. Then move /var/lib/mysql to a new directory on the extended space.
C.Use lvreduce to shrink the root LV by 10GB, then lvextend to create a new LV for /var/lib/mysql, format with ext4, mount, and copy data.
D.Partition /dev/sdb with a single partition, format with ext4, mount at /var/lib/mysql, and copy the data. Then update /etc/fstab.
AnswerA
Correct: uses LVM, creates dedicated storage, and migrates data with minimal downtime.
Why this answer
Option A is correct because it uses LVM to create a dedicated logical volume on the new disk, allowing the database data to be migrated without downtime. By using rsync while the database is running, the data remains accessible, and only a brief stop is needed for the final sync and remount. This approach avoids modifying the root filesystem and ensures the database service is interrupted minimally.
Exam trap
The trap here is that candidates may think extending the root volume group and logical volume is simpler, but they overlook that the root filesystem itself is not the bottleneck—the specific directory /var/lib/mysql needs dedicated space without risking the root filesystem's integrity.
How to eliminate wrong answers
Option B is wrong because extending the root logical volume and filesystem does not isolate /var/lib/mysql onto its own storage; the entire root filesystem would still be at risk of filling up, and moving data within the same filesystem does not solve the capacity issue. Option C is wrong because shrinking the root LV (lvreduce) on a live XFS filesystem is not supported without unmounting and risks data corruption; also, creating a new LV from the freed space would still leave the root filesystem constrained. Option D is wrong because mounting a new ext4 filesystem directly at /var/lib/mysql while the database is running would overwrite the existing data directory, causing immediate data loss and service disruption; the data must be copied after mounting elsewhere.
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
RHEL 8/9 defaults to XFS; resize2fs is for ext filesystems.
Why this answer
Option D is correct because 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.
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
Correct. This is the proper sequence for LUKS encryption.
Why this answer
Option E is correct because 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.
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
The LV is larger, but the filesystem must be resized to use the space.
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.
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
parted can toggle flags like boot.
Why this answer
Option B is correct because 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.
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 creates the RAID array; GRUB can be installed on each disk's MBR to allow booting from either disk.
Why this answer
Option A is correct because 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.
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
lvs with data_percent shows the percentage of the thin pool that has been allocated by the thin volume.
Why this answer
Option D is correct because 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.
Which TWO commands can be used to create a logical volume using all available free space in a volume group?
Select 2 answers
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, D
Uses all free extents.
Why this answer
Option B is correct because the `-l 100%FREE` flag allocates all available unassigned physical extents in the volume group to the new logical volume, which is the precise way to use all free space. Option D is also correct because `-l 100%VG` allocates 100% of the total physical extents in the volume group, which effectively uses all free space if no other logical volumes exist; if other logical volumes exist, it will fail or resize them, but in the context of 'all available free space,' it is a valid method when the VG has no other allocations.
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.
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
A process using the directory prevents mounting.
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.
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 filter (e.g., filter = ['r|/dev/sdb1|']) can cause the PV to be unknown because LVM does not scan it.
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.
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
Once data is moved, the old PV can be removed from the VG.
Why this answer
Option C is correct because 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.
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
Correct syntax.
Why this answer
Option A is correct because 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.
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 displays UUID and filesystem type.
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.
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 remount only affects the current session; after reboot, fstab is used, which has defaults (rw).
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
Correct: mkswap initializes 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.
Option C is correct because the `mdadm` command with the `-f` (fail) and `-r` (remove) flags in a single command line first marks /dev/sdb as faulty in the /dev/md0 array, then immediately removes it. This is the standard syntax for simulating a failure and removing the disk in one step, as tested in the EX200 exam.
Exam trap
The trap here is that candidates often confuse the `--fail` and `--remove` options with similar-sounding but incorrect terms like `--fault`, or they mistakenly specify the wrong disk device in the remove operation, testing attention to exact syntax and device naming.
How to eliminate wrong answers
Option A is wrong because it specifies `--remove /dev/sdc` instead of `/dev/sdb`, attempting to remove a different disk than the one failed, which would fail or cause unintended behavior. Option B is wrong because the `--remove` operation targets `/dev/sda` instead of `/dev/sdb`, and the semicolon separates two commands that are not combined into a single mdadm invocation, which is less efficient and could lead to race conditions. Option D is wrong because it uses the invalid option `--fault` instead of the correct `--fail`; the mdadm command does not recognize `--fault` and would return an error.
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
df -h shows disk space usage for mounted filesystems.
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.
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
AnswerC
This remounts the already mounted filesystem with the exec option added.
Why this answer
Option C is correct because the `mount -o remount,exec /mnt/backup` command changes the mount options of an already-mounted filesystem without unmounting it. The `remount` option applies the specified mount options (in this case, `exec`) to the existing mount point, and the filesystem path (device or mount point) is sufficient for the kernel to identify and modify the mount. This is the standard method for altering mount options on a live filesystem in Linux.
Exam trap
The trap here is that candidates often think they must specify both the device and mount point (as in Option B) for a remount, but the `remount` option only requires one identifier (the mount point or device) to locate the mount, and including both can cause a syntax error or be ignored.
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.
An administrator is configuring a RAID 1 (mirror) using two 100GB disks /dev/sda and /dev/sdb. After creating the array, which command(s) will verify the array status? (Choose the best answer.)
A.mdadm --detail /dev/md0
B.mdadm --examine /dev/sda
C.cat /proc/mdstat
D.mdadm --query /dev/md0
E.Both A and B
AnswerE
Correct. Both mdadm --detail and cat /proc/mdstat display RAID array status.
Why this answer
Option E is correct because both `mdadm --detail /dev/md0` and `mdadm --examine /dev/sda` are valid commands to verify the status of a RAID 1 array. `mdadm --detail /dev/md0` shows the current state, sync status, and member disks of the assembled array, while `mdadm --examine /dev/sda` displays the superblock metadata on a component disk, confirming its role in the array and its health. Together, they provide a complete verification from both the array and disk perspectives.
Exam trap
The trap here is that candidates often think only one command is needed, but the EX200 exam tests that `--detail` verifies the assembled array and `--examine` verifies the component disks, requiring both for complete status verification.
How to eliminate wrong answers
Option A is wrong because it alone is insufficient; `mdadm --detail /dev/md0` only checks the array after assembly, not the metadata on individual disks. Option B is wrong because it alone is insufficient; `mdadm --examine /dev/sda` only checks the superblock on one disk, not the array status. Option C is wrong because `cat /proc/mdstat` shows a real-time summary of all MD devices but is not as detailed as `mdadm --detail` or `--examine` for verifying specific array metadata or disk health.
Option D is wrong because `mdadm --query /dev/md0` provides only a brief status (e.g., active/inactive) without the detailed information needed for thorough verification.
To ensure that a filesystem is mounted automatically at boot and that only root can write to it, which mount options should be used in /etc/fstab? (Assume the filesystem permissions are appropriately set.)
A.ro,noauto
B.noexec,nodev,nosuid
C.defaults
D.rw,suid,dev,exec
E.auto,root
AnswerC
Correct. 'defaults' includes 'nouser' (only root can mount) and 'rw' (read-write). Actual write access is then controlled by filesystem permissions.
Why this answer
Option C is correct because the 'defaults' mount option in /etc/fstab implies rw, suid, dev, exec, auto, nouser, and async. This ensures the filesystem is mounted automatically at boot (via the 'auto' sub-option) and, critically, only root can write to it (because 'nouser' prevents non-root users from mounting or writing, and the default permissions allow root write access). The question states that filesystem permissions are appropriately set, so 'defaults' satisfies both requirements without additional options.
Exam trap
The trap here is that candidates often think 'defaults' is too generic or insufficient, and they overcomplicate by adding explicit options like 'rw' or 'auto', not realizing that 'defaults' already includes both 'auto' (for boot mounting) and 'nouser' (to restrict write access to root), making it the correct single-option answer.
How to eliminate wrong answers
Option A is wrong because 'ro' mounts the filesystem read-only, preventing root from writing, and 'noauto' prevents automatic mounting at boot, directly contradicting the requirement. Option B is wrong because 'noexec,nodev,nosuid' only restricts execution, device files, and setuid/setgid bits; it does not control automatic mounting at boot (missing 'auto') and does not restrict write access to root (it allows any user with write permissions to write). Option D is wrong because 'rw,suid,dev,exec' explicitly allows writing by any user with appropriate permissions, not just root, and does not include 'auto' to ensure boot-time mounting.
Option E is wrong because 'auto' is a valid mount option for boot-time mounting, but 'root' is not a valid mount option in /etc/fstab; the correct option to restrict write access to root is 'nouser' (implied by 'defaults'), not 'root'.