Red Hat Certified System Administrator EX200 EX200 Questions 76–127 | Page 2/2

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.

Full explanation →

MCQhard

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

A./etc/fstab: /dev/vg/lv /mnt ext4 noexec 0 0

B./etc/rc.d/rc.local: mount /dev/vg/lv /mnt -o noexec

C./etc/fstab: /dev/vg/lv /mnt ext4 defaults,noexec 0 0

D./etc/rc.local: mount -o noexec /dev/vg/lv /mnt

AnswerC

Correct fstab entry.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQmedium

An administrator notices that the /tmp directory is filling up quickly. They want to find all files in /tmp that are larger than 100 MB and owned by user 'ftp', then delete them. The administrator runs: find /tmp -type f -size 100M -user ftp -exec rm {} \;. However, this command deletes only files that are exactly 100 MB, not larger. Which find expression should be used instead?

A.find /tmp -type f -size 100M -user ftp -exec rm {} \;

B.find /tmp -type f -size +100M -user ftp -exec rm {} \;

C.find /tmp -type f -size +100M ! -size 100M -user ftp -exec rm {} \;

D.find /tmp -type f -size +100M -size -100M -user ftp -exec rm {} \;

AnswerB

The + in -size +100M correctly selects every regular file in /tmp owned by the ftp user whose size is greater than 100 MiB, because the plus sign means 'greater than' in find's size test. Combined with -type f to ensure only regular files are considered and -user ftp to restrict ownership, the -exec rm {} \; safely removes each matching file, replacing {} with the pathname. This is the simplest and most precise way to express the administrator's intention.

Why this answer

The `find` command uses `+` before a size value to match files larger than that size, not exactly equal. The original command omitted the `+`, so it matched only files exactly 100 MB. Adding `+100M` correctly selects files larger than 100 MB.

Exam trap

Red Hat often tests the subtle difference between exact size matching and size range matching using the `+` and `-` prefixes, trapping candidates who assume `-size 100M` means 'greater than or equal to' instead of 'exactly equal to'.

How to eliminate wrong answers

Option A is wrong because `-size 100M` matches files exactly 100 MB, not larger, so it fails to delete files exceeding that size. Option C is wrong because `-size +100M ! -size 100M` is redundant and incorrect; `-size +100M` already excludes files exactly 100 MB, and the negation adds no benefit while potentially causing confusion. Option D is wrong because `-size +100M -size -100M` is contradictory and matches no files, as a file cannot be both larger than 100 MB and smaller than 100 MB simultaneously.

Full explanation →

MCQhard

A company runs a critical web application in a container on a Red Hat Enterprise Linux 9 server. The container is started via a systemd service called 'webapp.service'. The service unit file was generated using 'podman generate systemd --new --name webapp'. Recently, after a kernel update and reboot, the service fails to start the container. The administrator runs 'systemctl status webapp.service' and sees 'Active: failed (Result: exit-code)' and 'Process: 1234 ExecStart=/usr/bin/podman run ... (code=exited, status=125)'. The administrator also checks 'journalctl -u webapp.service' and sees: 'Error: unable to start container: container create failed: OCI runtime error: container_linux.go:380: starting container process caused: exec: "/usr/bin/app.sh": stat /usr/bin/app.sh: no such file or directory'. The container image was built locally using a Containerfile that includes 'COPY app.sh /usr/bin/app.sh'. The administrator verifies the image is present locally. What should the administrator do to resolve this issue?

A.Disable SELinux with setenforce 0 and restart the service.

B.Remove the systemd service and regenerate it with 'podman generate systemd --new --name webapp'.

C.Manually create the /usr/bin/app.sh file inside the container using podman exec.

D.Rebuild the container image using 'podman build -t webapp .' to ensure the app.sh file is included, then restart the service.

AnswerD

Rebuilding with podman build -t webapp . rereads the Dockerfile/Containerfile in the current directory and recreates the image; if that file contains a COPY app.sh /usr/bin/app.sh step, the new image will contain the missing script. Because the systemd unit references the webapp image tag, when the service restarts it will pull the updated local image with the same tag and use it to run a fresh container. This addresses the root cause, and restarting the service verifies the container starts cleanly.

Why this answer

The error indicates that the container image is missing the `/usr/bin/app.sh` file, even though the `COPY` instruction was in the Containerfile. The most likely cause is that the image was built before the `app.sh` script was added to the build context, or the build was incomplete. Rebuilding the image with `podman build -t webapp .` ensures the file is properly included in the image layers, resolving the OCI runtime error.

Exam trap

The trap here is that candidates may confuse a missing file inside the container image with a host-level issue (SELinux, service unit, or runtime environment) and overlook the need to rebuild the image with the correct build context.

How to eliminate wrong answers

Option A is wrong because the error is a missing file inside the container, not a SELinux denial; disabling SELinux would not fix the missing binary and introduces a security risk. Option B is wrong because the systemd service unit is correctly generated and the issue is with the container image content, not the service definition; regenerating the unit would not add the missing file. Option C is wrong because `podman exec` requires a running container, but the container fails to start, so you cannot exec into it; even if you could, manual creation would be overwritten on restart and is not a proper fix.

Full explanation →

MCQeasy

A system administrator is setting up storage for a new application server. The application requires two separate filesystems: one for the database (needs to be at least 10GiB) and one for logs (needs at least 5GiB). The server has a single 20GiB disk /dev/sda. The administrator plans to use LVM and a single volume group 'vg_app'. They create physical volume on /dev/sda, create the volume group, and then create two logical volumes: 'lv_db' of 10GiB and 'lv_logs' of 5GiB. They format lv_db as ext4 and lv_logs as xfs, and mount them at /db and /logs respectively. After rebooting, the system fails to mount /logs. What is the most likely cause?

A.The logical volume 'lv_logs' overlaps with 'lv_db'.

B.The /logs entry is missing from /etc/fstab.

C.The physical volume /dev/sda is not recognized by LVM after reboot.

D.The volume group 'vg_app' is not automatically activated.

AnswerB

The /etc/fstab file is the persistent mount table that systemd reads at boot via fstab-generator to create mount units. Without an entry for /dev/vg_app/lv_logs (or its UUID) pointing to /logs, the filesystem will not be mounted automatically after a reboot. The storage device exists and is formatted, but the mount point is empty because no fstab line tells the system to mount it. This is the classic cause of a filesystem that is reachable manually but unavailable after the server restarts.

Why this answer

The most likely cause is that the /logs entry is missing from /etc/fstab. After reboot, the system relies on /etc/fstab to mount filesystems automatically. Since the administrator created and mounted the filesystem manually, but did not add an entry for /logs in /etc/fstab, the mount fails on reboot.

The database mount may succeed if it was added, but the logs mount fails due to the missing fstab entry.

Exam trap

Red Hat often tests the misconception that LVM volumes are automatically mounted after creation, when in fact only the logical volumes are activated; the filesystem mount must be explicitly configured in /etc/fstab.

How to eliminate wrong answers

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

Full explanation →

MCQhard

A complex script uses 'trap' to handle signals. The admin writes 'trap '' SIGINT' to ignore Ctrl+C, but later in the script they want to re-enable the default behavior. Which command restores the default behavior for SIGINT?

A.trap - SIGINT

B.trap : SIGINT

C.trap 2

D.trap SIGINT

AnswerA

Correct. `trap - SIGINT` removes the custom handler and restores the default behavior (terminating the process).

Why this answer

`trap - SIGINT` resets the signal handler for SIGINT to its default behavior. The `trap '' SIGINT` command sets an empty action, which ignores the signal; using `trap - signal` removes that custom handler and restores the default action (typically terminating the process).

Exam trap

The RHCSA exam often tests the subtle distinction between `trap '' signal` (ignore) and `trap - signal` (restore default), where candidates mistakenly think `trap signal` or `trap : signal` resets the handler.

How to eliminate wrong answers

Option B is wrong because `trap : SIGINT` sets the action to the null command `:`, which is a no-op that still ignores the signal (similar to `trap '' SIGINT`), not restoring the default. Option C is wrong because `trap 2` is invalid syntax; signal numbers must be preceded by a dash or used with a signal name, and this would attempt to set a command '2' for the signal, causing an error or unintended behavior. Option D is wrong because `trap SIGINT` without a command or dash is ambiguous and typically results in an error or sets the trap to an empty string, depending on the shell, but does not restore the default handler.

Full explanation →

MCQeasy

A system administrator is troubleshooting a RHEL 9 server that fails to boot and drops into emergency mode. The system console shows an error about mounting /dev/sdb1 on /data. The administrator enters emergency mode, checks /etc/fstab, and sees the line: /dev/sdb1 /data ext4 defaults 0 0. The /data directory exists but /dev/sdb1 is a partition on an external USB drive that was removed. The administrator needs the system to boot normally without the USB drive and plans to fix the mount configuration later. Which course of action should the administrator take?

A.Remove the line from /etc/fstab and run systemctl daemon-reload, then reboot.

B.Add the nofail option to the fstab line, then reboot.

C.Delete the /data directory and reboot.

D.Use a text editor to insert '#' at the beginning of the /dev/sdb1 line in /etc/fstab, then reboot.

AnswerD

Inserting a '#' at the start of the /dev/sdb1 line comments out the entire fstab entry, causing systemd-fstab-generator to skip generating a mount unit for that device. With the entry now inactive, no mount attempt is made at boot, and the system avoids the failure while retaining the rest of the fstab configuration for maintenance or later re-enablement.

Why this answer

Commenting out the /dev/sdb1 line in /etc/fstab with '#' prevents systemd from attempting to mount the missing device during boot, allowing the system to boot normally into multi-user.target. This is a safe, reversible change that does not delete the mount point or alter the filesystem, and it preserves the original configuration for later restoration.

Exam trap

The trap here is that candidates may think removing the line or adding nofail is the correct fix, but they overlook that the system is already in emergency mode and the immediate goal is to boot normally with minimal changes, making a simple comment-out the safest and most reversible action.

How to eliminate wrong answers

Option A is wrong because removing the line from /etc/fstab and running systemctl daemon-reload does not take effect until the next reboot; however, the immediate boot failure is caused by systemd's mount unit for /data failing, and removing the line alone does not address the current emergency mode state—though it would work after reboot, it is less reversible and not the minimal fix. Option B is wrong because adding the nofail option to the fstab line requires editing the file and rebooting, but the system is already in emergency mode; while nofail would prevent future boot failures, it does not resolve the immediate need to boot without the USB drive, and it permanently changes the mount behavior rather than temporarily disabling the entry. Option C is wrong because deleting the /data directory does not fix the mount failure; systemd still attempts to mount /dev/sdb1 on /data, and the missing device will cause the same error, plus deleting the directory may cause data loss if it contains important files.

Full explanation →

MCQmedium

A developer runs the script shown in the exhibit and always sees 'Success' printed, even when the previous command fails. What is the most likely cause?

A.The [[ ]] syntax always evaluates to true

B.The $? variable is only set after external commands, not builtins

C.The $? variable captures the exit status of the [[ command, not the intended command

D.The $? variable always returns 0 in a conditional

AnswerC

In the given script, if an intended command is followed by a [[ ... ]] test, $? will reflect the exit status of the [[ ]] evaluation, not the earlier command. For example, if the script does [[ -f file ]] after running an application, $? becomes 1 when file does not exist, even if the application succeeded. Because $? is overwritten by each subsequent command, any intervening conditional destroys the original exit value.

Why this answer

The `[[ ]]` conditional construct is a shell keyword that itself produces an exit status. When `$?` is checked immediately after `[[ ]]`, it captures the exit status of the `[[ ]]` evaluation (which is 0 if the condition is true, 1 if false), not the exit status of the command that was run before the `[[ ]]`. Since the developer always sees 'Success' printed, the `[[ ]]` condition must be evaluating to true (exit status 0), causing `$?` to be 0 and the script to always take the success path, regardless of the actual previous command's result.

Exam trap

The trap here is that candidates mistakenly think `$?` always reflects the original command's exit status, not realizing that `[[ ]]` is itself a command that resets `$?` to its own exit status, causing the check to always succeed if the `[[ ]]` expression is syntactically valid.

How to eliminate wrong answers

Option A is wrong because `[[ ]]` does not always evaluate to true; it evaluates to true (exit status 0) or false (exit status 1) based on the expression inside it. Option B is wrong because `$?` is set after every command, including shell builtins like `[[ ]]`, `[ ]`, and `echo`; it is not limited to external commands. Option D is wrong because `$?` does not always return 0 in a conditional; it returns the exit status of the most recently executed command, which can be non-zero if that command failed.

Full explanation →

MCQmedium

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

A.Use mdadm to create a RAID1 device and install GRUB on both disks

B.Use parted to create a RAID array directly by specifying the RAID level

C.Use fdisk to create a RAID partition and then format with ext4

D.Use LVM to create a mirrored logical volume for /boot

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQeasy

A developer is running Podman as a non-root user on a Red Hat Enterprise Linux 8 system. The developer successfully runs a container, but notices that after logging out of the SSH session, the container stops. The developer wants the container to continue running even after disconnecting from the SSH session. The container is a simple web server that listens on port 8080. The developer has already enabled lingering for the user account using 'loginctl enable-linger'. However, the container still stops upon logout. What additional step should the developer take to ensure the container persists after logout?

A.Add the --restart=always flag to the podman run command

B.Use podman run --detach to run the container in the background

C.Use podman run -d to run the container in detached mode

D.Create a systemd user service by running 'podman generate systemd --new --name mywebcontainer' and then enable and start the service with 'systemctl --user enable --now container-mywebcontainer.service'

AnswerD

For a rootless Podman container to persist after logout, the correct approach is to make it a systemd user service: podman generate systemd --new --name mywebcontainer creates a unit that will recreate and start the container each time the service is started, and systemctl --user enable --now container-mywebcontainer.service both enables the unit and starts it immediately. This places the container under the user's systemd manager rather than under the login session's process tree. To survive logout entirely, the user must also have lingering enabled (loginctl enable-linger <user>) so that the systemd user instance persists after the last session closes. This is the only option that actually ties the container to systemd and provides session-independent lifecycle management.

Why this answer

Even with lingering enabled, a container started directly via `podman run` is tied to the user's login session and will be terminated when the session ends. To make the container persist independently of the SSH session, it must be managed as a systemd user service. The `podman generate systemd --new` command creates a systemd unit file that can be enabled with `systemctl --user`, ensuring the container starts automatically and continues running after logout.

Exam trap

The trap here is that candidates confuse `--detach` or `-d` with making a container persistent, when in fact those flags only detach the container from the terminal, not from the user's login session; the container still stops when the session ends unless it is managed by systemd.

How to eliminate wrong answers

Option A is wrong because `--restart=always` is a Docker flag, not a Podman flag; Podman uses `--restart` with policies like `always` or `on-failure`, but even if used, it only restarts the container if it exits, not if the user session ends. Option B is wrong because `--detach` (or `-d`) runs the container in the background but still ties it to the user's login session; when the SSH session ends, the container is killed because it is a child of the shell session. Option C is wrong for the same reason as Option B: `-d` is synonymous with `--detach` and does not decouple the container from the user's login session; it only detaches the container from the terminal, not from the session lifecycle.

Full explanation →

MCQhard

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

A.df -h /dev/mapper/vg01-thinvol

B.lsblk /dev/mapper/vg01-thinvol

C.lvdisplay /dev/vg01/thinvol

D.lvs -o lv_name,data_percent

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

Multi-Selectmedium

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

Select 1 answer

A.lvcreate --size 20G vgdata lvdata

B.lvcreate -l 100%FREE -n lvdata vgdata

C.lvcreate -L 20G -n lvdata vgdata

D.lvcreate -l 100%VG -n lvdata vgdata

E.lvcreate -L 100%FREE -n lvdata vgdata

AnswersB

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

Why this answer

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

Exam trap

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

Full explanation →

Multi-Selecteasy

Which TWO commands can be used to display the current date and time in a format like '2023-10-05 14:30:00'?

Select 1 answer

A.date '+%Y-%m-%d %H:%M:%S'

B.cal

C.timedatectl

D.date -Iseconds

E.hwclock

AnswersA

Formats date as required.

Why this answer

The `date` command with the format string `'+%Y-%m-%d %H:%M:%S'` explicitly outputs the current date and time in the requested 'YYYY-MM-DD HH:MM:SS' format. Option D (`date -Iseconds`) outputs date and time in ISO 8601 format (e.g., 2023-10-05T14:30:00+00:00) with a 'T' separator and timezone, not the requested format. Therefore, only option A is correct.

Exam trap

Red Hat often tests the distinction between commands that display time in a raw format versus those that require explicit formatting; candidates may mistakenly choose `timedatectl` because it shows the current time, but it does not output in the exact 'YYYY-MM-DD HH:MM:SS' format without additional parsing.

Full explanation →

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.

Full explanation →

MCQeasy

A company needs to create a user account for a temporary contractor who will work for exactly 90 days. The account must be automatically disabled after 90 days. Which command should the administrator use?

A.useradd -f 90 contractor

B.useradd -e $(date -d '+90 days' +%Y-%m-%d) contractor

C.useradd -e 90 contractor

D.useradd -f 90 -e 0 contractor

AnswerB

Correct. The -e option specifies an account expiration date in YYYY-MM-DD format. Using $(date -d '+90 days' +%Y-%m-%d) dynamically calculates the date 90 days from today, ensuring the account is disabled after exactly 90 days.

Why this answer

The `-e` (expiration date) option sets the date on which the user account will be disabled. Using `$(date -d '+90 days' +%Y-%m-%d)` dynamically calculates the exact date 90 days from today in YYYY-MM-DD format, which meets the requirement for automatic disable after exactly 90 days.

Exam trap

The trap here is confusing the `-e` (account expiration date) option with a number of days, when it actually requires a specific date in YYYY-MM-DD format, and confusing `-f` (inactive days after password expiry) with account expiration.

How to eliminate wrong answers

Option A is wrong because the `-f` option sets the number of days after a password expires until the account is permanently disabled (inactive), not the account expiration date itself; it does not disable the account after 90 days from creation. Option C is wrong because the `-e` option expects a date in YYYY-MM-DD format, not a number of days; passing `90` will be interpreted as an invalid date and the account will not be set to expire. Option D is wrong because `-f 90` sets the inactivity period to 90 days after password expiry, and `-e 0` sets the account expiration date to January 1, 1970 (epoch), which disables the account immediately, not after 90 days.

Full explanation →

MCQmedium

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

A.The physical volume is corrupted and needs to be restored from backup

B.The LVM filter in /etc/lvm/lvm.conf is excluding /dev/sdb1

C.The filesystem on the logical volume has become corrupted, preventing LVM metadata access

D.The UUID of the physical volume has changed due to a disk replacement

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

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.

Full explanation →

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.

Full explanation →

MCQhard

An administrator needs to create a network bond interface 'bond0' with two slave interfaces 'eth0' and 'eth1' using active-backup mode. Which set of commands is correct?

A.nmcli con add type bond ifname bond0; nmcli con add type ethernet ifname eth0 master bond0 slave-type bond

B.Edit /etc/sysconfig/network-scripts/ifcfg-bond0 and ifcfg-eth0 manually

C.teamd -d -c '{"device":"bond0","runner":{"name":"activebackup"},"ports":{"eth0":{},"eth1":{}}}'

D.nmcli con add type bond ifname bond0 mode active-backup; nmcli con add type bond-slave ifname eth0 master bond0; nmcli con add type bond-slave ifname eth1 master bond0

AnswerD

Ly creates the bond interface with `nmcli con add type bond ifname bond0` and adds eth0 as a slave using `type bond-slave`, which is a native nmcli connection type for bond slaves. It directly fulfills the requirement of creating a bond with a slave interface, and the mode can be set separately.

Why this answer

The commands create a bond interface with active-backup mode using nmcli. First, `nmcli con add type bond ifname bond0 mode active-backup` creates the bond with the required mode. Then, `nmcli con add type bond-slave ifname eth0 master bond0` and similarly for eth1 add the slave interfaces.

This is the correct set of commands that fulfills the requirement. Option A uses an alternative syntax but does not set the mode. Option B involves manual editing, and option C uses teamd, which is for teaming, not bonding.

Exam trap

The trap is that candidates often confuse bonding with teaming (Option C) or resort to manual editing (Option B). Additionally, some may use the alternative syntax in Option A without specifying the mode, which would result in the default balance-rr mode instead of active-backup. The commands in Option D are correct because they explicitly set the mode and directly add bond slaves.

How to eliminate wrong answers

Option B is wrong because manually editing configuration files under `/etc/sysconfig/network-scripts/` is deprecated in RHEL 8/9 in favor of `nmcli`; it also does not include the second slave 'eth1' and lacks the active-backup mode specification. Option C is wrong because `teamd` is used for teaming (a different technology), not bonding; the command uses a teamd JSON configuration with 'activebackup' runner, but the question explicitly asks for a bond interface, not a team interface. Option D is wrong because `nmcli con add type bond-slave` is not a valid connection type in `nmcli`; the correct syntax is `type ethernet` with the `master` and `slave-type` options.

Full explanation →

MCQeasy

A user reports that they cannot create files in their home directory. The administrator checks permissions and sees drwxr-xr-x. What is the likely cause?

A.The directory has the sticky bit set

B.The filesystem is read-only

C.The user is not the owner of the directory

D.The user is not in the group

AnswerC

If the user is not the owner of their home directory, the owner permission set (typically rwx) does not apply to them. Depending on whether they belong to the directory's group, they fall under the group or other permissions, which in this case are r-x, lacking write permission. Write access to the directory is a prerequisite for creating a new entry, so without 'w' in the effective permission bits, the create operation fails with 'Permission denied'. The ownership mismatch is therefore the direct cause.

Why this answer

The permissions `drwxr-xr-x` mean the owner has read, write, and execute (rwx) access, while group and others have only read and execute (r-x). Since the user cannot create files (which requires write permission), the user must not be the owner of the directory. Only the owner (or root) can write to it, so the likely cause is that the user is not the owner.

Exam trap

Red Hat often tests the misconception that group membership alone grants write access, but here the group lacks write permission (`r-x`), so even being in the group does not allow file creation; the trap is focusing on group membership rather than the actual permission bits.

How to eliminate wrong answers

Option A is wrong because the sticky bit (indicated by a 't' in the execute position for others, e.g., `drwxr-xr-t`) is not set here; the permissions show a regular 'x' for others, and the sticky bit does not prevent file creation by the owner or those with write permission. Option B is wrong because a read-only filesystem would prevent all write operations system-wide, not just for this user, and the user can still read and execute files in the directory, which would be impossible if the filesystem were read-only. Option D is wrong because group permissions are `r-x`, which do not include write access, so even if the user were in the group, they still could not create files; the issue is the lack of write permission, not group membership.

Full explanation →

MCQhard

A system administrator is troubleshooting a custom service called 'database.service' that fails intermittently. The service is a proprietary database that requires large amounts of memory. The administrator runs systemctl status database and sees 'Active: failed (Result: core-dump)' and the journal shows 'Out of memory: Killed process (database) total-vm:...' The server has 8GB RAM and 2 CPU cores. The service unit file does not contain any memory limits. The application is configured to use up to 4GB. The administrator suspects the systemd service is being killed by the OOM killer. Which action should the administrator take to prevent this issue?

A.Set MemoryMax=6G in the service unit file.

B.Set OOMScoreAdjust=-1000 in the service unit file.

C.Modify kernel parameters to disable the OOM killer.

D.Increase swap space to 16GB.

AnswerB

Setting OOMScoreAdjust=-1000 in the service unit file writes -1000 to /proc/<pid>/oom_score_adj, making the process's OOM score effectively zero and marking it as the kernel's last choice for OOM victim selection. This is a direct, unit-level mitigation that applies only to the custom service, so it doesn't weaken system-wide OOM behavior. It is the recommended way to protect a critical service from being killed.

Why this answer

Setting OOMScoreAdjust=-1000 makes the systemd service less likely to be targeted by the OOM killer. The OOM killer selects processes based on a badness score; a lower score (down to -1000) reduces the likelihood of being killed. Since the service is already configured to use up to 4GB and the server has 8GB RAM, adjusting the OOM score is the targeted fix without disabling kernel protections or over-allocating resources.

Exam trap

The trap here is that candidates confuse systemd's cgroup memory limits (MemoryMax) with the kernel OOM killer's scoring mechanism, or they think disabling the OOM killer or adding swap is a safe solution, when the correct approach is to adjust the OOM score to protect the specific service.

How to eliminate wrong answers

Option A is wrong because MemoryMax=6G would set a cgroup memory limit that could cause the service to be killed by systemd's own OOM logic before the kernel OOM killer acts, and it does not address the kernel OOM killer's scoring; the service already uses up to 4GB, so a 6GB limit may still trigger OOM kills if other processes consume memory. Option C is wrong because disabling the OOM killer entirely (e.g., via vm.oom_kill_allocating_task=0 or panic_on_oom=0) is dangerous and not recommended; it can lead to system hangs or unresponsive states, and it is not a targeted fix for a single service. Option D is wrong because increasing swap space to 16GB only delays OOM conditions and can cause severe performance degradation (thrashing); the OOM killer may still kill the process if memory pressure persists, and it does not address the root cause of the service being scored high by the OOM killer.

Full explanation →

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.

Full explanation →

MCQhard

A server uses firewalld with the default zone set to 'drop'. SSH is allowed only for the 192.168.1.0/24 subnet via a rich rule in the 'internal' zone. After a reboot, SSH connections from that subnet are refused. What is the most likely cause?

A.The subnet 192.168.1.0/24 is not a valid source for rich rules.

B.The network interface is not assigned to the 'internal' zone.

C.The rich rule was not made permanent.

D.The SSH service is not enabled in the default zone.

AnswerB

This is the root cause. firewalld applies zones to traffic based on the ingress interface or source address; if the interface is not permanently assigned to the `internal` zone, it remains in the default zone, which here is `drop` and thus silently discards all incoming packets. The rich rule lives in `internal`, but without the interface assigned there, the rule never sees the SSH traffic. You must run `firewall-cmd --permanent --zone=internal --change-interface=eth0` (then `--reload`) to make the assignment persistent across reboots.

Why this answer

After a reboot, firewalld applies the default zone to all interfaces not explicitly assigned to another zone. Since the rich rule allowing SSH from 192.168.1.0/24 is defined in the 'internal' zone, the network interface must be assigned to that zone for the rule to take effect. If the interface is not assigned (e.g., it remains in the default 'drop' zone), all incoming traffic, including SSH from the allowed subnet, is dropped by default.

Exam trap

The trap here is that candidates assume rich rules are globally evaluated regardless of zone assignment, but firewalld enforces rules only within the zone bound to the interface, so a rule in the wrong zone is effectively invisible to traffic on that interface.

How to eliminate wrong answers

Option A is wrong because 192.168.1.0/24 is a valid source address in firewalld rich rules; rich rules support CIDR notation for source filtering. Option C is wrong because if the rich rule were not made permanent, it would be lost after reboot, but the question states the rule exists (it was configured), and the issue is that it is not being applied—the interface assignment is the missing link. Option D is wrong because the default zone is 'drop', which by design does not allow any services; the SSH service is intentionally allowed only via a rich rule in the 'internal' zone, not in the default zone, so this is expected behavior and not the cause of the refusal.

Full explanation →

MCQmedium

A user was recently added to the 'testgrp' group using `usermod -aG testgrp user1`. However, when they try to access a file owned by testgrp with permissions 660, they get permission denied. What is the most likely reason?

A.The user's primary group is not testgrp.

B.The user did not log out and log back in.

C.The file's group owner is not testgrp.

D.The file's ACL overrides group permissions.

AnswerB

When a user is added to a group via usermod -aG or gpasswd, the change is written to /etc/group, but the running login session still holds the old supplementary group list cache. The kernel caches group memberships in the process credential structure at login, and does not reload them dynamically. Until the user logs out and back in (or runs newgrp/su), the new testgrp membership will not be reflected in group-based permission checks. This is exactly why the user cannot access the file.

Why this answer

When a user is added to a supplementary group with `usermod -aG`, the group membership change does not take effect in the user's current login session. The user must log out and log back in (or start a new login shell) for the new group to be recognized by the kernel's process credential system. Without this, the user's process lacks the group ID in its supplementary group list, so access to a file with group permissions (660) is denied.

Exam trap

The trap here is that candidates assume `usermod -aG` immediately grants access, overlooking that group membership changes require a new login session to take effect in the process's credential cache.

How to eliminate wrong answers

Option A is wrong because the primary group is irrelevant for accessing a file owned by a supplementary group; the file's group permissions are checked against all groups the user belongs to, including supplementary groups. Option C is wrong because the question states the file is owned by testgrp, so the group owner is correct; if it were not, the user would not get group permissions but could still get 'other' permissions (which are 0 in 660). Option D is wrong because there is no mention of ACLs in the scenario, and standard POSIX permissions (660) are in effect; ACLs would only override if explicitly set, and the question does not indicate that.

Full explanation →

100

MCQmedium

A script needs to be run at system boot for a specific user. Which method ensures the script runs with that user's environment?

A.Place the script in /etc/rc.d/rc.local

B.Add an entry to ~/.xprofile

C.Create a systemd user unit in ~/.config/systemd/user/

D.Add the script to the user's crontab with @reboot

AnswerC

A systemd user unit placed in ~/.config/systemd/user/ is managed by the per-user systemd manager and runs in the user's own runtime context, with access to the user's environment, PATH, and systemd user D-Bus. To have it launch at boot rather than only after login, the user must be enabled for lingering (loginctl enable-linger username), after which the user manager starts automatically at boot. This makes it the correct choice for boot-time per-user scripts.

Why this answer

Systemd user units, placed in ~/.config/systemd/user/, are executed in the user's own session context, inheriting the user's environment variables, PATH, and D-Bus session. This ensures the script runs with the specific user's environment at boot, as systemd starts the user manager (systemd --user) early in the boot process for each enabled user.

Exam trap

The trap here is that candidates often assume @reboot in crontab runs with the full user environment, but in reality cron provides a stripped-down environment (e.g., no D-Bus, no systemd user session), making it unsuitable for scripts that depend on user-specific services or graphical session variables.

How to eliminate wrong answers

Option A is wrong because /etc/rc.d/rc.local runs as root during system boot, not as a specific user, so it does not load the target user's environment (e.g., $HOME, $USER, or desktop session variables). Option B is wrong because ~/.xprofile is sourced only when the X display server starts (e.g., via a display manager), not at system boot, and it depends on a graphical session being available. Option D is wrong because @reboot in a user's crontab runs the script under the cron daemon's minimal environment, which lacks the full user session context (e.g., D-Bus, systemd user services, or graphical session variables), and cron may not start until after the user logs in.

Full explanation →

101

MCQmedium

A Red Hat Enterprise Linux 8 system was recently updated via 'yum update'. After reboot, the systemd-logind service fails to start with the error 'Failed to start Login Service' and 'Permission denied' messages in the journal. The administrator checks the SELinux status with 'getenforce' and it returns 'Enforcing'. The administrator also notices that the '/var/run' directory is now a symlink to '/run'. There are no firewall issues. The service works if SELinux is set to permissive. Which single action should the administrator take to resolve this issue permanently?

A.Run 'restorecon -Rv /run' to restore default SELinux contexts for /run

B.Add 'selinux=0' to kernel boot parameters and reboot

C.Edit the systemd-logind service unit to add 'Permissions=yes'

D.Reinstall the systemd-logind package using 'yum reinstall systemd'

AnswerA

Running `restorecon -Rv /run` recursively resets the SELinux context of every file and directory under /run to the default labels defined in the active policy's file_contexts file. After a system update introduces a new SELinux policy, dynamically created runtime files such as logind's sockets and PID files may retain old or invalid types, causing permission denials. This command corrects exactly those mismatches without a reboot and is the minimal, targeted fix for the problem.

Why this answer

After a yum update, SELinux contexts on /run may be incorrect because /var/run is a symlink to /run. When SELinux is enforcing, systemd-logind requires the correct context (typically system_u:object_r:var_run_t:s0) on /run to access its runtime files. Running 'restorecon -Rv /run' restores the default SELinux contexts for all files under /run, resolving the 'Permission denied' errors permanently without disabling SELinux.

Exam trap

The trap here is that candidates may focus on the symlink (/var/run -> /run) and assume a package reinstall or disabling SELinux is needed, rather than recognizing that SELinux contexts on the target directory (/run) are the root cause, which is fixed by a simple restorecon.

How to eliminate wrong answers

Option B is wrong because adding 'selinux=0' disables SELinux entirely, which is not a permanent fix and violates security best practices; the service works in permissive mode, indicating SELinux is the issue but should remain enforcing. Option C is wrong because systemd-logind service units do not have a 'Permissions=yes' directive; this is a fictional option that misleads candidates into thinking a service-level permission setting exists. Option D is wrong because reinstalling the systemd-logind package does not fix SELinux context mismatches; the package files are correct, but the runtime contexts on /run are wrong due to the symlink change.

Full explanation →

102

Multi-Selecteasy

Which TWO commands can be used to display available disk space on mounted filesystems in a human-readable format?

Select 1 answer

A.blkid

B.df -h

C.ls -lh

D.du -sh

E.fdisk -l

AnswersB

df -h correctly shows available disk space on mounted filesystems in human-readable format.

Why this answer

The `df -h` command displays disk space usage for mounted filesystems, with the `-h` flag converting sizes into human-readable units (e.g., KB, MB, GB). This directly meets the requirement of showing available disk space on mounted filesystems in a human-readable format. The `du -sh` command shows the total disk usage of a specific directory or file, not available space on filesystems, so it does not satisfy the question's requirement.

Exam trap

The trap is that `du -sh` shows directory usage, not available space on filesystems. Candidates may mistakenly think it shows available space, but only `df -h` directly provides that information.

Full explanation →

103

MCQeasy

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

A.umount /mnt/backup && mount /mnt/backup

B.mount -o exec,remount /dev/sdc1 /mnt/backup

C.mount -o remount,exec /mnt/backup

D.mount -a -o exec

AnswerB, C

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

104

MCQeasy

Refer to the exhibit. A container named 'db' is running on the host. An administrator runs `podman inspect db` and sees the above output snippet. What can be concluded about the container's network configuration?

A.The container is using host networking mode.

B.The container cannot be reached from other containers.

C.The container's port 3306 is bound to all host interfaces.

D.The container is using bridge networking with a static IP.

AnswerC

The `PortBindings` map reveals that TCP port 3306 inside the container is published with `HostIp: 0.0.0.0` and `HostPort: 3306`, which tells Docker to bind the port on every IPv4 interface of the host machine. Consequently, any request sent to the host's IP address on port 3306 — whether on a local loopback, private LAN card, or public NIC — is forwarded through the bridge to the container. This is the opposite of binding to a single specific host interface, such as 127.0.0.1, and it is the standard way to expose a service to all external networks.

Why this answer

The output snippet from `podman inspect db` shows `"Ports": {"3306/tcp": [{"HostIp": "0.0.0.0", "HostPort": "3306"}]}`. This indicates that the container's port 3306 is mapped to port 3306 on all host interfaces (0.0.0.0), which is the default bridge networking port binding behavior. Therefore, option C is correct.

Exam trap

Red Hat often tests the distinction between host networking mode and bridge networking with port mapping, where candidates mistakenly think that any port binding to 0.0.0.0 implies host networking, but it actually indicates bridge mode with a published port.

How to eliminate wrong answers

Option A is wrong because host networking mode would show `"NetworkMode": "host"` in the inspect output, and the port mapping would not appear as a bind to 0.0.0.0; instead, the container would share the host's network stack directly. Option B is wrong because the container can be reached from other containers on the same bridge network via its IP address or container name, and the port mapping shown does not prevent inter-container communication. Option D is wrong because the inspect output does not show a static IP assignment; bridge networking with a static IP would require a custom network configuration with an explicit IP address, which is not indicated in the provided snippet.

Full explanation →

105

MCQhard

A system administrator is troubleshooting a container that fails to start with the error: 'Error: cannot start container: listen tcp4 :80: bind: address already in use'. The container is intended to serve HTTP traffic on port 80. What is the most appropriate first step to resolve this issue?

A.Add --force to the podman run command

B.Check which process is using port 80 and either stop that process or use a different host port

C.Add --replace to the podman run command

D.Use --net=host to bypass the port mapping

AnswerB

Start by identifying which process holds port 80 with `ss -tlnp` or `lsof -i :80`; the output shows the process ID and name. You can then stop that service with `systemctl stop` or `kill` if it is no longer needed, or simply run the container with a different host port mapping like `-p 8080:80` to avoid the conflict. This is the standard, correct approach because it either frees the required resource or selects an unused port.

Why this answer

The error 'address already in use' indicates that port 80 on the host is already occupied by another process. The correct first step is to identify that process using commands like `ss -tlnp` or `lsof -i :80` and either stop it or map the container to a different host port (e.g., `-p 8080:80`). This directly resolves the binding conflict without risking data loss or unintended behavior.

Exam trap

The trap here is that candidates may confuse container-level options like `--replace` or `--force` with host-level port management, or assume `--net=host` bypasses port conflicts, when in fact it still requires the port to be available on the host.

How to eliminate wrong answers

Option A is wrong because `--force` is not a valid flag for `podman run`; it is used with `podman rm` or `podman stop` to forcefully remove or stop a container, not to bypass port conflicts. Option C is wrong because `--replace` is used with `podman run` to stop and remove an existing container with the same name before starting a new one, but it does not address the underlying port binding conflict on the host. Option D is wrong because `--net=host` makes the container share the host's network stack, which would still require port 80 to be free on the host and does not resolve the conflict; it also reduces network isolation.

Full explanation →

106

MCQeasy

Refer to the exhibit. What does the file permission -rw------- indicate about /etc/shadow?

A.Root user can read, write, and execute; group and others have no access.

B.Owner can read and write; group can read; others can read.

C.Owner can read; group can read; others cannot access.

D.Only root user can read and write; others have no access.

AnswerD

The permission string begins with a hyphen indicating a regular file, followed by 'rw-' for the owner, which is root (or the file's owning user). The subsequent '---' for group and '---' for others show those classes have zero access, so only the owner can read and write (and not execute). This matches typical root-owned file permissions.

Why this answer

The permission string `-rw-------` breaks down as: owner (root) has read (4) and write (2) permissions, and no execute (0); group has no permissions (---); others have no permissions (---). Since `/etc/shadow` is owned by root, only the root user can read and write the file, while all other users (including group members and others) have zero access. Option D correctly states this.

Exam trap

Red Hat often tests the misconception that `-rw-------` means the owner can execute, or that the hyphen in the execute position is easily overlooked, causing candidates to incorrectly assume execute permission is present.

How to eliminate wrong answers

Option A is wrong because the permission string shows no execute bit for the owner (the third character is `-`, not `x`), so the root user cannot execute the file; also, group and others have no access, but the statement incorrectly includes execute. Option B is wrong because it claims group and others can read, but the permission string shows `---` for both group and others, meaning no read access. Option C is wrong because it says the owner can only read, but the owner actually has both read and write permissions (the second character is `w`).

Full explanation →

107

MCQeasy

A developer wrote a shell script that is intended to back up log files by copying all .log files from /var/log/myapp to /backup/logs. The script runs daily via cron but the backup folder is empty. The script contains the following line: `cp /var/log/myapp/*.log /backup/logs/`. What is the most likely reason the backup fails?

A.The PATH variable in cron is not set, so cp cannot be found.

B.The script does not have execute permission for the user running cron.

C.No .log files exist in /var/log/myapp at the time of script execution, causing the glob to match nothing.

D.The cron job is not enabled because the crontab syntax is incorrect.

AnswerC

In a non-interactive shell, an unmatched glob like /var/log/myapp/*.log is not expanded and is passed literally to cp. cp then attempts to copy a file named `*.log`, which does not exist, producing a 'No such file or directory' error and creating no backup. Unless the script checks the glob result or has error handling, this failure can be silent, especially if cron's stderr output is not inspected.

Why this answer

The glob pattern `*.log` in the `cp` command is expanded by the shell at the time the script runs. If no `.log` files exist in `/var/log/myapp` when the cron job executes, the shell passes the literal string `*.log` to `cp`, which then fails with a 'No such file or directory' error (or, depending on shell settings, may silently do nothing). This is a common issue when log rotation or cleanup removes files before the backup runs.

Exam trap

Red Hat often tests the misconception that cron PATH or permissions are the root cause, but the real trap is that glob expansion happens at script execution time and an empty glob silently fails, leading to an empty backup destination.

How to eliminate wrong answers

Option A is wrong because `cp` is a built-in shell command or located in standard paths like `/bin/cp` or `/usr/bin/cp`, and cron typically sets a minimal PATH that includes `/usr/bin` and `/bin`, so `cp` is almost always found. Option B is wrong because the script itself does not need execute permission if it is invoked via `sh script.sh` or if the cron job line directly calls `sh`; the issue is about file existence, not permissions. Option D is wrong because the question states the script runs daily via cron, implying the crontab syntax is correct and the job is enabled; the backup folder is empty, not that the job fails to run.

Full explanation →

108

MCQeasy

Which command sets the password maximum age for user 'bob' to 30 days?

A.chage -M 30 bob

B.passwd -x 30 bob

C.usermod -e 30 bob

D.chage -W 30 bob

AnswerA, B

chage -M 30 bob is the standard command for configuring password aging in RHCSA environments, setting the maximum password age to exactly 30 days. This writes to the fifth field of bob's /etc/shadow entry, after which the password will expire and require change. It is the direct equivalent of passwd -x, but is more commonly seen in scripts and documentation.

Why this answer

Both `chage -M 30 bob` and `passwd -x 30 bob` are valid commands to set the maximum password age for user 'bob' to 30 days. `chage -M` is the commonly used and RHCSA-recommended tool for password aging, but `passwd -x` also works on Red Hat systems. Option C (`usermod -e`) sets account expiration, not password maximum age. Option D (`chage -W`) sets the warning period before expiry.

Exam trap

Candidates often think only `chage -M` is valid for setting password max age, but `passwd -x` is also acceptable. The mistake is to mark B as wrong when it is actually correct.

How to eliminate wrong answers

Option B is wrong because `passwd -x 30 bob` sets the maximum password age, but the `-x` option is not a standard `passwd` flag; `passwd` uses `-x` only in some older or non-standard implementations, and on RHEL 8/9 the correct command for this is `chage -M`, not `passwd`. Option C is wrong because `usermod -e 30 bob` sets the account expiration date (in YYYY-MM-DD format or days since epoch), not the password maximum age; `-e` controls when the account itself expires, not the password. Option D is wrong because `chage -W 30 bob` sets the warning period (in days) before password expiration, not the maximum age; `-W` defines how many days before expiry the user is warned, not the expiry duration.

Full explanation →

109

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.

Full explanation →

110

MCQmedium

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

111

MCQmedium

A developer needs to search for the string 'ERROR' in all files under /var/log, but wants to exclude files ending with '.gz'. Which command is correct?

A.grep -r --exclude='*.gz' 'ERROR' /var/log

B.grep -R --exclude='*.gz' 'ERROR' /var/log

C.grep -l 'ERROR' /var/log/*.gz

D.grep -v '*.gz' -r 'ERROR' /var/log

AnswerA

The -r flag makes grep recursively descend into /var/log and all of its subdirectories, while --exclude='*.gz' instructs grep to skip any file whose basename matches that glob, thereby avoiding compressed log files. This precisely implements the requested search: only uncompressed files under /var/log are examined for the string 'ERROR'. Using -r rather than the similar -R is also safer because -r does not dereference symbolic links, keeping the search confined to the named directory tree.

Why this answer

`grep -r` performs a recursive search through all files under /var/log, and the `--exclude='*.gz'` option tells grep to skip any files matching the glob pattern '*.gz'. This combination ensures that only non-compressed log files are searched for the string 'ERROR', meeting the requirement exactly.

Option B uses `-R` instead of `-r`. In GNU grep, `-R` implies `--dereference-recursive`, which follows symbolic links into other directories. This could lead to searching outside `/var/log` if any symlinks point elsewhere, making it less precise for the stated requirement. While `-r` and `-R` are often conflated, `-R` is not equivalent to `-r` when symlinks are present, and the standard recursive option is `-r`. Therefore, B is incorrect.

Exam trap

Red Hat often tests the distinction between `--exclude` (which filters files by name) and `-v` (which inverts line matches), leading candidates to mistakenly use `-v` with a glob pattern to try to exclude files.

How to eliminate wrong answers

Option B is wrong because `grep -R` is equivalent to `grep -r` in most implementations, but the key issue is that the `--exclude` pattern is incorrectly quoted with single quotes inside double quotes or vice versa; however, the primary flaw is that `-R` is not a standard grep option (it is often used for dereferencing symlinks, but the correct recursive flag is `-r`). Option C is wrong because `grep -l 'ERROR' /var/log/*.gz` only lists files matching 'ERROR' that end with '.gz', which is the opposite of what is needed (it excludes non-.gz files). Option D is wrong because `grep -v '*.gz'` treats '*.gz' as a regex pattern to invert matches on lines, not as a file exclusion pattern, and the `-r` flag is misplaced after the pattern; this command would search recursively but exclude lines containing the literal string '*.gz', not files ending with '.gz'.

Full explanation →

112

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.

Full explanation →

113

MCQeasy

A user wants to run a container that will restart automatically unless explicitly stopped by the administrator. Which podman run option should be used?

A.--restart=on-failure

B.--restart=always

C.--restart=unless-stopped

D.--restart=no

AnswerC

--restart=unless-stopped is correct because it ensures the container is automatically restarted whenever it exits, for any reason, with one crucial exception: if an administrator explicitly issues 'docker stop', the container will not be restarted by the policy until it is manually started again. Docker distinguishes between a container that stopped on its own and one that was intentionally stopped, so this matches the requirement exactly. It also survives daemon restarts and host reboots, making it a robust production choice.

Why this answer

The `--restart=unless-stopped` policy ensures the container restarts automatically whenever it exits, unless the administrator explicitly stops it with `podman stop`. This matches the requirement exactly: the container will keep restarting even after system reboots or crashes, but will not restart if the admin manually stops it. The other policies either do not restart on manual stop (`always`) or only restart on non-zero exit codes (`on-failure`).

Exam trap

Candidates often choose `--restart=always` thinking it will restart automatically except when manually stopped. However, the key difference is that `--restart=always` will restart the container after a system reboot even if it was manually stopped before the reboot, whereas `--restart=unless-stopped` will not. The question's requirement 'unless explicitly stopped by the administrator' matches `unless-stopped` because it ensures the container does not restart after a manual stop, even across reboots.

How to eliminate wrong answers

Option A is wrong because `--restart=on-failure` only restarts the container when it exits with a non-zero exit code (indicating an error), not when it exits cleanly or is stopped by the administrator. Option B is wrong because `--restart=always` restarts the container regardless of why it stopped, including if the administrator explicitly stops it with `podman stop`, which violates the requirement. Option D is wrong because `--restart=no` is the default and never restarts the container automatically after it exits.

Full explanation →

114

MCQeasy

A server has been compromised, and the administrator suspects an unauthorized user account may have been created. Which file should be examined to list all local user accounts?

A./etc/shadow

B./etc/passwd

C./etc/shells

D./etc/login.defs

AnswerB

/etc/passwd is the authoritative, world-readable file that lists every local user account on a Linux system, with one line per account. Each colon-separated record contains the username, a placeholder for the password (typically x), the numeric UID, primary GID, GECOS comment, home directory, and login shell. This is exactly what an administrator should inspect to identify unexpected accounts, such as a newly added UID 0 user or a bad actor’s backdoor entry.

Why this answer

The /etc/passwd file is the primary local user account database on Linux systems, listing all user accounts with fields such as username, UID, GID, GECOS, home directory, and login shell. Examining this file reveals every local user account, including any unauthorized ones that may have been created, because each account must have an entry here to be recognized by the system.

Exam trap

Red Hat often tests the misconception that /etc/shadow contains the list of user accounts, but it only stores password hashes and aging data; the actual account list is always in /etc/passwd.

How to eliminate wrong answers

Option A is wrong because /etc/shadow stores encrypted password hashes and password aging information, not the list of user accounts; it is a companion file to /etc/passwd but does not contain usernames by itself. Option C is wrong because /etc/shells lists valid login shells (e.g., /bin/bash, /bin/sh) and is used by chsh and FTP daemons to validate shell choices, not to enumerate user accounts. Option D is wrong because /etc/login.defs defines configuration defaults for user account creation (e.g., UID ranges, password aging parameters) but does not contain the actual list of user accounts.

Full explanation →

115

MCQhard

Refer to the exhibit. The administrator wants to add an additional 5GB to the /mnt/data filesystem. There is no unpartitioned space on /dev/sdb. Which is the correct procedure?

A.Use resize2fs /dev/sdb1 to expand filesystem.

B.Add a new disk, create a physical volume, extend volume group, and extend logical volume.

C.Use fdisk to delete and recreate /dev/sdb1 with larger size, run partprobe, then xfs_growfs /mnt/data.

D.Use fdisk to delete and recreate /dev/sdb1 with larger size, then mount.

AnswerC

Correct steps for XFS on a partition.

Why this answer

The filesystem on /mnt/data is XFS (as shown in the exhibit), and XFS cannot be shrunk; it can only be grown. Since there is no unpartitioned space on /dev/sdb, the partition itself must be resized. The correct procedure is to delete and recreate the partition with a larger size using fdisk, inform the kernel of the change with partprobe, and then grow the XFS filesystem with xfs_growfs /mnt/data.

Exam trap

Red Hat often tests the distinction between XFS and ext4 filesystem resizing commands; the trap here is that candidates familiar with ext4 might incorrectly choose resize2fs (Option A) or forget that XFS requires xfs_growfs after partition resizing, leading them to select Option D without the grow step.

How to eliminate wrong answers

Option A is wrong because resize2fs is used for ext2/ext3/ext4 filesystems, not XFS; using it on an XFS filesystem would fail. Option B is wrong because adding a new disk, creating a physical volume, extending the volume group, and extending a logical volume is the procedure for LVM-based filesystems, but the exhibit shows /dev/sdb1 is a standard partition, not an LVM logical volume. Option D is wrong because after deleting and recreating the partition with a larger size, you must run partprobe to update the kernel's partition table and then grow the filesystem with xfs_growfs; simply mounting does not resize the filesystem.

Full explanation →

116

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.

Full explanation →

117

MCQmedium

Refer to the exhibit. What is the most likely cause of this failure?

A.Another process is already bound to port 22.

B.The sshd service is not enabled.

C.SELinux is blocking the service.

D.The /etc/ssh/sshd_config file is missing.

AnswerA

The log message 'Cannot bind any address' is what OpenSSH emits when bind(2) returns EADDRINUSE, meaning another process already holds a listening socket on 0.0.0.0:22 or the specific address configured in sshd_config. This can happen after a failed shutdown leaves an old sshd running, or if another daemon (e.g., a second sshd, a proxy) grabbed port 22. Confirm by checking `ss -tlnp` or `sudo lsof -i :22` to identify the PID holding the port.

Why this answer

The error message in the exhibit indicates that the sshd service failed to start because port 22 is already in use. This is a classic port conflict, where another process (e.g., another SSH daemon, a web server misconfigured to use port 22, or a leftover process) has bound to the same TCP port. The system log or `ss -tlnp` would show the PID and name of the conflicting process, confirming that port 22 is unavailable for the new sshd instance.

Exam trap

Red Hat often tests the distinction between service startup failures caused by port conflicts versus configuration or SELinux issues, and the trap here is that candidates may assume SELinux or a missing config file is the cause when the error message explicitly states 'address already in use'.

How to eliminate wrong answers

Option B is wrong because if the sshd service were not enabled, the error would occur at boot time (service not started) or when manually starting it, but the specific 'address already in use' message points to a port conflict, not a disabled service. Option C is wrong because SELinux blocking the service would produce an AVC denial message in the audit log (e.g., 'SELinux is preventing sshd from binding to port 22'), not a generic 'address already in use' error. Option D is wrong because a missing /etc/ssh/sshd_config file would cause sshd to fail with a configuration file error (e.g., 'Could not load host key' or 'fatal: Cannot open /etc/ssh/sshd_config'), not a port binding failure.

Full explanation →

118

MCQeasy

A user wants to run a command in the background after logging out of an SSH session. Which method ensures the process continues even after logout?

A.Run 'nohup command &' before logout

B.Run 'command', press Ctrl+Z, then type 'bg' and logout

C.Run 'command &' and then exit

D.Run 'command & disown' then logout

AnswerA

nohup ignores SIGHUP, allowing the process to continue.

Why this answer

`nohup` ignores the SIGHUP signal that the shell sends to its child processes when the parent shell exits (e.g., upon logout). By running `nohup command &`, the command is placed in the background and will continue running even after the SSH session terminates, as it is immune to the hangup signal.

Exam trap

The trap here is that candidates often think `&` alone or `bg` is sufficient to keep a process running after logout, but they miss that the shell sends SIGHUP to all child processes (including background jobs) upon exit unless explicitly ignored with `nohup` or handled with `disown` in a shell that supports `huponexit` off.

How to eliminate wrong answers

Option B is wrong because suspending a job with Ctrl+Z and then resuming it in the background with `bg` does not protect the process from SIGHUP; when the shell exits, the background job will still receive SIGHUP and terminate. Option C is wrong because running `command &` alone does not prevent SIGHUP; the background job is still a child of the shell and will be killed when the shell exits. Option D is wrong because `disown` removes the job from the shell's job table, but it does not prevent the shell from sending SIGHUP to the process on logout; the process may still receive SIGHUP depending on the shell implementation (e.g., bash sends SIGHUP to disowned jobs by default unless `huponexit` is disabled).

Full explanation →

119

MCQmedium

An administrator needs to compress a directory containing subdirectories and files into a single archive file, with maximum compression, and exclude all '*.tmp' files. Which command should be used?

A.tar -czvf archive.tar.gz --exclude='*.tmp' /path/to/dir

B.tar -czvf archive.tar.gz /path/to/dir --exclude='*.tmp'

C.tar -cjvf archive.tar.bz2 --exclude='*.tmp' /path/to/dir

D.tar -czvf archive.tar.gz /path/to/dir

AnswerC

The -j flag invokes bzip2, which provides a considerably higher compression ratio than gzip, satisfying the 'maximum compression' requirement. Placing --exclude='*.tmp' before the source directory ensures the pattern is active before tar reads the files, so temporary files are omitted. The output suffix .tar.bz2 matches the flag and makes the archive self-descriptive.

Why this answer

The question specifies 'maximum compression'. Among common tar compression methods, bzip2 (via the -j flag) typically provides better compression ratios than gzip (-z), though it is slower. Option C uses `tar -cjvf` with the `--exclude` option placed correctly before the source directory, which is the proper syntax for tar exclusions.

This command creates a .tar.bz2 archive with maximum compression while excluding all *.tmp files. Option A uses gzip, which offers faster compression but lower ratios, making it incorrect for 'maximum compression'. Options B and D also fail: B has incorrect syntax (--exclude after the directory), and D omits the exclude option entirely.

Exam trap

Red Hat often tests the distinction between compression methods: gzip (-z) is faster but yields larger archives, while bzip2 (-j) provides better compression at the cost of speed. Candidates may assume -z is the default or best option, but for 'maximum compression', bzip2 is superior.

How to eliminate wrong answers

Option B is wrong because the `--exclude` option is placed after the source directory `/path/to/dir`, which causes tar to ignore the exclusion pattern — tar processes positional arguments in order, and the exclude pattern must precede the source path to take effect. Option C is wrong because it uses `-j` for bzip2 compression instead of `-z` for gzip; while bzip2 can achieve higher compression ratios, the question specifies 'maximum compression' in the context of the commonly used gzip format, and the output file extension `.tar.bz2` does not match the expected `.tar.gz` archive. Option D is wrong because it omits the `--exclude='*.tmp'` option entirely, so all `*.tmp` files will be included in the archive, failing the requirement to exclude them.

Full explanation →

120

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.

Full explanation →

121

MCQhard

Refer to the exhibit. The backup script runs every 5 minutes but generates errors. What is the most likely cause?

A.The script is owned by root.

B.The cron daemon is not running.

C.The script uses absolute paths.

D.The script is not executable.

AnswerD

This is the cause. The exhibit shows the script has permissions 644, meaning there is no execute bit set for the owner, group, or others. When cron encounters a script path in a crontab, it invokes that file directly via execve(), which requires at least one execute bit; otherwise the kernel returns EACCES and the job logs 'Permission denied' or sends a non-zero exit status. The file must be made executable, for example with 'chmod +x', for cron to run it successfully.

Why this answer

The cron job fails because the script lacks execute permissions. Cron requires that scripts specified in crontab entries have the executable bit set (chmod +x) for the user under whose crontab the job runs. Without this, the cron daemon cannot spawn the script as a process, resulting in errors.

Exam trap

Red Hat often tests the distinction between file ownership and file permissions, where candidates mistakenly assume root ownership is the problem, but the actual issue is the missing executable bit that cron strictly enforces.

How to eliminate wrong answers

Option A is wrong because ownership by root does not prevent a script from executing; root ownership is common and cron can run root-owned scripts if the crontab belongs to root or the script has appropriate permissions. Option B is wrong because if the cron daemon were not running, no cron jobs would execute at all, not just this one script — the question states the script runs but generates errors, implying the daemon is active. Option C is wrong because using absolute paths is actually a best practice in cron scripts to avoid PATH issues; absolute paths do not cause execution errors.

Full explanation →

122

MCQmedium

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

A.xfs_repair /dev/sdc1

B.file -s /dev/sdc1

C.partprobe /dev/sdc

D.mkfs.xfs /dev/sdc1

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

123

MCQhard

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

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Full explanation →

124

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.

Full explanation →

125

MCQeasy

Consider the script in the exhibit. The script is run in a directory containing 'a.txt' and 'b.txt' but also has a subdirectory 'backup' with .txt files. What will be the output?

A.An error because the for loop cannot iterate over files with spaces

B.Line counts for .txt files in 'backup' only

C.Line counts for 'a.txt' and 'b.txt' only

D.Line counts for all .txt files including those in 'backup'

AnswerC

The shell expands `*.txt` to the names of matching files in the current directory, which in the given directory listing are `a.txt` and `b.txt`. The `for i in` loop assigns each name in turn to `i`, and `wc -l "$i"` prints the line count for each file. Files in subdirectories such as `backup` are not matched because globbing is not recursive unless `**` is used.

Why this answer

The script uses `for i in *.txt`, which by default only matches .txt files in the current directory, not in subdirectories. Since 'a.txt' and 'b.txt' are in the current directory, the loop iterates over them and runs `wc -l` on each, outputting their line counts. The 'backup' subdirectory is not traversed because the glob pattern does not include paths with directories.

Exam trap

Red Hat often tests the candidate's understanding that shell glob patterns like `*.txt` do not recurse into subdirectories, leading many to incorrectly assume that all .txt files in the entire directory tree are processed.

How to eliminate wrong answers

Option A is wrong because the for loop can iterate over files with spaces if the glob pattern is unquoted and the files are properly handled (though the script does not quote $i, which could cause issues with spaces, but the question states no files have spaces, so no error occurs). Option B is wrong because the glob `*.txt` does not match files in the 'backup' subdirectory; it only matches .txt files in the current directory. Option D is wrong because the glob pattern does not recursively include files in subdirectories; only files directly in the current directory are matched.

Full explanation →

126

MCQeasy

An administrator wants to add the user 'jane' to the supplementary groups 'wheel' and 'docker' without removing her from other groups. Which command should be used?

A.groupmems -a jane -g wheel,docker

B.usermod -aG wheel,docker jane

C.usermod -a -G wheel,docker jane

D.usermod -G wheel,docker jane

AnswerB, C

The -aG form is a compact combined option where -a enables append mode and -G specifies the supplementary group list, so the effect is exactly the same as usermod -a -G. It adds jane to wheel and docker while retaining any other supplementary groups she already has. Although it is less readable than the separated form, it is a fully valid and correct way to accomplish the task.

Why this answer

Both `usermod -aG wheel,docker jane` and `usermod -a -G wheel,docker jane` are valid commands to append the user to the specified supplementary groups without removing her from other groups. The `-a` (append) flag can be combined with `-G` as `-aG` or provided separately (`-a -G`); both forms work identically. Option D (`usermod -G`) without `-a` would overwrite all supplementary groups, which is incorrect.

Option A uses `groupmems`, which is not the standard command for this task and has incorrect syntax.

Exam trap

The exam may include both `-aG` and `-a -G` as options. Both are correct and achieve the append effect. The dangerous trap is choosing `-G` alone (option D), which replaces all existing supplementary groups.

How to eliminate wrong answers

Option A is wrong because `groupmems` is used to manage members of a single group (e.g., add/remove users from one group at a time) and does not support specifying multiple groups in a comma-separated list; it would fail or behave unexpectedly. Option C is wrong because `-a -G` is syntactically valid but functionally identical to `-aG`; however, the option order `-a -G` is non-standard and may cause parsing issues on some systems, making it less reliable than the combined `-aG` form. Option D is wrong because `usermod -G wheel,docker jane` without the `-a` flag will replace all supplementary groups for 'jane' with only 'wheel' and 'docker', removing her from any other groups she belongs to, which violates the requirement to not remove her from other groups.

Full explanation →

127

MCQhard

A junior administrator configured a new network interface (ens224) with a static IP address using a configuration file in /etc/sysconfig/network-scripts/ifcfg-ens224. After restarting the network service, the interface comes up but does not get the IP address. The administrator runs 'ip addr show ens224' and sees no IP address assigned. The interface is listed as DOWN. The administrator then runs 'ifup ens224' manually, which succeeds, and the IP address appears. What is the most likely cause?

A.The ONBOOT directive is set to no in the ifcfg file.

B.The network service is not enabled to start at boot.

C.The interface name does not match the device file.

D.There is a conflict with NetworkManager managing the interface.

AnswerA

The ONBOOT directive in the interface's ifcfg file (e.g., /etc/sysconfig/network-scripts/ifcfg-eth0) explicitly controls whether the interface is activated when the system boots. When ONBOOT=no, the interface is fully configured but is deliberately skipped by the boot-time startup sequence, so it stays down until an administrator runs ifup or uses NetworkManager to connect manually. Manual activation succeeds because the rest of the configuration (e.g., IP address, netmask, gateway) is valid, and the service that performs ifup is already running. This exactly matches the symptom of an interface that is correctly configured but not active after a reboot.

Why this answer

The ONBOOT directive controls whether the interface is automatically brought up at system boot. When set to 'no', the interface configuration file is read but the interface remains DOWN after a network service restart, requiring manual intervention via 'ifup'. The junior administrator's observation that 'ifup ens224' succeeds confirms the configuration is valid, but the interface fails to activate automatically due to ONBOOT=no.

Exam trap

In Red Hat Enterprise Linux, the ONBOOT directive in ifcfg files controls whether the interface is brought up automatically at boot. Candidates often mistakenly think that enabling the network service at boot is sufficient, but each interface must have ONBOOT=yes to activate automatically. Without it, the interface remains DOWN until manually started with ifup.

How to eliminate wrong answers

Option B is wrong because the network service being enabled or disabled at boot affects whether the service itself starts, not whether individual interfaces are activated after the service is already running; the administrator restarted the service manually, so the service was running. Option C is wrong because if the interface name did not match the device file, the 'ifup ens224' command would fail or the interface would not appear at all in 'ip addr show'; the manual activation succeeded, proving the name matches. Option D is wrong because NetworkManager managing the interface would typically cause a conflict only if both network scripts and NetworkManager try to control it, but the manual 'ifup' would still fail or be overridden; the successful manual activation indicates NetworkManager is not interfering, or the interface is explicitly configured to be controlled by network scripts.

Full explanation →

Red Hat Certified System Administrator EX200 (EX200) — Questions 76–127