Courseiva

CCNA Create and configure file systems Questions

21 questions · Create and configure file systems · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

In /etc/fstab, which values in the dump and pass fields enable automatic file system checking at boot?

A.dump=1, pass=0
B.dump=0, pass=0
C.dump=0, pass=1
D.dump=1, pass=1
AnswerC

This is the correct setting. A dump value of 0 is the standard choice on modern Linux systems, as dump(8) is obsolete and almost never used. The pass value of 1 tells fsck(8) to check this filesystem at boot, and 1 is specifically used for the root filesystem; other filesystems use pass=2 to run after the root check completes.

Why this answer

The `pass` field in `/etc/fstab` controls the order of file system checks at boot. A value of 1 means the root file system is checked first, and a value of 2 or higher means other file systems are checked after root. The `dump` field is for backup utility (dump) and is not related to boot-time checking; it must be 0 to disable dump.

Thus, `dump=0, pass=1` enables automatic file system checking (fsck) at boot for the root file system.

Exam trap

Red Hat often tests the misconception that `dump=1` is required for boot-time file system checks, but the `dump` field is unrelated to fsck; the trap is confusing the `dump` field with the `pass` field's role in enabling automatic checks.

How to eliminate wrong answers

Option A is wrong because `dump=1` enables dump backups (not boot-time checking), and `pass=0` disables fsck entirely, so no automatic checking occurs. Option B is wrong because `dump=0` and `pass=0` both disable dump and fsck, meaning no file system check at boot. Option D is wrong because `dump=1` enables dump (unnecessary for boot checking) and `pass=1` enables fsck, but the combination is not required; the correct minimal setting for enabling fsck is `dump=0, pass=1`.

Practice this question →
2
MCQmedium

Refer to the exhibit. An administrator runs xfs_growfs on /dev/sdc1. What is the most likely reason the command succeeded without prior partition resizing?

A.The partition was automatically resized by xfs_growfs
B.The underlying block device (partition or logical volume) was extended before the command
C.The filesystem was already using the full partition size and the command had no effect
D.The filesystem was mounted with the 'grow' option allowing online growth
AnswerB

xfs_growfs works by expanding the filesystem's data allocation structures to consume the additional space that must already exist on the backing device. Before running the command, the administrator must have extended the partition or logical volume using lvextend or a partition editor. When invoked on a mounted XFS filesystem with no arguments, it grows the filesystem to the maximum size permitted by the underlying block device.

Why this answer

xfs_growfs can only expand an XFS filesystem to fill the available space on the underlying block device. If the command succeeded without prior partition resizing, it means the block device (e.g., a partition or logical volume) was already extended beforehand. The filesystem then uses the new space when xfs_growfs is run.

Exam trap

A common misconception is that xfs_growfs can resize the partition itself, but it only expands the filesystem to match an already extended block device (e.g., LVM volume or disk partition).

How to eliminate wrong answers

Option A is wrong because xfs_growfs does not resize partitions; it only grows the filesystem within the existing block device. Option C is wrong because if the filesystem already used the full partition, xfs_growfs would report that no change was needed, but the question states the command 'succeeded' (implying growth occurred). Option D is wrong because there is no 'grow' mount option in XFS; online growth is handled by xfs_growfs itself, not a mount flag.

Practice this question →
3
MCQmedium

A filesystem is reported as 'read-only' after a system crash. The admin runs fsck and sees 'clean' status. What is the most likely reason it remains read-only?

A.fsck cannot fix errors on ext4 filesystems.
B.The filesystem is still mounted; fsck cannot fix it while mounted.
C.The filesystem is XFS, and fsck does not repair XFS.
D.fsck detected errors but did not fix them automatically.
AnswerC

This is correct. XFS is not repairable by fsck; fsck only inspects the XFS log to see whether the filesystem was cleanly unmounted and reports a 'clean' status based on that flag alone, without traversing metadata structures. To actually verify and repair an XFS filesystem you must use the dedicated xfs_repair utility, so a read-only XFS filesystem after a crash would still be reported as 'clean' by fsck while remaining unusable for writes.

Why this answer

If fsck reports 'clean', it means no errors were found in the filesystem's journal, so option D is incorrect. Option C is correct because XFS filesystems cannot be repaired by fsck; they require xfs_repair. Running fsck on an XFS filesystem simply reports the clean flag without performing a real check, leaving the kernel to enforce read-only status if any issues persist.

Exam trap

Candidates often assume that 'clean' means the filesystem is fully healthy and that fsck repairs all filesystem types. The trap is that fsck is for ext four, and XFS requires xfs_repair.

How to eliminate wrong answers

Option A is wrong because fsck can fix errors on ext4 filesystems; it is specifically designed to check and repair ext2/3/4 filesystems. Option B is wrong because the question states the admin runs fsck after a system crash, implying the filesystem is not mounted (or fsck would refuse to run with a warning); even if mounted read-only, fsck can still check it, but the issue here is that fsck did not apply repairs. Option C is wrong because the filesystem is reported as ext4 (fsck is run and shows 'clean'), not XFS; XFS uses xfs_repair, not fsck, and the question explicitly mentions fsck.

Practice this question →
4
MCQmedium

Refer to the exhibit. An administrator tries to mount the partition /dev/sdc1 and gets a superblock error. What is the most likely cause?

A.The filesystem is not recognized; need to install xfsprogs
B.The partition table is corrupted
C.The filesystem has not been created; mkfs.xfs was not run
D.The mount point /mnt/backup does not exist
AnswerC

Although blkid shows a UUID and type, the superblock error indicates the filesystem is not valid. This can happen if the partition was created but not formatted, yet blkid might show leftover metadata. Typically, you must run mkfs.xfs to create the filesystem.

Why this answer

The superblock error indicates that the kernel cannot read the filesystem metadata at the start of the partition. This most commonly occurs when no filesystem has been created on the partition — i.e., mkfs.xfs was never run on /dev/sdc1. Without a valid filesystem superblock, the mount command fails with a 'wrong fs type, bad option, bad superblock' message.

Exam trap

Red Hat often tests the distinction between a partition existing (created with fdisk/gdisk) and a filesystem existing on that partition (created with mkfs), leading candidates to confuse partition table corruption with a missing filesystem.

How to eliminate wrong answers

Option A is wrong because if the xfsprogs package were missing, the system would not have the xfs kernel module or mount helper, but the error would be 'mount: unknown filesystem type' rather than a superblock error. Option B is wrong because a corrupted partition table would prevent the kernel from recognizing the partition at all (e.g., 'no such device' or 'invalid partition table'), not produce a superblock error on a recognized block device. Option D is wrong because if /mnt/backup did not exist, the error would be 'mount point /mnt/backup does not exist', not a superblock error.

Practice this question →
5
MCQmedium

A system administrator runs 'mount -a' and receives an error: 'mount: /mnt/nfs: mount point does not exist'. The /etc/fstab entry is: server:/export /mnt/nfs nfs defaults 0 0. What is the most likely cause?

A.The directory /mnt/nfs does not exist
B.The 'defaults' option does not include '_netdev'
C.The filesystem type should be 'nfs4'
D.The NFS server is unreachable
AnswerA

Correct: The mount point must exist before mounting.

Why this answer

The error message 'mount: /mnt/nfs: mount point does not exist' explicitly indicates that the directory /mnt/nfs is missing. The 'mount -a' command processes all entries in /etc/fstab, and for each filesystem, it requires the mount point directory to exist before the mount can succeed. Since the directory is absent, the mount fails immediately, regardless of the NFS server status or filesystem type.

Exam trap

Red Hat often tests the distinction between mount point existence errors and network connectivity errors, trapping candidates who assume the issue is with NFS configuration or server reachability when the error message clearly points to a missing local directory.

How to eliminate wrong answers

Option B is wrong because the '_netdev' option is used to indicate that the filesystem requires network access, which is relevant for systemd ordering but does not affect the mount point existence check; the error is about a missing directory, not network dependency. Option C is wrong because 'nfs' is a valid filesystem type that auto-negotiates the NFS version (including NFSv4) with the server; specifying 'nfs4' is not required and would not resolve a missing mount point. Option D is wrong because an unreachable NFS server would produce a different error, such as 'mount.nfs: Connection timed out' or 'No route to host', not a 'mount point does not exist' error.

Practice this question →
6
MCQmedium

A technician runs 'mkfs.xfs /dev/sdb1' and later mounts it. The file system is reported as having a block size of 1024 bytes. What is the most likely reason?

A.The administrator used the -b size=1024 option.
B.The block size setting was ignored due to a kernel limitation.
C.The default block size for XFS is 1024 bytes.
D.The partition size is less than 1GB, so mkfs.xfs automatically used a 1024-byte block size.
AnswerD

When the partition on /dev/sdb1 is smaller than 1 GiB, mkfs.xfs automatically uses 1024-byte blocks instead of the usual 4096-byte blocks. This tuning improves space efficiency on small volumes by reducing the overhead associated with larger blocks, such as internal fragmentation and per-block metadata structures. The administrator did not need to specify any option; this is the default behavior for sub-1 GiB XFS filesystems.

Why this answer

Mkfs.xfs automatically selects a 1024-byte block size when the underlying partition is smaller than 1 GB. This is a built-in heuristic in the XFS filesystem to optimize metadata overhead and space utilization on small volumes. The technician did not specify a block size, so the tool applied this default behavior based on partition size.

Exam trap

Red Hat often tests the misconception that XFS always uses a 4096-byte block size, leading candidates to overlook the automatic block size reduction on small partitions.

How to eliminate wrong answers

Option A is wrong because the technician did not use the -b size=1024 option; the question states the command was run without any block size argument. Option B is wrong because there is no kernel limitation that ignores or overrides the block size setting; the kernel fully supports the specified block size. Option C is wrong because the default block size for XFS is 4096 bytes, not 1024 bytes; the 1024-byte block size is only used automatically for partitions smaller than 1 GB.

Practice this question →
7
MCQeasy

A system administrator needs to create a file system on a new 10GB partition /dev/sdb1 for use with a database that requires high reliability and supports snapshots. Which file system type should be chosen?

A.xfs
B.ext4
C.vfat
D.btrfs
AnswerA

XFS is the correct choice because it is the default filesystem on RHEL 9, and Red Hat fully supports it for production workloads. While XFS itself does not have native snapshot capabilities, it works seamlessly with LVM, which provides snapshot functionality for consistent backups and recovery. Its allocation groups, scalable inode handling, and high concurrency support make it ideal for large database files, exactly what the administrator needs.

Why this answer

XFS is the correct choice because it is a high-performance, 64-bit journaling file system that supports snapshots via LVM or external tools, and is designed for large files and partitions. For a database requiring high reliability and snapshot capabilities, XFS provides robust data integrity features and is the default file system in Red Hat Enterprise Linux 8 and later, making it the recommended option for this scenario.

Exam trap

The trap here is that candidates may choose btrfs because it natively supports snapshots, but the EX200 exam expects XFS as the default RHEL file system for high-reliability production use, and btrfs is not covered as a standard option in the exam objectives.

How to eliminate wrong answers

Option B (ext4) is wrong because while ext4 is a reliable journaling file system, it does not natively support snapshots; snapshots require LVM or other external mechanisms, and ext4 is less optimized for very large partitions and high-concurrency database workloads compared to XFS. Option C (vfat) is wrong because vfat is a simple, non-journaling file system designed for compatibility with legacy systems and removable media; it lacks journaling, reliability features, and snapshot support, making it unsuitable for a database. Option D (btrfs) is wrong because although btrfs supports snapshots and checksumming, it is not the default file system in RHEL and is considered less mature for production database use; the EX200 exam focuses on XFS as the standard choice for high-reliability scenarios.

Practice this question →
8
MCQmedium

The administrator wants to mount a new filesystem on /dev/sdb1 with the label 'backup' and mount it at /mnt/backup. Which commands achieve this?

A.parted /dev/sdb mkpart primary xfs 0% 100% && mkfs.xfs -L backup /dev/sdb1
B.mkfs.xfs /dev/sdb1 && xfs_admin -L backup /dev/sdb1 && mount -L backup /mnt/backup
C.mkfs.xfs -L backup /dev/sdb1 && mount /dev/sdb1 /mnt/backup
D.mkfs.ext4 -L backup /dev/sdb1 && echo '/dev/sdb1 /mnt/backup ext4 defaults 0 0' >> /etc/fstab
AnswerB, C

This sequence correctly creates an XFS filesystem on the existing /dev/sdb1, assigns it the label 'backup' using xfs_admin -L, and mounts it by label with 'mount -L backup /mnt/backup'. Mounting by label resolves through /dev/disk/by-label, avoiding dependence on unstable device names, and works without needing an /etc/fstab entry for immediate use. It assumes the partition already exists and that /mnt/backup is a valid mount point, both of which are prerequisites.

Why this answer

Both options B and C correctly create an XFS filesystem with the label 'backup' on /dev/sdb1 and mount it to /mnt/backup. Option B uses mkfs.xfs, then sets the label with xfs_admin, then mounts by label (mount -L works without fstab). Option C creates the filesystem with the label in one step and mounts by device path.

Options A and D are incorrect: A includes an unnecessary parted command and uses ext4? Actually A creates an XFS partition but then mounts? Wait A: parted ... mkpart primary xfs ... && mkfs.xfs -L backup /dev/sdb1. It doesn't mount, so incomplete. D uses ext4, not XFS.

Thus B and C are both valid.

Exam trap

The trap is that candidates may think mounting by label requires an /etc/fstab entry (as initially stated in the explanation for B), but mount -L works without fstab. Also, they might overlook that both B and C are valid sequences.

How to eliminate wrong answers

Option A is wrong because parted does not create a filesystem; it only creates a partition, and the mkpart command syntax is incomplete (missing filesystem type and partition type). Option B is wrong because xfs_admin -L backup cannot change the label of an XFS filesystem that is already mounted or without the filesystem being unmounted first, and mount -L backup uses the label but the label hasn't been set correctly before mounting. Option D is wrong because it creates an ext4 filesystem instead of XFS, and while it adds an fstab entry, it does not actually mount the filesystem immediately, failing the requirement to mount it at /mnt/backup.

Practice this question →
9
MCQhard

Refer to the exhibit. After mounting /dev/sdb1 with the noexec option, a script located at /mnt/data/test.file cannot be executed. What change will allow execution while maintaining security?

A.Copy the script to /tmp and run from there
B.Use chmod +x /mnt/data/test.file
C.Change the mount option to exec in /etc/fstab and remount
D.Remount without noexec and add setuid bit
AnswerC

Alter the /etc/fstab entry for /dev/sdb1 to include exec (or remove noexec), then run mount -o remount /mnt/data to re-read the options without a full unmount. This tells the kernel that the filesystem is allowed to serve as a source of executable programs. Using fstab ensures the change survives a reboot, and the remount applies it immediately to the mounted filesystem.

Why this answer

The noexec mount option prevents execution of any binaries or scripts on the filesystem, regardless of file permissions. To allow execution while maintaining security, you must change the mount option to exec in /etc/fstab and remount the filesystem (e.g., mount -o remount,exec /mnt/data). This approach preserves other mount options and avoids the security risks of removing noexec globally.

Exam trap

In RHEL, the noexec mount option overrides any execute permissions set on files, regardless of chmod. The common mistake is trying to fix permissions instead of modifying the mount options via /etc/fstab and remounting with exec.

How to eliminate wrong answers

Option A is wrong because copying the script to /tmp does not change the mount options on /mnt/data; /tmp may also be mounted with noexec, and even if it is not, this workaround bypasses the intended security policy without addressing the underlying filesystem configuration. Option B is wrong because chmod +x sets the executable permission bit on the file, but the noexec mount option overrides file permissions entirely—execution is blocked at the kernel level regardless of the file's mode. Option D is wrong because remounting without noexec and adding the setuid bit introduces a significant security risk (setuid allows the script to run with the privileges of its owner, often root), and the question asks to maintain security while allowing execution, not to escalate privileges.

Practice this question →
10
MCQmedium

Refer to the exhibit. An administrator wants to mount /dev/sdc1 on /mnt/storage. What must be done first?

A.Mount /dev/sdc directly
B.Add an entry to /etc/fstab
C.Create a partition on /dev/sdc
D.Run mkfs.xfs /dev/sdc1
AnswerC

The exhibit shows /dev/sdc as a whole disk with no recognized partitions (e.g., no /dev/sdc1). Before you can format and mount storage, you must create a partition table and a partition on the disk using a tool such as parted or fdisk. This step creates the necessary block device /dev/sdc1, which can then be formatted with mkfs.xfs and mounted. Without a partition, neither the device name referenced in the question nor a filesystem exists.

Why this answer

The exhibit shows that /dev/sdc has no partition table (it is a raw disk). Before you can mount a filesystem on /dev/sdc1, you must first create a partition on /dev/sdc using a tool like fdisk or parted. Without a partition, the block device /dev/sdc1 does not exist, so any mount attempt would fail with a 'no such device' error.

Exam trap

A common pitfall in the Red Hat RHCSA exam is thinking you can directly mount a raw disk or create a filesystem on a non-existent partition, leading candidates to select mkfs.xfs or /etc/fstab before partitioning.

How to eliminate wrong answers

Option A is wrong because mounting /dev/sdc directly would attempt to mount the whole disk without a partition table, which is not a standard practice and would fail unless the disk contains a filesystem written directly to it (which is not the case here). Option B is wrong because adding an entry to /etc/fstab is only useful after the partition and filesystem exist; it does not create the partition or the block device. Option D is wrong because running mkfs.xfs /dev/sdc1 requires that /dev/sdc1 already exists as a valid block device; you cannot create a filesystem on a non-existent partition.

Practice this question →
11
MCQhard

A server has an LVM volume group vg01 with a physical volume /dev/sdb. The administrator wants to move all physical extents from /dev/sdb to /dev/sdd which is also in the same volume group. Which command sequence is correct?

A.pvmove /dev/sdb; vgreduce vg01 /dev/sdb
B.vgreduce vg01 /dev/sdb; pvmove
C.pvmove /dev/sdb; pvremove /dev/sdb
D.pvmove /dev/sdb /dev/sdd
AnswerA

The correct sequence starts with `pvmove /dev/sdb`, which relocates every allocated physical extent on that disk to any available free extent elsewhere in the same volume group (vg01). Once the source PV is completely empty, `vgreduce vg01 /dev/sdb` safely removes it from the volume group's metadata, allowing the disk to be repurposed or detached without risking data loss or LVM corruption.

Why this answer

The correct sequence is to first use `pvmove /dev/sdb` to relocate all physical extents from /dev/sdb to other physical volumes in the same volume group (vg01), and then use `vgreduce vg01 /dev/sdb` to remove the now-empty physical volume from the volume group. This ensures no data loss and that the volume group metadata is properly updated.

Exam trap

The trap here is that candidates often think `pvmove` requires a target PV or that `pvremove` can be used directly after moving extents, but they forget that the PV must first be removed from the VG with `vgreduce` before it can be fully decommissioned.

How to eliminate wrong answers

Option B is wrong because `vgreduce` before `pvmove` would attempt to remove /dev/sdb from the volume group while it still contains data, causing an error or data loss. Option C is wrong because after `pvmove`, the physical volume /dev/sdb is empty but still part of the volume group; `pvremove` would fail because the PV is still in a VG, and it does not remove the PV from the VG metadata. Option D is wrong because `pvmove /dev/sdb /dev/sdd` attempts to move extents directly to a specific target PV, but if /dev/sdd does not have enough free extents, the command will fail; the correct approach is to use `pvmove` without a target to let LVM distribute extents across all available PVs in the VG.

Practice this question →
12
MCQmedium

Refer to the exhibit. An administrator needs to create a new 5GB filesystem for /var/log. Which step is required?

A.Create a new partition on /dev/sdc and format with xfs
B.Shrink /home to free space in vg00 and create a new LV
C.Add /dev/sdc as a physical volume, extend vg00, create a logical volume, and format
D.Create a new volume group using /dev/sdb
AnswerC

The exhibit shows VG vg00 has no free physical extents, so you cannot create a new logical volume in that volume group without first adding capacity. Adding /dev/sdc as a physical volume via pvcreate or vgextend expands the VG's available space, after which a new logical volume can be created with lvcreate and then formatted with a filesystem such as xfs using mkfs.xfs. This is the standard approach when a dedicated disk is available and the goal is to allocate a new filesystem from an existing volume group.

Why this answer

To create a new filesystem for /var/log using available space on /dev/sdc, the disk must first be added as a physical volume (pvcreate), then added to the existing volume group vg00 (vgextend). After extending the VG, a new logical volume can be created (lvcreate) and formatted with a filesystem (e.g., mkfs.xfs). This approach leverages LVM's flexibility to allocate space from multiple physical volumes without requiring a separate volume group or partition manipulation.

Exam trap

For RHCSA, the key trap is that candidates often forget to add the new disk as a physical volume (pvcreate) before extending the volume group. They may try to directly create a logical volume on the raw disk or add it to the VG without the pvcreate step.

How to eliminate wrong answers

Option A is wrong because creating a new partition on /dev/sdc and formatting it with xfs would create a standalone filesystem not managed by LVM, which contradicts the requirement to use the existing volume group vg00 and does not integrate with the existing logical volume management. Option B is wrong because shrinking /home to free space in vg00 is unnecessary and risky; the question specifies a new 5GB filesystem for /var/log, and the available disk /dev/sdc should be added to vg00 rather than resizing existing LVs, which could cause data loss or complexity. Option D is wrong because creating a new volume group using /dev/sdb is irrelevant; the exhibit shows /dev/sdc as the available disk, and the goal is to extend the existing vg00, not create a separate VG.

Practice this question →
13
Multi-Selecthard

Which TWO commands are valid for resizing an XFS file system? (Choose exactly two.)

Select 2 answers
A.xfs_admin -L /mnt
B.xfs_growfs /mnt
C.resize2fs /dev/sda1
D.xfs_growfs -D 10g /mnt
E.xfs_repair /dev/sda1
AnswersB, D

xfs_growfs is the standard tool for resizing an XFS filesystem, and running it with a mount point grows the filesystem to occupy all available space in the underlying device or logical volume. This command works online—meaning the filesystem can remain mounted and in use during the operation—which is a key advantage in production environments. Therefore, xfs_growfs /mnt is a valid and correct answer for resizing an XFS filesystem.

Why this answer

`xfs_growfs` is the dedicated command for resizing (growing) an XFS file system while it is mounted. It expands the file system to fill the available space in the underlying device or logical volume, making it the primary tool for XFS resizing operations.

Exam trap

Red Hat often tests the distinction between file system-specific tools, so the trap here is that candidates confuse `resize2fs` (for ext4) with `xfs_growfs` (for XFS), or mistakenly think `xfs_admin` can resize the file system when it only manages labels and UUIDs.

Practice this question →
14
MCQhard

The administrator attempts to run 'xfs_growfs /dev/vg00/lvol1' but receives an error. What is the most likely cause?

A.The file system is not XFS
B.Unmet dependencies
C.The volume group is full
D.The logical volume is not mounted
AnswerD

xfs_growfs requires the target XFS filesystem to be mounted because it performs an online growth operation, reading the current geometry via the mounted filesystem and updating the superblock without unmounting. The lvs attributes for lvol1 lack the 'o' flag (open), which indicates that the logical volume is not currently open/mounted. Since xfs_growfs is invoked on a device that is not mounted, it cannot determine the filesystem's mountpoint and returns an error indicating the filesystem is not mounted. Mounting the LV first and then re-running xfs_growfs with the mountpoint or device would resolve the issue.

Why this answer

The `xfs_growfs` command requires the XFS filesystem to be mounted in order to resize it. If the logical volume `/dev/vg00/lvol1` is not mounted, the kernel cannot access the filesystem's superblock and allocation group information, causing the command to fail with an error such as 'XFS filesystem not mounted' or 'No such file or directory'.

Exam trap

The trap here is that candidates often assume `xfs_growfs` works like `resize2fs` for ext4, which can resize unmounted filesystems, but XFS requires the filesystem to be mounted for online growth, and the error message may be misinterpreted as a missing package or wrong filesystem type.

How to eliminate wrong answers

Option A is wrong because the command `xfs_growfs` is specifically designed for XFS filesystems; if the filesystem were not XFS, the error would typically be 'wrong fs type' or the command would not be found, but the question states the command runs and receives an error, implying the filesystem is XFS. Option B is wrong because `xfs_growfs` is a standalone utility from the `xfsprogs` package and does not have runtime dependencies that would cause a failure during execution; unmet dependencies would prevent installation, not command execution. Option C is wrong because a full volume group would prevent extending the logical volume, but `xfs_growfs` only resizes the filesystem to match the already-extended logical volume; the error occurs before any resize attempt, and the volume group's free space is irrelevant if the logical volume itself is not mounted.

Practice this question →
15
MCQhard

After adding the last line to /etc/fstab, the system fails to boot with an error. What is the most likely cause?

A.The UUID for /boot is invalid
B.The mount point /mydata does not exist
C.The device /dev/sdb1 is not formatted
D.The filesystem type ext4 is incorrect for /dev/sdb1
AnswerB

The scenario explicitly states that /mydata does not exist, and systemd requires the mount point directory to be present before mounting any filesystem defined in /etc/fstab. For each fstab entry, systemd generates a mount unit that will fail if the target directory is absent, reporting an error like "mount: mount point /mydata does not exist." Because this directory is missing, the mount unit for /mydata fails, causing the boot to enter emergency mode. The solution is to create the directory with mkdir -p /mydata and then run mount -a to verify.

Why this answer

When a mount point directory specified in /etc/fstab does not exist, the systemd mount unit will fail during boot because the mount operation cannot find the target directory. This is a common misconfiguration: the fstab entry references /mydata, but the directory has not been created with mkdir. The boot process halts with an error indicating the mount point is missing, not that the device or filesystem is invalid.

Exam trap

The trap here is that candidates often focus on device or filesystem issues (UUID, formatting, type) and overlook the simple prerequisite that the mount point directory must exist, which is a fundamental step tested in the EX200.

How to eliminate wrong answers

Option A is wrong because an invalid UUID for /boot would cause a different error (e.g., 'UUID=... does not exist') and would prevent the root filesystem from mounting, not specifically a missing mount point error. Option C is wrong because an unformatted device would produce a 'wrong fs type, bad option, bad superblock' error, not a 'mount point does not exist' error. Option D is wrong because an incorrect filesystem type (e.g., ext4 on an XFS partition) would also yield a 'wrong fs type' error, not a missing directory error.

Practice this question →
16
MCQeasy

An administrator wants to ensure that a file system is automatically mounted at boot. Which file should be edited?

A./etc/rc.local
B./etc/fstab
C./boot/grub2/grub.cfg
D./etc/mtab
AnswerB

/etc/fstab is the filesystem table that the system reads at boot to determine which filesystems must be mounted, where, and with what options. It contains fields for the device or UUID, mount point, filesystem type, mount options, dump flag, and fsck pass order. Both the mount command and systemd's fstab generator use this file to create mount units, making it the definitive configuration for automatic mount-at-boot behavior on a Linux system.

Why this answer

The /etc/fstab file is the standard configuration file that defines how disk partitions, block devices, and remote filesystems should be mounted into the filesystem tree, including options for automatic mounting at boot time. The system reads this file during the boot process (via systemd or the traditional mount -a command) to mount all filesystems listed with the 'auto' or nofail option.

Exam trap

Red Hat often tests the distinction between configuration files (/etc/fstab) and runtime or bootloader files, leading candidates to mistakenly choose /etc/rc.local or /boot/grub2/grub.cfg because they associate 'boot' with bootloader or startup scripts.

How to eliminate wrong answers

Option A is wrong because /etc/rc.local is a legacy script executed at the end of the boot process, not a configuration file for automatic filesystem mounting; it is not designed for managing mount points and is often empty or disabled on modern Red Hat systems. Option C is wrong because /boot/grub2/grub.cfg is the GRUB2 bootloader configuration file that controls the kernel and initramfs selection, not filesystem mounting; editing it would not affect mount behavior. Option D is wrong because /etc/mtab is a dynamically updated file that lists currently mounted filesystems, maintained by the kernel or mount command; it is not a configuration file and changes to it are not persistent across reboots.

Practice this question →
17
MCQhard

The root filesystem is at 90% capacity. Which command increases available space without unmounting?

A.fstrim /
B.lvextend -L +5G /dev/mapper/vg_root-lv_root && xfs_growfs /
C.resize2fs /dev/mapper/vg_root-lv_root
D.lvextend -L +5G /dev/mapper/vg_root-lv_root
AnswerB

Correct: Extends the LV and grows the XFS filesystem.

Why this answer

It first extends the logical volume with `lvextend -L +5G`, then grows the XFS filesystem online with `xfs_growfs /` to utilize the new space without unmounting. This is the proper procedure for XFS filesystems, which require `xfs_growfs` (not `resize2fs`) to expand while mounted.

Exam trap

Red Hat often tests the distinction between filesystem-specific resizing tools (xfs_growfs vs. resize2fs) and the need to run both the LVM extension and the filesystem grow command; the trap here is that candidates may think `lvextend` alone is sufficient or that `resize2fs` works on all filesystems.

How to eliminate wrong answers

Option A is wrong because `fstrim /` only discards unused blocks on SSD-backed filesystems to reclaim free space from the storage device, but it does not increase the actual capacity of the filesystem; it only optimizes existing free space. Option C is wrong because `resize2fs` is used for ext2/ext3/ext4 filesystems, not XFS; running it on an XFS filesystem will fail or cause corruption. Option D is wrong because `lvextend` alone extends the logical volume but does not resize the filesystem; without `xfs_growfs`, the additional space remains invisible to the filesystem and the root filesystem remains at 90% capacity.

Practice this question →
18
MCQeasy

An administrator needs to add a 1GB swap partition on /dev/sdd1. Which series of commands accomplishes this?

A.mkswap /dev/sdd1 && echo '/dev/sdd1 swap swap defaults 0 0' >> /etc/fstab
B.mkfs.swap /dev/sdd1 && swapon /dev/sdd1
C.mkswap /dev/sdd1 && swapon /dev/sdd1
D.fdisk /dev/sdd, create partition, then mkswap /dev/sdd1, swapon /dev/sdd1, and add to /etc/fstab.
AnswerD

This is the complete and correct procedure: fdisk creates a 1 GB partition on /dev/sdd (assigned as /dev/sdd1), mkswap writes the swap signature to that partition, swapon activates the swap for immediate use, and adding the line to /etc/fstab ensures automatic activation at boot. The fstab entry alone or the swapon alone would be incomplete, but combining them covers both current-session and persistent swap. The fdisk step also ensures the partition actually exists with the desired size, unlike the other options that assume a preexisting /dev/sdd1.

Why this answer

It includes all necessary steps: first create the partition with fdisk (since /dev/sdd1 does not exist yet), then format it as swap with mkswap, activate it with swapon, and finally add an entry to /etc/fstab to ensure persistence across reboots. The other options omit the critical partition creation step or fail to make the swap permanent.

Exam trap

Red Hat often tests the requirement to create the partition first before formatting it as swap, leading candidates to mistakenly choose options that assume the partition already exists or skip the fstab entry for persistence.

How to eliminate wrong answers

Option A is wrong because it runs mkswap on /dev/sdd1 without first creating the partition, so the device node does not exist and the command will fail; also, while it adds an fstab entry, it does not activate the swap with swapon. Option B is wrong because mkfs.swap is not a valid command (the correct command is mkswap), and it lacks both partition creation and fstab persistence. Option C is wrong because it assumes /dev/sdd1 already exists and does not create the partition, nor does it add an entry to /etc/fstab, so the swap would not survive a reboot.

Practice this question →
19
MCQeasy

Which command displays the UUID of all file systems on the system?

A.blkid
B.dumpe2fs -h
C.lsblk
D.fdisk -l
AnswerA

blkid is the dedicated utility that enumerates all block devices visible to the system and prints each file system's UUID, TYPE, LABEL, PARTUUID, and other attributes by default. Since it scans every block device under /dev via libblkid, a bare `blkid` command displays the UUIDs of all file systems without needing a device argument or a filesystem-specific tool.

Why this answer

The `blkid` command is the correct choice because it is specifically designed to locate and display block device attributes, including the UUID, filesystem type, and label, for all filesystems on the system. It reads data from the `/dev/disk/by-uuid/` directory and the `udev` database, making it the most direct and reliable tool for querying UUIDs without requiring root privileges for basic output.

Exam trap

Red Hat often tests the distinction between partition-level identifiers (shown by `fdisk -l` for GPT partition UUIDs) and filesystem-level UUIDs (shown by `blkid`), leading candidates to mistakenly choose `fdisk -l` when the question specifically asks for filesystem UUIDs.

How to eliminate wrong answers

Option B is wrong because `dumpe2fs -h` only displays filesystem information for ext2/ext3/ext4 filesystems, not for all filesystem types (e.g., XFS, Btrfs, or swap), and it requires a specific device argument rather than showing all filesystems system-wide. Option C is wrong because `lsblk` lists block devices and their mount points, but it does not display UUIDs by default; while it can show UUIDs with the `-f` or `-o UUID` options, the plain `lsblk` command omits UUIDs, making it incorrect for this specific requirement. Option D is wrong because `fdisk -l` is a partitioning tool that displays partition tables (e.g., MBR or GPT), not filesystem UUIDs; it shows partition UUIDs (for GPT) or partition types, but not the filesystem-level UUID that `blkid` reports.

Practice this question →
20
MCQhard

The administrator wants to reduce the file system size to 40GB. Which command sequence should be used?

A.It is not possible to shrink an XFS file system
B.xfs_repair; lvreduce
C.umount /mnt/data; lvreduce -L 40G; mount; xfs_growfs
D.lvreduce -L 40G /dev/vg00/lvol0; xfs_growfs
AnswerA

XFS file systems are designed to be grow-only. The on-disk structures, especially the B+tree metadata and dynamic inode allocation, do not support in-place shrinkage, and there is neither an xfs_shrink command nor an option in xfs_growfs to reduce the size. To reduce the size, you must back up the data with tools such as xfsdump, destroy or remove the logical volume, recreate it at the desired size, create a new XFS file system, and restore the data. Attempting to shrink a live XFS file system with any tool is unsupported and will lead to corruption.

Why this answer

XFS is a high-performance 64-bit journaling file system that does not support online or offline shrinking. Once an XFS file system is created, its size cannot be reduced; the only way to reclaim space is to back up the data, destroy the file system, recreate it at the desired size, and restore the data. Therefore, any attempt to shrink an XFS file system using lvreduce or similar tools will corrupt the file system.

Exam trap

Red Hat often tests the misconception that any file system can be shrunk using logical volume management tools like lvreduce, but XFS is a notable exception that requires full data migration to reduce its size.

How to eliminate wrong answers

Option A is correct because XFS does not support shrinking. Option B is wrong because xfs_repair is used to repair an XFS file system, not to prepare it for shrinking, and lvreduce would shrink the logical volume without shrinking the XFS file system, causing corruption. Option C is wrong because unmounting and using lvreduce to shrink the logical volume still attempts to shrink an XFS file system, which is impossible; the subsequent mount and xfs_growfs would only grow the file system, not fix the corruption.

Option D is wrong because lvreduce -L 40G shrinks the logical volume without shrinking the XFS file system, and xfs_growfs is used to expand an XFS file system, not to shrink it; this sequence would corrupt the file system.

Practice this question →
21
MCQmedium

An administrator needs to create a new 500MB swap partition on a disk that already has an extended partition. The disk /dev/sda has partitions: /dev/sda1 (primary, /boot), /dev/sda2 (extended), /dev/sda5 (logical, swap, 2GB). The administrator wants to add another swap partition, but fdisk shows no free space. Which approach should be used?

A.Use LVM to create a logical volume for swap
B.Use a file-based swap file
C.Shrink the filesystem on /dev/sda1 to create free space
D.Delete /dev/sda5 and recreate it with larger size
AnswerB

A file-based swap file is the correct choice here because it can be created on any existing mounted filesystem without repartitioning the disk. You create a file (e.g., with fallocate or dd), then format it with mkswap and activate it with swapon, optionally adding an entry to /etc/fstab for persistence. This completely avoids the disk-space constraints and partition-table limitations that block the other options, making it the only immediately viable method to add 500MB of swap.

Why this answer

The disk has no free space (the extended partition consumes all remaining space after /dev/sda1, and logical partitions are contained within it). Adding a swap file is the simplest and safest approach: it does not require repartitioning, works with any filesystem, and is fully supported by systemd and swapon. The administrator can create a 500MB file, format it as swap with mkswap, and enable it with swapon.

Exam trap

The trap here is that candidates assume a new partition must be created, overlooking that swap files are a fully supported and simpler alternative when no free partition space exists.

How to eliminate wrong answers

Option A is wrong because the scenario does not mention LVM being in use; converting a non-LVM disk to LVM would require significant reconfiguration and is not the simplest solution. Option C is wrong because shrinking /dev/sda1 (a primary partition containing /boot) would not create free space outside the extended partition; the extended partition already occupies all remaining space, so any freed space would still be inside the extended partition and would require complex partition table manipulation. Option D is wrong because deleting /dev/sda5 and recreating it larger would still be limited by the size of the extended partition; it does not add a second swap partition, and it would destroy the existing swap without solving the need for additional swap space.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Create and configure file systems questions.

Start 20-question session