CCNA Configure local storage Questions — Page 2 of 2

Multi-Selecteasy

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

Select 2 answers

A.mkfs.ext4

B.pvcreate /dev/sdb1

C.pvcreate /dev/sdb

D.lvcreate

E.vgcreate

AnswersB, C

Creates a PV on a partition.

Why this answer

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

Exam trap

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.The 'pvck' command can be used to check physical volume metadata.

B.The 'pvs' command can repair corrupted metadata.

C.The 'fsck' tool is used to verify LVM metadata.

D.Metadata is stored in the volume group descriptor area (VGDA) on each physical volume.

E.LVM metadata is stored in /etc/lvm directory.

AnswersA, D

Correct: 'pvck' checks physical volume metadata.

Why this answer

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

Exam trap

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

Practice this question →

MCQmedium

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

A.Shrink the logical volume vg01-data and then extend vg01-root

B.Run vgextend vg01 /dev/sdc (assuming /dev/sdc is a new disk) but this command requires the PV to be created first

C.Use lvextend to extend the root logical volume into the free space of sdb1

D.Attach a new disk, create a physical volume on it, add it to vg01 with vgextend, then extend vg01-root

AnswerD

This is the correct sequence: add a new disk, pvcreate, vgextend, then lvextend to increase root.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

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

Practice this question →

MCQmedium

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

A.vgextend vg /dev/sdb

B.resize2fs /dev/vg/lv

C.lvextend -L +2G /dev/vg/lv

D.pvcreate /dev/sdb

AnswerC

lvextend extends a logical volume by the given size.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.Filesystem is corrupted

B.The disk has bad sectors

C.Deleted files still held open by processes

D.Filesystem is mounted with noexe

AnswerC

Open file handles prevent space reclamation.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.The array is in a degraded state and the recovery is waiting for the resync to start, but the event count is zero; the array may need to be forced to start recovery.

B.The recovery is complete because the data is already synchronized.

C.The device /dev/sdb1 was not properly removed; it still holds old metadata that conflicts.

D.The new disk /dev/sdb1 has a different size than the original, causing the recovery to stall.

AnswerA

Event count 0 and recovery stuck at 0% suggests the array isn't initiating resync; sometimes a 'mdadm --assemble --force' or 'mdadm --run' is needed.

Practice this question →

Multi-Selectmedium

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

Select 3 answers

A.vfat

B.ntfs

C.xfs

D.btrfs

E.ext4

AnswersA, C, E

vfat is supported for compatibility.

Why this answer

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

Exam trap

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

Practice this question →

MCQhard

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

A.The device path /dev/vg_data/lv_data is a symlink that may not be available; use /dev/mapper/vg_data-lv_data or UUID.

B.The mount point /srv/data does not exist.

C.The filesystem type specified in fstab is incorrect.

D.The logical volume is not activated at boot because lvm2-lvmetad is not running.

AnswerA

LVM symlinks under /dev/volume_group/ may not be ready at early boot; /dev/mapper/ is more reliable.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.xfs_repair /dev/sdc1

B.file -s /dev/sdc1

C.partprobe /dev/sdc

D.mkfs.xfs /dev/sdc1

AnswerB

The file command checks the actual filesystem type; the partition table shows xfs but maybe it's not created yet.

Practice this question →

MCQhard

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

A.mdadm --fail /dev/md0 /dev/sda1; mdadm --remove /dev/md0 /dev/sda1; mdadm --add /dev/md0 /dev/sdc1

B.mdadm /dev/md0 --fail /dev/sda1; mdadm /dev/md0 --remove /dev/sda1; mdadm /dev/md0 --add /dev/sdc1

C.mdadm /dev/md0 --set-faulty /dev/sda1; mdadm /dev/md0 --remove /dev/sda1; mdadm /dev/md0 --add /dev/sdc1

D.mdadm /dev/md0 --remove /dev/sda1; mdadm /dev/md0 --add /dev/sdc1

E.mdadm /dev/md0 --replace /dev/sda1 --with /dev/sdc1

AnswerB

Correct. This is the proper sequence to replace a failed disk.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.blkid

B.du

C.fdisk

D.df

E.lsblk

AnswersB, D

du shows directory space usage.

Why this answer

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

Exam trap

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

Practice this question →

Multi-Selecteasy

Which THREE of the following are valid steps to create and mount an XFS filesystem on a new disk /dev/sdb?

Select 3 answers

A.mkfs.xfs -f /dev/sdb

B.mount -t xfs /dev/sdb1 /mnt

C.mkfs.xfs /dev/sdb1

D.mount /dev/sdb1 /mnt

E.echo "/dev/sdb1 /mnt xfs defaults 0 0" >> /etc/fstab

AnswersB, C, E

Correct mount command specifying XFS type.

Why this answer

Option B is correct because the `mount -t xfs /dev/sdb1 /mnt` command explicitly specifies the XFS filesystem type with the `-t xfs` flag, ensuring the kernel uses the correct XFS driver to mount the filesystem. This is necessary when the filesystem type is not automatically detected or when you want to be explicit, which is a common requirement in exam scenarios.

Exam trap

The trap here is that candidates assume `mount /dev/sdb1 /mnt` (without `-t xfs`) is always sufficient, but Cisco tests the need for explicit filesystem type specification when the kernel's auto-detection might not reliably identify XFS.

Practice this question →