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

MCQmedium

A system administrator needs to ensure that a user named 'jdoe' can execute commands as root without being prompted for a password. Which configuration change should be made?

A.Add 'jdoe ALL=(ALL) NOPASSWD: ALL' to /etc/sudoers via visudo

B.Add jdoe to the wheel group and configure /etc/sudoers with '%wheel ALL=(ALL) ALL'

C.Set the UID of jdoe to 0

D.Add jdoe to the root group

AnswerA

Adding 'jdoe ALL=(ALL) NOPASSWD: ALL' to /etc/sudoers via visudo grants jdoe the ability to execute any command as any user on any host without being prompted for a password. The visudo command validates the syntax of the file before saving, preventing lockouts from malformed entries. The NOPASSWD tag overrides the default requirement to supply the user's own password when invoking sudo.

Why this answer

The sudoers directive 'jdoe ALL=(ALL) NOPASSWD: ALL' grants user jdoe the ability to run any command as any user (including root) on any host without a password prompt. This configuration must be added using visudo to ensure syntax validation and prevent lockout. The NOPASSWD tag overrides the default password requirement for sudo.

Exam trap

The trap here is that candidates often confuse the wheel group's default sudo behavior (password required) with passwordless access, or they incorrectly assume that group membership (root group) or UID changes are equivalent to sudo configuration.

How to eliminate wrong answers

Option B is wrong because '%wheel ALL=(ALL) ALL' requires members of the wheel group to enter their own password when using sudo; it does not provide passwordless access. Option C is wrong because setting the UID of jdoe to 0 would effectively make jdoe a second root user, which is a severe security risk and violates the principle of least privilege; it also does not use sudo at all. Option D is wrong because adding jdoe to the root group grants group-level permissions but does not allow command execution as root via sudo; root group membership does not bypass sudo password requirements.

Full explanation →

MCQeasy

A user reports that they cannot log in to a RHEL 9 system. The administrator checks /etc/passwd and finds the user's shell is set to /sbin/nologin. What is the most likely cause?

A.The SSH service is not running.

B.The user account has been locked by pam_tally2.

C.The user's password has expired.

D.The user account is intentionally disabled for login.

AnswerD

An intentionally disabled login account is typically configured with /sbin/nologin as the user's login shell or by locking the account in /etc/shadow with an '!' or '*' in the encrypted password field. This prevents the user from starting an interactive shell while still potentially allowing non-login services like POP3 or FTP, depending on PAM configuration. Because the problem is isolated to one user and no other users are affected, an administrative disablement is the most precise cause. The system administrator can verify this with the 'chsh -l' or by inspecting the last field of /etc/passwd.

Why this answer

The /sbin/nologin shell is a valid shell entry that, when set as a user's login shell, prevents interactive login by immediately exiting with a message that the account is not available. This is a standard method for disabling login for system accounts (e.g., daemon, bin) or intentionally disabling a user account while keeping the account and its files intact. Option D correctly identifies that the user account is intentionally disabled for login.

Exam trap

The trap here is that candidates may confuse the /sbin/nologin shell with account locking or password expiration, not realizing that the shell setting is a deliberate, static configuration to disable interactive login without affecting password state or authentication attempts.

How to eliminate wrong answers

Option A is wrong because the SSH service not running would affect all SSH connections, not just a single user, and the shell setting in /etc/passwd is independent of SSH service status. Option B is wrong because pam_tally2 locks an account after failed login attempts by setting a lock flag in /etc/shadow or /var/log/faillog, not by changing the user's shell to /sbin/nologin. Option C is wrong because an expired password would prompt the user to change their password upon login (via PAM modules like pam_unix), but the shell would still be a valid interactive shell like /bin/bash; the user would not be immediately rejected with a nologin message.

Full explanation →

MCQeasy

A system administrator wants to allow incoming HTTPS traffic on the default zone of firewalld. Which command should be used?

A.firewall-cmd --add-port=443/tcp --zone=public --permanent

B.firewall-cmd --enable-service=https

C.firewall-cmd --add-rule=allow https

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

AnswerD

This command adds the predefined HTTPS service to the default zone and marks the change as permanent, so it will persist across firewalld reloads and system reboots. The 'https' service definition maps to 'tcp/443', so this is the canonical way to allow incoming web traffic. One subtlety: the permanent configuration does not take effect until a reload (e.g., 'firewall-cmd --reload'), but the command itself is correct and is the expected answer for persisting the rule.

Why this answer

The `--add-service=https` option adds the predefined HTTPS service (port 443/tcp) to the firewalld configuration. The `--permanent` flag ensures the rule persists across reboots. By default, the command applies to the default zone if no zone is specified, which matches the requirement to allow HTTPS traffic on the default zone.

Exam trap

The trap here is that candidates often confuse `--add-port` with `--add-service` or forget that omitting `--zone` applies the rule to the default zone, leading them to incorrectly specify a zone or use invalid command syntax.

How to eliminate wrong answers

Option A is wrong because `--add-port=443/tcp` adds a raw port rule, but the `--zone=public` explicitly sets the zone to 'public' rather than using the default zone; the question requires the default zone, not a specific zone. Option B is wrong because `--enable-service=https` is not a valid firewalld command; the correct syntax uses `--add-service` or `--remove-service`. Option C is wrong because `--add-rule=allow https` is not a valid firewalld option; firewalld uses `--add-rich-rule` for custom rules, and the syntax 'allow https' is incorrect.

Full explanation →

MCQmedium

A user named jdoe is receiving 'Permission denied' errors when trying to access a file owned by root with permissions 644. The user is a member of the root group. What is the most likely cause?

A.The directory containing the file lacks execute permission for the group or others.

B.The file's group owner is not root.

C.The file's read permission is not granted to the root group.

D.The user needs to be added to the root group again.

AnswerA

The directory containing the file lacks execute permission for the group or others. This is the most likely cause because to access a file inside a directory, the user needs execute (x) permission on the directory. Without it, even with correct file permissions, the user will get 'Permission denied'.

Why this answer

The file has permissions 644, meaning the owner (root) has read/write, and the group (root) and others have read-only access. Since jdoe is a member of the root group, the file's group read permission should allow access. However, to traverse a directory and access any file within it, the user needs execute (x) permission on that directory.

If the directory lacks execute for the group or others, jdoe will get 'Permission denied' even if the file permissions are correct.

Exam trap

The trap here is that candidates focus solely on file permissions (644) and overlook that directory execute permission is required for file access, leading them to incorrectly suspect group membership or file group ownership issues.

How to eliminate wrong answers

Option B is wrong because the file's group owner is root (as stated in the scenario), and the user jdoe is a member of the root group, so group ownership is correct. Option C is wrong because the file's permissions 644 grant read (4) to the group, so the root group does have read permission. Option D is wrong because the user is already a member of the root group; re-adding them would not resolve a directory permission issue.

Full explanation →

Multi-Selecteasy

Which TWO commands can be used to display SELinux contexts of files? (Choose two.)

Select 2 answers

A.stat -c %C

B.chcon -l

C.id -Z

D.ls -Z

E.getenforce

AnswersA, D

The `stat -c %C` option is correct because the `stat` command's `%C` format specifier directly prints the SELinux security context of the specified file, such as `system_u:object_r:etc_t:s0`. This works on any filesystem object and is a precise, scriptable way to retrieve only the context string.

Why this answer

The `stat -c %C` command displays the SELinux security context of a file by using the `%C` format specifier, which outputs the security context string. The `ls -Z` command also shows SELinux contexts for files in a directory listing, with the `-Z` flag specifically requesting security context information. Both commands are standard tools for viewing SELinux labels on files.

Exam trap

The trap here is that candidates confuse commands that display process or system-wide SELinux status (like `id -Z` and `getenforce`) with those that display file contexts, leading them to select options that show user or enforcement mode instead of file labels.

Full explanation →

MCQhard

A system administrator wants to run a container as a systemd service that restarts automatically after a system reboot. Which approach follows Red Hat best practices?

A.Create a cron job that checks if the container is running and starts it if not.

B.Create a sysvinit script that calls podman commands.

C.Add 'podman run ...' to /etc/rc.local.

D.Use 'podman generate systemd --new --name mycontainer' and enable the generated service.

AnswerD

podman generate systemd --new --name mycontainer generates a complete systemd service unit that records the exact podman command, container ID, and environment required to create and start the container fresh on every invocation of the service. Placing this unit in /etc/systemd/system and enabling it with systemctl enable --now makes systemd the supervisor: it sets up dependencies such as After=network-online.target, can apply Restart=on-failure, and will tear down the container cleanly on service stop. This is the intended way to manage a container's lifecycle as a systemd service.

Why this answer

`podman generate systemd --new --name mycontainer` creates a systemd unit file that defines the container as a transient service with `Restart=always` and `WantedBy=multi-user.target`, ensuring the container starts automatically after a reboot. This approach aligns with Red Hat best practices for managing containers as systemd services, leveraging systemd's native dependency and restart capabilities rather than relying on legacy or non-standard methods.

Exam trap

The trap here is that candidates may think any method that runs a command at boot (like cron or rc.local) is sufficient, but Red Hat specifically tests that systemd is the standard service manager in RHEL 8/9 and that `podman generate systemd` is the recommended way to create persistent container services with proper restart and dependency handling.

How to eliminate wrong answers

Option A is wrong because a cron job that polls for container status introduces unnecessary latency, race conditions, and complexity; it does not integrate with systemd's dependency-based startup ordering or provide reliable restart-on-failure behavior. Option B is wrong because sysvinit scripts are legacy in RHEL 8/9, which uses systemd as the default init system; using sysvinit bypasses systemd's native container management features and is not a supported Red Hat best practice. Option C is wrong because `/etc/rc.local` is executed after most services have started, offers no dependency management, and is considered a legacy workaround; it does not provide the restart policy or lifecycle control that systemd units offer.

Full explanation →

MCQmedium

A system administrator needs to create a point-in-time backup of a logical volume 'lv_home' that is currently mounted. Which LVM feature should be used?

A.lvreduce

B.lvchange

C.lvextend

D.lvcreate -s

E.pvmove

AnswerD

lvcreate -s is correct because it creates a snapshot logical volume, which provides a point-in-time image of the origin LV. LVM snapshots use copy-on-write (CoW) technology: when the original LV is modified, the old data is preserved in the snapshot's allocated extents. This allows the snapshot to serve as a consistent backup target for subsequent operations like mounting or archiving.

Why this answer

The 'lvcreate -s' command creates a snapshot of a logical volume, which provides a point-in-time backup without unmounting the volume. Snapshots are a native LVM feature that allow consistent backups of mounted filesystems by capturing the state of the logical volume at the moment the snapshot is created.

Exam trap

The trap here is that candidates may confuse 'lvcreate -s' with other LVM commands like 'lvreduce' or 'lvextend', mistakenly thinking those can create backups, or they may assume that a mounted volume must be unmounted before any backup operation, which is not required with LVM snapshots.

How to eliminate wrong answers

Option A is wrong because 'lvreduce' reduces the size of a logical volume, which is unrelated to creating backups and can cause data loss if not done carefully. Option B is wrong because 'lvchange' modifies attributes of an existing logical volume (e.g., activation, permissions) and does not create point-in-time copies. Option C is wrong because 'lvextend' increases the size of a logical volume, which is used for capacity expansion, not backup creation.

Option E is wrong because 'pvmove' moves physical extents from one physical volume to another within a volume group, which is used for storage migration or maintenance, not for creating backups.

Full explanation →

MCQhard

A server has a requirement that all users in the 'finance' group must have a password aging policy that forces password change every 90 days. Which approach best achieves this for existing users?

A.Set PASS_MAX_DAYS 90 in /etc/login.defs

B.Edit /etc/shadow and change the fifth field for all users

C.Configure pam_pwquality.so to enforce password age

D.Write a script to run 'chage -M 90' for each user in the finance group

AnswerD

A script that calls chage -M 90 for each user in the finance group is the correct approach because chage directly updates the maximum password age field in /etc/shadow for existing user accounts. For example, you can iterate over `getent group finance | cut -d: -f4`, and run chage for each member, which precisely targets the intended accounts and leaves all other users untouched.

Why this answer

`chage -M 90` sets the maximum password age for a specific user, and by scripting it to apply to all members of the 'finance' group, you directly enforce the 90-day policy on existing users. This approach works regardless of the default settings in `/etc/login.defs`, which only affect new users, and avoids the manual and error-prone editing of `/etc/shadow`.

Exam trap

The trap here is that candidates often confuse `/etc/login.defs` as applying to all users (including existing ones), when in fact it only sets defaults for new user creation via `useradd`.

How to eliminate wrong answers

Option A is wrong because `/etc/login.defs` only sets default values for newly created users; it does not retroactively apply to existing users. Option B is wrong because manually editing the fifth field in `/etc/shadow` is fragile, error-prone, and not a supported or recommended administrative practice; the `chage` command is the proper tool for this task. Option C is wrong because `pam_pwquality.so` is a module for password quality/complexity checks (e.g., length, character classes), not for enforcing password aging policies like maximum days between changes.

Full explanation →

MCQeasy

Refer to the exhibit. A security analyst reviews the journal output for sshd.service. Which of the following best describes the observed pattern of events?

A.The system is under a denial-of-service attack because the connections are being closed before authentication.

B.The SSH service is malfunctioning and dropping connections due to a configuration error.

C.Multiple hosts are attempting to connect to the SSH service simultaneously, causing connection errors.

D.The system experienced a brute-force attack on the root account originating from IP 192.168.1.100, which eventually succeeded.

AnswerD

This is the classic signature of a brute-force attack: a large number of 'Failed password for root from 192.168.1.100' entries followed by an 'Accepted password for root from 192.168.1.100' entry. The attacker systematically guessed passwords until one succeeded, giving them authenticated root access to the system. The escalation to a successful login after repeated failures confirms that the attack was not just a random scan but a targeted credential-guessing attack that ultimately breached the root account.

Why this answer

The journal output shows repeated failed authentication attempts for the root user from IP 192.168.1.100, followed by a successful login. This pattern is characteristic of a brute-force attack where an attacker tries many passwords until one works. The final 'Accepted password for root' line confirms the attack succeeded, making D correct.

Exam trap

Red Hat often tests the distinction between a denial-of-service attack (which would show connections dropped before authentication) and a brute-force attack (which shows repeated failed authentications followed by a success), leading candidates to confuse the two patterns.

How to eliminate wrong answers

Option A is wrong because the connections are not being closed before authentication; they are completing authentication (both failed and eventually accepted). Option B is wrong because there is no evidence of a configuration error; the SSH service is functioning normally by processing and logging authentication attempts. Option C is wrong because the events are sequential from a single IP, not simultaneous from multiple hosts, and the errors are authentication failures, not connection errors.

Full explanation →

Matchingmedium

Match each file system type to its description.

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

Concepts

Matches

Default file system for RHEL 8/9 with journaling and support for large files

High-performance 64-bit journaling file system, default for /boot in RHEL 7

Copy-on-write file system with snapshots and compression (available in RHEL 8/9)

Used for virtual memory, typically as a partition or file

Why these pairings

In RHEL, ext4 is the standard journaling file system, XFS excels with large files, and Btrfs provides advanced features like snapshots. Swap is used for virtual memory, not data storage.

Full explanation →

MCQmedium

Refer to the exhibit. An administrator needs to create a new logical volume named 'data' of size 3GB. Which command should be used?

A.lvcreate -n data -L 3G vg01

B.lvcreate -n data -L 3G vg00

C.lvcreate -n data -L 3G /dev/sda1

D.lvcreate -n data -l 100 vg01

E.lvcreate -n data -l 100 vg00

AnswerA

This command correctly creates a new logical volume named 'data' with a size of 3GiB (using the -L option, where 'G' denotes GiB) within volume group vg01. Since vg01 has 5GiB of free space, the allocation request is satisfied and the LV is created successfully with default linear mapping. The -n flag assigns the name, and the final positional argument correctly specifies the volume group, which is the only valid target for lvcreate.

Why this answer

The `lvcreate` command with `-n data` names the logical volume 'data', `-L 3G` sets its size to 3 gigabytes, and `vg01` specifies the volume group that contains the physical volumes. This matches the requirement exactly, assuming the volume group `vg01` exists and has sufficient free extents.

Exam trap

Red Hat often tests the distinction between the `-L` (size in units) and `-l` (number of extents) options, and the requirement to specify a volume group name rather than a device path, to catch candidates who confuse LVM syntax with standard partition commands.

How to eliminate wrong answers

Option B is wrong because it specifies `vg00` instead of `vg01`, which does not match the volume group referenced in the exhibit (the exhibit shows `vg01`). Option C is wrong because `lvcreate` requires a volume group name, not a device path like `/dev/sda1`; using a device path would attempt to create a logical volume directly on a physical volume, which is invalid syntax. Option D is wrong because `-l 100` allocates 100 logical extents, not a fixed size of 3GB; the size in extents depends on the extent size of the volume group, which may not equal 3GB.

Option E is wrong because it uses `-l 100` (extents, not a fixed size) and specifies `vg00` instead of `vg01`.

Full explanation →

MCQhard

Refer to the exhibit. After extending the logical volume, why does the df output still show 5.0G?

A.The lvextend command failed silently.

B.The filesystem type is ext4 and requires resize2fs.

C.The mount point /data is not accessible.

D.The filesystem needs to be resized with xfs_growfs.

AnswerD

After lvextend expands the logical volume, the XFS filesystem still occupies only the original space, because the kernel only updates the block device size, not the filesystem metadata. Running xfs_growfs /data on the mounted filesystem instructs the kernel to expand the filesystem to fill the entire logical volume. This is the mandatory step for XFS filesystems, analogous to resize2fs for ext4. Without it, the added capacity remains invisible to applications and users.

Why this answer

The output shows the logical volume was extended (e.g., from 5G to 10G), but the filesystem itself has not been resized to use the new space. For XFS filesystems, the `xfs_growfs` command must be run to expand the filesystem to match the logical volume size. The `df` command reports filesystem usage, not block device size, so it still shows 5.0G until the filesystem is grown.

Exam trap

The trap here is that candidates assume extending the logical volume automatically resizes the filesystem, but XFS requires a separate `xfs_growfs` step, unlike ext4 which can be resized with `resize2fs` after lvextend.

How to eliminate wrong answers

Option A is wrong because the lvextend command did not fail silently; the logical volume was successfully extended (as seen in the lvs output), but the filesystem was not resized. Option B is wrong because the filesystem type is XFS (not ext4), and ext4 uses `resize2fs`, not `xfs_growfs`. Option C is wrong because the mount point /data is accessible (the df output shows it mounted), and inaccessibility would cause an error, not a stale size.

Full explanation →

Matchingmedium

Match each command to its function in managing storage.

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

Concepts

Matches

Partition table manipulator for MBR and GPT

Create a volume group in LVM

Create an ext4 file system on a partition

Attach a file system to a directory

Why these pairings

The correct matches are: fdisk for partition table manipulation, mkfs for filesystem creation, mount for attaching filesystems, and lvcreate for logical volume creation. Common confusions include associating df or du with filesystem creation, and confusing lvcreate with display commands.

Full explanation →

MCQhard

A storage administrator is asked to increase the size of an ext4 filesystem mounted at /data. The underlying logical volume /dev/mapper/vg01-lv01 is currently 10GB and the volume group has 5GB of free extents. After extending the logical volume by 2GB using lvextend -L +2G /dev/mapper/vg01-lv01, what command must be run to resize the filesystem?

A.resize2fs /dev/mapper/vg01-lv01

B.lvextend -r -L +2G /dev/mapper/vg01-lv01

C.xfs_growfs /data

D.fsck -f /dev/mapper/vg01-lv01

AnswerA

resize2fs /dev/mapper/vg01-lv01 is correct because the logical volume was already extended with lvextend (without -r), leaving the ext4 filesystem still sized for the old smaller LV. Running resize2fs online grows the ext4 filesystem to consume the newly added space in the enlarged block device, and since the filesystem type is ext4, resize2fs is the matching tool. Unlike shrinking, growing an ext4 filesystem with resize2fs can be done while the filesystem is mounted, which makes it the immediate follow-up command in this LVM workflow.

Why this answer

After extending the logical volume with `lvextend`, the filesystem does not automatically recognize the new space. For ext4 filesystems, the `resize2fs` command must be run to resize the filesystem to use the additional logical volume capacity. This command can be executed online (while the filesystem is mounted) and will expand the filesystem to fill the available space in the logical volume.

Exam trap

The trap here is that candidates may confuse filesystem-specific resize commands (resize2fs for ext4 vs. xfs_growfs for XFS) or assume that `lvextend` automatically resizes the filesystem without the `-r` flag.

How to eliminate wrong answers

Option B is wrong because `lvextend -r` automatically resizes the filesystem during the LV extension, but the question states the administrator already ran `lvextend` without the `-r` flag, so a separate resize command is required. Option C is wrong because `xfs_growfs` is used for XFS filesystems, not ext4; using it on an ext4 filesystem would fail. Option D is wrong because `fsck -f` performs a filesystem consistency check and repair, not a resize operation; it does not change the filesystem size.

Full explanation →

MCQmedium

Based on the exhibit, which device is used for swap?

A./dev/mapper/vg00-home

B./dev/sda2

C.The UUID deadbeef-cafe-babe-0000-000000000000

D.The UUID abcdef01-2345-6789-abcd-ef0123456789

E.The UUID 12345678-1234-1234-1234-123456789abc

AnswerC

The UUID deadbeef-cafe-babe-0000-000000000000 is the correct answer because the exhibit's fstab excerpt shows this exact UUID in the line that contains the 'swap' keyword in the options field. This UUID is the device identifier that the system uses to find and activate swap space at boot time, either via swapon or through systemd's fstab generator. In modern Linux, swap devices are reliably referenced by UUID to avoid ambiguity if disk device names change.

Why this answer

The exhibit shows a swap partition with the UUID deadbeef-cafe-babe-0000-000000000000. In Red Hat Enterprise Linux, swap devices are identified by their UUID in /etc/fstab, and the 'sw' or 'swap' keyword in the mount options column confirms this. The other UUIDs correspond to non-swap filesystems or are not present in the exhibit.

Exam trap

Red Hat often tests the distinction between device names (like /dev/sda2) and UUIDs, and candidates may mistakenly choose a device name or a UUID from a non-swap filesystem because they overlook the 'swap' keyword in the fstab options column.

How to eliminate wrong answers

Option A is wrong because /dev/mapper/vg00-home is a logical volume typically used for the /home filesystem, not swap; it would have a filesystem type like xfs or ext4, not swap. Option B is wrong because /dev/sda2 is a device name, not a UUID, and the exhibit explicitly shows UUIDs for swap identification; using a device name would be less reliable and not match the exhibit's format. Option D is wrong because the UUID abcdef01-2345-6789-abcd-ef0123456789 is not listed in the exhibit as a swap device; it likely belongs to another filesystem.

Option E is wrong because the UUID 12345678-1234-1234-1234-123456789abc is not present in the exhibit and does not correspond to any swap entry.

Full explanation →

Matchingmedium

Match each networking term to its definition.

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

Concepts

Matches

Automatically assigns IP addresses to hosts

Resolves hostnames to IP addresses

Translates private IPs to public IPs

Combines multiple network interfaces for redundancy or throughput

Why these pairings

The correct matches are: IP address (unique identifier), Subnet mask (network/host division), Default gateway (router to external networks), DNS server (name resolution). Common confusions include swapping definitions between IP address and subnet mask, or between default gateway and DNS server.

Full explanation →

MCQeasy

A user reports they cannot log in to a Linux system. Their account was recently created. The administrator checks /etc/passwd and sees the entry: jsmith:x:1001:1001::/home/jsmith:/sbin/nologin. What is the likely issue?

A.The user is locked due to expired password

B.The home directory does not exist

C.The user is not in any supplementary groups

D.The user's shell is set to /sbin/nologin which prevents login

AnswerD

The login shell in /etc/passwd is the program executed after authentication, so setting it to /sbin/nologin makes the login process run a binary that immediately prints "This account is currently not available" and exits. Since no command interpreter is ever started, the user cannot obtain a shell, making this the direct cause of the reported inability to log in. This is the standard way to deliberately disable interactive logins for system accounts while keeping the account enabled for other services.

Why this answer

The user's shell is set to /sbin/nologin, which is a shell that displays a message and exits immediately, preventing interactive login. This is the direct cause of the login failure, as the system uses the shell field in /etc/passwd to determine the login program.

Exam trap

The trap here is that candidates may confuse the shell field with account lockout mechanisms (like using 'passwd -l' or setting the password expiration) or assume that a missing home directory is the cause. In Red Hat Enterprise Linux, the shell field in /etc/passwd directly controls whether an interactive login is allowed; /sbin/nologin explicitly denies login.

How to eliminate wrong answers

Option A is wrong because an expired password would typically be indicated by a password aging flag in /etc/shadow, not by the shell field in /etc/passwd. Option B is wrong because a missing home directory does not prevent login; the user would still be able to log in but might see a message like 'Could not chdir to home directory'. Option C is wrong because supplementary groups are not required for login; the user's primary group (GID 1001) is sufficient for authentication and shell access.

Full explanation →

MCQeasy

After creating a new partition on /dev/sdc, the administrator runs 'partprobe' to inform the kernel of the change. What is the primary purpose of partprobe?

A.To create a filesystem label

B.To repair a damaged partition table

C.To format the partition with a filesystem

D.To make the kernel re-read the partition table

AnswerD

partprobe, from the parted suite, is specifically designed to make the Linux kernel re-read the partition table from a disk. After partitioning /dev/sdc, the kernel may still have the old view, so partprobe triggers a revalidation so that the new partition appears as a block device (e.g., /dev/sdc1) without requiring a reboot. This is the correct and intended purpose of the command, though in cases where the disk is in use, a reboot or partx may be needed.

Why this answer

The `partprobe` command is used to inform the operating system kernel of changes to the partition table without requiring a system reboot. After creating a new partition on `/dev/sdc`, running `partprobe` makes the kernel re-read the partition table from the disk, ensuring the new partition is recognized and accessible. This is essential for the kernel to update its in-memory representation of the disk's partitions.

Exam trap

The trap here is that candidates often confuse `partprobe` with `partx` or `mkfs`, mistakenly thinking it formats or repairs partitions, when its sole purpose is to synchronize the kernel's partition table with the disk's actual partition layout.

How to eliminate wrong answers

Option A is wrong because creating a filesystem label is done with commands like `e2label` or `tune2fs`, not `partprobe`. Option B is wrong because repairing a damaged partition table is typically performed with tools like `gdisk` or `fdisk` in recovery mode, not `partprobe`. Option C is wrong because formatting a partition with a filesystem is accomplished using commands like `mkfs.ext4` or `mkfs.xfs`, not `partprobe`.

Full explanation →

MCQeasy

Refer to the exhibit. Which command will ensure cron jobs run automatically at system boot?

A.systemctl reenable crond

B.systemctl start crond

C.systemctl enable crond

D.systemctl unmask crond

AnswerC

systemctl enable crond creates the symlinks that pull the cron daemon into the boot target, so the scheduler starts automatically at every system boot. Starting it manually or enabling individual jobs would not satisfy the requirement that cron jobs run automatically after reboot.

Why this answer

The `systemctl enable crond` command creates the necessary symlinks in the systemd unit configuration to ensure the `crond` service starts automatically at boot. This is the correct method to enable a service for automatic startup in a systemd-based Red Hat Enterprise Linux system.

Exam trap

The trap here is that candidates often confuse `systemctl start` (immediate start) with `systemctl enable` (boot-time start), or think that `systemctl unmask` alone is sufficient to make a service start at boot.

How to eliminate wrong answers

Option A is wrong because `systemctl reenable crond` is used to re-create the symlinks for the service, typically after modifying the unit file, but it does not ensure the service is enabled for boot if it was already disabled. Option B is wrong because `systemctl start crond` only starts the service immediately in the current session, without configuring it to start automatically at boot. Option D is wrong because `systemctl unmask crond` removes a mask that prevents the service from being started manually or automatically, but it does not enable the service for boot; the service must still be enabled separately.

Full explanation →

MCQeasy

Which command creates an XFS filesystem on /dev/nvme0n1p1 and sets the label to 'data'?

A.mkfs.xfs -l data /dev/nvme0n1p1

B.mkfs.xfs -f /dev/nvme0n1p1

C.mkfs.xfs -L data /dev/nvme0n1p1

D.mkfs.xfs -n data /dev/nvme0n1p1

AnswerC

Uppercase -L is the mkfs.xfs option for setting the XFS volume label, and `data` becomes that label on /dev/nvme0n1p1. This creates a filesystem that can later be referenced via `-L data` in mount options or by symlinks under /dev/disk/by-label/. The command is correct as written and satisfies the requirement to create a labeled XFS filesystem.

Why this answer

The `-L` flag in `mkfs.xfs` is used to set the filesystem label. The command `mkfs.xfs -L data /dev/nvme0n1p1` creates an XFS filesystem on the specified partition and assigns it the label 'data'.

Exam trap

The trap here is confusing the `-L` (label) flag with the `-l` (log) flag, as they look similar but have completely different functions in XFS, and candidates often misremember the option letter from other filesystem tools.

How to eliminate wrong answers

Option A is wrong because the `-l` flag in `mkfs.xfs` is used to specify log device or log parameters, not the label; using `-l data` would attempt to set a log parameter named 'data', which is invalid. Option B is wrong because the `-f` flag forces overwrite of an existing filesystem but does not set a label; it would create an unlabeled filesystem. Option D is wrong because the `-n` flag in `mkfs.xfs` is used to specify naming (directory) parameters, not the filesystem label; `-n data` would attempt to set a naming option, not the label.

Full explanation →

MCQhard

Refer to the exhibit. What effect does the value INACTIVE=-1 have on newly created user accounts?

A.The account expires immediately.

B.Passwords never expire.

C.Account is disabled if password expires but user does not log in within -1 days (immediately).

D.The password inactivity period is disabled.

AnswerD

When INACTIVE is set to -1, the password inactivity period is disabled entirely. After a user's password expires, the account will not be automatically locked due to the user failing to log in within a set number of days. The user remains able to log in and is typically forced to change the expired password, provided other account expiration policies such as EXPIRE are not also set.

Why this answer

The `INACTIVE=-1` setting in the `useradd -D` or `/etc/default/useradd` configuration disables the password inactivity period. This means that after a password expires, the account will not be locked due to inactivity, effectively turning off the inactivity timer. The value -1 is a special sentinel that indicates no inactivity period is enforced.

Exam trap

Red Hat often tests the distinction between password expiration (`PASS_MAX_DAYS`) and the inactivity period (`INACTIVE`), trapping candidates who confuse the two or misinterpret -1 as 'immediate' rather than 'disabled'.

How to eliminate wrong answers

Option A is wrong because `INACTIVE=-1` does not cause immediate account expiration; account expiration is controlled by the `EXPIRE` field or `-e` option, not the inactivity setting. Option B is wrong because password expiration is controlled by `PASS_MAX_DAYS` (e.g., in `/etc/login.defs`), not by the inactivity period; `INACTIVE` only affects what happens after a password expires. Option C is wrong because a negative value (-1) disables the inactivity check entirely; it does not mean 'immediately' — the account is not disabled at all due to inactivity when set to -1.

Full explanation →

MCQmedium

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

A.fsck cannot fix errors on ext4 filesystems.

B.The filesystem is still mounted; fsck cannot fix it while mounted.

C.The filesystem is XFS, and fsck does not repair XFS.

D.fsck detected errors but did not fix them automatically.

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

MCQmedium

A sysadmin writes a shell script /usr/local/bin/check_service.sh that must accept exactly two positional arguments: a service name and a threshold. The script begins with: #!/bin/bash if [ $# -ne 2 ]; then echo "Usage: $0 <service> <threshold>" exit 1 fi An operator runs the script as: ./check_service.sh httpd What is the exit status of the script, and what output is produced?

A.The script exits with status 0 because the usage message is displayed successfully.

B.The script exits with status 1 and prints the usage line to standard output.

C.The script terminates with a syntax error because $# is not a valid variable.

D.The script continues past the check and prompts for the missing threshold value.

AnswerB

Because only one argument is supplied, $# equals 1, the test [ $# -ne 2 ] is true, the usage message is echoed to standard output, and exit 1 terminates the script with status 1. This matches the intended argument-validation pattern.

Why this answer

The script validates its argument count with $# and the numeric test -ne. With one positional argument supplied, the condition is true, so the usage message is written to standard output and exit 1 ends execution with a non-zero status. This is the conventional way to signal misuse from a shell script.

Exam trap

The trap here is assuming that printing a usage message means the script succeeded, when the explicit exit 1 overrides that and returns failure to the caller.

Full explanation →

MCQeasy

An administrator wants to add an additional swap partition of 2GB on device /dev/sdb1. Which set of commands should be used to enable swap and make it persistent across reboots?

A.parted /dev/sdb set 1 swap on

B.swapadd /dev/sdb1

C.mkswap /dev/sdb1; swapon /dev/sdb1; echo '/dev/sdb1 swap swap defaults 0 0' >> /etc/fstab

D.mkfs.ext4 /dev/sdb1; mount /dev/sdb1 /swap

E.None of the above

AnswerC

This is the correct sequence: `mkswap` initializes the partition with a swap signature, `swapon` activates it immediately for use by the kernel, and appending the line to `/etc/fstab` ensures the swap partition is automatically enabled at boot. The fstab entry uses the correct fields: device, mount point specified as `swap`, filesystem type `swap`, and `defaults` as the mount options. This covers both immediate activation and persistence across reboots, satisfying the administrator's requirement.

Why this answer

It follows the proper sequence to prepare and activate a swap partition on /dev/sdb1. First, `mkswap` initializes the partition as a swap area by writing a swap signature. Then `swapon` activates it immediately.

Finally, adding an entry to /etc/fstab ensures the swap is automatically enabled at boot, making it persistent across reboots.

Exam trap

Red Hat often tests the distinction between filesystem creation (`mkfs.*`) and swap initialization (`mkswap`), and the trap here is that candidates may confuse `swapon` with a non-existent command like `swapadd` or think `parted` can enable swap directly.

How to eliminate wrong answers

Option A is wrong because `parted` does not have a 'swap on' subcommand; swap is enabled via `mkswap` and `swapon`, not through a parted flag. Option B is wrong because `swapadd` is not a valid Linux command; the correct command to activate swap is `swapon`. Option D is wrong because `mkfs.ext4` creates an ext4 filesystem, which is not suitable for swap; swap requires a raw partition formatted with `mkswap`, and mounting it is not how swap is used.

Option E is wrong because option C is correct.

Full explanation →

100

MCQhard

Refer to the exhibit. A web server is serving content from /var/www/html. SELinux is in enforcing mode. The web client reports 'Forbidden'. What is the most likely cause?

A.The file is owned by root, and Apache runs as apache user, so it cannot read.

B.The directory /var/www/html may have incorrect context or permissions preventing Apache from listing files.

C.The file permissions are 644, which restricts access.

D.The file has an incorrect SELinux context; it should be httpd_user_content_t.

AnswerB

The directory /var/www/html must be both readable and executable (searchable) for Apache to enter it and list or serve files; if it is 700 root:root or has a restrictive context, Apache is denied. SELinux also requires the httpd_sys_content_t type on this directory; if it was incorrectly relabeled, httpd cannot access it. This is the classic cause of a 403 'Forbidden' error even when the file itself is world-readable.

Why this answer

The most likely cause of a 'Forbidden' error when SELinux is enforcing is that the directory or file lacks the correct SELinux context (e.g., httpd_sys_content_t) or the permissions do not allow the Apache user (apache) to read or traverse the directory. Even if file permissions are 644, SELinux can block access if the context is wrong, such as being set to default_t or user_home_t. The error indicates Apache cannot access the content, which is typically resolved by restoring the correct context with restorecon or setting it with chcon.

Exam trap

A common pitfall in Red Hat RHCSA is assuming that file permissions alone cause 'Forbidden' errors, but with SELinux enforcing, incorrect context (e.g., httpd_user_content_t instead of httpd_sys_content_t) is the primary cause. Candidates must remember that SELinux overrides DAC permissions.

How to eliminate wrong answers

Option A is wrong because file ownership by root does not inherently prevent Apache from reading it; Apache runs as the apache user, and as long as the file has world-readable permissions (e.g., 644) and the directory is traversable, the apache user can read it. Option C is wrong because file permissions of 644 (owner read/write, group read, others read) are standard for web content and do not restrict access; they allow the apache user (as 'others') to read the file. Option D is wrong because the correct SELinux context for web content served by Apache is httpd_sys_content_t, not httpd_user_content_t, which is used for user-specific content (e.g., in public_html directories).

Full explanation →

101

Drag & Dropmedium

Put the steps to configure NFS server to export /nfsshare to a specific client in order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

NFS export configuration involves creating the directory, editing /etc/exports, exporting, and starting services.

Full explanation →

102

Multi-Selecthard

Which TWO commands can be used to list block devices and their attributes? (Choose exactly two.)

Select 2 answers

A.fdisk -l

B.lsblk

C.du

D.df

E.blkid

AnswersB, E

lsblk reads the sysfs filesystem to present all available block devices as a hierarchical tree, showing essential attributes like name, size, type, and mount point, and with the -f flag adds filesystem type, UUID, and label. It is the canonical, dependency-free command for listing block devices quickly, and it runs without root for basic output. This directly answers the request to list block devices, making it the correct choice.

Why this answer

B (lsblk) is correct because it lists all block devices (e.g., /dev/sda, /dev/nvme0n1) and displays their attributes such as size, type, mount point, and model in a tree-like format by reading the sysfs filesystem. E (blkid) is correct because it shows block device attributes like UUID, filesystem type, and LABEL by querying the libblkid library, which reads metadata directly from the device.

Exam trap

Red Hat often tests the distinction between commands that list block devices (lsblk, blkid) versus commands that manage partitions (fdisk) or report filesystem usage (df, du), causing candidates to confuse 'block device attributes' with 'partition table' or 'disk usage' information.

Full explanation →

103

MCQhard

A system administrator is troubleshooting a cron job that runs a script as root. The script is located at /root/scripts/backup.sh and has permissions 755. The cron job is defined in /etc/crontab with the line: 0 2 * * * root /root/scripts/backup.sh. However, the script does not run at the scheduled time. The administrator checks the cron logs and finds no errors. The administrator then runs the script manually as root and it executes successfully. What is the most likely cause of the cron job not running?

A.The cron job line uses absolute path to the script but the script requires an environment variable that is not set in cron's minimal environment.

B.The script is not executable by the root user.

C.The cron daemon is not running.

D.The /etc/crontab file does not allow running scripts from /root.

AnswerA

Cron runs with a sparse environment that includes only a few default variables such as HOME, LOGIN, and SHELL, with PATH typically set to /usr/bin:/bin. It does not source /etc/profile or a user's ~/.bash_profile, so any custom environment variable that the script expects—for example, a database password or an application home—will be unset. Even though the script's absolute path is correct and it runs manually, the missing variable causes the script to fail under cron. The solution is to export the variable inside the script or define it explicitly in the crontab.

Why this answer

Cron jobs run with a minimal environment, setting only a few variables (such as HOME, SHELL, LOGNAME, and a default PATH) and not sourcing the user's shell startup files. The script at /root/scripts/backup.sh may rely on an environment variable (e.g., a database password or directory path) defined in root's interactive shell but not in cron's environment. When run manually as root, the variable is available, but cron does not source /root/.bashrc or /root/.bash_profile, causing the script to fail silently or not execute as expected.

Exam trap

Red Hat often tests the misconception that file permissions or cron daemon status are the primary causes of cron job failures, when in reality the minimal cron environment and missing environment variables are the subtle but frequent issue.

How to eliminate wrong answers

Option B is wrong because the script has permissions 755, which includes execute permission for the owner (root), so it is executable by root. Option C is wrong because if the cron daemon were not running, the cron logs would typically show an error or the job would not be logged at all; the administrator found no errors in the logs, indicating the daemon is active. Option D is wrong because /etc/crontab has no restriction on running scripts from /root; the root user can execute scripts from any directory, and the cron job specifies the user 'root' explicitly.

Full explanation →

104

MCQhard

A user is unable to delete a file named '-f' in the current directory. Which command will successfully remove it?

A.rm \-f

B.rm -- -f

C.rm -f

D.rm "-f"

AnswerB

The command `rm -- -f` uses the standard end-of-options delimiter `--`, which POSIX utilities use to signal that no more options follow. When rm encounters `--`, it stops option processing and treats every subsequent argument literally as an operand, so `-f` becomes a filename. This is the correct way to delete a file whose name begins with a dash, because the argument is never interpreted as the force flag.

Why this answer

The '--' double dash signals the end of command options to most Linux utilities, including rm. This allows rm to interpret '-f' as a literal filename rather than the '--force' option, enabling its deletion.

Exam trap

The trap here is that candidates assume quoting or escaping the dash will prevent option parsing, but only the '--' separator reliably tells rm to stop interpreting arguments as options.

How to eliminate wrong answers

Option A is wrong because 'rm \-f' escapes the hyphen with a backslash, but rm still interprets '-f' as the force option, not a filename. Option C is wrong because 'rm -f' is the standard force-delete option, which does not target a file named '-f' and will fail or delete unintended files. Option D is wrong because 'rm "-f"' uses quotes, but the shell still passes the string '-f' as an argument, which rm interprets as the force option, not a filename.

Full explanation →

105

MCQhard

Refer to the exhibit. An administrator needs to create a 1.2 TiB logical volume named 'data' in volume group 'myvg' and mount it persistently at /data. Which sequence of commands should be used?

A.lvcreate -L 1.2T -n data myvg mkfs.ext4 /dev/myvg/data echo '/dev/myvg/data /data ext4 defaults 0 0' >> /etc/fstab mount -a

B.lvcreate -l 100%FREE -n data myvg mkfs.xfs /dev/myvg/data echo '/dev/mapper/myvg-data /data xfs defaults 0 0' >> /etc/fstab mount -a

C.lvcreate -L 1.2T -n data myvg mkfs.xfs /dev/myvg/data echo '/dev/myvg/data /data xfs defaults 0 0' >> /etc/fstab mount -a

D.lvcreate -L 1200G -n data myvg mkfs.ext4 /dev/myvg/data echo '/dev/myvg/data /data ext4 defaults 0 0' >> /etc/fstab mount -a

AnswerC

This is correct because lvcreate -L 1.2T allocates exactly 1.2 TiB—in LVM, an uppercase T suffix represents Tebibytes (2^40 bytes), not SI terabytes. Formatting with mkfs.xfs creates a modern, scalable filesystem appropriate for large volumes, and the fstab entry uses /dev/myvg/data, a stable LVM2 device-mapper path. Running mount -a then validates the configuration by actually mounting the new filesystem.

Why this answer

It creates a logical volume of exactly 1.2 TiB using the valid -L 1.2T size specification. LVM's -L option accepts floating-point values with suffixes like T for TiB. The volume is formatted with XFS (default for RHEL 8+), a correct fstab entry is added with /dev/myvg/data, and mount -a mounts it persistently.

Option D uses 1200G, which yields approximately 1.17 TiB, not the required 1.2 TiB.

Exam trap

A common pitfall on the RHCSA exam is assuming that -L does not accept fractional TiB values. In fact, lvcreate supports floating-point sizes (e.g., 1.2T). Candidates may incorrectly use an approximation like 1200G instead of the exact 1.2T.

How to eliminate wrong answers

Option A is wrong because lvcreate -L 1.2T uses an invalid size suffix; LVM does not accept fractional TiB values (e.g., 1.2T), which would cause a syntax error or unexpected behavior. Option B is wrong because -l 100%FREE creates a volume using all free space in the volume group, not a specific 1.2 TiB size, and it uses xfs instead of ext4 (though xfs is acceptable, the size requirement is not met). Option C is wrong because lvcreate -L 1.2T uses the invalid size suffix 1.2T, and it formats with xfs instead of ext4, but the primary failure is the invalid size specification.

Full explanation →

106

MCQhard

A company runs a web application on a Red Hat Enterprise Linux 8 server. The application is served by Apache HTTPD, and it requires read/write access to a custom directory /var/www/app_data. The SELinux context for the directory is set to httpd_sys_rw_content_t. Apache runs in enforcing mode. Recently, a new feature was added that requires Apache to connect to a database on the same server via a Unix socket. The database serves on /var/run/mysqld/mysqld.sock. After the feature deployment, the web application fails to connect to the database. The error logs show permission denied on the socket file. The socket file has permissions 660 and is owned by mysql:mysql. SELinux audit logs show AVC denials for httpd_t trying to connect to mysqld_var_run_t. Which of the following solutions should the administrator implement to allow Apache to read the database socket while maintaining security?

A.Change the SELinux context of the socket file to httpd_sys_rw_content_t using chcon.

B.Enable the SELinux boolean httpd_can_network_connect_db using setsebool -P httpd_can_network_connect_db on.

C.Enable the SELinux boolean httpd_can_connect_db using setsebool -P httpd_can_connect_db on.

D.Use semanage to add a context mapping for the socket file to httpd_var_run_t and set the httpd to permissive mode.

AnswerC

This is the correct boolean because httpd_can_connect_db allows the httpd daemon to connect to a database through local Unix socket files, such as /var/run/mysql/mysql.sock, while leaving network controls unchanged. Using setsebool with -P is essential because it writes the change to the persistent policy so the permission survives a reboot, matching the intended production configuration. The boolean directly addresses the SELinux denial shown in the audit log instead of masking the problem.

Why this answer

The correct solution is to enable the SELinux boolean `httpd_can_connect_db` using `setsebull -P httpd_can_connect_db on`. This boolean specifically allows the `httpd_t` domain to connect to MySQL/MariaDB databases via Unix sockets, which is exactly the scenario described: Apache needs to connect to a local database socket with context `mysqld_var_run_t`. The AVC denial confirms that the default policy blocks this socket connection, and enabling this boolean grants the necessary permission without weakening other security controls.

Exam trap

The trap here is that candidates often confuse `httpd_can_connect_db` (for local database connections via Unix sockets) with `httpd_can_network_connect_db` (for remote TCP connections), leading them to choose the wrong boolean when the scenario involves a local socket file.

How to eliminate wrong answers

Option A is wrong because changing the SELinux context of the socket file to `httpd_sys_rw_content_t` would mislabel a socket file (which should remain `mysqld_var_run_t`) and could break the database daemon's ability to use it; moreover, the issue is about connecting to the socket, not file read/write access. Option B is wrong because `httpd_can_network_connect_db` controls TCP network connections to remote databases, not Unix socket connections to a local database. Option D is wrong because adding a context mapping to `httpd_var_run_t` does not address the socket connection permission (the socket is already labeled `mysqld_var_run_t`), and setting httpd to permissive mode would disable SELinux enforcement entirely, which is not a secure or recommended solution.

Full explanation →

107

MCQeasy

A system administrator needs to view the last 10 lines of the log file /var/log/messages in real time as new lines are added. Which command should be used?

A.tail -f /var/log/messages

B.less /var/log/messages

C.head -n 10 /var/log/messages

D.cat /var/log/messages

AnswerA

tail -f /var/log/messages is correct because tail by default prints the last 10 lines of the file, and the -f flag (follow) keeps the command running and continuously outputs newly appended lines as they are written. This makes it ideal for real-time monitoring of a live log, satisfying the requirement to view the last 10 lines and see updates without re-running the command.

Why this answer

The `tail -f /var/log/messages` command displays the last 10 lines of the file by default and then continues to output new lines as they are appended, providing real-time monitoring. The `-f` (follow) option keeps the file open and polls for changes, making it the correct tool for live log watching.

Exam trap

Red Hat often tests the distinction between `tail -f` and `tail` without `-f`, where candidates mistakenly think `tail` alone provides real-time updates, or confuse `head` and `tail` for viewing the end of a file.

How to eliminate wrong answers

Option B is wrong because `less` is a pager that shows the file content page by page but does not automatically follow new lines in real time (unless used with `+F` mode, which is not specified). Option C is wrong because `head -n 10` only shows the first 10 lines, not the last 10, and does not follow updates. Option D is wrong because `cat` dumps the entire file to stdout and exits, providing no real-time monitoring capability.

Full explanation →

108

MCQhard

A developer needs to compile software from source and install it under /opt/custom. To avoid affecting the system package manager, which approach should be used?

A.Compile and install with default paths, then use 'make uninstall' to remove

B.Compile with './configure --prefix=/opt/custom' and use 'checkinstall' to create an RPM

C.Compile with './configure --prefix=/usr' and then install

D.Compile with './configure --prefix=/opt/custom' and then 'make install'

AnswerD

Using './configure --prefix=/opt/custom' sets the installation root to a dedicated directory, typically /opt/custom. The subsequent 'make install' places all binaries, libraries, and configuration files under that single prefix, keeping the software isolated from system-managed areas. This avoids conflicts with the package manager and allows clean removal by simply deleting the /opt/custom directory.

Why this answer

Using `./configure --prefix=/opt/custom` sets the installation root to `/opt/custom`, which keeps the compiled software completely separate from the system-managed directories (e.g., `/usr`, `/usr/local`). Running `make install` then installs all files under this custom prefix, ensuring the system package manager (RPM/YUM/DNF) is not affected by the manual installation.

Exam trap

Red Hat often tests the misconception that `--prefix=/usr/local` is safe, but the trap here is that `/usr/local` can still be managed by the system package manager in some configurations, and the only way to guarantee no interference is to use a completely separate directory like `/opt/custom`.

How to eliminate wrong answers

Option A is wrong because compiling with default paths (typically `/usr/local`) still places files in a location that may conflict with system-managed packages, and `make uninstall` is unreliable (many Makefiles do not support it or leave residual files). Option B is wrong because `checkinstall` creates an RPM that, when installed, registers the software with the system package manager, which defeats the goal of avoiding package manager interference. Option C is wrong because `--prefix=/usr` installs directly into the system-managed directory, which can overwrite or conflict with RPM-managed files and corrupt the package database.

Full explanation →

109

MCQeasy

A technician needs to create a new group named 'developers' with GID 5000. Which command accomplishes this?

A.groupadd -r developers

B.useradd -g developers

C.groupadd developers

D.groupadd -g 5000 developers

AnswerD

The -g option lets you explicitly assign the numeric GID 5000 to the new group, making this command exactly what the technician needs. groupadd will validate that the GID is not already in use and that it fits within the allowed range for ordinary groups. As long as no group with GID 5000 exists, this creates developers with the correct ID in a single operation.

Why this answer

The `groupadd -g 5000 developers` command explicitly sets the GID to 5000 for the new group named 'developers'. The `-g` option specifies the numeric group ID, which is required to meet the technician's exact requirement.

Exam trap

The trap here is that candidates may confuse `groupadd -r` (system group) with creating a group with a specific GID, or they may think `useradd -g` creates a group, when it actually assigns a user to an existing group.

How to eliminate wrong answers

Option A is wrong because `groupadd -r` creates a system group with a GID in the system range (typically below 1000), not a custom GID of 5000. Option B is wrong because `useradd -g developers` creates a new user and assigns them to an existing group named 'developers', but it does not create a new group. Option C is wrong because `groupadd developers` creates the group with an automatically assigned GID (usually the next available above 1000), not the specific GID 5000.

Full explanation →

110

MCQeasy

An administrator needs to configure a service to start automatically at boot and also start it immediately without rebooting. Which single command accomplishes both tasks?

A.systemctl start httpd.service

B.systemctl enable httpd.service

C.systemctl enable --now httpd.service

D.systemctl reenable httpd.service

AnswerC

systemctl enable --now httpd.service combines boot-persistent enablement with immediate activation in a single atomic operation. The --now flag instructs systemd to both create the boot-enabling symlinks and start the unit right away, eliminating the risk of forgetting either step. This is the correct choice when the requirement explicitly states that the service must start automatically after reboot; it satisfies both the immediate runtime need and the persistent boot-time need simultaneously.

Why this answer

`systemctl enable --now httpd.service` combines the `enable` action (creating symlinks for automatic start at boot) with the `start` action (immediately launching the service) in a single command. This is the precise method in systemd to achieve both goals without rebooting.

Exam trap

The trap here is that candidates often confuse `enable` with `start`, thinking `enable` alone also starts the service, or they choose `start` alone, forgetting that boot persistence requires a separate `enable` step.

How to eliminate wrong answers

Option A is wrong because `systemctl start httpd.service` only starts the service immediately but does not configure it to start automatically at boot; it lacks the `enable` action. Option B is wrong because `systemctl enable httpd.service` only configures the service to start at boot but does not start it immediately; it requires a separate `start` command or a reboot. Option D is wrong because `systemctl reenable httpd.service` is used to recreate the enable symlinks (e.g., after a unit file change) but does not start the service; it neither starts it immediately nor guarantees a fresh enable for boot.

Full explanation →

111

MCQhard

A system has two logical volumes in the same volume group: 'lv_prod' (100% used) and 'lv_backup' (20% used). The administrator wants to allocate 5 GiB from 'lv_backup' to 'lv_prod' without unmounting any filesystems. Is this possible and why?

A.Yes, use lvreduce and lvextend while mounted; ext4 supports online shrinking.

B.No, because LVM does not allow freeing extents from an LV while it is active.

C.No, because ext4 filesystems cannot be shrunk online; they must be unmounted.

D.Yes, use lvresize to move extents between LVs directly.

AnswerC

ext4 filesystems can only be shrunk while unmounted; the resize2fs tool does not support online shrink. Therefore, to free space from an ext4 LV, the filesystem must be unmounted, shrunk, and then the LV reduced, meaning the operation cannot occur while the volume is in use.

Why this answer

Ext4 filesystems do not support online shrinking; they must be unmounted before reducing the logical volume. Since the administrator wants to shrink lv_backup (which is only 20% used) to free 5 GiB, the ext4 filesystem on that LV must be unmounted first. Without unmounting, the lvreduce operation would fail, making the scenario impossible as described.

Exam trap

The trap here is that candidates confuse LVM's ability to resize logical volumes online (which is true for both growth and reduction at the LVM layer) with the filesystem's ability to shrink online, forgetting that ext4 requires unmounting for shrink operations.

How to eliminate wrong answers

Option A is wrong because ext4 does not support online shrinking; lvreduce on an ext4 filesystem requires the filesystem to be unmounted first, so the statement that ext4 supports online shrinking is false. Option B is wrong because LVM does allow freeing extents from an LV while it is active (the LV can be reduced online), but the filesystem on top (ext4) does not support online shrinking, so the limitation is at the filesystem level, not LVM. Option D is wrong because lvresize cannot move extents directly between LVs; it can only resize individual LVs, and extents must be freed from one LV and then allocated to another using separate lvreduce and lvextend steps, and the filesystem must be unmounted for the shrink.

Full explanation →

112

MCQeasy

A new Linux administrator needs to read the manual page for the 'ls' command but also wants to search for the word 'color' within the manual. Which command accomplishes this?

A.man -k color

B.man ls and then type /color

C.man ls | grep color

D.man color

AnswerB

This is the correct approach because man ls opens the ls manual page in a pager (typically less), and typing the slash key (/) invokes the pager's interactive search function. Entering /color immediately jumps to the first occurrence of the string 'color' in the fully formatted page, and pressing 'n' cycles through subsequent matches. This lets you quickly locate the --color option's description right where it appears in the manual.

Why this answer

The man command opens the manual page for 'ls', and typing '/color' within the pager (usually less) performs an interactive forward search for the string 'color'. This allows the administrator to read the manual and search for the term in one session.

Exam trap

The trap here is that candidates may confuse 'man -k' (keyword search in manual page descriptions) with searching within a specific manual page, or they may think piping to grep is equivalent to the interactive search inside the man pager.

How to eliminate wrong answers

Option A is wrong because 'man -k color' searches the manual page name and short description (whatis database) for the keyword 'color', not within the content of a specific manual page. Option C is wrong because 'man ls | grep color' pipes the formatted output of the man page to grep, which searches for 'color' but does not allow interactive reading of the manual; it also may miss matches due to formatting escape sequences. Option D is wrong because 'man color' attempts to open a manual page named 'color', which does not exist as a standard command, and does not search within the 'ls' manual.

Full explanation →

113

MCQhard

A server has an LVM volume group 'vg_data' with a logical volume 'lv_data' formatted as ext4. The administrator needs to increase the filesystem size by 2 GB without unmounting. Which set of commands should be used?

A.lvresize -L +2G /dev/vg_data/lv_data && xfs_growfs /mountpoint

B.lvextend -L +2G /dev/vg_data/lv_data

C.umount /dev/vg_data/lv_data && lvextend -L +2G /dev/vg_data/lv_data && mount /dev/vg_data/lv_data /mountpoint

D.lvextend -L +2G /dev/vg_data/lv_data && resize2fs /dev/vg_data/lv_data

AnswerD

lvextend -L +2G extends the logical volume by 2 GiB, giving the underlying block device more capacity, and resize2fs then grows the ext4 filesystem online to occupy the newly available space. When invoked without a size argument, resize2fs expands the filesystem to fill the entire LV, and ext4 permits this while the filesystem is mounted, so no unmount is needed.

Why this answer

The filesystem is ext4, which supports online resizing. The `lvextend` command first expands the logical volume by 2 GB, and then `resize2fs` grows the ext4 filesystem to fill the newly allocated space—all without unmounting.

Exam trap

The trap here is that candidates often confuse the filesystem-specific resize commands—using `xfs_growfs` for ext4 or forgetting to run any filesystem resize command after extending the logical volume.

How to eliminate wrong answers

Option A is wrong because `xfs_growfs` is used for XFS filesystems, not ext4; using it on an ext4 filesystem would fail. Option B is wrong because it only extends the logical volume but does not resize the filesystem, leaving the extra space unusable. Option C is wrong because it unnecessarily unmounts and remounts the filesystem; ext4 supports online resizing, so unmounting is not required and adds downtime.

Full explanation →

114

MCQeasy

Which command displays the UUID of a filesystem on /dev/sda1?

A.blkid /dev/sda1

B.df -h

C.mount

D.fdisk -l /dev/sda

AnswerA

blkid /dev/sda1 is correct because blkid is a util-linux command that scans the specified block device and prints its detected attributes, including the filesystem UUID, along with the filesystem type and partition label. It reads the superblock directly via libblkid, so the device does not need to be mounted. This is the standard tool for looking up a filesystem's UUID in a scriptable, field-friendly format.

Why this answer

The `blkid` command is specifically designed to locate and print block device attributes, including the UUID (Universally Unique Identifier) of a filesystem. Running `blkid /dev/sda1` queries the device's superblock and outputs the UUID, filesystem type, and other metadata, making it the correct tool for this task.

Exam trap

The trap here is that candidates confuse `blkid` with `fdisk` or `df`, assuming partition tools or mount commands can reveal filesystem UUIDs, when in fact only `blkid` (or `lsblk -f`) directly queries the filesystem superblock for this attribute.

How to eliminate wrong answers

Option B is wrong because `df -h` displays disk space usage for mounted filesystems (human-readable sizes), not UUIDs or low-level device attributes. Option C is wrong because `mount` shows currently mounted filesystems and their mount options, but it does not display the UUID of a device unless the device was mounted by UUID (and even then, it shows the mount source, not a direct UUID query). Option D is wrong because `fdisk -l /dev/sda` lists partition tables (sectors, sizes, types) for the entire disk, but it does not show filesystem UUIDs; it only shows partition UUIDs (PTUUID) and partition type GUIDs on GPT disks, not the filesystem UUID stored in the superblock.

Full explanation →

115

MCQhard

Refer to the exhibit. A user 'alice' is unable to write to /data directory. What is the most likely reason?

A.The directory permissions restrict access

B.The filesystem is nearly full

C.The directory is owned by root and alice is not root

D.The directory has ACLs preventing access

AnswerA

With mode 700 (drwx------), only the directory's owner has read, write, and execute permissions. Alice is neither root nor the owning UID, so for her the directory falls under 'others' with no permission bits set. Since creating or modifying a file requires write (and execute) permission on the directory itself, her write attempt is denied. This is exactly why the effective access is 'Permission denied'.

Why this answer

The exhibit (not shown here) likely displays directory permissions such as 'drwxr-xr-x' or 'drwx------' that do not grant write access to the user 'alice'. In Linux, the write permission (w) on a directory controls whether a user can create, delete, or rename files within it. Since 'alice' lacks write permission on /data, she cannot write to it, regardless of ownership or filesystem space.

Exam trap

The trap here is that candidates often assume ownership by root (Option C) is the sole reason for denial, overlooking that permissions (Option A) are the actual gatekeeper; Red Hat exams test whether you understand that 'root ownership' does not block a non-root user if the 'others' permission allows write.

How to eliminate wrong answers

Option B is wrong because a nearly full filesystem would produce a 'No space left on device' error, not a permission denied error; the question describes inability to write due to permissions, not capacity. Option C is wrong because directory ownership by root does not inherently prevent 'alice' from writing if the directory's permissions grant write access to others (e.g., 'drwxrwxrwx') or if 'alice' is in a group with write permission; the exhibit likely shows restrictive permissions, not just ownership. Option D is wrong because ACLs (Access Control Lists) could also restrict access, but the question asks for the 'most likely' reason, and standard Unix permissions are the default and more common cause; ACLs would require explicit 'setfacl' configuration, which is less typical in basic scenarios.

Full explanation →

116

MCQmedium

A system administrator writes the script shown. The /etc directory contains .conf files with spaces in their names (e.g., "my config.conf"). What is the most accurate description of the script's behavior?

A.The script will correctly process all .conf files, including those with spaces.

B.The script will only process the first .conf file and then exit.

C.The script will not execute because of a syntax error.

D.The script will split filenames with spaces into multiple words, causing errors.

AnswerD

This is the correct behavior. When the command substitution `$(ls /etc/*.conf)` is left unquoted, the shell splits the result using the characters in `IFS` (space, tab, and newline by default). A file named, for example, `app config.conf` becomes two loop tokens, `app` and `config.conf`, causing the loop body to run extra times with incorrect arguments. These partial names are unlikely to exist, so the script produces errors and fails to handle the actual .conf files that have spaces.

Why this answer

The script uses a for loop with `for file in /etc/*.conf`, which relies on shell globbing. When the glob expands, filenames with spaces (e.g., "my config.conf") are treated as separate words due to word splitting, causing the loop to iterate over each word rather than each file. This results in errors when commands like `echo` or `cp` receive broken paths.

Exam trap

Red Hat often tests the misconception that globbing automatically handles spaces, when in fact unquoted expansions cause word splitting that breaks filenames with spaces.

How to eliminate wrong answers

Option A is wrong because the script does not handle filenames with spaces; word splitting breaks them into multiple arguments. Option B is wrong because the loop does not exit after the first file; it continues iterating over all expanded words, but each iteration may fail due to incorrect filenames. Option C is wrong because there is no syntax error in the script; the for loop syntax is valid, and the issue is a runtime behavior problem with word splitting.

Full explanation →

117

Multi-Selectmedium

Which TWO of the following are valid reasons to use LVM in a Red Hat Enterprise Linux environment?

Select 2 answers

A.Improved disk I/O performance over direct partitions

B.Ability to resize logical volumes without repartitioning

C.Support for snapshots for backup purposes

D.Simplification of disk partitioning by removing the need for partitions

E.Ability to create RAID arrays without mdadm

AnswersB, C

LVM decouples the filesystem from the underlying physical partition layout by using physical volumes, volume groups, and logical volumes. This logical abstraction enables administrators to grow or shrink logical volumes on-the-fly (with filesystem support) without the need to delete/recreate partitions or disrupt running systems. This flexibility is a fundamental advantage over static partition-based layouts.

Why this answer

LVM allows you to resize logical volumes (LVs) online or offline without needing to repartition the underlying disk, which is a key advantage over traditional partitions. Option C is correct because LVM provides snapshot functionality, which creates a point-in-time copy of a logical volume for consistent backups or testing, without requiring additional backup software.

Exam trap

The trap here is that candidates often confuse LVM's flexibility features (like resizing and snapshots) with performance improvements or RAID capabilities, leading them to select options A or E, which are not inherent LVM benefits.

Full explanation →

118

Multi-Selecthard

Which two statements are true regarding network teaming (teamd) compared to bonding?

Select 2 answers

A.Teaming must be configured manually with configuration files only

B.Teaming supports more advanced features like load balancing and link monitoring

C.Bonding is deprecated in RHEL 8

D.Bonding does not support active-backup mode

E.Teaming uses the libteam library

AnswersB, E

Unlike the kernel-only bonding driver, teaming implements its logic in user space, which enables sophisticated features such as IEEE 802.3ad LACP dynamic load balancing, fallback policies, and custom link-watchdog techniques. The teamd daemon can combine multiple load-balancing methods on a single team interface and supports link monitoring via ethtool, ARP ping, or VLAN-based methods that are more extensible than bonding's fixed modes. This is why the statement that teaming supports more advanced load balancing and link monitoring is correct.

Why this answer

Teaming (teamd) provides advanced features such as IEEE 802.3ad load balancing, active-backup, and LACP support, along with more sophisticated link monitoring (e.g., ARP ping, NSNA) compared to the older bonding driver. Teaming uses the libteam library to offer a modular and extensible architecture, which is why option E is also correct.

Exam trap

The trap here is that candidates often assume bonding is deprecated or lacks features like active-backup, but Red Hat still supports bonding in RHEL 8, and the key differentiator is the userspace control and modularity of teaming, not a complete replacement.

Full explanation →

119

MCQmedium

A user jdoe, who is a member of the group staff, reports they cannot access the directory /shared. The administrator runs getfacl /shared and receives the output shown. Which of the following explains the issue?

A.The group staff does not have execute permission

B.An ACL entry denies all permissions for jdoe

C.The mask entry restricts group permissions

D.The directory is read-only for the owner

AnswerB

Access control list evaluation checks a named user entry for jdoe before it checks the owning group. The entry user:jdoe:--- supplies no read, write, or execute bits, which causes every attempted operation on the directory to fail for jdoe. This explicit deny overrides the otherwise permissive group::rwx entry that staff members would normally inherit.

Why this answer

The getfacl output shows a user ACL entry for jdoe with permissions '---' (no read, write, or execute), which explicitly denies all access. This user-specific ACL entry overrides any group or other permissions, so jdoe cannot access /shared regardless of group staff membership.

Exam trap

The trap here is that candidates often focus on group permissions or the mask, overlooking that a user-specific ACL entry with no permissions explicitly denies access, overriding all other entries.

How to eliminate wrong answers

Option A is wrong because the group staff may have execute permission (indicated by 'r-x' in the group ACL entry), but the user-specific deny entry for jdoe takes precedence. Option C is wrong because the mask entry (often 'r-x') restricts only the maximum permissions for named users and groups, but it does not override a user-specific deny entry; the deny entry explicitly sets permissions to none. Option D is wrong because the owner's permissions (e.g., 'rwx') are irrelevant when a user-specific ACL entry denies all access; the deny entry applies directly to jdoe.

Full explanation →

120

Multi-Selectmedium

Which three of the following are required steps to create a new logical volume of 5GB in an existing volume group 'vg00'?

Select 3 answers

A.Create a logical volume with lvcreate

B.Format the logical volume with a filesystem (e.g., mkfs)

C.Mount the filesystem

D.Create a physical volume

E.Create a volume group

AnswersA, B, C

The lvcreate command carves a new logical volume out of the free extents in an existing volume group, such as vg00. It requires specifying the LV name, size (-L or -l), and the target VG; without this step, there is no block device available for formatting or mounting. Because the VG already holds the physical storage, lvcreate is the first and essential action in the workflow.

Why this answer

`lvcreate` is the command used to create a new logical volume within an existing volume group. For a 5GB volume in vg00, the command would be `lvcreate -L 5G -n lvname vg00`. This step is mandatory to allocate the logical volume from the free extents in the volume group.

Exam trap

The trap here is that candidates confuse the entire LVM creation workflow (PV → VG → LV → filesystem → mount) with the steps required when the volume group already exists, leading them to incorrectly select D or E as necessary steps.

Full explanation →

121

MCQeasy

A system administrator needs to find all files modified in the last 24 hours under /var/log. Which command accomplishes this?

A.find /var/log -ctime -1

B.find /var/log -atime -1

C.find /var/log -mmin 1440

D.find /var/log -mtime -1

AnswerD

This is the correct command because -mtime -1 specifically filters on the modification time (mtime) and the leading minus sign means 'less than one day old,' i.e., files whose content was last changed within the past 24 hours. Unlike ctime or atime, mtime only updates when the file's data is written to, which is exactly what is needed to identify recently modified log files. In find's age arithmetic, -mtime -1 corresponds to 'less than one 24-hour period,' so it reliably catches all files modified since the same time yesterday.

Why this answer

`find /var/log -mtime -1` searches for files under `/var/log` whose modification time (`mtime`) is less than 1 day ago (i.e., modified within the last 24 hours). The `-mtime` flag checks the last modification time of file content, which is the standard criterion for 'modified' files.

Exam trap

The trap here is confusing `-mtime -1` (modified within the last 24 hours) with `-mtime 1` (modified exactly 1 day ago) or with `-ctime` (metadata change), leading candidates to pick options that check the wrong timestamp or an exact time rather than a range.

How to eliminate wrong answers

Option A is wrong because `-ctime -1` checks the last change time of file metadata (inode change), not the modification of file content; this includes permission or ownership changes, not just content edits. Option B is wrong because `-atime -1` checks the last access time (read time), which is unrelated to file modification and can be misleading due to access caching. Option C is wrong because `-mmin 1440` checks for files modified exactly 1440 minutes ago (i.e., exactly 24 hours ago), not within the last 24 hours; the `-mmin` flag with a positive number matches files modified exactly that many minutes ago, not a range.

Full explanation →

122

MCQmedium

After configuring sudo, a user reports: 'sudo: unable to open /etc/sudoers: Permission denied'. The admin checks the file permissions and sees '-rw-r-----' owned by root:root. What is the most likely cause?

A.The file is owned by the wrong user.

B.The sudo binary is missing the setuid bit.

C.The file permissions are too permissive (0640 instead of 0440).

D.SELinux is blocking access.

AnswerC

Sudo requires /etc/sudoers to be owned by root:root and have mode 0440 (read-only for owner and group). A mode of 0640 grants write permission to root, which sudo considers unsafe because it suggests the file was modified manually outside visudo's validation; sudo then refuses to open it for policy parsing and reports an error. Changing the mode back to 0440 with `chmod 0440 /etc/sudoers` resolves the issue. The message may explicitly say 'sudo: /etc/sudoers is mode 0640, should be 0440'.

Why this answer

The sudoers file requires strict permissions of 0440 (owner read, group read) to be considered secure by sudo. The current permissions of 0640 (owner read/write, group read) are too permissive, as they grant write access to the owner (root), which violates sudo's security model. When sudo detects that /etc/sudoers has permissions other than 0440, it refuses to open the file and reports 'Permission denied' to prevent potential tampering.

Exam trap

The trap here is that candidates assume 'Permission denied' always means the user lacks read access, but sudo specifically rejects files with write permissions for root to enforce its security policy, not because the user cannot read the file.

How to eliminate wrong answers

Option A is wrong because the file is owned by root:root, which is the correct ownership for /etc/sudoers; the issue is with permissions, not ownership. Option B is wrong because the sudo binary's setuid bit is unrelated to this error; the error message specifically references /etc/sudoers, not the sudo executable, and a missing setuid bit would cause a different error like 'sudo: must be setuid root'. Option D is wrong because SELinux would produce a different error message (e.g., 'Permission denied' with an AVC denial logged in audit.log) and the file permissions are the direct cause here; SELinux is not indicated by the given permission string.

Full explanation →

123

MCQeasy

A system administrator is trying to compress the contents of the directory /home/user/project into a tarball named project_backup.tar.gz using the command: tar -czf project_backup.tar.gz /home/user/project. The command completes without errors, but when the administrator tries to list the contents of the tarball using tar -tzf project_backup.tar.gz, it shows a leading slash (/) in the paths, like /home/user/project/file1. The administrator wants to create the tarball with relative paths instead. What change should be made to the tar command?

A.Use tar -czf project_backup.tar.gz --absolute-names /home/user/project

B.Use tar -czf project_backup.tar.gz -P /home/user/project

C.Use tar -czf project_backup.tar.gz -C /home/user project

D.Use tar -czf project_backup.tar.gz -h /home/user/project

AnswerC

Using -C /home/user makes tar change its working directory to /home/user before processing the file list, so the argument 'project' is interpreted as a relative path. The resulting archive therefore contains members like project/file1 rather than /home/user/project/file1, allowing the archive to be extracted into any directory without side effects. This is the standard, safe way to back up a directory subtree with relative pathnames.

Why this answer

The `-C` option changes the working directory to `/home/user` before archiving, so the argument `project` is interpreted as a relative path. This strips the leading slash and stores paths like `project/file1` instead of absolute paths. The `-C` option is the standard way to create tarballs with relative paths in a single command.

Exam trap

Red Hat often tests the `-C` option as the correct way to create tarballs with relative paths, and the trap here is that candidates mistakenly think `-P` or `--absolute-names` removes leading slashes, when in fact they preserve them.

How to eliminate wrong answers

Option A is wrong because `--absolute-names` (or `-P`) preserves absolute paths, which is the opposite of what the administrator wants. Option B is wrong because `-P` is the short form of `--absolute-names` and also preserves leading slashes, not removes them. Option D is wrong because `-h` (or `--dereference`) follows symlinks and archives the files they point to, but does not affect path stripping or relative path creation.

Full explanation →

124

Multi-Selecteasy

Which TWO commands can be used to create a filesystem on a new partition? (Choose two.)

Select 2 answers

A.mount /dev/sdb1 /mnt

B.mkfs /dev/sdb1

C.parted /dev/sdb

D.mkfs.ext4 /dev/sdb1

E.fdisk /dev/sdb

AnswersB, D

mkfs is the standard command-line front-end that builds a filesystem on a device, writing the superblock, inode table, and other metadata. With no -t option, it defaults to ext2, but it silently calls the appropriate mkfs.<type> binary. This command correctly initializes /dev/sdb1 for use, so it is a valid answer.

Why this answer

B is correct because `mkfs` is the generic command to create a filesystem on a partition. D is correct because `mkfs.ext4` is a specific variant of `mkfs` that creates an ext4 filesystem. Both commands write the filesystem metadata to the partition, making it ready for mounting.

Exam trap

The trap here is that candidates confuse partition management commands (fdisk, parted) with filesystem creation commands (mkfs), or think that mounting a partition will automatically create a filesystem on it.

Full explanation →

125

MCQmedium

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

A.The filesystem is not recognized; need to install xfsprogs

B.The partition table is corrupted

C.The filesystem has not been created; mkfs.xfs was not run

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

126

MCQmedium

An administrator receives an alert that a process named 'apache2' is consuming excessive CPU. The administrator needs to identify the PID of the process and then change its priority to the lowest possible value (least favorable scheduling). Which sequence of commands should be used?

A.pidof apache2; renice -n 20 -p <PID>

B.pidof apache2; renice -n 19 -p <PID>

C.ps -C apache2 -o pid=; renice -n -20 -p <PID>

D.ps aux | grep apache2; nice -n 19 <PID>

AnswerB

The pidof apache2 command directly outputs the PID(s) of the apache2 process, which can be passed to renice using -p. The renice -n 19 -p <PID> command sets the niceness of the existing process to 19, the lowest possible priority (often called 'most nice'). This is the correct way to reduce a running process's CPU priority on Linux; note that lowering priority (raising nice value) can be done by the process owner without root.

Why this answer

`pidof apache2` retrieves the PID of the apache2 process, and `renice -n 19 -p <PID>` sets the priority to the lowest possible (least favorable) scheduling value. In Linux, `renice` accepts nice values from -20 (highest priority) to 19 (lowest priority), so 19 is the correct value for the least favorable scheduling.

Exam trap

Red Hat often tests the exact range of nice values (0-19 for non-root users, -20 to 19 for root) and the distinction between `nice` (for starting processes) and `renice` (for changing priority of running processes), leading candidates to confuse the two or use out-of-range values.

How to eliminate wrong answers

Option A is wrong because it uses `renice -n 20`, but the valid nice range is -20 to 19; a value of 20 is out of range and will be rejected or clamped. Option C is wrong because it uses `renice -n -20`, which sets the highest priority (most favorable scheduling), not the lowest. Option D is wrong because `nice` is used to start a new process with a given priority, not to change the priority of an existing process; also, the syntax `nice -n 19 <PID>` is incorrect as `nice` expects a command, not a PID.

Full explanation →

127

MCQhard

Based on the exhibit, what is the most likely cause of the failure?

A.The SSH daemon is already running on another port.

B.Another process is already listening on port 22.

C.The sshd configuration file has a syntax error.

D.The service is not enabled.

AnswerB

This is the correct cause because 'Address already in use' is the standard EADDRINUSE error returned when a process attempts to bind() to a TCP port already held by another socket. Since sshd defaults to listening on port 22, a conflicting process — often a duplicate sshd instance, a misconfigured service, or a leftover listener — prevents the daemon from starting. The exhibit's journalctl output directly matches this failure mode, and the standard diagnostic is to run `ss -tlnp` or `lsof -i :22` to identify the offending PID.

Why this answer

The failure message indicates that the SSH daemon cannot start because port 22 is already in use. Option B is correct because the error 'Address already in use' or 'bind to port 22 failed' directly points to another process occupying the port, preventing sshd from binding. This is a common port conflict scenario, not a configuration syntax or service enablement issue.

Exam trap

The trap here is that candidates may confuse a port conflict with a configuration syntax error or service enablement status, but the specific 'Address already in use' error message uniquely identifies a port binding conflict.

How to eliminate wrong answers

Option A is wrong because the SSH daemon is not already running on another port; the error specifically shows it fails to bind to port 22, implying it is configured for port 22 but cannot acquire it. Option C is wrong because a syntax error in sshd_config would produce a different error, such as 'Parse error' or 'Bad configuration option', not a port binding failure. Option D is wrong because the service not being enabled would not cause a failure at runtime; it would simply not start on boot, but the attempt to start it manually or via systemd would still succeed if no other issue exists.

Full explanation →

128

MCQmedium

A web server is running in enforcing mode with SELinux, but Apache cannot read content in a custom directory /web. The directory has been labeled correctly with httpd_sys_content_t. However, access is still denied. What is the most likely cause?

A.SELinux boolean httpd_enable_homedirs is off.

B.The httpd process is running in permissive mode.

C.The directory has incorrect permissions of 700.

D.The files are labeled with default_t.

AnswerC

A directory mode of 700 grants full permissions only to its owner, which is typically root, while the httpd process runs as the non-owner user apache (or www-data). That places the daemon in the 'other' permission class, which has no read or execute rights, so even an otherwise correct SELinux context and enabling booleans won't help because DAC checks are evaluated first. The fix is to use a mode like 755, or 750 with proper group ownership, so the web server can traverse and read the content.

Why this answer

Even though the SELinux context is correctly set to httpd_sys_content_t, the directory has permissions of 700 (rwx------). This means only the owner (typically root) can read, write, or execute the directory. The Apache httpd process runs as the 'apache' or 'httpd' user, which is not the owner, so it is denied read access.

SELinux enforces its own policy, but DAC (Discretionary Access Control) permissions are checked first; if DAC denies access, SELinux never gets to evaluate the context match.

Exam trap

The trap here is that candidates focus solely on SELinux context and booleans, forgetting that DAC permissions are evaluated first and can block access even when SELinux labels are perfectly correct.

How to eliminate wrong answers

Option A is wrong because the httpd_enable_homedirs boolean controls whether httpd can access user home directories (e.g., /home/*/public_html), not a custom directory like /web. Option B is wrong because the question states the system is running in enforcing mode, and if httpd were permissive, SELinux would log denials but still allow access, so access would not be denied. Option D is wrong because the question explicitly says the directory is labeled correctly with httpd_sys_content_t, not default_t; if files were labeled default_t, SELinux would deny access with an AVC denial, but the problem states the label is correct, so the issue must be DAC permissions.

Full explanation →

129

MCQeasy

Refer to the exhibit. The SSH service has been running for 2 weeks. An administrator wants to restart the service without interrupting existing SSH connections. Which command should they use?

A.systemctl reload sshd

B.systemctl stop sshd; systemctl start sshd

C.kill -HUP 1234

D.systemctl restart sshd

AnswerA

Correct. systemctl reload sshd sends a SIGHUP to the sshd main process via the service unit's ExecReload directive. sshd then reparses /etc/ssh/sshd_config and applies changes (like new ciphers or Port settings) to future connections. Existing sessions are not interrupted because their already-established state and options are preserved, making this the safe way to apply most configuration changes without dropping users.

Why this answer

`systemctl reload sshd` sends a SIGHUP signal to the SSH daemon, instructing it to reload its configuration file without terminating existing connections. This is the standard method for applying configuration changes to services that support graceful reloads, such as sshd, which maintains persistent sessions by only re-reading its configuration and not restarting the process.

Exam trap

The trap here is that candidates confuse `reload` with `restart`, assuming both achieve the same result, but `restart` terminates all active connections while `reload` preserves them, and Red Hat often tests this distinction to catch those who overlook the 'without interrupting' requirement.

How to eliminate wrong answers

Option B is wrong because `systemctl stop sshd; systemctl start sshd` first stops the service, which kills all active SSH sessions, and then starts it again, causing disruption to users. Option C is wrong because `kill -HUP 1234` assumes PID 1234 is the sshd process, but this is unreliable; the PID may change after a restart, and using a hardcoded PID without verification can target the wrong process or fail entirely. Option D is wrong because `systemctl restart sshd` stops the service completely before starting it, which terminates all existing SSH connections, unlike a reload.

Full explanation →

130

Matchingmedium

Match each user/group management command to its function.

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

Concepts

Matches

Create a new user account

Modify an existing user account

Create a new group

Set or change a user's password

Why these pairings

useradd creates users, usermod modifies them, userdel deletes them, and groupadd creates groups. Common confusions arise from similar command names.

Full explanation →

131

MCQhard

An administrator accidentally deleted the group 'sales' which is the primary group of several users. What is the immediate effect on those users?

A.Their files will show a missing GID in directory listings

B.The system will recreate the group automatically

C.Their primary group will be changed to their UID

D.They will be unable to log in

AnswerA

When the sales group is deleted, the group definition is removed from /etc/group, but the GID itself remains in the inode metadata of any files previously owned by that group. The ls command invokes getgrgid() to map that GID back to a group name; when the mapping fails, ls falls back to printing the raw numeric GID. As a result, directory listings show an unresolved numeric GID rather than the name 'sales', while the files themselves remain intact and fully accessible.

Why this answer

When a group is deleted, the system does not retroactively change the GID stored in the /etc/passwd file for users whose primary group was that group. The GID field in /etc/passwd still contains the numeric GID of the deleted group, but since the group no longer exists in /etc/group, the system cannot resolve that GID to a group name. As a result, commands like ls -l will display the numeric GID instead of the group name for files owned by those users, because the GID-to-name mapping fails.

Exam trap

A common misconception is that deleting a group will prevent users from logging in or will automatically reassign their primary group. In Red Hat Enterprise Linux, login is unaffected and the GID remains in /etc/passwd until manually changed, so files will show the numeric GID instead of the group name.

How to eliminate wrong answers

Option B is wrong because Linux does not automatically recreate deleted groups; group management is entirely manual via groupadd, groupdel, and groupmod commands. Option C is wrong because the primary group GID in /etc/passwd remains unchanged; it is not replaced by the user's UID — the UID and GID are independent fields. Option D is wrong because login authentication checks the user's password and shell, not the existence of the primary group; users can still log in even if their primary group is missing.

Full explanation →

132

MCQhard

A system administrator is configuring a new RHEL 9 server with two 500GB SSDs. The requirement: create a 200GB XFS filesystem for /srv/data that is resilient to disk failure. The admin decides to create a RAID 1 (mirror) using mdadm with partitions on each disk: /dev/sda1 and /dev/sdb1, each 200GB. He creates the partitions with fdisk, then runs: mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1. The array is created and synced. He then creates a physical volume, volume group, and logical volume on top of /dev/md0, formats with XFS, and mounts. Later, a disk fails. After replacing the failed disk, he recreates the partition with identical size and runs: mdadm /dev/md0 --add /dev/sdb1. The command fails with 'Device /dev/sdb1 is busy'. What is the most likely cause?

A.The replacement disk was not initialized with an mdadm superblock before adding.

B.The kernel still sees the old partition table; need to run partprobe to reread the partition table.

C.The /dev/md0 array is still in a clean state and does not need the disk yet.

D.The /dev/sdb1 partition is already part of another md array.

AnswerB

After you create a new partition table entry on /dev/sdb, the kernel keeps using the old partition layout cached in memory. Running partprobe (or partx -a) forces a re-read of the partition table so that /dev/sdb1 actually appears. Without this step, mdadm will report that the partition does not exist, even though it is visible in fdisk output.

Why this answer

After replacing a failed disk and recreating the partition, the kernel's in-memory partition table still reflects the old state. The `mdadm --add` command fails with 'Device busy' because the kernel sees the old partition layout and may still hold references to the old partition. Running `partprobe` (or `partx -a`) forces the kernel to reread the partition table from the disk, clearing the stale state and allowing the new partition to be added to the RAID array.

Exam trap

The trap here is that candidates often assume the 'Device busy' error means the disk is already in use by another array or process, when in fact it is a stale partition table cache that prevents the kernel from recognizing the new partition.

How to eliminate wrong answers

Option A is wrong because mdadm does not require a separate superblock initialization on the replacement partition; the `--add` command will write the superblock automatically when the partition is added to the array. Option C is wrong because even if the array is in a clean state (e.g., degraded but functional), it still accepts a new disk to restore redundancy; the 'Device busy' error is unrelated to array state. Option D is wrong because there is no indication that /dev/sdb1 is part of another array; the error is due to the kernel's stale partition table, not membership in another md device.

Full explanation →

133

MCQeasy

Which file contains the list of filesystems to be mounted at system startup?

A./etc/fstab

B./etc/rc.local

C./etc/filesystems

D./etc/mtab

AnswerA

/etc/fstab is the correct answer because it is the system's permanent filesystem table. Each line defines a filesystem to be mounted at boot, specifying the device or UUID, the mount point, the filesystem type, mount options, and dump/fsck flags. The systemd mount mechanism and the mount -a command both read this file to bring up all persistent filesystems. Without /etc/fstab, manually configured mounts would be lost after every reboot, so this file is the canonical location for mount definitions.

Why this answer

The /etc/fstab file is the system configuration file that defines static filesystem information, including devices, mount points, filesystem types, mount options, dump frequency, and fsck pass order. During system startup, the mount -a command (typically run by systemd or init scripts) reads /etc/fstab to mount all filesystems listed there, making it the definitive source for automatic mounting at boot.

Exam trap

Red Hat often tests the distinction between /etc/fstab (static boot-time configuration) and /etc/mtab (dynamic current mount state), leading candidates to confuse the two because both contain mount information.

How to eliminate wrong answers

Option B is wrong because /etc/rc.local is a legacy script executed at the end of the boot process for custom commands, not a file that lists filesystems to be mounted; it is not read by the mount command for automatic mounting. Option C is wrong because /etc/filesystems is a deprecated file that lists supported filesystem types (e.g., ext4, xfs) for the mount command to probe, not a list of filesystems to mount at startup. Option D is wrong because /etc/mtab is a dynamically updated file showing currently mounted filesystems, maintained by the mount command, and is not used for boot-time mounting; it is often a symlink to /proc/mounts on modern systems.

Full explanation →

134

MCQhard

A server has a software RAID 5 array /dev/md0. One of its disks fails. The administrator wants to replace it without rebooting. Which command should be used to mark the disk as failed?

A.mdadm --fault /dev/md0 /dev/sdb

B.echo faulty > /sys/block/md0/md/dev-sdb/state

C.mdadm --set-faulty /dev/md0 /dev/sdb

D.mdadm --fail /dev/md0 /dev/sdb

AnswerD

This is the correct command: mdadm --manage --fail /dev/md0 /dev/sdb (the --manage action is implicit when using --fail) marks /dev/sdb as faulty in the RAID 5 array /dev/md0. Once marked, mdadm removes the device from the active array, and the array continues operating in a degraded state because RAID 5 tolerates a single disk failure. You can then remove the failed disk (mdadm --remove) and replace it (mdadm --add) to rebuild redundancy, which is the proper workflow for handling a failing disk.

Why this answer

The correct command to mark a disk as failed in a software RAID array without rebooting is `mdadm --fail /dev/md0 /dev/sdb`. This command tells the md driver to mark the specified disk as faulty, which triggers the RAID 5 array to degrade and allows the failed disk to be removed and replaced while the system remains online.

Exam trap

The trap here is that candidates confuse the valid `--fail` option with the non-existent `--fault` or `--set-faulty` options, or they incorrectly think the sysfs method is the standard command-line approach expected in the EX200 exam.

How to eliminate wrong answers

Option A is wrong because `mdadm --fault` is not a valid mdadm option; the correct option is `--fail` or `--set-faulty`. Option B is wrong because while writing 'faulty' to the sysfs attribute `/sys/block/md0/md/dev-sdb/state` can mark a disk as faulty, the correct string to write is 'faulty' (not 'faulty' with a typo, but the path uses 'dev-sdb' which is correct; however, the syntax shown is a valid alternative, but the question asks for the command, and this is a sysfs manipulation, not the standard mdadm command expected in the EX200 exam). Option C is wrong because `mdadm --set-faulty` is not a valid mdadm option; the correct option is `--fail`.

Full explanation →

135

MCQhard

Refer to the exhibit. An administrator sees that a user from 192.168.1.101 cannot connect to the SSH server. Based on the log, what is the most probable cause?

A.The client's host key type is not supported by the server

B.The server's firewall is blocking the connection

C.The SSH service is not running

D.The client's IP is blacklisted

AnswerA

The SSH handshake fails during algorithm negotiation because the server's list of acceptable host key algorithms (as sent in its SSH_MSG_KEXINIT) does not include the type the client offers, such as ssh-rsa or ssh-ed25519. This produces a 'no matching host key type' error before any authentication, which is exactly the negotiation failure recorded in the log. The server does not reject the client's credentials or IP; it cannot even complete the transport layer handshake.

Why this answer

The log shows 'no matching host key type found. Their offer: ssh-rsa'. This indicates the client offered an ssh-rsa host key, but the server's configuration (likely via the `HostKeyAlgorithms` directive in `/etc/ssh/sshd_config`) does not include ssh-rsa.

In modern OpenSSH (e.g., RHEL 8/9), ssh-rsa is often disabled by default due to its reliance on SHA-1, which is considered weak. The server requires a different host key type (e.g., rsa-sha2-256, rsa-sha2-512, or ecdsa-sha2-nistp256), causing the connection to fail before authentication even begins.

Exam trap

The RHCSA exam often tests the distinction between authentication failures (e.g., wrong password or key) and key exchange failures (e.g., unsupported host key algorithm), leading candidates to mistakenly blame firewall rules or service status when the log clearly points to a cryptographic algorithm mismatch.

How to eliminate wrong answers

Option B is wrong because a firewall block would typically result in a timeout or 'Connection refused' error, not a host key algorithm mismatch log entry. Option C is wrong because if the SSH service were not running, the client would receive a 'Connection refused' message, not a host key negotiation failure. Option D is wrong because an IP blacklist (e.g., via `DenyUsers` or `Match Address` in sshd_config) would reject the connection after authentication or with a 'Permission denied' message, not during the key exchange phase.

Full explanation →

136

MCQeasy

Which file contains the hashed passwords for local user accounts?

A./etc/security/passwd

B./etc/passwd

C./etc/shadow

D./etc/gshadow

AnswerC

The /etc/shadow file is the correct location for hashed passwords of local users on RHEL. It is readable only by root (and members of the shadow group) and stores each user's password hash, along with password aging information such as last change, minimum and maximum days, and expiration warning. The 'x' in /etc/passwd references this file for the actual hash.

Why this answer

The /etc/shadow file stores hashed passwords for local user accounts, along with password aging and expiration information. It is readable only by root (or privileged processes) to prevent unauthorized access to password hashes, unlike /etc/passwd which is world-readable.

Exam trap

Red Hat often tests the distinction between /etc/passwd (world-readable, stores user info but not hashes) and /etc/shadow (restricted, stores hashes), exploiting the common misconception that passwords are still in /etc/passwd.

How to eliminate wrong answers

Option A is wrong because /etc/security/passwd does not exist in standard Linux; it may be confused with /etc/security/opasswd (used by pam_pwhistory) or /etc/security/limits.conf, but none store hashed passwords. Option B is wrong because /etc/passwd historically stored password hashes but now uses an 'x' placeholder; it is world-readable and would expose hashes, so modern systems moved hashes to /etc/shadow. Option D is wrong because /etc/gshadow stores hashed passwords for group accounts (for group administrators), not for local user accounts.

Full explanation →

137

MCQeasy

A user needs to view the last 15 lines of a log file that is constantly being updated. Which command should they use?

A.tail -n 15 /var/log/messages

B.tail -f /var/log/messages

C.cat /var/log/messages

D.head -15 /var/log/messages

AnswerA

tail -n 15 /var/log/messages is correct because tail reads from the end of a file, and the -n 15 flag limits output to exactly the last 15 lines. Unless told otherwise, tail prints the final 10 lines; -n overrides this default to match the requested count. The command then exits, providing a clean, one-time snapshot of the most recent entries in the system log.

Why this answer

The `tail -n 15 /var/log/messages` command displays the last 15 lines of the specified log file without following it. This meets the requirement to view the last 15 lines of a file that is constantly being updated, as it provides a static snapshot of the most recent entries.

Exam trap

The trap here is that candidates often confuse `tail -f` (which follows the file in real time) with `tail -n` (which shows a specific number of lines from the end), leading them to choose option B when the requirement is for a static view of the last lines.

How to eliminate wrong answers

Option B is wrong because `tail -f /var/log/messages` continuously follows the file, displaying new lines as they are appended, which does not limit the output to the last 15 lines and is not suitable for a one-time view. Option C is wrong because `cat /var/log/messages` outputs the entire file content, which is impractical for viewing only the last 15 lines, especially in a large log file. Option D is wrong because `head -15 /var/log/messages` displays the first 15 lines, not the last 15 lines, which is the opposite of what the user needs.

Full explanation →

138

MCQeasy

A critical service must restart automatically after a crash. Which systemd directive should be added to the [Service] section of the service unit file?

A.OnFailure=

B.Requires=

C.Restart=always

D.Wants=

AnswerC

Restart=always is the correct systemd directive for automatically restarting a service after it exits, regardless of the exit status. Placed in the [Service] section, it tells systemd to unconditionally restart the process, covering crashes, normal exits, and signals. This provides a high degree of availability, though it may also restart after intentional stops; more granular control can be achieved with variants like Restart=on-failure.

Why this answer

The `Restart=always` directive in the `[Service]` section of a systemd unit file instructs systemd to automatically restart the service whenever it exits, regardless of the exit status. This ensures the critical service recovers immediately after a crash without manual intervention, which is essential for high-availability requirements.

Exam trap

The trap here is that candidates often confuse dependency directives like `Requires=` or `Wants=` with restart behavior, but systemd separates dependency management from process supervision, so only `Restart=` controls automatic restart after a crash.

How to eliminate wrong answers

Option A is wrong because `OnFailure=` is used to specify a unit (e.g., a script or another service) to activate when the service fails, not to restart the service itself. Option B is wrong because `Requires=` declares a strong dependency that the service must be started with the required unit, but it does not handle automatic restart after a crash. Option D is wrong because `Wants=` is a weaker dependency that only attempts to start the listed unit without enforcing it, and it has no effect on restart behavior after a crash.

Full explanation →

139

MCQmedium

A user reports that the Apache web server cannot serve the file /var/www/html/index.html on a RHEL 9 system when SELinux is in enforcing mode. Given the exhibit output, what is the most likely cause?

A.The firewalld service is blocking HTTP traffic on port 80.

B.The file is owned by root and Apache cannot read it.

C.The file permissions do not allow the apache user to read the file.

D.The SELinux context of the file is incorrect for web serving.

AnswerD

The SELinux context user_home_t is intended for files in user home directories, and the httpd_t domain is not allowed to read files with that type by default. Even with correct Unix permissions, Apache will receive a permission denial from SELinux because the file is not labeled with a type such as httpd_sys_content_t or public_content_t. This is a classic SELinux mislabeling problem, easily verified with ls -Z and fixed with restorecon or semanage fcontext.

Why this answer

The default SELinux context for files served by Apache in /var/www/html is `httpd_sys_content_t`. If the file has a different context (e.g., `unconfined_u:object_r:admin_home_t:s0`), SELinux will deny Apache read access even if standard Linux permissions are permissive. The `ls -Z` output would reveal the mismatch, and `restorecon -v /var/www/html/index.html` would fix it.

Exam trap

The trap here is that candidates often focus on file permissions or ownership (options B and C) because they are familiar from non-SELinux systems, but the question explicitly states SELinux is in enforcing mode, which overrides DAC permissions when a type mismatch exists.

How to eliminate wrong answers

Option A is wrong because firewalld blocking HTTP traffic would prevent remote clients from reaching the server, but the user reports the server cannot serve the file locally, and SELinux enforcing mode is the stated condition. Option B is wrong because file ownership by root does not inherently prevent Apache from reading it; Apache runs as the apache user and can read files owned by root if permissions allow (e.g., 644). Option C is wrong because the exhibit output (not shown here but implied) would show standard permissions like 644, which grant read access to the apache user; the issue is SELinux, not DAC permissions.

Full explanation →

140

Multi-Selectmedium

Which TWO commands can be used to check the UUID of a filesystem on /dev/sda1?

Select 2 answers

A.e2label /dev/sda1

B.findmnt /dev/sda1

C.lsblk -o UUID /dev/sda1

D.blkid /dev/sda1

E.file -s /dev/sda1

AnswersC, D

lsblk -o UUID /dev/sda1 is correct because lsblk enumerates block devices and can output any column you request, including UUID. This works without mounting the filesystem and is a direct, efficient way to list the UUID for a specific device like /dev/sda1.

Why this answer

The `blkid` command directly queries the UUID of a block device from the libblkid cache or by reading the filesystem superblock, and `lsblk -o UUID` filters the lsblk output to show only the UUID column for the specified device. Both commands reliably retrieve the UUID of /dev/sda1.

Exam trap

The trap here is that candidates confuse `e2label` (which only handles labels) with UUID retrieval, or assume `findmnt` shows UUIDs by default when it actually requires explicit column selection.

Full explanation →

141

MCQeasy

Refer to the exhibit. An administrator runs lsblk and sees the above output. The administrator wants to mount /dev/sdb1 at /mnt/data. What should be done first?

A.Create the directory /mnt/data and then run mount

B.Run mount /dev/sdb1 /mnt/data

C.Run partprobe to detect the partition

D.Run mkfs.xfs /dev/sdb1

E.Edit /etc/fstab and add an entry

AnswerA

The mount point directory must exist as a directory in the current root filesystem before any device can be attached to it. Creating /mnt/data with mkdir provides that directory, after which mount /dev/sdb1 /mnt/data associates the block device's filesystem with that path. Without this step, the kernel has no inode to anchor the mounted filesystem to, and the mount syscall will fail with ENOENT.

Why this answer

Before mounting a filesystem, the mount point directory must exist. Option A correctly instructs to create /mnt/data with mkdir -p /mnt/data and then run mount /dev/sdb1 /mnt/data. Without the directory, the mount command will fail with a 'mount point does not exist' error.

Exam trap

Red Hat often tests the prerequisite of creating the mount point directory, tricking candidates who assume mount will create it automatically or who jump to formatting or fstab editing without verifying the directory exists.

How to eliminate wrong answers

Option B is wrong because it attempts to mount to a non-existent directory /mnt/data, which will fail. Option C is wrong because partprobe is used to inform the kernel of partition table changes, but the partition /dev/sdb1 already appears in lsblk output, so it is already detected. Option D is wrong because mkfs.xfs would create a new filesystem, potentially destroying existing data; the question only asks to mount the partition, not format it.

Option E is wrong because editing /etc/fstab is for persistent mounts across reboots, but the immediate step before mounting is to ensure the mount point exists.

Full explanation →

142

MCQhard

A user executes the script shown in the exhibit with './export_script.sh' and then runs 'echo $MY_VAR' in the same terminal. The output is empty. Why does this happen?

A.The script lacks execute permissions

B.The script runs in a sub-shell, so exported variables are not available to the parent shell

C.The 'export' command is incorrectly placed after the variable assignment

D.The variable name should be in uppercase for it to be inherited

AnswerB

When you execute a script by name or with ./script, the kernel starts a new shell process (child) with its own copy of the parent's environment. The export builtin marks VARIABLE for inheritance by that child, but any assignments or exports made inside the script modify only the child's environment, which is discarded when the script exits. Therefore the exported variable never appears in the parent shell, even though it is available to programs launched within the script. This is the fundamental process isolation you are observing.

Why this answer

When a script is executed with './export_script.sh', it runs in a sub-shell (a child process). The 'export' command within the script makes the variable available to that sub-shell and its own child processes, but not to the parent shell that invoked the script. Therefore, after the script exits, the variable MY_VAR is not defined in the parent shell's environment, resulting in an empty output from 'echo $MY_VAR'.

Exam trap

The trap here is that candidates often confuse 'export' with making a variable globally available across all shells, not realizing that export only propagates to child processes, not to the parent shell that executed the script.

How to eliminate wrong answers

Option A is wrong because if the script lacked execute permissions, the './export_script.sh' command would fail with a 'Permission denied' error, not produce an empty output after the script runs. Option C is wrong because the placement of 'export' after the variable assignment (e.g., MY_VAR=value; export MY_VAR) is syntactically correct and does not affect the variable's export status; the issue is the sub-shell boundary, not the order of commands. Option D is wrong because variable names in bash are case-sensitive but can be any case; uppercase is a convention for environment variables but not a requirement for inheritance—lowercase variables can be exported and inherited just as well.

Full explanation →

143

MCQmedium

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

A.The directory /mnt/nfs does not exist

B.The 'defaults' option does not include '_netdev'

C.The filesystem type should be 'nfs4'

D.The NFS server is unreachable

AnswerA

The error explicitly states the mount point is missing, so the NFS export path is irrelevant until the local directory exists. Creating /mnt/nfs with mkdir -p satisfies the mount point requirement, after which mount -a will succeed provided the server is reachable and the export is permitted.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

144

MCQeasy

A system administrator has created a new group named 'ops'. The administrator wants to add the existing user 'alice' to this group as a supplementary group without affecting her current group memberships. Which command should be used?

A.usermod -aG ops alice

B.usermod -G ops alice

C.groupadd ops alice

D.usermod -g ops alice

AnswerA

usermod -aG ops alice explicitly appends alice to the supplementary group ops while preserving any existing supplementary group memberships. The -a (append) flag works in conjunction with -G (supplementary groups) to add the specified group to the user's current group set rather than replacing it. This is the correct, non-destructive way to grant a user access to an additional secondary group.

Why this answer

The `-a` (append) flag combined with `-G` (supplementary groups) in `usermod` adds the user 'alice' to the 'ops' group without removing her from any existing supplementary groups. Without `-a`, the `-G` flag alone would replace the user's current supplementary group list with only the specified groups, which would remove her from any other groups she already belongs to.

Exam trap

The trap here is that candidates often forget the `-a` flag and choose `usermod -G ops alice`, mistakenly thinking it adds the user to the group, when in fact it replaces all supplementary group memberships.

How to eliminate wrong answers

Option B is wrong because `usermod -G ops alice` without the `-a` flag sets the user's supplementary groups to exactly 'ops', overwriting and removing all other supplementary group memberships. Option C is wrong because `groupadd` creates a new group, not a user; the syntax `groupadd ops alice` is invalid and would fail or be misinterpreted. Option D is wrong because `usermod -g ops alice` changes the user's primary group (the group listed in /etc/passwd) to 'ops', not a supplementary group, and would alter the default group ownership for files created by alice.

Full explanation →

145

Multi-Selectmedium

An administrator is configuring a new filesystem for a database server that requires high performance and reliability. Which two features should be considered when choosing between ext4 and XFS? (Choose two.)

Select 2 answers

A.Ext4 supports larger files than XFS

B.XFS is optimized for parallel I/O

C.Ext4 has better online resizing capabilities

D.Ext4 supports subvolume snapshots

E.XFS has robust metadata integrity features

AnswersB, E

XFS's on-disk structures, particularly its multiple allocation groups and B-tree-based extent maps, allow concurrent allocations and reads/writes to different file regions without a single global lock. This makes XFS scale nearly linearly with CPU count and mixed parallel workloads, which is exactly what a database server with many concurrent sessions demands. The allocation group design is the key reason XFS outperforms ext4 on parallel I/O patterns.

Why this answer

B is correct because XFS is designed for high-performance, parallel I/O workloads, using allocation groups that allow concurrent operations, making it ideal for database servers. E is correct because XFS employs checksums in its metadata (since RHEL 7) and self-healing capabilities via the reflink feature, providing robust integrity against corruption.

Exam trap

Red Hat often tests the misconception that ext4 is superior for all general-purpose workloads, but the trap here is that candidates overlook XFS's parallel I/O optimization and metadata integrity features, which are specifically required for high-performance database servers.

Full explanation →

146

MCQhard

Which of the following is true regarding shrinking logical volumes?

A.You can reduce a volume while it is mounted if you use resize2fs

B.XFS filesystems cannot be shrunk

C.Reducing an LVM volume is a simple process

D.Ext4 filesystems support online shrinking

AnswerB

XFS was architecturally designed for high scalability and only supports growing a filesystem, not shrinking it. The extent-based B-tree structure and lack of any shrink mechanism in the on-disk format make reducing an XFS filesystem impossible even when unmounted. This is why a logical volume with XFS must be backed up and recreated at a smaller size if space needs to be reclaimed.

Why this answer

B is correct because XFS filesystems do not support shrinking. The XFS design is based on allocation groups and a log-structured metadata layout that makes online or offline shrinking infeasible without significant filesystem restructuring. This is a fundamental limitation of XFS, unlike ext4 which can be shrunk offline.

Exam trap

Red Hat often tests the misconception that all filesystems can be shrunk similarly, but the trap here is that XFS is fundamentally unshrinkable, and candidates confuse online resizing (which XFS supports for growth) with shrinking.

How to eliminate wrong answers

Option A is wrong because resize2fs can only shrink ext2/3/4 filesystems while unmounted; shrinking a mounted ext4 filesystem is not supported and will cause corruption. Option C is wrong because reducing an LVM volume is not a simple process; it requires multiple steps: unmounting the filesystem, running fsck, shrinking the filesystem with resize2fs (for ext4), then reducing the logical volume with lvreduce, and finally remounting. Option D is wrong because ext4 filesystems do not support online shrinking; they can only be shrunk when unmounted, and resize2fs requires the filesystem to be offline for shrink operations.

Full explanation →

147

MCQhard

A system administrator wants to allow user 'jdoe' to execute any command as root via sudo without being prompted for a password, but only from the host 'client1.example.com'. Which sudoers rule achieves this?

A.jdoe client1.example.com=(root) NOPASSWD: ALL

B.jdoe client1.example.com=(root) ALL

C.jdoe ALL=(root) NOPASSWD: ALL

D.jdoe ALL=(root) ALL

AnswerA

This is the correct rule. It confines the privilege to client1.example.com, specifies that commands run as root via (root), and uses the NOPASSWD tag so jdoe is not prompted for a password. The syntax exactly matches the sudoers grammar: user host_list = (runas) TAG: command_list, so it satisfies the requirement without unnecessary wildcards.

Why this answer

The sudoers rule 'jdoe client1.example.com=(root) NOPASSWD: ALL' specifies the user 'jdoe', the host 'client1.example.com' as the source host from which the command is run, the target user '(root)', the NOPASSWD tag to skip password authentication, and the command 'ALL' to allow any command. This matches the requirement exactly: passwordless root access restricted to a specific client host.

Exam trap

The trap here is that candidates often forget the NOPASSWD tag when passwordless access is required, or they use 'ALL' for the host list instead of specifying the exact hostname, assuming 'ALL' means 'all commands' rather than 'all hosts'.

How to eliminate wrong answers

Option B is wrong because it omits the NOPASSWD tag, so 'jdoe' would still be prompted for a password when running sudo commands from client1.example.com. Option C is wrong because it uses 'ALL' as the host specification, allowing the rule to apply from any host, not just client1.example.com. Option D is wrong because it both omits the NOPASSWD tag and uses 'ALL' for the host, allowing password-protected sudo from any host.

Full explanation →

148

Multi-Selecteasy

Which two commands can be used to create a new partition on a disk without erasing existing partitions? (Choose two.)

Select 2 answers

A.mkswap

B.fdisk

C.dd

D.parted

E.wipefs

AnswersB, D

fdisk is an interactive partitioning utility that can create new partitions by manipulating the partition table on a disk such as /dev/sda. Using its interactive 'n' command, you specify a partition type and size, then use 'w' to write the new partition table entry. It supports MBR and, in modern versions, GPT, making it a correct tool for creating partitions.

Why this answer

The `fdisk` command is a disk partitioning tool that allows you to create, delete, and modify partitions on a disk without erasing existing partitions, as long as there is unallocated space. It operates on the MBR or GPT partition table and writes changes only when explicitly saved, preserving existing partition entries.

Exam trap

The trap here is that candidates may confuse `mkswap` or `wipefs` as partition-creation tools because they are commonly used in storage setup workflows, but neither actually creates a partition entry in the partition table.

Full explanation →

149

MCQmedium

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

A.The administrator used the -b size=1024 option.

B.The block size setting was ignored due to a kernel limitation.

C.The default block size for XFS is 1024 bytes.

D.The partition size is less than 1GB, so mkfs.xfs automatically used a 1024-byte block size.

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

150

Multi-Selectmedium

Which THREE commands are used to manage SELinux file security contexts? (Select exactly three.)

Select 3 answers

A.setenforce

B.chcon

C.selinux

D.semanage fcontext

E.restorecon

AnswersB, D, E

chcon is the direct, immediate way to change the SELinux context of an existing file or directory by explicitly specifying a context, such as 'chcon -t httpd_sys_content_t /var/www/html/index.html'. It writes the new security.selinux extended attribute value on the file itself, which makes the change take effect right away without a policy reload. However, chcon does not update the persistent SELinux policy mappings, so the label can be lost if restorecon is later run or the filesystem is relabeled.

Why this answer

B (chcon) is correct because it changes the SELinux security context of a file or directory immediately, without reference to the SELinux policy database. This is useful for temporary or one-off changes, but the context may be overwritten by restorecon or a file system relabel.

Exam trap

Red Hat frequently tests the distinction between commands that modify the running SELinux file context (chcon), commands that modify the policy defaults (semanage fcontext), and commands that restore contexts from policy (restorecon). Candidates often confuse 'setenforce' (which controls SELinux enforcing/permissive mode) with context management commands.

Full explanation →

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