Red Hat Certified System Administrator EX200 EX200 Questions 301–375 | Page 5/6

301

Multi-Selectmedium

Which TWO statements are true regarding container images and containers in Podman?

Select 2 answers

A.A container can only be created from an image that is stored locally.

B.A container is a running or stopped instance of an image with a writable layer.

C.A container image is a read-only template used to create containers.

D.When a container is stopped, its writable layer is automatically removed.

E.A container image must be built using a Dockerfile.

AnswersB, C

A container is the runtime instance produced when an image is instantiated, and it always has its own thin writable layer placed on top of the read-only image layers. This layer captures all file system changes made by the container, regardless of whether the container is currently executing or has been stopped. The writable layer remains associated with the container object until the container itself is deleted, so both running and stopped containers are considered instances with that writable layer.

Why this answer

A container in Podman is an instantiation of an image that adds a writable layer on top of the image's read-only layers. This writable layer persists changes made during the container's runtime, even after the container is stopped, unless explicitly removed.

Exam trap

Red Hat often tests the misconception that a container's writable layer is ephemeral and automatically deleted when the container stops, but in Podman (and Docker) the writable layer persists until the container is explicitly removed.

Full explanation →

302

MCQeasy

To mount an ext4 filesystem with the noatime option and remount read-only on errors, which file should be edited?

A./etc/mtab

B./etc/sysconfig/network

C./etc/fstab

D./etc/rc.d/rc.local

AnswerC

/etc/fstab is the static filesystem table read by mount when you run 'mount -a' and by systemd-fstab-generator at boot. To make an ext4 filesystem mount with noatime persistently, you add that option to the fourth field (options) of its /etc/fstab entry. After editing, running 'mount -o remount /mountpoint' applies the change without rebooting. This is the canonical place for persistent mount options, including noatime.

Why this answer

The /etc/fstab file is the system configuration file that defines how disk partitions, block devices, and remote filesystems should be mounted into the filesystem tree. To mount an ext4 filesystem with the noatime option and to remount it read-only on errors, you add the options 'noatime,errors=remount-ro' in the fourth field (mount options) of the corresponding entry in /etc/fstab. This ensures the options are applied automatically at boot and during subsequent mount operations.

Exam trap

The RHCSA exam often tests the distinction between /etc/fstab (persistent configuration) and /etc/mtab (current mount state), leading candidates to mistakenly think editing /etc/mtab will persist mount options across reboots.

How to eliminate wrong answers

Option A is wrong because /etc/mtab is a dynamically maintained file that lists currently mounted filesystems; editing it does not persist mount options across reboots and is not used for configuration. Option B is wrong because /etc/sysconfig/network is a Red Hat Enterprise Linux file used for network configuration (e.g., hostname, gateway), not for filesystem mount options. Option D is wrong because /etc/rc.d/rc.local is a legacy script executed at the end of the boot process; while you could add mount commands there, it is not the standard or recommended location for defining persistent mount options, and it would not be used by the mount command automatically.

Full explanation →

303

MCQmedium

A containerized application writes logs to stdout. The administrator wants to view only the last 50 lines of logs from a container named 'app1'. Which command accomplishes this?

A.podman logs --lines 50 app1

B.podman logs app1

C.podman logs -n 50 app1

D.podman logs --tail 50 app1

AnswerD

The `--tail` option explicitly instructs `podman logs` to output only the last 50 lines of the container's log stream. This is the exact functionality needed to satisfy the admin's requirement. The syntax `podman logs --tail 50 app1` is correct and will work as expected. Specifying a numeric value after `--tail` is the standard way to limit log output to the most recent entries.

Why this answer

The `podman logs --tail 50 app1` command is correct because `--tail` is the Podman option to specify the number of lines from the end of the log to display. This directly fulfills the requirement to view only the last 50 lines of logs from the container named 'app1'.

Exam trap

The trap here is that candidates may confuse `--tail` with `--lines` or `-n`, which are common in other tools like `tail` or `kubectl logs`, but Podman specifically uses `--tail` for this purpose.

How to eliminate wrong answers

Option A is wrong because `--lines` is not a valid option for `podman logs`; Podman uses `--tail` to specify the number of lines from the end. Option B is wrong because `podman logs app1` without any options displays all logs from the container, not just the last 50 lines. Option C is wrong because `-n` is not a valid shorthand for `--tail` in `podman logs`; the correct shorthand is `-t` for timestamps, and `-n` is not recognized for line count.

Full explanation →

304

MCQeasy

Which command displays the current working directory?

A.pwd

B.ls

C.dir

D.cd

AnswerA

pwd (print working directory) outputs the absolute pathname of the directory the shell is currently in, beginning from the root (/). It is both a shell builtin and a standalone program at /bin/pwd, and it reads the kernel's per-process current working directory. Without options it prints the logical path, while -P resolves symlinks to show the physical location.

Why this answer

The `pwd` command stands for 'print working directory' and is the standard Linux/Unix command to display the absolute path of the current directory. It is part of the GNU Core Utilities and is the correct tool for this task in the Red Hat Enterprise Linux environment tested in EX200.

Exam trap

Red Hat often tests the distinction between commands that navigate (`cd`), list contents (`ls`), and display the current path (`pwd`), and candidates may confuse `cd` with `pwd` because both are commonly used together in shell navigation.

How to eliminate wrong answers

Option B is wrong because `ls` lists the contents of a directory, not the current working directory path. Option C is wrong because `dir` is a command typically used in Windows or DOS environments to list directory contents, and it is not a standard command in Linux for displaying the working directory. Option D is wrong because `cd` is used to change the current working directory, not to display it.

Full explanation →

305

MCQmedium

A system has a disk that may be failing. Which tool can be used to check the health of a SATA disk using SMART monitoring?

A.fsck

B.dd

C.smartctl

D.badblocks

AnswerC

smartctl from the smartmontools package is the correct tool for assessing disk health because it queries the S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) subsystem built into the drive's firmware. It retrieves attribute values like reallocated-sector counts, raw read error rates, and temperature, and can invoke self-tests such as short or long tests to verify the media. By comparing current values against failure thresholds, smartctl provides early warning of impending disk failure, unlike filesystem or block-level tools.

Why this answer

smartctl is the correct tool because it directly interfaces with the Self-Monitoring, Analysis, and Reporting Technology (SMART) built into modern SATA and ATA drives. It can query the drive's internal health metrics, such as reallocated sector counts and temperature, to predict potential failure. The other options do not access SMART data.

Exam trap

Red Hat often tests the distinction between file system tools (fsck), block-level utilities (dd, badblocks), and hardware monitoring tools (smartctl), leading candidates to confuse disk surface testing with SMART health checks.

How to eliminate wrong answers

Option A is wrong because fsck (file system check) operates on the file system layer, not on the underlying disk hardware, and cannot read SMART attributes. Option B is wrong because dd is a low-level data copy and conversion tool; it can read/write raw disk blocks but has no capability to query SMART health data. Option D is wrong because badblocks scans for physical bad sectors by performing read/write tests, but it does not access the drive's internal SMART logs or predictive failure indicators.

Full explanation →

306

MCQhard

A system has two 500GB disks in a RAID1 (mirror) using mdadm. One disk fails. After replacement, what is the correct procedure to restore redundancy?

A.Run 'mdadm --manage /dev/md0 --add /dev/sdb'

B.Remove the failed disk with 'mdadm /dev/md0 --fail /dev/sdb1' then add new.

C.Run 'mdadm --assemble --scan' to rebuild the array automatically.

D.Use sfdisk to copy partition table from /dev/sda to /dev/sdb, then 'mdadm --manage /dev/md0 --add /dev/sdb1'

AnswerD

Use 'sfdisk' to clone the partition table from /dev/sda to /dev/sdb, ensuring the new disk has a matching partition layout with the correct RAID partition type and UUIDs. After that, 'mdadm --manage /dev/md0 --add /dev/sdb1' enrolls the freshly partitioned partition as a spare, causing the array to start rebuilding the mirror data. This sequence properly introduces the new disk into the existing RAID1 without disrupting the active array.

Why this answer

When replacing a failed disk in a RAID1 array managed by mdadm, the new disk must have a partition table that matches the surviving disk. Using sfdisk to copy the partition table from /dev/sda to /dev/sdb ensures that the partition layout (e.g., partition type 0xFD for Linux RAID autodetect) is identical, which is required before adding the partition (e.g., /dev/sdb1) to the array with mdadm --manage --add. Simply adding the raw disk without a proper partition table would fail because mdadm expects a partition with the correct RAID superblock and partition type.

Exam trap

The trap here is that candidates assume adding a new disk directly with 'mdadm --add' is sufficient, overlooking the critical prerequisite of having an identical partition table on the replacement disk, which is a common oversight in RAID recovery procedures.

How to eliminate wrong answers

Option A is wrong because 'mdadm --manage /dev/md0 --add /dev/sdb' attempts to add the entire disk device, but mdadm requires a partition (e.g., /dev/sdb1) that has a valid partition table and RAID superblock; adding a raw disk without a partition table will not work and may corrupt the array. Option B is wrong because 'mdadm /dev/md0 --fail /dev/sdb1' is used to mark an existing device as failed, but the question states the disk has already failed; the failed device should be removed with 'mdadm --remove' after marking it failed, and the new disk still needs a partition table before adding, which this option omits. Option C is wrong because 'mdadm --assemble --scan' is used to reassemble an existing array from its components after a system reboot or if the array is stopped, not to add a replacement disk to an already active array; it does not handle the partition table requirement for a new disk.

Full explanation →

307

MCQmedium

Which command checks if a user's password has expired and forces a password change at next login?

A.chage -d 0 username

B.passwd -f username

C.usermod -L username

D.passwd -l username

AnswerA

chage -d 0 sets the 'date of last password change' field to 0, representing the epoch date (1970-01-01). When the user attempts to log in, the system compares the current date to this zero epoch and determines that the password has already exceeded its maximum age, forcing an immediate password change. This command is the standard method to expire a user's existing password without locking the account or requiring manual intervention.

Why this answer

The `chage -d 0 username` command sets the last password change date to the epoch (January 1, 1970), which forces the password to be considered expired immediately. On the next login, the system will prompt the user to change their password before granting access, as defined by the PAM (Pluggable Authentication Modules) password aging policy.

Exam trap

The trick is to distinguish between password expiration (chage -d 0) and account locking (passwd -l, usermod -L). Many candidates incorrectly choose an account lock command because they think it forces a password change at next login, but locking prevents login entirely until unlocked.

How to eliminate wrong answers

Option B is wrong because `passwd -f username` forces a password change on the next login only if the password has already expired; it does not expire the password itself. Option C is wrong because `usermod -L username` locks the user account by placing an exclamation mark in the shadow password file, preventing login entirely rather than forcing a password change. Option D is wrong because `passwd -l username` locks the account by adding a '!' prefix to the encrypted password in /etc/shadow, which also denies login access.

Full explanation →

308

MCQhard

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

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

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

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

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

AnswerD

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

309

MCQmedium

Refer to the exhibit. An administrator runs 'mount -o remount,ro /data' and then 'mount' shows /data as read-only. Later, the system is rebooted. What is the state of /data after reboot?

A./data will be mounted read-write because fstab specifies defaults (rw).

B./data will be mounted read-only because the remount persists across reboots.

C./data will not be mounted because the filesystem is marked as read-only.

D./data will be mounted read-only because the kernel remembers the last mount state.

AnswerA

The mount -o remount command reapplies the options currently listed in /etc/fstab for that filesystem without fully unmounting it. Since fstab for /data contains the defaults option, which implies rw (read-write), the remounted filesystem will be writable. This is a runtime operation only — fstab is the persistent source of truth, so after a reboot the same rw state would be applied again anyway.

Why this answer

The `mount -o remount,ro /data` command changes the mount state only for the current session; it does not modify the `/etc/fstab` entry. The `defaults` mount option in fstab implies `rw` (read-write). After a reboot, the system reads fstab and mounts `/data` according to its persistent configuration, which is read-write.

Exam trap

Red Hat often tests the misconception that runtime mount options persist after a reboot, leading candidates to forget that `/etc/fstab` is the authoritative source for mount behavior at boot.

How to eliminate wrong answers

Option B is wrong because `remount` does not persist across reboots; mount options applied at runtime are lost after a reboot unless they are written to `/etc/fstab` or a systemd mount unit. Option C is wrong because a read-only remount does not mark the filesystem itself as read-only; it only changes the current mount's access mode, and the filesystem remains fully functional for a subsequent read-write mount. Option D is wrong because the kernel does not remember mount states across reboots; mount information is ephemeral and is re-established from fstab or initramfs during boot.

Full explanation →

310

MCQeasy

A system administrator needs to create a new ext4 filesystem on /dev/sdb1 and mount it persistently at /data. Which set of commands should be used?

A.mkfs -t ext4 /dev/sdb1 && mkdir /data && mount /dev/sdb1 /data && echo '/dev/sdb1 /data ext4 defaults 0 0' >> /etc/fstab

B.mkfs.ext4 /dev/sdb1 && mount /dev/sdb1 /data

C.mkfs -t ext4 /dev/sdb1 && echo '/dev/sdb1 /data ext4 defaults 0 0' >> /etc/fstab && mount /data

D.mkfs.ext4 /dev/sdb1 && mkdir /data && mount /dev/sdb1 /data && blkid /dev/sdb1 >> /etc/fstab

AnswerA

This is the only complete sequence: mkfs -t ext4 /dev/sdb1 (equivalent to mkfs.ext4) creates a fresh ext4 filesystem, mkdir /data provides the required directory mount point, mount /dev/sdb1 /data attaches the filesystem for immediate use, and appending a correctly formatted fstab line ('/dev/sdb1 /data ext4 defaults 0 0') ensures the filesystem is mounted automatically at boot. The fstab line contains the six required fields in the correct order, making this the correct answer.

Why this answer

It creates the ext4 filesystem with `mkfs -t ext4 /dev/sdb1`, creates the mount point directory with `mkdir /data`, mounts the filesystem immediately with `mount /dev/sdb1 /data`, and then adds an entry to `/etc/fstab` using the correct format (device, mount point, filesystem type, options, dump, pass) to ensure the mount persists across reboots. The `&&` operator ensures each command only runs if the previous one succeeds, which is a safe practice for scripting this task.

Exam trap

The trap here is that candidates often forget to create the mount point directory or attempt to use `blkid` output directly in fstab, assuming it will work, when in fact the fstab file requires a specific columnar format with the device, mount point, filesystem type, options, dump, and pass fields.

How to eliminate wrong answers

Option B is wrong because it does not create the mount point directory (`/data`) before mounting, which will cause the mount command to fail if `/data` does not already exist, and it does not add an entry to `/etc/fstab`, so the mount is not persistent. Option C is wrong because it attempts to mount using `mount /data` without specifying the device, which is invalid syntax; the mount command requires either a device or an existing fstab entry to reference, and the fstab entry is added after the mount command in this sequence, so the mount would fail. Option D is wrong because it uses `blkid /dev/sdb1 >> /etc/fstab` to append the output of blkid (which includes the UUID and filesystem type in a non-fstab format) instead of a properly formatted fstab line; this would corrupt /etc/fstab and not result in a persistent mount.

Full explanation →

311

MCQmedium

An administrator wants to run a container with --user 1001:1001 to avoid running as root. After starting, the container cannot write to a bind-mounted directory owned by root. What is the best practice to allow write access?

A.Run the container with --privileged.

B.Add the user 1001 on the host to the root group.

C.Use 'podman unshare chown 1001:1001 /host/dir' to change host directory ownership.

D.Set setuid bit on the host directory.

AnswerC

The command podman unshare chown 1001:1001 /host/dir changes ownership of the host directory from inside the same user namespace that the rootless container will use. Because podman unshare maps the container's UID/GID to the correct underlying host UIDs, the directory becomes owned by UID 1001 and GID 1001 as seen by the container, and the container user 1001 can write to it. This is the recommended approach for fixing rootless bind-mount permission issues, as it avoids requiring host-level root and precisely matches the container's identity.

Why this answer

`podman unshare chown 1001:1001 /host/dir` changes the ownership of the host directory to UID/GID 1001, matching the container's user. This is the best practice in rootless Podman environments, as it avoids running the container with elevated privileges while ensuring the container user can write to the bind-mounted directory.

Exam trap

The trap here is that candidates often choose `--privileged` or setuid as a quick fix, not realizing that rootless Podman requires explicit ownership changes via `podman unshare` to maintain security and proper UID mapping.

How to eliminate wrong answers

Option A is wrong because `--privileged` grants the container all capabilities and access to host devices, which defeats the purpose of running as a non-root user and introduces unnecessary security risks. Option B is wrong because adding user 1001 to the root group on the host does not grant write access to a directory owned by root unless the directory's group permissions allow it (e.g., 775), and it violates the principle of least privilege. Option D is wrong because setting the setuid bit on the host directory does not affect write permissions for a non-root container user; setuid is for executable files, not directories, and does not change ownership for file creation.

Full explanation →

312

Multi-Selecteasy

Which TWO options correctly describe the use of 'podman exec'? (Choose TWO.)

Select 2 answers

A.podman exec <container> ls / runs the ls command inside the running container.

B.podman exec can run commands as a different user with --user.

C.podman exec -it <container> /bin/bash attaches to an existing shell process.

D.podman exec can start a stopped container.

E.podman exec -it <container> /bin/bash runs an interactive shell in a new container.

AnswersA, B

The `podman exec` command takes a container name or ID followed by a command, then runs that command as a new process inside the already running container's namespaces and root filesystem. Here, `ls /` is executed directly by the container's runtime, not through a shell unless explicitly wrapped, so the output is the contents of the container's root directory. This is the core purpose of `exec`: to run a one-off command in an existing, running container without creating a new container.

Why this answer

`podman exec <container> ls /` executes the `ls /` command directly inside the specified running container, using the container's filesystem and environment. This is the primary purpose of `podman exec`: to run a new process in an already running container without creating a new container.

Exam trap

The trap here is confusing `podman exec` (which runs a new process in an existing running container) with `podman attach` (which connects to an existing process) or `podman run` (which creates a new container), leading candidates to incorrectly select options about attaching to existing shells or starting stopped containers.

Full explanation →

313

MCQhard

Refer to the exhibit. An administrator attempts to mount all filesystems using 'mount -a' and receives an error. What is the most likely cause?

A.The ext4 filesystem on /dev/vdb1 is corrupted.

B.The filesystem type specified in /etc/fstab is incorrect.

C.The entry for /dev/vdb1 in /etc/fstab uses a device name that does not exist.

D.The mount point /mnt/data does not exist.

AnswerC

The fstab entry specifies the device path /dev/vdb1, but that block device is not present in the system (e.g., the disk was removed, or the kernel assigned a different name after a reboot). The error message 'can't find /dev/vdb1' directly states that the kernel cannot resolve that device path, which is why mount -a fails. This demonstrates a common pitfall of using static device names in fstab; using persistent identifiers like UUID= or LABEL= would avoid this issue.

Why this answer

The error occurs because the entry in /etc/fstab for /dev/vdb1 references a device name that does not exist on the system. When 'mount -a' is executed, it reads /etc/fstab and attempts to mount each filesystem; if the device node is missing (e.g., due to a typo, incorrect kernel name, or the device not being attached), the mount fails with an error like 'mount: special device /dev/vdb1 does not exist'. This is the most likely cause given the scenario.

Exam trap

Red Hat RHCSA often tests the distinction between errors caused by a missing device node versus a missing mount point or filesystem corruption, and candidates mistakenly assume the error is due to a missing mount point or a corrupted filesystem without reading the exact error message.

How to eliminate wrong answers

Option A is wrong because a corrupted ext4 filesystem would produce a different error (e.g., 'mount: /dev/vdb1: can't read superblock' or 'wrong fs type'), not a 'device does not exist' message. Option B is wrong because an incorrect filesystem type in /etc/fstab would result in an error like 'mount: wrong fs type, bad option, bad superblock', not a missing device error. Option D is wrong because if the mount point /mnt/data did not exist, the error would be 'mount: mount point /mnt/data does not exist', which is a distinct message from the device-not-found error.

Full explanation →

314

Matchingmedium

Match each systemd unit type to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Manages a daemon or service process

Groups units to define system states (runlevels)

Enables socket-based activation for services

Triggers activation of other units on a schedule

Why these pairings

Systemd unit types define system resources: service (daemons), socket (IPC), target (group/synchronization), timer (scheduled activation). Common confusions involve mixing mount with service and target with timer.

Full explanation →

315

Multi-Selecteasy

Which two commands can be used to display the contents of a compressed .tar.gz archive without extracting it? (Choose two)

Select 2 answers

A.gzcat archive.tar.gz

B.less archive.tar.gz

C.tar -tzf archive.tar.gz

D.tar -tf archive.tar.gz

E.tar -xf archive.tar.gz

AnswersC, D

tar -tzf archive.tar.gz is the textbook explicit way to list a gzipped tarball's contents. The -z option tells tar to decompress the archive through gzip before reading it, -t selects list mode instead of extract mode, and -f names the archive file. The output is a path-by-path listing of every file and directory stored in the archive, with no data extracted to disk.

Why this answer

`tar -tzf` lists the contents of a gzip-compressed tar archive without extracting it. The `-t` flag tells tar to list the table of contents, `-z` handles the gzip decompression on the fly, and `-f` specifies the archive file. This is the standard way to inspect a .tar.gz file's contents without extraction.

Exam trap

Red Hat often tests the distinction between `-t` (list) and `-x` (extract), and candidates mistakenly choose `tar -xf` thinking it only displays contents, or they confuse `gzcat` with a listing tool.

Full explanation →

316

Multi-Selecthard

Which THREE commands are required to create a logical volume named lv_data of size 10G in volume group vg_data, format it as XFS, and mount it at /mnt/data?

Select 3 answers

A.vgcreate vg_data /dev/sde1

B.lvcreate -L 10G -n lv_data vg_data

C.mount /dev/vg_data/lv_data /mnt/data

D.pvcreate /dev/sde1

E.mkfs.xfs /dev/vg_data/lv_data

AnswersB, C, E

This is the primary command that carves out a logical volume named lv_data from the existing volume group vg_data with a size of 10 GiB. The -L flag specifies the size and -n assigns the name, making this an essential step in creating the LV device node under /dev/vg_data/. Without this command, no logical volume would exist to format or mount.

Why this answer

The `lvcreate -L 10G -n lv_data vg_data` command creates a logical volume named lv_data with a size of 10 GB within the volume group vg_data. This is the standard LVM command for creating logical volumes, where `-L` specifies the size and `-n` specifies the name.

Exam trap

The trap here is that candidates often include `pvcreate` and `vgcreate` as required steps, but the question specifies that the volume group vg_data already exists, so only the LV creation, formatting, and mounting commands are needed.

Full explanation →

317

MCQeasy

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

A.The directory has the sticky bit set

B.The filesystem is read-only

C.The user is not the owner of the directory

D.The user is not in the group

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

318

MCQeasy

The administrator wants to create a new ext4 file system on /dev/sdb1 with a block size of 1024 bytes. Which command should be used?

A.mkfs.ext4 -b 1024 /dev/sdb1

B.mkfs.ext4 -B 1024 /dev/sdb1

C.mkfs.ext4 -s 1024 /dev/sdb1

D.mkfs.ext4 --block-size 1024 /dev/sdb1

AnswerA

The -b option in mkfs.ext4 sets the filesystem block size in bytes, overriding the default of 4096 bytes. With -b 1024, the filesystem uses 1 KiB blocks, which reduces internal fragmentation for volumes that will hold many small files, though it also reduces the maximum supported filesystem size. This is the correct syntax for creating a valid ext4 filesystem with a non-default block size.

Why this answer

The `-b` flag in `mkfs.ext4` specifies the block size in bytes. To create an ext4 filesystem with 1024-byte blocks on /dev/sdb1, the command `mkfs.ext4 -b 1024 /dev/sdb1` is used. This is the standard syntax for setting the logical block size when formatting an ext4 filesystem.

Exam trap

The trap here is that candidates confuse the `-b` flag with other common flags like `-B` (used by XFS) or `-s` (used for stride), or assume GNU-style long options like `--block-size` are supported by `mkfs.ext4` when they are not.

How to eliminate wrong answers

Option B is wrong because `-B` is not a valid flag for `mkfs.ext4`; it is used by `mkfs.xfs` to specify block size, but for ext4 the correct flag is lowercase `-b`. Option C is wrong because `-s` in `mkfs.ext4` is used to specify the number of bytes per inode (stride), not the block size. Option D is wrong because `--block-size` is not a recognized long option for `mkfs.ext4`; the utility does not support GNU-style long options for block size, only the short `-b` flag.

Full explanation →

319

MCQhard

A logical volume 'lv_share' in volume group 'vg_share' has no free extents. The administrator needs to increase the size of '/dev/vg_share/lv_share' by 5 GB. There is another logical volume 'lv_archive' in the same volume group that has 10 GB free space within its filesystem. What must the administrator do to allocate space from 'lv_archive' to 'lv_share'?

A.Reduce the filesystem on 'lv_archive' with resize2fs, then reduce the logical volume with lvreduce, then extend 'lv_share'.

B.Shrink the filesystem on 'lv_archive' to free space, then use vgsplit to move the space to 'lv_share'.

C.Use lvreduce directly on 'lv_archive' without changing the filesystem, then lvextend on 'lv_share'.

D.Use lvresize to reduce 'lv_archive' and extend 'lv_share' in one command.

E.Add a new physical volume to the volume group instead.

AnswerA

The safe sequence is to first shrink the filesystem with resize2fs so its data structures fit within a smaller block device, then use lvreduce to shrink the logical volume to match (or slightly exceed) the new filesystem size, ensuring no filesystem metadata is truncated. After that, the freed extents become available in the volume group, allowing lvextend to grow lv_share without any data loss. This ordering is mandatory because the kernel/filesystem must be told about a smaller size before the underlying block device is reduced.

Why this answer

You must first shrink the filesystem on 'lv_archive' using resize2fs (or e2fsck -f / resize2fs) to free space within the filesystem, then reduce the logical volume with lvreduce to release the underlying physical extents back to the volume group. Only after those steps can you extend 'lv_share' with lvextend and then resize its filesystem. This sequence ensures data integrity and avoids filesystem corruption.

Exam trap

Red Hat often tests the misconception that you can reduce a logical volume without first shrinking the filesystem, leading candidates to choose option C, but the correct sequence always requires filesystem resizing before LV reduction to prevent corruption.

How to eliminate wrong answers

Option B is wrong because vgsplit is used to move entire physical volumes between volume groups, not to reallocate free space within the same volume group; it would break the volume group structure. Option C is wrong because using lvreduce directly on 'lv_archive' without first shrinking the filesystem will corrupt the filesystem, as the logical volume shrink truncates the block device before the filesystem is aware. Option D is wrong because lvresize cannot simultaneously reduce one LV and extend another in a single command; it operates on one logical volume at a time.

Option E is wrong because adding a new physical volume does not utilize the existing free space within 'lv_archive' and is unnecessary when space can be reclaimed from the same volume group.

Full explanation →

320

MCQhard

An administrator needs to ensure that a container always runs with a specific SELinux context for security reasons. The container uses a volume mount from the host. Which command should be used to start the container?

A.podman run --label selinux_context=container_t -v /host/data:/data myimage

B.podman run --privileged -v /host/data:/data myimage

C.podman run --selinux-context container_t -v /host/data:/data myimage

D.podman run --security-opt label=type:container_t -v /host/data:/data myimage

AnswerD

`--security-opt label=type:container_t` directly instructs the container runtime to apply the SELinux type `container_t` to the container's processes and files, which is the proper way to set a SELinux context in Podman. This option is processed by the OCI runtime and translates into the appropriate SELinux labeling call, ensuring the container is confined by the targeted policy. It is the correct method because it leverages the intended `security-opt` mechanism for SELinux type selection.

Why this answer

`--security-opt label=type:container_t` explicitly sets the SELinux type for the container process to `container_t`, ensuring the container runs with the required SELinux context. This is the proper way to assign a specific SELinux type when using `podman run`, especially when volume mounts are involved, as it avoids permission conflicts with the host's SELinux policy.

Exam trap

The trap here is that candidates often confuse `--label` (for metadata) with SELinux labeling, or assume `--privileged` is a quick fix for SELinux issues, but the exam specifically tests the correct `--security-opt label=type:` syntax for setting SELinux contexts in Podman.

How to eliminate wrong answers

Option A is wrong because `--label` is used to add metadata labels to the container (e.g., for Podman or Docker), not to set SELinux contexts; `selinux_context` is not a valid option for `--label`. Option B is wrong because `--privileged` grants the container full access to the host, including disabling SELinux enforcement, which bypasses the requirement to run with a specific SELinux context and is insecure. Option C is wrong because `--selinux-context` is not a valid flag in Podman; the correct syntax uses `--security-opt label=type:` to specify the SELinux type.

Full explanation →

321

MCQhard

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

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

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

C.Modify kernel parameters to disable the OOM killer.

D.Increase swap space to 16GB.

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

322

Multi-Selecthard

Which TWO of the following are valid examples of using redirection and pipes in bash to append the output of a command to a file while also displaying it on the terminal? (Choose exactly two.)

Select 2 answers

A.command 2>&1 | tee file

B.command | tee -a file

C.command > file

D.command |& tee -a file

E.command >> file

AnswersB, D

The pipeline command | tee -a file sends only stdout to tee, and the -a flag makes tee open the destination file in append mode, preserving any data already in the file. Tee also writes the same bytes to its own standard output, so the user still sees the command's output live on the terminal. This combination of appending to a persistent log and duplicating the stream to the terminal is exactly what makes it a valid redirection example.

Why this answer

`tee -a file` reads from stdin and writes both to stdout and appends to the named file. The pipe `|` sends the stdout of `command` to `tee`, so the output is displayed on the terminal and appended to `file`. The `-a` flag ensures append mode, not overwrite.

Exam trap

Red Hat often tests the distinction between `|` (stdout only) and `|&` (stdout and stderr), and the requirement for `-a` to append rather than overwrite, causing candidates to miss that option A lacks `-a` and option D correctly uses `|&` with `-a`.

Full explanation →

323

MCQeasy

An administrator needs to create a 10GB logical volume named 'mylv' in an existing volume group 'vg1', format it with XFS, and mount it at /mnt/data. Which set of commands achieves this correctly?

A.lvcreate -n mylv -L 10G vg1 && mkfs.xfs /dev/vg1/mylv && mount /dev/vg1/mylv /mnt/data && echo "/dev/vg1/mylv /mnt/data xfs defaults 0 0" >> /etc/fstab

B.lvcreate -n mylv -L 10G vg1 && mkfs.xfs /dev/vg1/mylv && mount /dev/vg1/mylv /mnt/data && blkid /dev/vg1/mylv >> /etc/fstab

C.lvcreate -n mylv -L 10G vg1 && mkfs.xfs /dev/vg1/mylv && mount /dev/vg1/mylv /mnt/data && echo "/dev/vg1/mylv /mnt/data xfs defaults 0 0" > /etc/fstab

D.lvcreate -n mylv --size 10G vg1 && mkfs.xfs /dev/mylv && mount /dev/mylv /mnt/data && echo "/dev/mylv /mnt/data xfs defaults 0 0" >> /etc/fstab

AnswerA

This command correctly creates a 10GB logical volume named mylv, formats it as XFS, mounts it to /mnt/data, and persists the mount in /etc/fstab. `lvcreate -n mylv -L 10G vg1` creates the LV and exposes it at `/dev/vg1/mylv`, which is then formatted with `mkfs.xfs` and mounted. The `echo` command appends a properly formatted fstab entry — device, mount point, filesystem type, options, dump, and pass fields — to `/etc/fstab` using `>>`, which preserves all existing entries. This is the only option that correctly leaves the system configured to mount the LV automatically after a reboot.

Why this answer

It uses the proper `lvcreate` syntax with `-n` for name and `-L` for size, creates the logical volume `/dev/vg1/mylv`, formats it with XFS, mounts it, and appends the correct fstab entry using `>>` to avoid overwriting existing entries. The device path `/dev/vg1/mylv` is the standard LVM device mapper path for a logical volume named 'mylv' in volume group 'vg1'.

Exam trap

Red Hat often tests the distinction between `>` (overwrite) and `>>` (append) in fstab manipulation, and the correct LVM device path format (`/dev/vg1/mylv` vs. `/dev/mylv`), to catch candidates who confuse volume group names with logical volume paths or misuse shell redirection.

How to eliminate wrong answers

Option B is wrong because `blkid` outputs a line with the UUID and filesystem type, but the format is not a valid fstab entry (it lacks mount point, options, dump, and pass fields), and appending it directly to `/etc/fstab` would cause mount failures. Option C is wrong because it uses `>` (single redirect) instead of `>>`, which overwrites the entire `/etc/fstab` file, destroying all existing mount entries. Option D is wrong because it uses the incorrect device path `/dev/mylv` (which would be a volume group name, not a logical volume path) and also uses `--size` instead of `-L` (though `--size` works, the path error is fatal); the correct path should be `/dev/vg1/mylv`.

Full explanation →

324

Multi-Selectmedium

A system administrator needs to configure a firewall using firewalld to allow incoming HTTPS traffic and deny incoming SSH traffic from a specific source IP 192.168.1.100. Which two commands should be run? (Choose two.)

Select 2 answers

A.firewall-cmd --runtime-to-permanent

B.firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.100 service name=ssh reject' --permanent

C.firewall-cmd --add-service=https --permanent

D.firewall-cmd --add-service=http --permanent

E.firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.100 service name=ssh drop' --permanent

AnswersC, E

This command correctly adds the predefined https service to the permanent zone configuration, allowing inbound TCP traffic on port 443. Using --permanent ensures the rule survives reboots, and the https service entry in firewalld maps cleanly to the standard HTTPS port. Since the requirement is to permit secure web traffic, adding the https service is the appropriate, concise way to achieve that with firewalld.

Why this answer

`firewall-cmd --add-service=https --permanent` adds the HTTPS service (TCP port 443) to the permanent firewall configuration, which is required to allow incoming HTTPS traffic persistently across reboots. The `--permanent` flag ensures the rule survives a reload or restart, and the `--add-service` option uses predefined service definitions from firewalld to simplify rule creation.

Exam trap

The trap here is that candidates often confuse `reject` with `drop` in rich rules, or they mistakenly add the HTTP service instead of HTTPS, failing to distinguish between the two services and their respective ports.

Full explanation →

325

MCQeasy

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

A./etc/rc.local

B./etc/fstab

C./boot/grub2/grub.cfg

D./etc/mtab

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

326

MCQmedium

Refer to the exhibit. An administrator extends an XFS filesystem on /data. Which prerequisite step is missing from the output?

A.The filesystem must be mounted before xfs_growfs

B.The filesystem must be checked with xfs_repair before growing

C.The filesystem must be unmounted before xfs_growfs

D.The logical volume must be deactivated before xfs_growfs

AnswerA

xfs_growfs is an online resizing tool that operates on a mounted XFS filesystem; it takes the mount point as its argument and uses the live filesystem's geometry to determine the new size. If the filesystem is not mounted, xfs_growfs cannot obtain the necessary superblock and allocation group information via the kernel, so the operation fails. This requirement is the exact opposite of the old ext2/3/4 resize2fs workflow, which typically requires unmounting, and is a key differentiator for XFS administration.

Why this answer

The xfs_growfs command requires the XFS filesystem to be mounted because it operates on a live filesystem, resizing it to match the underlying block device. The exhibit shows the administrator running xfs_growfs without first mounting /data, which is the missing prerequisite step. Without mounting, xfs_growfs cannot access the filesystem's superblock to perform the resize.

Exam trap

A common misconception is that filesystems must be unmounted before resizing, but XFS specifically supports online growing. The trap is assuming a traditional unmount requirement applies here.

How to eliminate wrong answers

Option B is wrong because xfs_repair is used to repair a corrupted filesystem, not as a prerequisite for growing; xfs_growfs does not require a prior check. Option C is wrong because XFS filesystems must be mounted to be grown with xfs_growfs; unmounting would prevent the command from working. Option D is wrong because the logical volume must be active (not deactivated) to be accessible; deactivating it would make the block device unavailable for the filesystem.

Full explanation →

327

MCQmedium

After adding a new disk /dev/sdc, a system administrator wants to mount it persistently at /mnt/backup. Which entry in /etc/fstab is most reliable?

A.LABEL=data /mnt/backup xfs defaults 0 0

B.PARTUUID=def456... /mnt/backup xfs defaults 0 0

C./dev/sdc /mnt/backup xfs defaults 0 0

D.UUID=abc123... /mnt/backup xfs defaults 0 0

AnswerD

The filesystem UUID is a unique identifier generated at mkfs time and stored in the filesystem superblock. It remains constant even if the disk moves to a different port or the device name changes. Using UUID= in /etc/fstab ensures the correct filesystem is mounted at boot. This is the standard, reliable method for persistent mount configuration.

Why this answer

Using the UUID (Universally Unique Identifier) ensures the filesystem is mounted persistently regardless of device name changes (e.g., /dev/sdc could become /dev/sdd after a reboot or disk addition). The UUID is generated when the filesystem is created and remains constant, making it the most reliable method for persistent mounts in /etc/fstab.

Exam trap

Red Hat often tests the misconception that device names like /dev/sdc are stable, but the trap here is that device names can change after reboots or hardware changes, while UUIDs remain constant and are the recommended method for persistent mounts in /etc/fstab.

How to eliminate wrong answers

Option A is wrong because it uses a LABEL, which is not set by default on a new disk; if the label 'data' does not exist on /dev/sdc, the mount will fail, and labels can be accidentally duplicated or changed. Option B is wrong because PARTUUID identifies the partition table entry, not the filesystem itself; it is used for partition identification (e.g., with GPT) and does not guarantee the filesystem is present or consistent. Option C is wrong because /dev/sdc is a device name that can change dynamically (e.g., after a reboot or adding other disks), leading to mount failures or mounting the wrong device.

Full explanation →

328

Matchingmedium

Match each firewall zone to its default trust level.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Low trust; only allow selected incoming connections

Moderate trust; for private networks

High trust; accept all connections

For publicly accessible systems isolated from internal network

Why these pairings

Correct matches: drop blocks all traffic silently, public allows only basic services, internal allows more services, trusted allows all. Common confusions include mixing drop with trusted or public with internal.

Full explanation →

329

MCQhard

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

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

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

C.The rich rule was not made permanent.

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

330

Multi-Selecthard

Which three of the following actions are required when adding a new swap device to the system? (Choose three.)

Select 3 answers

A.Mount the device to a swap directory

B.Create a filesystem using mkfs

C.Use mkswap to set up the swap signature

D.Use swapon to activate swap

E.Add an entry in /etc/fstab with the swap option

AnswersC, D, E

mkswap initializes a disk partition or file by writing a swap signature and labeling information, preparing it for use as virtual memory. Without this step, the kernel does not recognize the device as swap, so mkswap is a mandatory prerequisite for any swap area. It is a distinct operation separate from filesystem creation, because swap uses a raw layout rather than a filesystem.

Why this answer

`mkswap` writes a swap signature (UUID and label) to the device, which is required before the kernel can use it as swap space. Without this signature, the device is not recognized as a swap area.

Exam trap

Red Hat often tests the misconception that swap devices must be mounted or formatted with a filesystem, leading candidates to incorrectly select options A or B.

Full explanation →

331

MCQmedium

A system is experiencing high CPU usage. The administrator suspects a process is stuck in an infinite loop. Which command can be used to identify the most CPU-intensive process in real-time?

A.top

B.lsof

C.ps aux

D.strace

AnswerA

top is a real-time process monitoring utility that continuously updates the list of running processes and sorts by CPU usage by default, making it easy to spot which process is consuming high CPU. It refreshes every few seconds and provides interactive sorting and filtering options, allowing administrators to quickly identify and act on the CPU-intensive process.

Why this answer

The `top` command provides a real-time, dynamic view of system processes, sorted by CPU usage by default. It continuously refreshes, making it ideal for identifying the most CPU-intensive process as it runs, which directly addresses the scenario of a suspected infinite loop causing high CPU usage.

Exam trap

Red Hat often tests the distinction between real-time monitoring (`top`) and static snapshots (`ps`), where candidates mistakenly choose `ps aux` because they see CPU columns, but fail to recognize that `ps` does not refresh dynamically to catch a looping process.

How to eliminate wrong answers

Option B is wrong because `lsof` lists open files and the processes using them, but it does not show CPU usage or sort processes by CPU consumption in real-time. Option C is wrong because `ps aux` provides a static snapshot of all processes with CPU usage at the moment of execution, but it does not update in real-time to track a rapidly changing CPU-intensive process. Option D is wrong because `strace` traces system calls and signals for a specific process, but it is not designed to identify the most CPU-intensive process; it is a debugging tool for analyzing a process's behavior, not for monitoring overall system CPU usage.

Full explanation →

332

MCQeasy

A user is unable to log in via SSH. The administrator checks /var/log/secure and sees 'Authentication refused: bad ownership or modes' for the user's home directory. What is the most likely cause?

A.The sshd service is not running

B.The SELinux context is wrong

C.The .ssh/authorized_keys file has incorrect permissions

D.The user's home directory is owned by root

AnswerD

An improperly owned home directory is a different failure point that would prevent the '.' in 'bad ownership or modes for /home/user/.ssh/authorized_keys' from being accurate. When the home directory is owned by root, sshd may either fail to traverse into it (if permissions block the user) or produce a separate StrictModes complaint such as 'Home directory /home/user is not owned by user' or 'Could not open authorized keys'. This would stop the login process at an earlier stage, not specifically point at the authorized_keys file's permissions as the cause.

Why this answer

The error 'Authentication refused: bad ownership or modes' includes the path of the offending file. When the log message references the user's home directory, it means the home directory itself has incorrect ownership or permissions. SSH's StrictModes requires the home directory to be owned by the user and not writable by group or others.

If the home directory is owned by root, sshd refuses authentication. The correct answer is D.

Exam trap

The log message explicitly points to the home directory, not to ~/.ssh/authorized_keys. Students often confuse this with authorized_keys permissions, but the path in the log determines which file/directory is misconfigured.

How to eliminate wrong answers

Option A is wrong because if the sshd service were not running, the user would not even reach the authentication stage; the error would be a connection timeout or 'Connection refused', not a permission-related log entry. Option B is wrong because SELinux context issues typically produce AVC denial messages in /var/log/audit/audit.log, not the specific 'bad ownership or modes' error in /var/log/secure. Option D is wrong because while a home directory owned by root could cause other issues (e.g., inability to write files), the specific error about 'bad ownership or modes' for SSH authentication is triggered by the permissions of ~/.ssh/authorized_keys, not the home directory itself.

Full explanation →

333

MCQmedium

An administrator wants to create a swap partition on /dev/sdb1. After creating the partition with fdisk, which command sets up the swap area?

A.mkswap /dev/sdb1

B.mkfs.swap /dev/sdb1

C.swapon /dev/sdb1

D.swapoff /dev/sdb1

AnswerA

mkswap /dev/sdb1 is the correct initial step because it writes the swap signature (UUID and swap superblock) onto the partition, turning it into a usable swap area. Once this initialization is complete, the swap space can be activated with swapon. Without mkswap, the partition lacks the metadata required for the kernel to recognize it as swap.

Why this answer

The correct command to set up a swap area on a partition is `mkswap /dev/sdb1`. This command initializes the partition with a swap signature, writing the necessary metadata (such as the swap superblock and version information) so the kernel can later use it as swap space. Without running `mkswap`, the partition is not recognized as a valid swap device.

Exam trap

Red Hat often tests the distinction between preparing a swap area (`mkswap`) and activating it (`swapon`), so candidates mistakenly choose `swapon` thinking it both creates and enables the swap.

How to eliminate wrong answers

Option B is wrong because `mkfs.swap` is not a valid command; the proper tool for creating a swap filesystem is `mkswap`, not a `mkfs.*` variant. Option C is wrong because `swapon` activates an already-prepared swap area; it does not set up or initialize the swap signature on the partition. Option D is wrong because `swapoff` deactivates an active swap device, which is the opposite of what is needed to prepare a new swap area.

Full explanation →

334

MCQmedium

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

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

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

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

D.The file's ACL overrides group permissions.

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

335

MCQmedium

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

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

B.Add an entry to ~/.xprofile

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

336

MCQeasy

A script needs to read every line from a file and execute a command on each line. Which code block is correct and handles whitespace correctly?

A.while IFS=$'\n' read line; do echo "$line"; done <<< file.txt

B.while IFS= read -r line; do echo "$line"; done < file.txt

C.while read line; do echo $line; done < file.txt

D.for line in $(cat file.txt); do echo $line; done

AnswerB

Setting IFS= ensures read does not trim leading or trailing whitespace from each line, preserving the exact content of the input. The -r flag prevents backslashes from being interpreted as escape characters, so paths like C:\new remain literal. Quoting "$line" in the echo command prevents word splitting and glob expansion, and < file.txt correctly redirects the file to the loop's stdin line by line. This combination is the canonical robust way to process lines in Bash.

Why this answer

It uses `IFS=` to preserve leading/trailing whitespace and `-r` to prevent backslash interpretation, ensuring each line is read exactly as it appears in the file. The `< file.txt` redirect feeds the file line by line into the `while` loop, which is the standard and safe method for line-by-line processing in Bash.

Exam trap

Red Hat often tests the distinction between `while read` loops and `for` loops with command substitution, trapping candidates who forget that `for line in $(cat file)` splits on all whitespace and expands globs, not just newlines.

How to eliminate wrong answers

Option A is wrong because `<<<` is a here-string that passes the literal string 'file.txt' as input, not the file contents, and `IFS=$'\n'` only splits on newlines but does not preserve other whitespace within lines. Option C is wrong because omitting `IFS=` causes `read` to strip leading/trailing whitespace (default IFS includes space and tab), and omitting `-r` causes backslashes to be interpreted as escape characters, altering the line content. Option D is wrong because `$(cat file.txt)` subjects the file to word splitting and glob expansion, breaking lines on any whitespace (spaces, tabs) and expanding wildcards like `*`, so it does not read lines correctly.

Full explanation →

337

MCQmedium

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

338

MCQeasy

Which command shows the amount of disk space used and available on each mounted filesystem?

A.fdisk -l

B.df -h

C.du -sh

D.lsblk

AnswerB

The df command, with the -h (human-readable) flag, is the standard RHCSA tool for reporting disk space usage and availability. It reads the filesystem superblock and kernel tables for every mounted filesystem, outputting total, used, available, and mount point columns (e.g., /dev/sda1 50G 20G 30G /). This directly answers the question: it shows both the amount of space used and the amount still available, which is why it is the correct choice.

Why this answer

The `df -h` command displays disk space usage for all mounted filesystems, showing total, used, and available space in human-readable format (e.g., GB, MB). This directly answers the question about disk space on each mounted filesystem.

Exam trap

The trap here is that candidates confuse `df` (filesystem-level space) with `du` (directory-level usage) or `fdisk` (partition table), leading them to pick a command that does not report available space on mounted filesystems.

How to eliminate wrong answers

Option A is wrong because `fdisk -l` lists partition tables on block devices, not disk space usage on mounted filesystems; it shows partition geometry and types, not available space. Option C is wrong because `du -sh` summarizes disk usage of files and directories, not filesystem-level available space; it reports space consumed by specific paths, not mounted filesystems. Option D is wrong because `lsblk` lists block devices and their attributes (e.g., size, type, mount point) but does not show used or available disk space on mounted filesystems; it omits usage percentages and available space.

Full explanation →

339

MCQmedium

A storage administrator has added a new 10 GiB disk (/dev/vdb) to a Red Hat Enterprise Linux 9 server. The requirement is to create a single XFS filesystem on the entire disk and mount it persistently at /data. The administrator runs mkfs.xfs /dev/vdb and then adds the line '/dev/vdb /data xfs defaults 0 0' to /etc/fstab. After running mount -a, the mount succeeds and df -h shows the expected size. However, after a reboot the system drops into emergency mode and reports that /data cannot be mounted. The administrator verifies that the disk is still present and the filesystem is intact. Which of the following is the most likely cause of the failure?

A.The XFS filesystem was created directly on /dev/vdb instead of on a partition such as /dev/vdb1, so the kernel cannot resolve the device at boot.

B.The /etc/fstab entry relies on the kernel device name /dev/vdb, which is not guaranteed to be stable across reboots; a persistent identifier such as a UUID or label should be used instead.

C.The XFS filesystem must be registered with the kernel using xfs_admin before it can be mounted automatically at boot.

D.The XFS filesystem must be mounted with the 'nofail' option in /etc/fstab, otherwise any filesystem mount failure will always halt the boot process.

AnswerB

Kernel-assigned names like /dev/vdb are not guaranteed to remain the same across reboots, especially when other devices are added or removed. If the device is renumbered, the fstab entry points at the wrong block device and the mount fails, dropping the system into emergency mode. Using the filesystem UUID or a label makes the entry stable and is the recommended practice for persistent mounts.

Why this answer

Persistent mounts should reference a stable identifier rather than a kernel-assigned device name. When /etc/fstab uses /dev/vdb, a reboot that reorders block devices can cause the mount unit to fail and the system to enter emergency mode. Querying the filesystem UUID with blkid and substituting UUID=... in /etc/fstab makes the entry resilient to device renaming and restores normal boot behavior.

Exam trap

The trap here is assuming that a mount that works interactively will always work after a reboot, overlooking that kernel device names are not stable identifiers.

Full explanation →

340

MCQhard

A RHEL 9 server uses LVM with volume group vg_app on a single physical volume /dev/sdc. The logical volume lv_home, formatted as XFS and mounted at /home, is running out of space, but the volume group has no free extents and no additional disks can be added. A colleague notes that /dev/sdc is a 200 GB device, yet only 120 GB of it is currently allocated to vg_app. Which single command will make the remaining space available to grow lv_home?

A.pvresize /dev/sdc

B.pvcreate /dev/sdc

C.vgextend vg_app /dev/sdc

D.lvextend -l +100%FREE /dev/vg_app/lv_home

AnswerA

pvresize re-reads the size of an existing physical volume and grows its metadata so that newly available sectors at the end of the device become usable physical extents. Because /dev/sdc is already a PV in vg_app, this is the correct single step to reclaim the unused 80 GB. After pvresize, vg_app gains free extents that can be assigned to lv_home with lvextend.

Why this answer

The physical volume /dev/sdc is larger than the extents currently recorded in its LVM metadata, so the volume group cannot see the unused tail of the disk. Resizing the existing PV with pvresize updates that metadata and makes the additional space available as free physical extents. Once the VG has free extents, lvextend and xfs_growfs can be used to enlarge and grow the XFS file system on lv_home.

Exam trap

The trap here is assuming that a volume group automatically detects extra capacity on a physical volume after the underlying device is enlarged, when in fact the PV metadata must be refreshed with pvresize first.

Full explanation →

341

Multi-Selecthard

On a default Red Hat Enterprise Linux 8 installation, which THREE tools or files can be used to configure time synchronization?

Select 3 answers

A.ntpq

B./etc/ntp.conf

C.chronyc

D.timedatectl

E./etc/chrony.conf

AnswersC, D, E

chronyc is the command-line control and monitoring tool that talks directly to chronyd, the default NTP daemon on RHEL 8. It allows queries and dynamic configuration of NTP sources, such as with chronyc sources or chronyc add server, and provides immediate status feedback. This makes chronyc the primary interactive interface for managing time synchronization in the default installation.

Why this answer

On a default Red Hat Enterprise Linux 8 installation, `chronyd` is the default NTP daemon, and its configuration file is `/etc/chrony.conf`. The `chronyc` command is the command-line interface for interacting with the `chronyd` daemon, allowing you to monitor and adjust time synchronization. `timedatectl` is the systemd-based tool for managing system time and date settings, including enabling NTP synchronization via `chronyd`.

Exam trap

The trap here is that candidates familiar with older RHEL versions (6/7) may assume `ntpq` and `/etc/ntp.conf` are still the default tools, but RHEL 8 has replaced `ntpd` with `chronyd` as the default NTP implementation.

Full explanation →

342

Multi-Selecthard

Which TWO of the following are valid mount options for enabling quotas on an ext4 file system?

Select 2 answers

A.grpquota

B.quota

C.userquota

D.noquota

E.usrquota

AnswersA, E

The `grpquota` mount option instructs the kernel to enable per-group quota accounting and enforcement on an ext4 filesystem. When placed in `/etc/fstab` or passed via `mount -o remount,grpquota`, the kernel tracks block and inode usage by group ID and can enforce limits when the `quotaon` utility activates them. This option is used alongside `usrquota` when both user and group limits are required, but it is equally valid by itself.

Why this answer

`grpquota` is a valid mount option for enabling group quotas on an ext4 file system. Option E is correct because `usrquota` is the valid mount option for enabling user quotas. Both options are recognized by the `mount` command and the ext4 driver to activate quota tracking at mount time.

Exam trap

The trap here is that candidates confuse the generic `quota` command with a mount option, or misremember the exact option names (e.g., `userquota` instead of `usrquota`), leading them to select incorrect options like `quota` or `userquota`.

Full explanation →

343

MCQeasy

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

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

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

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

D.mount -a -o exec

AnswerB, C

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

344

MCQeasy

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

A.The container is using host networking mode.

B.The container cannot be reached from other containers.

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

345

MCQeasy

A system administrator needs to verify that the filesystem on /dev/sdb1 is ext4 before adding it to /etc/fstab. Which command provides this information?

A.mount -a

B.df -Th /dev/sdb1

C.fdisk -l /dev/sdb1

D.lsblk -f /dev/sdb1

AnswerD

lsblk -f /dev/sdb1 is correct because the -f (--fs) option makes lsblk output the filesystem type, label, UUID, and mount point for the specified block device. It reads this information from udev and kernel device da, which ultimately come from the filesystem superblock, so it works whether the device is mounted or not. This makes it ideal for verifying that /dev/sdb1 was formatted with the expected filesystem before attempting to mount it.

Why this answer

The `lsblk -f /dev/sdb1` command displays the filesystem type (FSTYPE) for the specified block device, such as ext4. This is the most direct and reliable way to verify the filesystem on a specific partition before adding it to /etc/fstab.

Exam trap

The trap here is that candidates often choose `df -Th` because it shows filesystem type, but they forget that it only works on mounted filesystems, whereas `lsblk -f` works on unmounted devices as well.

How to eliminate wrong answers

Option A is wrong because `mount -a` mounts all filesystems listed in /etc/fstab that are not already mounted; it does not display filesystem type information. Option B is wrong because `df -Th /dev/sdb1` shows the filesystem type of mounted filesystems, but if /dev/sdb1 is not mounted, it will not show the type or may produce an error. Option C is wrong because `fdisk -l /dev/sdb1` displays partition table information (size, type, start/end sectors) but does not show the filesystem type (e.g., ext4) — it only shows the partition type ID (e.g., 83 for Linux).

Full explanation →

346

MCQmedium

A user reports that they cannot use the 'systemctl' command to manage services. The user is part of the 'wheel' group. Which configuration change is required to allow this?

A.Set the 'permissive' mode for systemd via systemd.conf

B.Add the user to the 'systemd-journal' group

C.Add the user to /etc/sudoers with 'ALL ALL=(ALL) ALL'

D.Ensure /etc/polkit-1/rules.d/10-admin.rules includes an admin rule for the wheel group

AnswerD

systemd's D-Bus service (org.freedesktop.systemd1) uses polkit to authorize actions such as starting, stopping, and enabling units. The default admin rule in /etc/polkit-1/rules.d/10-admin.rules (or equivalent) defines which users or groups—typically wheel—are considered administrators for these actions. Ensuring this rule actually includes the wheel group lets a member of wheel invoke systemctl directly without sudo, resolving the user's inability to use the command.

Why this answer

The 'systemctl' command requires PolicyKit authorization for non-root users to manage systemd services. The correct configuration is to add a PolicyKit rule in /etc/polkit-1/rules.d/10-admin.rules that grants the 'wheel' group administrative privileges, allowing them to invoke systemctl without a password or with appropriate authentication.

Exam trap

The trap here is that candidates often confuse group membership (like 'wheel' for sudo) with direct authorization via PolicyKit, assuming being in the 'wheel' group automatically grants all administrative privileges, when in fact systemctl relies on polkit rules for non-root users.

How to eliminate wrong answers

Option A is wrong because there is no 'systemd.conf' file; systemd uses 'system.conf' and 'user.conf' for daemon configuration, and 'permissive' mode is a SELinux concept, not a systemd setting. Option B is wrong because the 'systemd-journal' group only grants access to read systemd journal logs, not to manage services with systemctl. Option C is wrong because adding the user to /etc/sudoers with 'ALL ALL=(ALL) ALL' would allow them to run any command as root via sudo, but the question specifies using 'systemctl' directly, not via sudo, and the user is already in the 'wheel' group which typically has sudo access; the issue is about direct PolicyKit authorization for systemctl.

Full explanation →

347

MCQeasy

An administrator needs to pull a container image from a private registry at registry.example.com:5000. The registry requires authentication. Which command should be used first?

A.podman login registry.example.com:5000

B.podman tag registry.example.com:5000/myimage

C.podman images

D.podman pull registry.example.com:5000/myimage

AnswerA

Running 'podman login registry.example.com:5000' first authenticates you to the private registry, using the username and password you supply to create an entry in your local credentials store (typically $XDG_RUNTIME_DIR/containers/auth.json). This grants your user session permission to read image metadata and layers from that registry's namespace. Only after a successful login will a subsequent 'podman pull' be able to authenticate and retrieve the image. Therefore, this is the correct prerequisite step to enable the pull.

Why this answer

`podman login` authenticates the user to the specified private registry (registry.example.com:5000) before any pull or push operation. Without prior authentication, Podman cannot access the registry's content, and the pull command will fail with an authentication error.

Exam trap

Red Hat often tests the prerequisite step of authentication before interacting with a private registry, and the trap here is that candidates may jump directly to `podman pull` (option D) thinking it will prompt for credentials, but Podman does not prompt interactively in non-TTY environments and requires explicit prior login.

How to eliminate wrong answers

Option B is wrong because `podman tag` is used to assign a new name or alias to an existing local image, not to authenticate or pull from a registry; it requires a source image and a target tag. Option C is wrong because `podman images` lists only locally stored images and does not interact with remote registries or handle authentication. Option D is wrong because `podman pull registry.example.com:5000/myimage` attempts to download the image directly, but without prior authentication (via `podman login`), the pull will fail if the registry requires credentials.

Full explanation →

348

MCQhard

An administrator needs to configure system tuning profiles for a database server. Which command is used to set the 'throughput-performance' profile?

A.powertop --set-profile=throughput-performance

B.sysctl -w kernel.throughput=1

C.systemctl set-profile throughput-performance

D.tuned-adm profile throughput-performance

AnswerD

The tuned-adm command is the correct and intended utility for managing tuning profiles on RHEL. Running 'tuned-adm profile throughput-performance' instructs the tuned daemon to activate the shipped throughput-performance profile, which tunes CPU scaling_governor, vm.swappiness, and other kernel/disk parameters for maximum throughput at the cost of power savings. Administrators can verify the change with 'tuned-adm active' or revert with 'tuned-adm off'.

Why this answer

The `tuned-adm profile throughput-performance` command is correct because Tuned is the system tuning service on Red Hat Enterprise Linux, and `tuned-adm` is the command-line tool used to activate predefined tuning profiles. The 'throughput-performance' profile optimizes the system for maximum network and disk throughput by disabling power-saving features and tuning kernel parameters.

Exam trap

The trap here is that candidates confuse `systemctl` (which manages systemd services) with `tuned-adm` (which manages Tuned profiles), or they assume a generic sysctl parameter exists for setting a complete tuning profile.

How to eliminate wrong answers

Option A is wrong because `powertop` is a power management diagnostic tool, not a profile manager; it does not have a `--set-profile` option for setting Tuned profiles. Option B is wrong because `sysctl` is used to modify kernel parameters at runtime, but there is no `kernel.throughput` parameter; setting a Tuned profile involves multiple kernel and system settings, not a single sysctl variable. Option C is wrong because `systemctl` manages systemd services, not Tuned profiles; the correct command to set a Tuned profile is `tuned-adm profile`, not `systemctl set-profile`.

Full explanation →

349

MCQhard

After restoring files from backup, an SELinux context of a directory is not correct. Which command will restore the file contexts to the system defaults?

A.chcon -R default_t /directory

B.restorecon -R /directory

C.semanage fcontext -R /directory

D.setfiles -v /directory

AnswerB

restorecon -R /directory reads the current file_contexts database to determine the policy-defined default context for every path under /directory and, with -R, recursively resets the security.selinux extended attribute on any file whose label differs from that default. It does not alter permissions or ownership and only touches files that are actually mislabeled, making it the standard, safe repair tool after a backup restore. Unlike chcon, it uses authoritative policy rules, so it guarantees a consistent context that will survive a future autorelabel.

Why this answer

The `restorecon -R /directory` command reads the default SELinux contexts from the policy (stored in the file_contexts database) and applies them recursively to the specified directory. This is the standard method to reset file contexts to system defaults after a restore or misconfiguration.

Exam trap

The trap here is that candidates confuse `chcon` (which sets an arbitrary context) with `restorecon` (which sets the default context from policy), or they think `semanage fcontext` directly modifies file contexts rather than the policy database.

How to eliminate wrong answers

Option A is wrong because `chcon` sets a context manually but does not reference the system defaults; `default_t` is not a valid SELinux type and the command would fail or set an incorrect context. Option C is wrong because `semanage fcontext` is used to add, modify, or delete default context rules in the policy database, not to apply them to files; it requires a subsequent `restorecon` to take effect. Option D is wrong because `setfiles` is a low-level tool typically used to verify or relabel entire filesystems during boot or maintenance, not for targeted restoration of a single directory; it also requires a specification file and is not the standard interactive command for this task.

Full explanation →

350

Multi-Selectmedium

Which THREE options to podman run can be used to publish container ports to the host? (Select exactly three.)

Select 3 answers

A.-p

B.--publish

C.--expose

D.-P

E.--port

AnswersA, B, D

The lowercase -p option is the short form of --publish and is the primary way to map a container port to a host port. It accepts the syntax -p hostPort:containerPort/protocol, such as -p 8080:80/tcp, and can be repeated to publish multiple ports. By default, it binds to all host interfaces (0.0.0.0) unless you prefix an IP address, making the container's service reachable from the host or external network.

Why this answer

(-p) is correct because it is the short form of --publish, which maps a container port to a host port. Option B (--publish) is the long form of -p and explicitly publishes container ports to the host. Option D (-P) is correct because it publishes all exposed container ports to random high-numbered ports on the host (typically in the range 32768-60999).

Exam trap

Red Hat often tests the distinction between --expose (which does not publish ports) and -p/--publish (which does), and the fact that --port is not a valid podman option, causing candidates to confuse it with the correct --publish flag.

Full explanation →

351

MCQmedium

Refer to the exhibit. What is the primary security concern with this sudo configuration?

A.The NOPASSWD option eliminates the need for a password.

B.The entry uses (ALL) instead of (root), allowing jane to run as any user.

C.The less command allows executing shell commands via !, enabling privilege escalation.

D.The command /usr/bin/less can be used to read any file.

AnswerC

The less pager has a built-in feature that allows users to execute shell commands by typing ! followed by a command. When less is run with sudo as root, that shell is spawned as root, effectively giving jane a root shell. This is a well-known sudo escape vector listed in GTFOBins, and it is the primary reason this sudoers entry is dangerous, far more than the NOPASSWD or (ALL) attributes.

Why this answer

The `less` command, when executed with sudo, allows the user to escape to a shell by typing `!command` from within the pager. This bypasses the intended restriction of only running `/usr/bin/less` as root, enabling arbitrary command execution with elevated privileges. The NOPASSWD directive further compounds the risk by removing the password prompt, making the escalation trivial.

Exam trap

The trap here is that candidates focus on the NOPASSWD or the (ALL) syntax, missing the fact that the command itself (`less`) has built-in shell escape capabilities that can be exploited for privilege escalation.

How to eliminate wrong answers

Option A is wrong because while NOPASSWD eliminates the password requirement, it is not the primary security concern; the real issue is the ability to escape to a shell via `less`. Option B is wrong because using `(ALL)` allows jane to run commands as any user, but the primary concern is the privilege escalation vector within the allowed command itself, not the user specification. Option D is wrong because reading any file with `less` is a consequence of the command's functionality, but the critical security flaw is the shell escape feature that allows executing arbitrary commands, not just reading files.

Full explanation →

352

MCQmedium

A file server is experiencing slow write performance. The admin suspects the filesystem is nearly full. Which command should be used to check disk usage per partition?

A.df -h

B.df -i

C.du -h --max-depth=1 /

D.du -sh /

AnswerA

df -h — Correct: this command invokes df with human-readable units and reports actual disk space usage per mounted filesystem. It shows total capacity, used space, available space, and use percentage, which is exactly what you need to determine if a slow file server is hitting a full partition. Since full filesystems are a top cause of write performance degradation, df -h is the right first diagnostic.

Why this answer

The `df -h` command displays disk space usage for all mounted filesystems in human-readable format (e.g., GB, MB). This directly answers the admin's need to check per-partition usage and identify if a filesystem is nearly full, which can cause slow write performance due to lack of free space.

Exam trap

The trap here is that candidates confuse `df` (disk free, per-partition) with `du` (disk usage, per-directory), or they mistake inode usage (`df -i`) for space usage, leading them to pick a command that does not show partition-level free space.

How to eliminate wrong answers

Option B is wrong because `df -i` shows inode usage, not disk space usage; a filesystem can have free space but run out of inodes, which is a different issue. Option C is wrong because `du -h --max-depth=1 /` shows disk usage of directories under the root, not per-partition usage, and it does not report free space or partition boundaries. Option D is wrong because `du -sh /` shows the total disk usage of the root directory only, not per-partition breakdown, and it cannot identify which partition is nearly full.

Full explanation →

353

MCQhard

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

A.Add --force to the podman run command

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

C.Add --replace to the podman run command

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

354

MCQmedium

Refer to the exhibit. An administrator wants to add the HTTP service (port 80) to the internal zone permanently. Which sequence of commands should be used?

A.firewall-cmd --add-service=http --zone=internal; firewall-cmd --reload

B.firewall-cmd --permanent --add-service=http --zone=internal; systemctl restart firewalld

C.firewall-cmd --zone=internal --add-service=http; firewall-cmd --runtime-to-permanent

D.firewall-cmd --zone=internal --add-service=http --permanent; firewall-cmd --reload

AnswerD

This command correctly combines --permanent to write the http service rule for the internal zone into the active firewalld configuration, then --reload to apply that persisted configuration to the running firewall. Unlike a restart, reload preserves current connections while seamlessly activating the new permanent rule. This two-step sequence is the canonical, exam-accepted method for adding a service and making it effective immediately and after reboot.

Why this answer

It uses the --permanent flag to make the rule persistent across reboots, and then runs firewall-cmd --reload to apply the permanent configuration to the running runtime environment without restarting the firewalld service. This sequence ensures the HTTP service is added to the internal zone permanently while maintaining active connections.

Exam trap

The trap here is that candidates often confuse --reload with restarting the service, or they think runtime changes persist without the --permanent flag, leading them to choose options that either lose the change (A) or unnecessarily restart firewalld (B).

How to eliminate wrong answers

Option A is wrong because it adds the service to the runtime configuration only (no --permanent flag), and then runs --reload, which discards runtime changes and reloads the permanent configuration, effectively removing the just-added rule. Option B is wrong because while it correctly uses --permanent, it then runs systemctl restart firewalld, which is unnecessary and disruptive (it drops all active connections); the proper method is firewall-cmd --reload. Option C is wrong because it adds the service to the runtime configuration first, then uses --runtime-to-permanent to save runtime changes to permanent; while this works functionally, it is not the most direct or recommended sequence for a single permanent addition, and the question asks for the correct sequence among the given options—D is more straightforward and avoids the extra step.

Full explanation →

355

MCQhard

After a system crash, an administrator needs to review logs from the previous boot. Which command shows only logs from the boot before the current one?

A.journalctl -b -1

B.dmesg -b -1

C.cat /var/log/boot.log

D.journalctl -b 0

AnswerA

journalctl -b -1 displays the journal entries from the boot immediately preceding the current one, using a boot offset of -1. This is the appropriate command after a system crash because it lets you inspect the logs from the crashed boot without including the current recovery boot's messages. For this to work, the journal must be persisted across reboots, typically in /var/log/journal, rather than only in memory.

Why this answer

The `journalctl -b -1` command shows logs from the previous boot by using the `-b` (boot) option with an offset of `-1`, which refers to the boot session immediately before the current one. This is the correct way to access historical boot logs in systems using systemd-journald, as the journal retains logs from multiple boots by default.

Exam trap

The trap here is that candidates confuse the offset numbering: `-b 0` refers to the current boot, not the previous one, leading them to select option D, while the correct offset for the previous boot is `-1`.

How to eliminate wrong answers

Option B is wrong because `dmesg` does not support a `-b` flag; `dmesg` reads kernel ring buffer messages for the current boot only and cannot access logs from previous boots. Option C is wrong because `/var/log/boot.log` is a legacy file used by sysvinit or early boot scripts, not by systemd, and it only contains messages from the current boot, not previous ones. Option D is wrong because `journalctl -b 0` shows logs from the current boot (offset 0), not the previous boot.

Full explanation →

356

MCQeasy

An administrator needs to run a container with a bind mount of the host directory /data to /var/lib/data inside the container. The container image is web:latest. Which command correctly achieves this?

A.podman run -V /data:/var/lib/data web:latest

B.podman run -v /data:/var/lib/data web:latest

C.podman run -v /var/lib/data:/data web:latest

D.podman run -v /data::/var/lib/data web:latest

AnswerB

Using lowercase -v with the absolute source and destination paths is the correct bind-mount syntax: podman -v /data:/var/lib/data mounts the host directory /data at the container path /var/lib/data. Because /data is an absolute path, Podman treats it as a bind mount rather than creating a named volume. The container's writes to /var/lib/data will be immediately reflected in host's /data, which is exactly the desired behavior.

Why this answer

The `-v` flag in Podman creates a bind mount from the host directory `/data` to the container directory `/var/lib/data`. The syntax `-v /host/path:/container/path` is the standard way to specify a bind mount, and this command correctly maps the host directory to the intended container path.

Exam trap

The trap here is that candidates often confuse the order of paths in the bind mount syntax, incorrectly placing the container path before the host path, or they mistakenly use an invalid flag like `-V` instead of the correct `-v`.

How to eliminate wrong answers

Option A is wrong because it uses the uppercase `-V` flag, which is not a valid Podman option; Podman uses lowercase `-v` for volume or bind mount operations. Option C is wrong because it reverses the bind mount syntax, mapping the host directory `/var/lib/data` to the container directory `/data`, which does not match the requirement of mounting `/data` to `/var/lib/data`. Option D is wrong because it contains an extra colon (`::`) in the mount specification, which is syntactically incorrect and would cause Podman to fail with an invalid argument error.

Full explanation →

357

MCQmedium

An administrator needs to monitor network traffic on a specific interface in real time. Which tool is most appropriate for this task?

A.tcpdump -i eth0

B.ip -s link

C.ss -tulpn

D.nload eth0

AnswerA

tcpdump -i eth0 is the correct tool because it uses libpcap to capture raw packets as they traverse the specified interface, displaying protocol headers and payloads in real time. It can apply BPF filters to narrow the traffic and, with root or CAP_NET_RAW, operates in promiscuous mode to see all frames, not just those addressed to the host.

Why this answer

tcpdump -i eth0 captures and displays packet headers in real time on the specified interface (eth0). It uses libpcap to intercept raw network frames at the data link layer, making it the standard tool for live traffic monitoring and analysis.

Exam trap

Red Hat often tests the distinction between tools that show aggregate statistics (ip -s link, nload) versus tools that capture individual packets (tcpdump), leading candidates to choose nload because it shows real-time data, but it does not show packet contents.

How to eliminate wrong answers

Option B is wrong because 'ip -s link' shows cumulative statistics (bytes, packets, errors) for interfaces, not real-time packet-by-packet traffic. Option C is wrong because 'ss -tulpn' lists current TCP/UDP sockets and listening services, not live network traffic on an interface. Option D is wrong because 'nload eth0' displays real-time bandwidth usage (in/out rates) but does not show individual packets or their contents; it is a traffic meter, not a packet capture tool.

Full explanation →

358

Drag & Dropmedium

Arrange the steps to configure a network bond (mode 1) using two interfaces (eth0, eth1) in RHEL.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Network bonding requires creating a bond interface and configuring slaves, then restarting network.

Full explanation →

359

MCQhard

A system administrator notices that a RHEL 9 server's /var/log/messages is filling up the /var partition. The administrator wants to ensure log rotation runs daily and keeps 4 weeks of logs. Which configuration file should be modified?

A./etc/systemd/journald.conf

B./etc/logrotate.d/syslog

C./etc/rsyslog.conf

D./etc/cron.daily/logrotate

AnswerB

This is a logrotate drop-in configuration file located under /etc/logrotate.d. logrotate reads this file when it runs, and it lists /var/log/messages (along with /var/log/secure, cron, etc.) with directives for rotation frequency, number of retained rotated logs, and a postrotate command to signal rsyslog with HUP. Editing this file is the correct way to change how those syslog files are rotated.

Why this answer

/etc/logrotate.d/syslog is the configuration file that controls log rotation for system log files such as /var/log/messages. By modifying this file, the administrator can set the rotation frequency to daily and specify the number of weeks (e.g., rotate 28 for 4 weeks) to retain logs, directly addressing the requirement.

Exam trap

The trap here is that candidates confuse the log rotation configuration file (/etc/logrotate.d/syslog) with the cron job that triggers it (/etc/cron.daily/logrotate) or with the logging daemon configuration files (journald.conf or rsyslog.conf), assuming those control rotation parameters.

How to eliminate wrong answers

Option A is wrong because /etc/systemd/journald.conf configures the systemd journal daemon (journald), which manages binary journal logs, not the rotation of text-based log files like /var/log/messages; log rotation for syslog files is handled by logrotate. Option C is wrong because /etc/rsyslog.conf configures the rsyslog daemon's logging rules and destinations, not log rotation parameters; rotation is a separate function managed by logrotate. Option D is wrong because /etc/cron.daily/logrotate is the cron job script that triggers logrotate execution daily, not a configuration file where rotation parameters (frequency, retention) are defined; modifying this script would not set the rotation schedule or retention count.

Full explanation →

360

MCQeasy

An administrator wants to modify the default expiration settings for new user passwords. Which file should be modified?

A./etc/shadow

B./etc/pam.d/passwd

C./etc/security/pwquality.conf

D./etc/login.defs

AnswerD

The /etc/login.defs file contains the system-wide defaults used by useradd (and other account tools) when creating new accounts, including PASS_MAX_DAYS, PASS_MIN_DAYS, and PASS_WARN_AGE. These values determine the default password aging policy for newly created users and are stored later in the shadowed per-user fields. Modifying login.defs changes the default for future accounts; chage or usermod can override an individual account afterward.

Why this answer

The /etc/login.defs file contains default settings for user account creation, including password aging parameters such as PASS_MAX_DAYS, PASS_MIN_DAYS, and PASS_WARN_AGE. Modifying this file changes the default expiration settings for new user passwords system-wide, as these values are applied when a user is created via useradd or similar tools.

Exam trap

Candidates often mistake /etc/shadow as the place to modify default password expiration settings because it contains per-user expiration fields. However, /etc/login.defs defines system-wide defaults for new users.

How to eliminate wrong answers

Option A is wrong because /etc/shadow stores per-user encrypted password hashes and aging information, not system-wide default expiration settings; modifying it would only affect individual users, not defaults for new users. Option B is wrong because /etc/pam.d/passwd is a PAM configuration file for the passwd command, controlling authentication behavior during password changes, not default expiration values. Option C is wrong because /etc/security/pwquality.conf configures password quality and strength requirements (e.g., length, complexity), not expiration or aging defaults.

Full explanation →

361

Multi-Selecteasy

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

Select 2 answers

A.mkfs.ext4

B.pvcreate /dev/sdb1

C.pvcreate /dev/sdb

D.lvcreate

E.vgcreate

AnswersB, C

pvcreate /dev/sdb1 is the correct command to initialize a specific partition as a physical volume. It writes a PV label to the partition and records its metadata, allowing it to be later added to a volume group with vgcreate or vgextend. This is the standard approach when you want to dedicate only a portion of a disk to LVM while keeping other partitions for different purposes.

Why this answer

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

Exam trap

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

Full explanation →

362

MCQmedium

A system administrator receives reports that a web server service (httpd) fails to start after a reboot. The administrator checks the service status and sees it is disabled. Which of the following is the most appropriate command to ensure the service starts automatically on future reboots?

A.systemctl start httpd

B.systemctl enable httpd

C.systemctl restart httpd

D.systemctl daemon-reload

AnswerB

This is the correct command because it creates symbolic links in /etc/systemd/system/ (typically into multi-user.target.wants or similar) that instruct systemd to start httpd automatically at boot. It does not start the service immediately; it only establishes the persistent configuration for future boots. This directly addresses the requirement that the web server starts automatically after a reboot.

Why this answer

The `systemctl enable httpd` command creates the necessary symlinks in the systemd unit configuration directory (typically `/etc/systemd/system/multi-user.target.wants/`) to ensure the httpd service starts automatically at boot. Since the service is disabled after reboot, enabling it is the correct action to set it to start on future reboots.

Exam trap

The trap here is that candidates confuse `systemctl start` (immediate runtime action) with `systemctl enable` (boot-time configuration), leading them to choose a command that works now but fails to persist across reboots.

How to eliminate wrong answers

Option A is wrong because `systemctl start httpd` starts the service immediately but does not configure it to start automatically on future reboots; it only affects the current session. Option C is wrong because `systemctl restart httpd` stops and then starts the service immediately, which is irrelevant to setting the service to start at boot. Option D is wrong because `systemctl daemon-reload` reloads systemd manager configuration and unit files, but it does not enable or disable services; it is used after modifying unit files, not to set boot-time behavior.

Full explanation →

363

MCQeasy

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

364

Multi-Selecteasy

Which two commands correctly set the system to boot into a multi-user target (runlevel 3)?

Select 2 answers

A.systemctl enable multi-user.target

B.systemctl default multi-user

C.systemctl set-default multi-user.target

D.ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

E.systemctl set-default runlevel3.target

AnswersC, D

systemctl set-default multi-user.target is the canonical way to set the boot target to the text-mode multi-user environment. This command carefully creates or updates the /etc/systemd/system/default.target symlink to point to /lib/systemd/system/multi-user.target, which systemd reads at startup to determine the initial target. It is the recommended replacement for the SysVinit 'init 3' or modifying inittab.

Why this answer

Option C, `systemctl set-default multi-user.target`, is correct because it changes the default boot target by creating the symlink `/etc/systemd/system/default.target` pointing to `multi-user.target`, which is the systemd equivalent of runlevel 3. Option D, `ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target`, is correct because it manually performs the same action that `systemctl set-default` does, replacing the default.target symlink so the system boots into the multi-user target. Option A is wrong because `systemctl enable multi-user.target` only enables the unit to start at boot; it does not change the default boot target.

Option B is wrong because `systemctl default multi-user` is not a valid command syntax. Option E is wrong because `runlevel3.target` is not a valid systemd target name; the correct target is `multi-user.target`.

Exam trap

The trap here is that candidates may confuse `systemctl set-default` with `systemctl enable` or use incorrect target names like `runlevel3.target`, which does not exist in systemd; the correct target is `multi-user.target`.

Full explanation →

365

MCQeasy

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

366

MCQhard

A backup script uses tar to create an archive, but the administrator wants to exclude the /tmp directory from the backup. Which tar option should be added?

A.--exclude=/tmp

B.--ignore-failed-read

C.--exclude-from=/tmp

D.-X /tmp

AnswerA

The --exclude=/tmp option is correct because it directly tells GNU tar to skip the entire /tmp directory tree when creating the archive. The argument after --exclude is a shell glob pattern (or literal path) that tar matches against absolute paths while traversing the filesystem, so /tmp (and everything beneath it) will not be included. This is the standard, dedicated mechanism for omitting a directory from a backup.

Why this answer

The `--exclude=PATTERN` option in tar tells the command to skip files or directories matching the given pattern. By specifying `--exclude=/tmp`, the tar archive will omit the /tmp directory and all its contents, which is exactly what the administrator needs for the backup script.

Exam trap

The trap here is that candidates confuse `--exclude` (which excludes a pattern) with `--exclude-from` (which reads patterns from a file), leading them to pick option C or D, thinking they can pass a directory path directly to exclude it.

How to eliminate wrong answers

Option B is wrong because `--ignore-failed-read` tells tar to continue archiving even if it cannot read a file (e.g., due to permissions), but it does not exclude any directory. Option C is wrong because `--exclude-from=FILE` reads exclusion patterns from a file, not from a directory path; using `--exclude-from=/tmp` would try to read patterns from the /tmp directory itself, which is not a valid pattern file and would cause an error. Option D is wrong because `-X /tmp` is the short form of `--exclude-from`, which again expects a file containing patterns, not a directory to exclude; it would attempt to read exclusion patterns from /tmp, not exclude the /tmp directory.

Full explanation →

367

Multi-Selectmedium

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

Select 2 answers

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

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

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

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

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

AnswersA, D

The pvck command is a specialized LVM utility designed to verify the consistency and integrity of physical volume metadata located in the metadata areas on a PV. It can also dump the raw metadata contents for debugging purposes, but it only checks and displays; it does not repair or rewrite the metadata. Use it when you suspect corruption on a PV.

Why this answer

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

Exam trap

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

Full explanation →

368

MCQhard

A company policy requires that all new logical volumes be created with a physical extent size of 16 MiB to optimize performance for large sequential I/O. During the creation of a new volume group, what parameter should be used?

A.vgcreate -p 16M vg_data /dev/sdc1

B.vgcreate -L 16M vg_data /dev/sdc1

C.vgcreate -e 16M vg_data /dev/sdc1

D.vgcreate -c 16M vg_data /dev/sdc1

E.vgcreate -s 16M vg_data /dev/sdc1

AnswerE

The -s option is the correct way to set the physical extent size for a new volume group. In vgcreate -s 16M vg_data /dev/sdc1, the 16M argument defines each physical extent as 16 MiB, so all subsequent logical volumes are allocated in 16 MiB chunks. This ensures that new logical volumes align with the company policy of 16M extents from the moment the VG is created.

Why this answer

The `-s` parameter in `vgcreate` sets the physical extent (PE) size for the volume group. A PE size of 16 MiB is specified with `-s 16M`, which ensures all subsequent logical volumes in that VG use 16 MiB extents, optimizing performance for large sequential I/O by reducing metadata overhead.

Exam trap

The trap here is confusing the `-s` (extent size) option with other common LVM parameters like `-L` (size) or `-p` (max PVs), leading candidates to select a wrong option that sets a different attribute entirely.

How to eliminate wrong answers

Option A is wrong because `-p` sets the maximum number of physical volumes allowed in the volume group, not the extent size. Option B is wrong because `-L` sets the maximum logical volume size, not the extent size. Option C is wrong because `-e` is not a valid parameter for `vgcreate`; it is used with `pvcreate` to set the PE start offset.

Option D is wrong because `-c` sets the cluster mode for the volume group, not the extent size.

Full explanation →

369

MCQhard

A server running RHEL 9 has an LVM logical volume /dev/vg00/lvol0 formatted with XFS, mounted at /data. The administrator needs to increase the file system size from 100GB to 150GB. Which command sequence should be used?

A.xfs_info /data; lvextend -L 150G /dev/vg00/lvol0

B.umount /data; lvextend -L +50G /dev/vg00/lvol0; mount /data; xfs_growfs /data

C.resize2fs /dev/vg00/lvol0

D.lvextend -L +50G /dev/vg00/lvol0; xfs_growfs /data

AnswerD

This is the correct sequence: the lvextend -L +50G /dev/vg00/lvol0 command first extends the logical volume by 50GB, giving the underlying block device more space; then xfs_growfs /data online-grows the mounted XFS filesystem to fill the expanded LV. XFS can only grow, not shrink, and growth must happen after the LV is enlarged, not before. Because xfs_growfs defaults to using all available space, no size argument is required after extending the LV.

Why this answer

It first extends the logical volume by the exact amount needed (+50G) using lvextend, then grows the XFS filesystem to match using xfs_growfs. XFS filesystems can be grown online (no unmount required), and xfs_growfs expands the filesystem to fill the available space in the logical volume.

Exam trap

The trap here is that candidates may assume all filesystems require unmounting before resizing (as with some older tools), or they may confuse XFS with ext4 and try to use resize2fs, or they may think xfs_info is a growth command instead of an info command.

How to eliminate wrong answers

Option A is wrong because xfs_info only displays filesystem information and does not perform any growth operation; the sequence lacks the actual grow command. Option B is wrong because unmounting the XFS filesystem is unnecessary and disruptive; xfs_growfs works on a mounted filesystem, and the -L +50G syntax is correct but the umount/mount steps are redundant and incorrect. Option C is wrong because resize2fs is the tool for ext2/3/4 filesystems, not XFS; using it on an XFS filesystem would fail or cause corruption.

Full explanation →

370

MCQmedium

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

A.The httpd service is disabled.

B.The Apache configuration has a syntax error.

C.The /var/www/html directory does not exist.

D.SELinux context on /var/www/html/index.html is incorrect.

AnswerB

A syntax error in Apache's configuration would prevent the server from starting or reloading cleanly, typically producing an explicit error like `Syntax error on line ...` in the error log or when running `apachectl configtest`. The exhibited log contains no such configuration complaint; instead, it shows an active request ending with `Permission denied`. Since Apache is running and serving the request, a configuration syntax error is not the cause.

Why this answer

The most likely cause of the httpd service failing to start is a configuration syntax error (option B). When the Apache configuration contains an invalid directive or syntax mistake, `httpd` will refuse to start and report the error via `apachectl configtest` or `systemctl start httpd`. A missing document root may cause a warning but does not prevent startup; incorrect SELinux context leads to 403 errors but does not stop the service; and a disabled service only affects boot-time startup, not manual starts.

Exam trap

Candidates may overlook that some issues (like SELinux or file permissions) prevent serving content but do not crash the service. Always distinguish between the service failing to start vs. failures in serving requests.

How to eliminate wrong answers

Option A is wrong because a disabled service would not attempt to start at all; the systemctl status would show 'disabled' but the service could still be started manually, and the failure here is during runtime. Option B is wrong because a syntax error in Apache configuration would cause the service to fail to start with a specific error message (e.g., 'Syntax error on line ...'), not a silent failure after starting. Option C is wrong because if /var/www/html did not exist, Apache would log a clear 'Directory not found' error and fail to serve content, but the service itself would start; the question implies the service fails entirely, not just content delivery.

Full explanation →

371

MCQmedium

A cron job runs a script every hour and leaves many log files. The administrator wants to clean up log files older than 7 days in /var/log/myapp/. Which command should be added to a weekly cron job?

A.find /var/log/myapp -type f -atime +7 -delete

B.find /var/log/myapp -type f -mtime +7 -exec rm {} \;

C.find /var/log/myapp -type f -ctime +7 -delete

D.find /var/log/myapp -type f -mtime +7 -delete

AnswerD

This command correctly targets log files whose data was last modified more than 7 days ago, because -mtime +7 matches any file with a modification time older than 168 hours (7 × 24 hours). The -type f restriction ensures only regular files are removed, not directories or special files, and -delete is a safe, built-in action that unlinks each matched file without spawning an external process. When used in a cron job, this is an efficient and reliable one-line log cleanup method. It correctly balances retaining recent logs (≤7 days old) while purging stale entries.

Why this answer

`-mtime +7` matches files whose modification time is older than 7 days, and `-delete` safely removes them. This is the most efficient and standard approach for cleaning up old log files in a cron job, as it avoids spawning a separate process for each file.

Exam trap

The trap here is that candidates often confuse `-atime`, `-ctime`, and `-mtime`, or think `-exec rm {} \;` is equivalent to `-delete`, when in fact `-delete` is the preferred, safer, and more efficient method for bulk file removal in cron jobs.

How to eliminate wrong answers

Option A is wrong because `-atime` checks access time, not modification time; log files may be accessed (e.g., read by monitoring tools) without being modified, so they could be deleted prematurely or not at all. Option B is wrong because while `-mtime +7` is correct, using `-exec rm {} \;` is inefficient and less safe than `-delete`; it forks a new `rm` process for each file, which is slower and can cause issues with special characters in filenames. Option C is wrong because `-ctime` checks inode change time (metadata changes like permissions or ownership), not the file's content modification time; log files might have unchanged metadata but old content, leading to incorrect cleanup.

Full explanation →

372

MCQeasy

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

A.chage -M 30 bob

B.passwd -x 30 bob

C.usermod -e 30 bob

D.chage -W 30 bob

AnswerA, B

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

373

MCQeasy

A user reports that a script in their home directory fails to execute. The script has permissions -rw-r--r-- and is owned by the user. Which command will allow execution for the owner?

A.chmod u+r script.sh

B.chmod a+x script.sh

C.chmod u+x script.sh

D.chmod u-x script.sh

AnswerC

chmod u+x is the precise fix because it sets the execute permission for the owner (the user who owns the file) without altering permissions for anyone else. On Linux, a file must have its execute bit(s) set before the kernel will allow it to be run directly via a path like ./script.sh. Since the script's owner is the user who is running it, this user only needs owner execute permission, not group or other. This follows the minimal privilege principle and is the correct, targeted solution.

Why this answer

The script currently has permissions `-rw-r--r--`, meaning the owner has read and write but not execute. To allow the owner to execute it, you need to add the execute permission for the owner only. `chmod u+x script.sh` adds the execute bit for the user (owner) without affecting group or others, which is the precise requirement.

Exam trap

Red Hat often tests the distinction between adding execute permission for the owner only versus adding it for all users, and the trap here is that candidates might choose `a+x` (option B) thinking it is the simplest solution, but the question explicitly asks for execution for the owner.

How to eliminate wrong answers

Option A is wrong because `chmod u+r script.sh` adds read permission for the owner, but the owner already has read access; it does not add execute permission. Option B is wrong because `chmod a+x script.sh` adds execute permission for all (owner, group, and others), which is excessive and not the minimal change requested. Option D is wrong because `chmod u-x script.sh` removes execute permission from the owner, which would make the script even less executable.

Full explanation →

374

Multi-Selecthard

Which THREE statements about /etc/shadow are true? (Choose exactly 3)

Select 3 answers

A.Contains account expiration dates.

B.Contains the date of last password change.

C.Contains encrypted password hashes.

D.Is readable by all users.

E.Contains user ID numbers.

AnswersA, B, C

The /etc/shadow file stores account expiration dates in the eighth field (field 8), which is the number of days since the epoch until the account is disabled. This field is used by the system to enforce account aging policies.

Why this answer

The /etc/shadow file stores account expiration dates in the ninth field (field 9), which is the number of days since the epoch until the account is disabled. This field is used by the system to enforce account aging policies, such as automatically locking accounts after a set period of inactivity.

Exam trap

Red Hat often tests the distinction between /etc/passwd and /etc/shadow, trapping candidates who think UIDs or group membership are in shadow, or that shadow is world-readable like passwd.

Full explanation →

375

MCQhard

An administrator wants to ensure that when a user presses Ctrl+C during a long-running script, the script cleans up temporary files before exiting. Which approach should the script use?

A.Use 'trap' to catch SIGINT and run cleanup.

B.Use 'set -o ignoreeof' to ignore Ctrl+C.

C.Run the script in the background with '&'.

D.Use 'set -e' to exit on any error.

AnswerA

The `trap` built-in lets the script register a custom handler for signals such as SIGINT, which is what pressing Ctrl+C sends. When the signal is received, the shell suspends the current operation and runs the specified cleanup routine, allowing the administrator to remove temporary files, release locks, or log the interruption before exiting. Setting `trap cleanup INT` (or using a quoted command list) is the standard way to gracefully intercept an interrupt and maintain controlled state.

Why this answer

The `trap` command in Bash allows a script to catch signals like SIGINT (sent when Ctrl+C is pressed) and execute a custom function or command before exiting. By setting `trap cleanup SIGINT`, the script can remove temporary files or perform other cleanup actions automatically, ensuring a graceful termination.

Exam trap

Red Hat often tests the distinction between signals like SIGINT (Ctrl+C) and EOF (Ctrl+D), leading candidates to confuse `ignoreeof` with signal handling.

How to eliminate wrong answers

Option B is wrong because `set -o ignoreeof` prevents the shell from exiting on Ctrl+D (EOF), not Ctrl+C, and does not handle signal-based interruption. Option C is wrong because running a script in the background with `&` does not change how Ctrl+C affects the script; it still receives SIGINT and exits without cleanup. Option D is wrong because `set -e` causes the script to exit immediately if any command fails, but it does not catch or handle the SIGINT signal from Ctrl+C.

Full explanation →

Red Hat Certified System Administrator EX200 (EX200) — Questions 301–375