Red Hat Certified System Administrator EX200 EX200 Questions 376–427 | Page 6/6

376

Multi-Selecteasy

Which TWO of the following are true about creating simple shell scripts in Red Hat Enterprise Linux?

Select 2 answers

A.The shebang line (e.g., #!/bin/bash) is used to specify the interpreter.

B.Scripts must be stored in /usr/local/bin to be found by the shell.

C.The script file must have execute permission (chmod +x) to be run directly.

D.A script must be compiled before it can be run.

E.A script must have a .sh file extension to be executable.

AnswersA, C

The shebang line is a special two-byte sequence (0x23 0x21) followed by an absolute path to an interpreter, such as #!/bin/bash. When the kernel tries to execute a script directly, it reads the first line, sees the shebang, and launches the specified interpreter with the script as its argument. If the interpreter path is invalid, the script fails with a "bad interpreter" error, so the shebang is essential for scripts executed as standalone commands. However, a script can omit the shebang if it is explicitly run as the argument to an interpreter, e.g., bash script.sh.

Why this answer

The shebang line (e.g., #!/bin/bash) tells the kernel which interpreter to use when executing the script. Without it, the shell may fall back to the default interpreter (often /bin/sh) or fail to run the script correctly. This is a fundamental requirement for any interpreted script in Linux.

Exam trap

Red Hat often tests the misconception that file extensions or specific directories are mandatory for script execution, when in fact the shebang line and execute permission are the only requirements.

Full explanation →

377

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

Extending the logical volume then growing the XFS filesystem online satisfies the no-unmount constraint, since XFS supports live growth via xfs_growfs on a mounted filesystem. The lvextend command adds 5 GB from the volume group, immediately increasing available space on the root 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 →

378

MCQeasy

A user wants to set an environment variable named 'EDITOR' to the value '/usr/bin/vim' so that it is available in all future login sessions. Which file should the user add the export command to?

A.~/.bash_logout

B.~/.bash_profile

C./etc/bashrc

D.~/.bashrc

AnswerB

When a user logs in, Bash reads ~/.bash_profile as the user-specific startup file for login shells, which is exactly when persistent environment variables should be defined. Exporting editor in this file makes it available to the shell itself and to all child processes launched during that session, ensuring the setting is inherited system-wide from a user perspective. This is the canonical location for setting per-user environment variables.

Why this answer

The ~/.bash_profile file is executed for login shells, making it the correct place to set environment variables like EDITOR that should persist across all future login sessions. Adding 'export EDITOR=/usr/bin/vim' to this file ensures the variable is defined each time the user logs in.

Exam trap

Red Hat often tests the distinction between login and non-login shell startup files, and the trap here is that candidates mistakenly choose ~/.bashrc because they associate it with user-specific settings, not realizing it is not sourced by login shells.

How to eliminate wrong answers

Option A is wrong because ~/.bash_logout is executed when the user logs out, not at login, so it cannot set environment variables for future sessions. Option C is wrong because /etc/bashrc is a system-wide file that affects all users and is typically sourced by non-login shells, not the appropriate per-user file for login shell environment variables. Option D is wrong because ~/.bashrc is executed for interactive non-login shells (e.g., opening a terminal in a GUI), not for login shells, so it would not guarantee the variable is set in all future login sessions.

Full explanation →

379

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 →

380

Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

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

Full explanation →

381

MCQeasy

To enforce that user passwords expire every 90 days and users are warned 7 days before expiration, which command sets these policies for user 'john'?

A.chage -m 90 -W 7 john

B.chage -M 90 -W 7 john

C.usermod -e 90 -f 7 john

D.passwd -x 90 -w 7 john

AnswerB

The chage command manages password aging in /etc/shadow. The -M 90 flag sets maximum days before expiry, while -W 7 defines the warning period before that expiry, together enforcing the 90-day rotation and 7-day advance notice for john.

Why this answer

The `chage -M 90 -W 7 john` command sets the maximum number of days a password is valid (password aging) to 90 days via the `-M` flag, and the `-W` flag sets the warning period to 7 days before expiration. The `chage` command is the standard tool in Red Hat Enterprise Linux for modifying user password aging information stored in `/etc/shadow`.

Exam trap

A common pitfall is confusing the `-m` (minimum days) with `-M` (maximum days) flag in `chage`. The RHCSA exam tests this distinction, and candidates may incorrectly select `usermod` or `passwd` for password expiration settings. Only `chage -M` sets the maximum password age, and `-W` sets the warning period.

How to eliminate wrong answers

Option A is wrong because `-m` sets the minimum number of days before a password can be changed, not the maximum validity period; this would enforce a 90-day minimum password age, which is the opposite of the requirement. Option C is wrong because `usermod -e` sets an account expiration date (in YYYY-MM-DD format), not password aging, and `-f` sets the number of days after password expiration until the account is disabled, not a warning period. Option D is wrong because `passwd -x 90 -w 7` is a valid syntax for setting password maximum age and warning days, but the `passwd` command is not the standard tool for this purpose on RHEL 8/9; `chage` is the preferred and exam-relevant command for password aging policies.

Full explanation →

382

MCQmedium

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

A.vgextend vg /dev/sdb

B.resize2fs /dev/vg/lv

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

D.pvcreate /dev/sdb

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

383

Multi-Selectmedium

A system administrator has added a new disk /dev/sdb to a Red Hat Enterprise Linux 9 server. The directory /data already exists. Which two steps must be performed to prepare the disk for mounting as an XFS file system at /data?

Select 2 answers

A.Run mkfs.xfs on the partition (e.g., mkfs.xfs /dev/sdb1)

B.Mount the partition to /data (mount /dev/sdb1 /data)

C.Create a partition on /dev/sdb (e.g., fdisk /dev/sdb)

D.Create the /data directory (mkdir -p /data)

E.Add an entry to /etc/fstab for the new mount

AnswersA, C

Without a filesystem, the partition is just raw block storage; the kernel cannot mount it because there is no superblock or inode structure to manage files. Running mkfs.xfs writes the XFS superblock, allocation groups, and journaling structures onto /dev/sdb1, making it a valid, mountable filesystem. This step is mandatory after partitioning and before attempting any mount operation.

Why this answer

After creating a partition on /dev/sdb, you must format it with the XFS file system using mkfs.xfs. This writes the XFS superblock and metadata structures to the partition, making it ready for mounting. Without this step, the partition has no file system and cannot be mounted.

Exam trap

The trap here is that candidates often think mounting or adding an fstab entry is a preparatory step, but the question specifically asks for steps to prepare the disk for mounting, which are partitioning and creating the file system.

Full explanation →

384

MCQeasy

A system administrator needs to ensure that the user 'jdoe' cannot log in via SSH but can still use other services like FTP. Which approach should the administrator take?

A.Lock the user account with 'usermod -L jdoe'

B.Delete the user's password with 'passwd -d jdoe'

C.Remove the user's home directory

D.Change the user's shell to /sbin/nologin

AnswerD

Setting jdoe's shell to /sbin/nologin in /etc/passwd makes PAM deny interactive login sessions, typically printing 'This account is currently not available.' FTP daemons such as vsftpd or proftpd authenticate against /etc/shadow without invoking the user's shell, so they still allow file transfers. Because /sbin/nologin only blocks shell access and does not alter the password hash, it is the standard, targeted solution for allowing non-login services while prohibiting interactive logins.

Why this answer

Changing the user's shell to /sbin/nologin prevents interactive login via SSH (which requires a valid shell listed in /etc/shells) while still allowing non-interactive services like FTP, which typically do not check the user's shell. This approach specifically blocks SSH access without locking the account or affecting other authentication methods.

Exam trap

The trap here is that candidates often confuse account locking (usermod -L) with shell restriction, assuming that locking the account only affects SSH, when in fact it blocks all password-based authentication, including FTP and other services.

How to eliminate wrong answers

Option A is wrong because 'usermod -L' locks the account by placing an exclamation mark in the password hash field, which prevents all password-based authentication, including FTP, thus blocking the user from using other services. Option B is wrong because 'passwd -d' deletes the password, leaving the account with an empty password, which may allow login without a password (depending on PAM configuration) and does not specifically block SSH while allowing FTP. Option C is wrong because removing the home directory does not prevent SSH login; the user could still authenticate and log in, though they would have no home directory, potentially causing errors but not blocking access.

Full explanation →

385

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 →

386

Multi-Selecthard

Which three actions enhance security for user accounts on a Red Hat Enterprise Linux system? (Choose three.)

Select 3 answers

A.Enforcing password complexity via pam_pwquality.

B.Disabling SSH root login by setting PermitRootLogin no.

C.Granting all users sudo access to run all commands.

D.Setting the password expiration to 0 days.

E.Using SSH key-based authentication instead of passwords.

AnswersA, B, E

pam_pwquality enforces password strength during password changes via configurable rules such as minlen, dcredit, ucredit, lcredit, and ocredit, forcing users to create passwords with sufficient length and character diversity. This dramatically shrinks the space of guessable or dictionary-based passwords that an attacker can attempt. As a PAM module typically stacked in system-auth or password-auth, it can also reject passwords too similar to the previous one, closing a common users' shortcut.

Why this answer

Option A is correct because enforcing password complexity via pam_pwquality (configured in /etc/security/pwquality.conf and applied through the pam_pwquality PAM module) requires users to choose strong passwords, reducing the risk of brute-force and dictionary attacks. Option B is correct because setting PermitRootLogin no in /etc/ssh/sshd_config prevents direct root logins over SSH, forcing attackers to compromise a normal account and then escalate privileges, which adds a layer of defense. Option E is correct because SSH key-based authentication uses asymmetric cryptographic key pairs instead of reusable passwords, making credential guessing, brute-force, and password-reuse attacks ineffective.

Option C is not appropriate because granting all users unrestricted sudo access to run all commands violates least privilege and effectively gives every account root-equivalent power. Option D is not appropriate because setting password expiration to 0 days disables expiration, allowing passwords to remain valid indefinitely and increasing the window of exposure if a password is compromised.

Exam trap

The trap here is that candidates may think granting all users full sudo access is a convenience feature for administration, but Red Hat exams emphasize security best practices, so any option that violates least privilege or introduces unnecessary risk is automatically incorrect.

Full explanation →

387

MCQeasy

A junior administrator needs to create a new Ext4 file system on the device /dev/sdb1. Which command should be used?

A.fdisk /dev/sdb1

B.parted /dev/sdb1

C.tune2fs /dev/sdb1

D.mkfs.ext4 /dev/sdb1

E.fsck /dev/sdb1

AnswerD

mkfs.ext4 /dev/sdb1 is correct because mkfs.ext4 is a front-end to mke2fs -t ext4, which initializes a fresh ext4 filesystem on the partition. It writes the essential on-disk metadata—superblock, descriptor blocks, inode table, and journal—so the partition can be mounted and used by the Linux kernel. This is the standard command a junior administrator would run after a partition like /dev/sdb1 has been created.

Why this answer

The `mkfs.ext4` command is the standard utility for creating an ext4 filesystem on a block device. It formats the partition with the ext4 journaling filesystem, writing the superblock, inode table, and journal metadata. Option D is correct because it directly invokes the mke2fs program with the ext4 filesystem type.

Exam trap

The trap here is that candidates confuse partition management tools (fdisk, parted) with filesystem creation tools, or mistake maintenance utilities (tune2fs, fsck) for creation commands, leading them to select a wrong option that operates on a different layer of storage management.

How to eliminate wrong answers

Option A is wrong because `fdisk` is a partition table manipulation tool (MBR/GPT) and cannot create a filesystem; it only manages partitions on a disk, not on a partition like /dev/sdb1. Option B is wrong because `parted` is also a partition table editor, not a filesystem creation tool; it can resize or create partitions but not format them with a filesystem. Option C is wrong because `tune2fs` is used to adjust tunable filesystem parameters on an existing ext2/ext3/ext4 filesystem, not to create a new one.

Option E is wrong because `fsck` is a filesystem consistency check and repair tool, not a creation utility; it operates on an already-formatted filesystem.

Full explanation →

388

MCQmedium

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

A.Filesystem is corrupted

B.The disk has bad sectors

C.Deleted files still held open by processes

D.Filesystem is mounted with noexe

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

389

MCQhard

A database container crashes repeatedly. The administrator wants to see the last 10 lines of the container's logs before it exited. Which command should be used?

A.podman logs --tail 10 <container>

B.podman logs -f <container>

C.podman logs --since 10m <container>

D.podman inspect <container>

AnswerA

The `--tail 10` flag limits the output to the last 10 lines of the container's log stream, which is exactly what an administrator needs when a database crashes repeatedly. Because the crash reason almost always appears in the final log entries before the process exits, viewing the tail provides the most recent error without wading through the full history. This is the standard, non-interactive way to capture the fatal diagnostics for a container that has already stopped.

Why this answer

The `podman logs --tail 10 <container>` command retrieves the last 10 lines of the container's log output, which is exactly what the administrator needs to see the final log entries before the container exited. The `--tail` flag specifies the number of lines from the end of the log, making it ideal for troubleshooting a crash without viewing the entire log history.

Exam trap

The trap here is that candidates confuse `--tail` with `-f` (follow) or `--since`, thinking they all show recent logs, but only `--tail` precisely limits output to the last N lines of the container's entire log history.

How to eliminate wrong answers

Option B is wrong because `podman logs -f` follows (tails) the log output in real time, which is useful for live monitoring but does not show only the last 10 lines of the exited container's logs. Option C is wrong because `podman logs --since 10m` shows log entries from the last 10 minutes, which may include many lines or miss the final crash logs if the container exited more than 10 minutes ago. Option D is wrong because `podman inspect` returns detailed metadata about the container (e.g., configuration, state, mounts) but does not display log content.

Full explanation →

390

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 →

391

MCQhard

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

392

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 →

393

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 →

394

Multi-Selectmedium

Which TWO commands can be used to display the contents of a compressed log file without decompressing it first?

Select 2 answers

A.bzless /var/log/messages.bz2

B.zcat /var/log/messages.gz

C.grep 'error' /var/log/messages.gz

D.vim /var/log/messages.gz

E.less /var/log/messages.gz

AnswersA, B

bzless is the bzip2-aware counterpart of less; it invokes bzip2 to decompress the file on the fly and pipes the output into the less pager. This lets you interactively scroll through /var/log/messages.bz2 without first expanding it to disk, and bzless cleans up any temporary decompression stream when you quit. Because the file is bzip2-compressed, this command correctly renders the log contents.

Why this answer

`bzless` is a utility specifically designed to view bzip2-compressed files without decompressing them first. It decompresses the file on the fly and pipes the output to a pager, allowing you to scroll through the content. Similarly, option B is correct because `zcat` reads a gzip-compressed file and writes the decompressed data to standard output, effectively displaying the contents without permanently decompressing the file.

Exam trap

The trap here is that candidates often assume `less` or `grep` can handle compressed files natively, but they cannot; the correct approach is to use dedicated tools like `zcat`, `zless`, `bzcat`, or `bzless` that perform on-the-fly decompression.

Full explanation →

395

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 →

396

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 →

397

MCQhard

An administrator has a logical volume 'lv_data' in a volume group 'vg_data' with a filesystem. The administrator needs to reduce the size of 'lv_data' by 2GB. Which sequence of commands should be performed?

A.umount, e2fsck -f, resize2fs, lvreduce

B.lvreduce, resize2fs, e2fsck, umount

C.resize2fs, lvreduce, umount, e2fsck

D.umount, lvreduce, resize2fs, e2fsck

AnswerA

This is the only safe sequence. The volume must be unmounted (`umount`) to stop the kernel from writing to it, then `e2fsck -f` forces a full consistency check so the filesystem metadata is known-good before any resize. Only after the check can `resize2fs` shrink the filesystem to its target size; once that completes successfully, `lvreduce` can shrink the logical volume to match, because the fs no longer occupies the space being removed.

Why this answer

Reducing a logical volume with a filesystem requires a specific sequence: first unmount the filesystem to ensure no writes occur, then run e2fsck -f to force a filesystem check and ensure consistency, then use resize2fs to shrink the filesystem to the desired size, and finally lvreduce to shrink the logical volume itself. This order prevents data corruption by resizing the filesystem before the underlying block device.

Exam trap

Red Hat often tests the misconception that you can reduce the logical volume first and then shrink the filesystem, but the correct order is always filesystem first, then LV reduction, with unmount and fsck as prerequisites.

How to eliminate wrong answers

Option B is wrong because lvreduce is performed before resize2fs, which would shrink the logical volume while the filesystem still expects the original size, causing data corruption. Option C is wrong because resize2fs is attempted before unmounting the filesystem, which is not allowed on a mounted ext filesystem and will fail; additionally, lvreduce is done before e2fsck, risking corruption. Option D is wrong because lvreduce is performed before resize2fs, meaning the logical volume is reduced while the filesystem still occupies the original space, leading to data loss or corruption.

Full explanation →

398

MCQeasy

Which file should be present in a directory to build a container image using 'podman build'?

A.docker-compose.yml

B.container.json

C.Dockerfile (or Containerfile)

D..dockerignore

AnswerC

Dockerfile (or Containerfile) is the conventional build file that podman build reads by default to assemble an image, containing instructions such as FROM, RUN, and COPY. Podman automatically looks for Dockerfile and, if not found, falls back to Containerfile, which uses the same syntax and is tool-agnostic. A directory with one of these files is the minimal requirement to start a build.

Why this answer

The `podman build` command requires a Dockerfile or Containerfile in the build context directory to define the container image layers and instructions. Podman follows the OCI (Open Container Initiative) image specification and uses the Dockerfile format by default, making option C the only correct choice for building an image.

Exam trap

Red Hat often tests the distinction between files used for building images (Dockerfile/Containerfile) versus files used for orchestrating containers (docker-compose.yml) or excluding files (.dockerignore), leading candidates to mistakenly select A or D as required files.

How to eliminate wrong answers

Option A is wrong because docker-compose.yml is used by Docker Compose (or Podman Compose) to define multi-container applications, not for building a single container image. Option B is wrong because container.json is not a standard file recognized by Podman or Docker for image builds; it is not part of the OCI or Dockerfile specification. Option D is wrong because .dockerignore is an optional file that excludes files from the build context, but it is not required and cannot replace the Dockerfile or Containerfile as the build instruction source.

Full explanation →

399

MCQhard

A system fails to boot with an error about a missing ext4 filesystem. From the rescue environment, which command should be run to attempt automatic repair of all filesystems?

A.fsck /dev/sda1

B.debugfs -R 'repair'

C.e2fsck -p

D.fsck -A -y

AnswerD

fsck -A -y is the correct rescue command because -A makes fsck consult /etc/fstab and check every filesystem with a nonzero pass number in the proper order, while -y automatically responds 'yes' to all repair prompts, allowing the operation to run without manual input. This covers all mounted filesystems, including the root filesystem, so a corrupted ext4 filesystem that aborts the boot process is likely to be detected and repaired in one pass. It is the standard first-line tool when a system fails to boot due to filesystem inconsistency or a missing ext4 superblock.

Why this answer

`fsck -A -y` automatically checks all filesystems listed in `/etc/fstab` (the `-A` flag) and answers 'yes' to any repair prompts (the `-y` flag), making it the most appropriate command for automatic repair of all filesystems from a rescue environment. The error indicates a missing ext4 filesystem, and this command will attempt to repair any ext4 (or other) filesystem issues without manual intervention.

Exam trap

The trap here is that candidates confuse `e2fsck -p` (which only repairs a single ext filesystem automatically) with `fsck -A -y` (which repairs all filesystems automatically), or they mistakenly think `debugfs` has a repair command, when it is actually a debugging tool, not a repair utility.

How to eliminate wrong answers

Option A is wrong because `fsck /dev/sda1` only checks a single partition (sda1), not all filesystems, and it does not automatically answer 'yes' to repair prompts, so it may stall or require manual input. Option B is wrong because `debugfs -R 'repair'` is not a valid command; `debugfs` is an interactive ext2/ext3/ext4 filesystem debugger, and it does not have a `-R 'repair'` option—it is used for low-level manipulation, not automatic repair. Option C is wrong because `e2fsck -p` automatically repairs ext2/ext3/ext4 filesystems without prompting, but it only operates on a single filesystem (the one specified, e.g., `e2fsck -p /dev/sda1`), not all filesystems; the `-p` flag is for preen mode, not for scanning all fstab entries.

Full explanation →

400

MCQmedium

Based on the exhibit, how much free space is available in the volume group vg00?

A.19.98 GiB

B.10235 MiB

C.20.00 GiB

D.19.99 GiB

E.5115 MiB

AnswerA

In vgdisplay, the Free PE count is 5115 and the PE size is 4.00 MiB, so the unallocated capacity equals 5115 × 4 = 20,460 MiB. Converting MiB to GiB by dividing by 1024 yields 19.98 GiB, which is the available free space. This is the exact value that vgdisplay reports as the remaining space in the volume group.

Why this answer

The VG free space is calculated from the total number of Physical Extents (PEs) and the PE size. The output shows 5115 PEs and a PE size of 4.00 MiB, so total free space = 5115 × 4 MiB = 20460 MiB = 19.98 GiB (since 20460 ÷ 1024 = 19.98046875). No Logical Volumes are allocated, so all PEs are free.

Option B (10235 MiB) is exactly half of 20470 MiB, a common miscalculation. Option C (20.00 GiB) is the raw PV size, ignoring the PE overhead. Option D (19.99 GiB) is a rounding error.

Option E (5115 MiB) confuses the PE count with the free space in MiB.

Exam trap

Red Hat often tests the distinction between raw PV size and usable VG space, trapping candidates who assume the PV size equals the VG free space without accounting for PE size and rounding.

How to eliminate wrong answers

Option B is wrong because 10235 MiB is exactly half of the total usable space (20460 MiB / 2), which might be a miscalculation if one mistakenly divides by 2 or confuses with a different metric. Option C is wrong because 20.00 GiB is the raw PV size, but the VG uses a PE size of 4 MiB, which introduces rounding and metadata overhead, so the actual free space is slightly less (19.98 GiB). Option D is wrong because 19.99 GiB is a rounding error; the precise calculation yields 19.98 GiB (20460 MiB / 1024 = 19.98046875 GiB).

Option E is wrong because 5115 MiB is the total number of PEs, not the free space in MiB; the free space in MiB is 20460 MiB (5115 PE × 4 MiB/PE).

Full explanation →

401

MCQmedium

An administrator runs 'getenforce' and sees 'Enforcing'. They then run 'setenforce 0' but SELinux still denies access to a custom application. What is the most likely reason?

A.SELinux is in enforcing mode and the policy is misconfigured.

B.The application's SELinux context is incorrect and needs relabeling.

C.The issue is due to file permissions or ACLs, not SELinux.

D.The change requires a reboot to take effect.

AnswerC

Because the administrator has already switched SELinux to permissive mode and the access is still refused, the remaining blocker must be from Linux's discretionary access control (DAC) layer — the classic Unix permissions (owner/group/others) or POSIX ACLs. SELinux is a mandatory access control (MAC) system layered on top of DAC, so it can only deny what DAC would otherwise permit; in permissive mode it adds no denials. Inspect ls -l, getfacl, and ownership to find the real permission or ACL problem.

Why this answer

`setenforce 0` switches SELinux to permissive mode, which logs but does not enforce denials. If access is still denied after this command, the issue is not caused by SELinux enforcement but by traditional Linux file permissions (DAC) or ACLs. The administrator should check `ls -l` and `getfacl` to verify the file's ownership and permissions.

Exam trap

The trap here is that candidates assume any denial after `setenforce 0` must still be SELinux-related, overlooking that traditional Linux permissions (DAC) operate independently and can block access even when SELinux is permissive.

How to eliminate wrong answers

Option A is wrong because `setenforce 0` disables enforcing mode, so a misconfigured policy would not cause denials in permissive mode. Option B is wrong because an incorrect SELinux context would only cause denials in enforcing mode; in permissive mode, context mismatches are logged but not enforced, so the application would still run. Option D is wrong because `setenforce` takes effect immediately without requiring a reboot; SELinux runtime mode changes are instantaneous.

Full explanation →

402

MCQeasy

A security policy requires user passwords to expire 60 days after last change. Which command sets this for user 'jdoe'?

A.usermod -f 60 jdoe

B.passwd -x 60 jdoe

C.chage -m 60 jdoe

D.chage -M 60 jdoe

AnswerD

chage -M 60 jdoe sets the MAX_DAYS field in /etc/shadow, which defines the maximum number of days a password is valid before the system forces the user to choose a new one. With this command, jdoe's password will expire 60 days after the most recent password change, directly implementing the security policy. chage is the standard utility for password aging because it lets an administrator read and write the aging fields clearly and predictably.

Why this answer

The `chage -M 60 jdoe` command sets the maximum number of days a password is valid for user 'jdoe' to 60 days. The `-M` flag in `chage` directly controls the password expiration period, counting from the last password change, which matches the security policy requirement.

Exam trap

The trap here is confusing the `-m` and `-M` flags in `chage`, where candidates often mistakenly think `-m` sets the maximum age (expiration) when it actually sets the minimum days between changes, or they incorrectly recall `usermod -f` as the password expiration command.

How to eliminate wrong answers

Option A is wrong because `usermod -f` sets the number of days after a password expires until the account is permanently disabled (inactive lockout), not the password expiration period itself. Option B is wrong because `passwd -x 60` is not a valid syntax; the `passwd` command does not have a `-x` flag for setting maximum password age (that flag is used by `chage`). Option C is wrong because `chage -m 60` sets the minimum number of days required between password changes, not the maximum age (expiration) of the password.

Full explanation →

403

Multi-Selectmedium

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

Select 3 answers

A.vfat

B.ntfs

C.xfs

D.btrfs

E.ext4

AnswersA, C, E

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

Why this answer

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

Exam trap

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

Full explanation →

404

MCQhard

An administrator used the command useradd -D -f 10 to change the default inactivity period. What effect does this have on future user accounts?

A.The default group for new users will be changed to GID 10.

B.New user accounts will have a maximum password age of 10 days.

C.New user accounts will be disabled after 10 days of inactivity if the password has expired.

D.New user accounts will have a password expiration of 10 days.

AnswerC

The -f 10 option sets the INACTIVE field in /etc/default/useradd, which becomes the seventh field in the /etc/shadow entry, specifying how many days after a password expires the account is disabled. If the password never expires or is changed before that, inactivity does not apply; only after expiry does the 10-day countdown begin. When the countdown ends, the account is locked, preventing login until an administrator reactivates it.

Why this answer

The `useradd -D -f 10` command modifies the default value for the `INACTIVE` field in `/etc/default/useradd`. This field sets the number of days after a password expires that the account will be disabled if the password is not changed. Option C correctly describes this behavior: new user accounts will be disabled after 10 days of inactivity following password expiration.

Exam trap

The trap here is confusing the `-f` (inactivity period after password expiration) with password aging (`-M` or `PASS_MAX_DAYS`), leading candidates to incorrectly select options B or D.

How to eliminate wrong answers

Option A is wrong because `-f` sets the inactivity period, not the default group; the default group is set with `-g` or `-G`. Option B is wrong because the maximum password age is controlled by the `PASS_MAX_DAYS` parameter in `/etc/login.defs`, not by the `-f` flag. Option D is wrong because the `-f` flag sets the inactivity period after password expiration, not the password expiration itself; password expiration is set with `-e` or via `chage -M`.

Full explanation →

405

MCQhard

A company policy requires that all cron jobs run by non-root users must be logged to a specific file /var/log/usercron.log. The system administrator decides to use rsyslog to capture these messages. Which configuration directive should be added to /etc/rsyslog.conf or a file in /etc/rsyslog.d/ to achieve this?

A.user.* /var/log/usercron.log

B.cron.* /var/log/usercron.log

C.*.* /var/log/usercron.log

D.authpriv.* /var/log/usercron.log

AnswerB

The 'cron' facility is the designated syslog source for all messages generated by the cron daemon, such as job launches, completions, and errors. Using the '*' priority wildcard ensures that every severity level—from debug to emergency—is recorded, capturing the full cron activity stream without dropping lower-priority messages. This makes 'cron.*' the precise, policy-compliant directive for sending cron logging to /var/log/usercron.log.

Why this answer

The cron facility in rsyslog captures messages generated by the cron daemon, including cron jobs run by non-root users. By adding the directive `cron.* /var/log/usercron.log` to the rsyslog configuration, all cron messages (regardless of priority) are logged to the specified file, satisfying the policy requirement.

Exam trap

The trap here is that candidates may confuse the `cron` facility with the `user` facility, mistakenly thinking user cron jobs are logged under `user.*` instead of the dedicated `cron` facility.

How to eliminate wrong answers

Option A is wrong because `user.*` captures messages from user-level processes (e.g., user applications), not from the cron daemon; cron jobs are logged under the `cron` facility, not `user`. Option C is wrong because `*.*` logs all syslog messages from every facility to the file, which is overly broad and violates the policy of logging only cron jobs; it would also clutter the log with unrelated system messages. Option D is wrong because `authpriv.*` captures authentication and security-related messages (e.g., sudo, login), not cron job logs; this would miss all cron activity.

Full explanation →

406

MCQeasy

A system administrator needs to find all files in /var/log that have been modified in the last 2 hours. Which command should be used?

A.find /var/log -mmin -120

B.find /var/log -amin -120

C.find /var/log -mtime -0.08

D.find /var/log -cmin -120

AnswerA

The `-mmin -120` predicate is the correct choice because it directly tests modification time in minutes. A leading minus sign means "less than," so `-120` matches any file whose data was last modified within the last 120 minutes (i.e., less than two hours ago). This precisely answers the requirement to find files in `/var/log` that have been modified in the last two hours.

Why this answer

The `find` command with `-mmin -120` searches for files whose data was modified (changed content) within the last 120 minutes. This directly matches the requirement to find files modified in the last 2 hours in /var/log.

Exam trap

The trap here is confusing `-mmin` (modification time) with `-cmin` (change time) or `-amin` (access time), as candidates often misremember which flag tracks content changes versus metadata or access events.

How to eliminate wrong answers

Option B is wrong because `-amin -120` searches for files accessed (read) within the last 120 minutes, not modified. Option C is wrong because `-mtime -0.08` uses a fractional day value that is not precise for a 2-hour window; `-mtime` works in 24-hour increments and rounding can cause inaccuracies. Option D is wrong because `-cmin -120` searches for files whose status (metadata) changed within the last 120 minutes, which includes permission or ownership changes, not necessarily data modification.

Full explanation →

407

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 →

408

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 →

409

MCQmedium

A containerized web server needs to persist logs outside the container. Which podman run option allows the administrator to specify a bind mount with mount propagation options?

A.--mount

B.--volume

C.--bind

D.-v

AnswerA

The --mount option is the correct choice because it provides an explicit, structured way to define a bind mount with comma-separated key=value syntax, such as type=bind,source=/host/logs,destination=/var/log/nginx. It allows specifying advanced parameters like bind-propagation (e.g., rshared, rslave) and read-only enforcement, which are essential for reliably persisting container logs outside the container. Unlike -v or --volume, --mount does not guess whether the source is a file, directory, or named volume, making it the most deterministic and production-safe approach for this task.

Why this answer

The `--mount` flag in `podman run` provides the most granular control over bind mounts, including the ability to specify mount propagation options (e.g., `shared`, `slave`, `private`) via the `propagation` parameter. This is essential for persisting container logs to the host filesystem while controlling how mount events are propagated between the container and the host.

Exam trap

The trap here is that candidates confuse `--volume`/`-v` with `--mount`, assuming both support the same options, but only `--mount` allows explicit mount propagation settings, which is a key differentiator tested in the EX200 exam.

How to eliminate wrong answers

Option B is wrong because `--volume` (or `-v`) in Podman creates a volume managed by Podman, not a bind mount, and does not support mount propagation options directly; it is designed for persistent storage managed by Podman's volume driver. Option C is wrong because `--bind` is not a valid `podman run` option; the correct syntax for bind mounts uses `--mount type=bind` or `-v` with a host path. Option D is wrong because `-v` (short form of `--volume`) can create bind mounts when a host path is specified, but it does not support mount propagation options; propagation can only be set via the `--mount` option.

Full explanation →

410

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 →

411

MCQeasy

A Red Hat Enterprise Linux system has a second disk /dev/sdb with a single partition /dev/sdb1 that was formatted as XFS and mounted at /mnt/backup. The administrator wants to change the filesystem on /dev/sdb1 to ext4 without losing existing data. Which steps should be taken in order?

A.Unmount, mkfs.ext4 /dev/sdb1, then mount

B.Use xfs_admin to change type

C.Use fsck.ext4 to convert in place

D.Backup data, unmount, mkfs.ext4, remount, restore data

AnswerD

The correct procedure is to first copy all data from /dev/sdb1 to a safe location (e.g., tar, rsync, or cp to another disk), then unmount the partition, run mkfs.ext4 /dev/sdb1 to create a new ext4 filesystem, remount the partition, and finally restore the data from the backup. This sequence preserves user files and directory structure because the destructive mkfs operation is performed only after a verified backup exists, and the restore repopulates the freshly formatted ext4 filesystem with the original content.

Why this answer

You cannot convert an XFS filesystem to ext4 in place; the only safe method is to back up the data, unmount the partition, create a new ext4 filesystem with mkfs.ext4, remount, and then restore the data. XFS and ext4 have fundamentally different on-disk structures (e.g., allocation groups vs. block groups, different journaling formats), so no in-place conversion tool exists.

Exam trap

The trap here is that candidates assume a filesystem can be 'converted' in place using a command like fsck or a tuning tool, when in fact only a backup-and-restore cycle is safe for changing between fundamentally different filesystem types like XFS and ext4.

How to eliminate wrong answers

Option A is wrong because running mkfs.ext4 on a partition that currently contains an XFS filesystem will overwrite the existing filesystem metadata, destroying all data without any conversion. Option B is wrong because xfs_admin is a tool for tuning XFS filesystem parameters (e.g., changing the UUID or label), not for changing the filesystem type to ext4. Option C is wrong because fsck.ext4 is a filesystem check and repair tool for ext4; it cannot convert an XFS filesystem to ext4, and attempting to run it on an XFS partition would fail or cause corruption.

Full explanation →

412

MCQhard

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

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

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

C.The filesystem type specified in fstab is incorrect.

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

413

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 →

414

Multi-Selecthard

Which TWO methods are considered best practices for securing SSH access to a server? (Select exactly two.)

Select 2 answers

A.Disable root login by setting PermitRootLogin no.

B.Use only password authentication for simplicity.

C.Use key-based authentication with passphrase-protected keys.

D.Change the default SSH port to a high-numbered port.

E.Allow SSH access for all users in the system.

AnswersA, C

Setting PermitRootLogin no in /etc/ssh/sshd_config blocks direct SSH logins as the root user. This forces administrators to authenticate as an unprivileged account and then use sudo, which provides an auditable trail of privileged commands. Since root has unrestricted access to the entire system, removing direct root SSH access significantly reduces the risk of attackers obtaining full control through a single root credential compromise.

Why this answer

Disabling root login by setting `PermitRootLogin no` in `/etc/ssh/sshd_config` prevents direct SSH access as the root user, forcing administrators to log in as a regular user and then use `sudo` or `su` to escalate privileges. This reduces the attack surface by eliminating a high-value target for brute-force attacks and ensures all actions are auditable via the regular user's session.

Exam trap

Red Hat often tests the misconception that changing the default SSH port (option D) is a legitimate security measure, but in the EX200 exam, security through obscurity is never considered a best practice—only controls that enforce authentication and authorization are accepted.

Full explanation →

415

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 →

416

MCQmedium

An administrator wants to allow user 'alice' to SSH into the server using key-based authentication only. Which configuration change is required?

A.Add alice's public key to ~alice/.ssh/authorized_keys and set PubkeyAuthentication yes in sshd_config.

B.Add alice's private key to /etc/ssh/authorized_keys.

C.Set PasswordAuthentication no in /etc/ssh/sshd_config and restart sshd.

D.Set PermitRootLogin prohibit-password.

AnswerA

Alice's public key is placed in ~alice/.ssh/authorized_keys, and the sshd server verifies that alice possesses the matching private key by sending a challenge that requires a signature. Setting PubkeyAuthentication yes in sshd_config (or confirming it is uncommented, as it defaults to yes) explicitly enables this key-based login mechanism. This is the proper, secure way to allow alice to authenticate without a password.

Why this answer

SSH key-based authentication requires the user's public key to be placed in the user's `~/.ssh/authorized_keys` file, and the SSH daemon must have `PubkeyAuthentication yes` set in `/etc/ssh/sshd_config` to allow public key authentication. This configuration ensures that only users with the corresponding private key can authenticate as 'alice'.

Exam trap

The trap here is that candidates often think disabling password authentication alone is sufficient for key-based access, but they forget that the public key must be placed in the correct location and that `PubkeyAuthentication` must be explicitly enabled if it was previously disabled.

How to eliminate wrong answers

Option B is wrong because private keys must never be stored on the server; only public keys belong in `authorized_keys` files, and the correct location is the user's home directory, not `/etc/ssh/`. Option C is wrong because disabling password authentication (`PasswordAuthentication no`) alone does not enable key-based authentication; it only prevents password logins, but without `PubkeyAuthentication yes` and a valid public key, 'alice' would be locked out entirely. Option D is wrong because `PermitRootLogin prohibit-password` only affects root login, not user 'alice', and it does not configure key-based authentication for non-root users.

Full explanation →

417

Multi-Selecteasy

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

Select 2 answers

A.blkid

B.du

C.fdisk

D.df

E.lsblk

AnswersB, D

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

Why this answer

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

Exam trap

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

Full explanation →

418

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 →

419

Multi-Selectmedium

Which three of the following are valid methods to view the manual page for the 'ls' command? (Choose three)

Select 3 answers

A.help ls

B.man ls

C.whatis ls

D.info ls

E.ls --help

AnswersB, D, E

The `man` utility formats and displays the official manual page for `ls`, which is the canonical reference documentation on most Linux systems. The `ls(1)` man page from GNU coreutils describes all command-line options, exit statuses, and usage examples, and is rendered through a pager such as `less`. Manual pages are numbered by section, and `man ls` automatically finds the user-command entry in section 1. This provides the most comprehensive and authoritative offline documentation for the command.

Why this answer

The 'man' command is the primary method for viewing manual pages in Linux. Running 'man ls' displays the full manual page for the 'ls' command, including its description, options, and usage details.

Exam trap

Red Hat often tests the distinction between commands that provide full manual pages ('man', 'info') versus those that give brief summaries ('--help', 'whatis'), and the trap here is that candidates may mistakenly think 'help' or 'whatis' are valid methods for viewing the full manual page.

Full explanation →

420

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 →

421

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 →

422

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 →

423

MCQhard

A company requires that SSH access from the external network (10.0.1.0/24) only be allowed to port 2222, and all other incoming traffic on the firewall should be dropped. Which firewalld rule should be applied to the external zone?

A.firewall-cmd --zone=external --add-service=ssh --permanent

B.firewall-cmd --zone=external --add-port=2222/tcp --permanent

C.firewall-cmd --zone=external --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" service name="ssh" accept' --permanent

D.firewall-cmd --zone=external --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" port port="2222" protocol="tcp" accept' --permanent

AnswerD

This rich rule combines a source address restriction (10.0.1.0/24) with an explicit port and protocol (2222/tcp), so only that internal subnet can reach the SSH service on the non-standard port. Using port instead of service avoids any ambiguity introduced by default service definitions. With --permanent, the rule survives reloads, and it precisely matches the requirement of limiting external SSH access to the specified source network and port.

Why this answer

It uses a rich rule to explicitly allow incoming TCP traffic on port 2222 from the 10.0.1.0/24 source network, which matches the requirement. The default target for the external zone is 'drop', so only explicitly permitted traffic is allowed; this rule ensures SSH on port 2222 is accepted while all other incoming traffic is dropped.

Exam trap

The trap here is that candidates often confuse the 'service name' with a custom port, selecting Option C which uses the SSH service (port 22) instead of the required port 2222, or they forget to restrict the source address as in Option B.

How to eliminate wrong answers

Option A is wrong because it adds the standard SSH service (port 22/tcp) to the external zone, not port 2222, and does not restrict the source to 10.0.1.0/24. Option B is wrong because it opens port 2222/tcp to all sources, not just the 10.0.1.0/24 network, violating the source restriction requirement. Option C is wrong because it references the SSH service name (port 22/tcp) instead of port 2222, and the source address is specified but the service is incorrect.

Full explanation →

424

MCQhard

An organization uses a shell script that runs daily via cron on a central management server to archive logs from 50 remote Red Hat Enterprise Linux servers. The script uses `scp` with SSH key-based authentication (passwordless) to transfer files. Recently, after a security team rotated the SSH host keys on all remote servers, the script started failing with 'Host key verification failed' errors. The administrator needs to restore automated log transfers without compromising security. The remote servers are in a controlled internal network, and the management server's `~/.ssh/known_hosts` file is not centrally managed. Which course of action should the administrator take?

A.Add the -o StrictHostKeyChecking=no option to the scp command in the script.

B.Use ssh-keyscan to retrieve the new host keys and add them to the management server's known_hosts file.

C.Modify the sshd_config on each remote server to disable host key checking.

D.Replace scp with rsync in the script, as rsync uses a different authentication method.

AnswerB

This answer correctly re-establishes trust by fetching the remote server's current public host keys with ssh-keyscan and appending them to the management server's known_hosts file. After this update, scp will find the new host key for that server and pass verification, allowing the cron job to run normally. To preserve security, the administrator should verify the retrieved fingerprints out-of-band (for example, by comparing the server's SSH host key fingerprint from the console) before adding them, because blindly accepting keys could still allow man-in-the-middle attacks.

Why this answer

Using `ssh-keyscan` to retrieve the new host keys and add them to the management server's `known_hosts` file is the proper method to update host keys without disabling security. This approach maintains SSH host key verification, which prevents man-in-the-middle attacks, while allowing the script to authenticate the remote servers after the key rotation.

Exam trap

The trap here is that candidates may think disabling host key checking (Option A) is an acceptable quick fix, but the RHCSA exam expects understanding that `StrictHostKeyChecking=no` is a security risk and that the correct approach is to update the `known_hosts` file with the new keys using `ssh-keyscan`.

How to eliminate wrong answers

Option A is wrong because adding `-o StrictHostKeyChecking=no` disables host key verification entirely, which compromises security by making the system vulnerable to man-in-the-middle attacks; it is a dangerous workaround, not a fix. Option C is wrong because modifying `sshd_config` on remote servers to disable host key checking is a server-side change that does not address the client-side `known_hosts` mismatch and also weakens SSH security globally. Option D is wrong because `rsync` uses the same SSH transport and authentication mechanism as `scp`, so it would still fail with the same 'Host key verification failed' error; it does not use a different authentication method.

Full explanation →

425

MCQhard

Refer to the exhibit. The script produces the error shown. What is the most likely cause?

A.The = operator should be == for string comparison.

B.The string 'value' contains spaces.

C.The script is missing a valid shebang.

D.The variable $var is empty or unset.

AnswerD

The variable $var is empty or unset, and because it is referenced without double quotes, the shell expands it to an empty string and then removes it entirely during word splitting. That causes [ $var = value ] to become [ = value ], which the test command sees as two arguments; it tries to treat '=' as a unary operator, producing the 'unary operator expected' error. Properly quoting as [ "$var" = value ] would keep the empty argument and yield a valid comparison, confirming the diagnosis.

Why this answer

The error 'unary operator expected' occurs in bash when the `[ ]` test command encounters an empty or unset variable on the left side of a comparison operator. Since `$var` is empty, the expression `[ $var = 'value' ]` expands to `[ = 'value' ]`, which is syntactically invalid because the `=` operator expects a left operand. Option D correctly identifies this as the root cause.

Exam trap

The trap here is that candidates often blame the comparison operator (`=` vs `==`) or think the string contains spaces, when the real issue is an unquoted variable that becomes empty after expansion, causing a missing operand for the `=` operator. In a Red Hat environment, this is a common bash scripting pitfall.

How to eliminate wrong answers

Option A is wrong because the `=` operator is the correct string comparison operator inside single brackets `[ ]` in bash; `==` is also accepted but not required, and using `=` does not cause this error. Option B is wrong because if the string 'value' contained spaces, the error would be about too many arguments, not 'unary operator expected', and the script uses single quotes which preserve spaces. Option C is wrong because the script runs and produces an error, meaning it is being executed (likely by bash); a missing shebang would cause the script to be interpreted by the default shell or fail to run at all, not produce this specific runtime error.

Full explanation →

426

MCQhard

A container needs to share the host's network namespace for performance monitoring. Which podman run option achieves this?

A.--network slirp4netns

B.--network bridge

C.--network none

D.--network host

AnswerD

--network host connects the container directly to the host's network namespace, so the container sees the same IP address, routing table, and network interfaces as the host. Any service listening in the container binds directly to the host's ports without requiring -p or --publish mappings. This eliminates the NAT and veth-pair overhead of bridge networking, but it also means the container has no network isolation from the host, which can be a security risk if untrusted workloads are run.

Why this answer

`--network host` makes the container use the host's network stack directly, bypassing any network namespace isolation. This allows performance monitoring tools inside the container to see the host's actual network interfaces, IP addresses, and traffic without NAT or port mapping overhead.

Exam trap

The trap here is that candidates often confuse `--network host` with `--network bridge` (the default), assuming bridge mode provides host-level visibility, but bridge mode actually creates an isolated network namespace with NAT, hiding the host's interfaces.

How to eliminate wrong answers

Option A is wrong because `--network slirp4netns` uses user-mode networking with NAT, which isolates the container's network from the host and adds performance overhead, making it unsuitable for direct host network monitoring. Option B is wrong because `--network bridge` creates a separate network namespace with a virtual bridge (default for rootless containers), isolating the container from the host's network interfaces. Option C is wrong because `--network none` disables all networking inside the container, preventing any network monitoring of the host.

Full explanation →

427

MCQmedium

A logical volume /dev/vg_data/lv_data formatted as XFS is full. The administrator extends the LV by 1 GB using 'lvextend -L +1G /dev/vg_data/lv_data'. Which additional command is required to use the new space?

A.xfs_repair /dev/vg_data/lv_data

B.xfs_growfs /mount/point

C.resize2fs /mount/point

D.lvresize -L +1G /dev/vg_data/lv_data

AnswerB

xfs_growfs is the intended command to expand an XFS filesystem to fill the newly available space in the underlying logical volume. It operates on a mounted filesystem and uses the VFS layer to increase data and inode block counts without offline downtime. The command's argument is the mount point (or device) and it extends the filesystem to the LV's current size. Because XFS can only grow (not shrink), this is the single missing step after the LV has already been enlarged.

Why this answer

After extending the logical volume, the XFS file system must be grown to recognize the new space. The `xfs_growfs` command resizes an XFS file system to fill the available space in the underlying block device, and it requires the mount point as an argument (not the device). This is necessary because XFS does not support online resizing via a simple block device extension; the file system must be explicitly told to expand.

Exam trap

The trap here is that candidates confuse the file system type and apply the wrong resize command (e.g., `resize2fs` for ext4) or think that extending the logical volume automatically grows the file system, which is not true for XFS.

How to eliminate wrong answers

Option A is wrong because `xfs_repair` is used to check and repair XFS file system corruption, not to resize it; running it on a healthy file system would be unnecessary and could cause downtime. Option C is wrong because `resize2fs` is the tool for ext2/ext3/ext4 file systems, not XFS; using it on an XFS file system would fail or cause damage. Option D is wrong because `lvresize` is the command to resize the logical volume itself, which has already been done with `lvextend`; repeating it would either do nothing or attempt to extend again, but it does not resize the file system.

Full explanation →

Red Hat Certified System Administrator EX200 (EX200) — Questions 376–427