Courseiva

CCNA Deploy, configure, and maintain systems Questions

57 questions · Deploy, configure, and maintain systems · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

A system administrator needs to ensure that a web server running Apache httpd starts automatically after a system reboot. Which command should the administrator use to enable the httpd service?

A.systemctl daemon-reload
B.systemctl start httpd
C.systemctl reenable httpd
D.systemctl enable httpd
AnswerD

systemctl enable httpd creates the systemd symlinks that pull the httpd unit into the boot target, so the service starts automatically at reboot. It satisfies the persistence requirement without starting the service immediately, unlike systemctl start.

Why this answer

`systemctl enable httpd` creates the necessary symlinks in the systemd unit configuration directories (e.g., `/etc/systemd/system/multi-user.target.wants/`) to ensure the httpd service starts automatically at boot. This is the standard method for enabling a service in a Red Hat Enterprise Linux 8/9 environment using systemd.

Exam trap

The trap here is that candidates confuse `systemctl start` (immediate runtime start) with `systemctl enable` (persistent boot-time activation), or they invent a non-existent command like `systemctl reenable` instead of using the correct `systemctl enable`.

How to eliminate wrong answers

Option A is wrong because `systemctl daemon-reload` reloads the systemd manager configuration, scanning for new or changed unit files, but does not enable any service for automatic startup. Option B is wrong because `systemctl start httpd` immediately starts the service in the current session but does not configure it to persist across reboots. Option C is wrong because `systemctl reenable httpd` is not a valid systemd command; the correct command to re-enable a service is `systemctl enable httpd` (which is idempotent) or `systemctl disable httpd` followed by `systemctl enable httpd`.

Practice this question →
2
MCQhard

Refer to the exhibit. A web server must also accept HTTPS traffic on port 8443. Which command should the administrator run to permanently open this port?

A.firewall-cmd --add-service=8443/tcp --permanent
B.firewall-cmd --add-port=8443/tcp
C.firewall-cmd --add-port=8443/tcp --permanent && firewall-cmd --reload
D.firewall-cmd --add-port=8443/tcp --zone=public
AnswerC

This correctly adds TCP port 8443 to the persistent configuration of the default zone and then reloads firewalld to make the permanent rule active without restarting services. The --permanent flag writes the rule to the zone's permanent config (e.g., /etc/firewalld/zones/public.xml), and --reload re-applies that config cleanly. This is the proper way to expose a non-standard HTTPS port.

Why this answer

It uses `--add-port=8443/tcp` to open a non-standard port (8443) for HTTPS traffic, applies the `--permanent` flag to persist the rule across reboots, and then runs `--reload` to activate the change immediately without restarting the firewall service. Without `--reload`, the permanent rule would not take effect until the next firewall reload or system restart.

Exam trap

The trap here is that candidates often forget the `--permanent` flag or the `--reload` step, assuming that adding a port with `--add-port` alone is sufficient to make it persistent, or they mistakenly use `--add-service` with a port number instead of a service name.

How to eliminate wrong answers

Option A is wrong because `--add-service` expects a predefined service name (e.g., 'https'), not a port/protocol string like '8443/tcp'; it would fail or create an invalid rule. Option B is wrong because it omits `--permanent`, so the rule is only added to the runtime configuration and will be lost after a reboot or firewall reload. Option D is wrong because it lacks `--permanent` and does not include `--reload`, meaning the rule is temporary and not activated in the current runtime; additionally, specifying `--zone=public` is unnecessary here as the default zone is already public.

Practice this question →
3
MCQhard

A RHEL 9 system has a second disk /dev/sdb that needs to be partitioned with a single partition using all space, formatted with XFS, and mounted persistently at /data. The administrator uses fdisk to create the partition /dev/sdb1. Which filesystem creation command should be used?

A.mkfs.xfs /dev/sdb1
B.mke2fs /dev/sdb1
C.mkfs -t ext4 /dev/sdb1
D.mkfs.ext4 /dev/sdb1
AnswerA

mkfs.xfs is the correct command because it explicitly initializes an XFS filesystem on the target partition. XFS is the default filesystem in RHEL 9 for root and many standard partitions, and this invocation creates the required on-disk structure, including the superblock, allocation groups, and B+tree metadata. After running this command, the partition can be mounted and used as an XFS volume.

Why this answer

The correct command is mkfs.xfs /dev/sdb1 because the question specifies that the partition must be formatted with XFS. The mkfs.xfs command is the dedicated tool for creating an XFS filesystem on a block device. It directly invokes the mkfs.xfs utility, which writes the XFS superblock and metadata structures to the partition.

Exam trap

The trap here is that candidates often confuse mkfs.xfs with generic mkfs commands or ext-family tools, assuming any mkfs variant will work, but the exam specifically tests knowledge of the correct filesystem-specific command for XFS.

How to eliminate wrong answers

Option B is wrong because mke2fs is a legacy command for creating ext2/ext3/ext4 filesystems, not XFS. Option C is wrong because mkfs -t ext4 creates an ext4 filesystem, not XFS. Option D is wrong because mkfs.ext4 is a convenience wrapper for creating ext4 filesystems, not XFS.

Practice this question →
4
MCQeasy

A user reports that they cannot start a service. Which command would an administrator use to view the service's journal logs since last boot?

A.journalctl -b
B.journalctl -u service -b
C.journalctl service
D.dmesg | grep service
AnswerB

Running `journalctl -u service -b` combines the `--unit` filter with the `--boot` option, instructing systemd's journal to display only log records belonging to the specified service unit within the current boot cycle. This is the precise diagnostic command because it isolates the service's own output, errors, and exit status messages. It also automatically appends `.service` to the name if omitted, making it the recommended method for checking why a service failed to start.

Why this answer

`journalctl -u service -b` combines the `-u` flag to filter logs for a specific systemd unit (the service) with the `-b` flag to show only logs from the current boot. This is the precise command an administrator would use to view a service's journal logs since the last system start, directly addressing the user's inability to start the service.

Exam trap

The trap here is that candidates often forget the `-u` flag is mandatory to filter for a specific service unit, mistakenly thinking `journalctl service` is valid, or they confuse `journalctl -b` (all logs since boot) with the more targeted command needed for service-specific troubleshooting.

How to eliminate wrong answers

Option A is wrong because `journalctl -b` shows all journal logs since the last boot, but without the `-u` flag it does not filter for a specific service, making it impractical for troubleshooting a single service. Option C is wrong because `journalctl service` is invalid syntax; `journalctl` requires the `-u` flag to specify a unit name, otherwise it treats 'service' as a non-existent option or argument. Option D is wrong because `dmesg | grep service` displays kernel ring buffer messages, which are primarily hardware and driver-related, not the detailed service logs from systemd-journald, and it does not filter by boot session.

Practice this question →
5
MCQmedium

A junior system administrator configures rsyslog on a RHEL 9 server to forward logs to a remote centralized log server. They add the line *.* @192.168.1.100:514 to /etc/rsyslog.conf and restart rsyslog with systemctl restart rsyslog. Local logging works fine, but the remote server does not receive any logs. The administrator checks the local firewall and confirms that UDP port 514 is open outbound. They also verify network connectivity using nc. What is the most likely cause?

A.The systemd unit for rsyslog is masked, preventing it from running.
B.The remote rsyslog server is not listening on UDP port 514.
C.The SELinux boolean rsyslog_remote is disabled, blocking outbound syslog.
D.The configuration should use @@ for TCP instead of @ for UDP.
AnswerC

On RHEL 9, SELinux ships with the rsyslog_remote boolean disabled by default, which prevents rsyslogd from making outbound TCP/UDP connections to a central log server. Even with a correct rsyslog action line (e.g., *.* @192.0.2.10:514), SELinux will silently drop the packet and log an AVC denial in /var/log/audit/audit.log. Enabling the boolean with `setsebool -P rsyslog_remote 1` allows rsyslog to send syslog messages over the network, making this the correct fix when the service restarts normally but no logs arrive at the remote server.

Why this answer

On RHEL 9, SELinux enforces a targeted policy that blocks rsyslog from making outbound network connections by default. The boolean `rsyslog_remote` controls this behavior; when disabled, SELinux denies the outbound syslog traffic even though the local firewall allows it. The administrator must enable this boolean with `setsebool -P rsyslog_remote on` to allow rsyslog to forward logs via UDP or TCP.

Exam trap

The trap here is that candidates focus on network-level troubleshooting (firewall, connectivity) and overlook SELinux, which is a mandatory access control layer that can block outbound connections even when the firewall is open.

How to eliminate wrong answers

Option A is wrong because if the systemd unit for rsyslog were masked, the `systemctl restart rsyslog` command would fail with an error, and local logging would not work. Option B is wrong because the administrator verified network connectivity with `nc`, which would fail if the remote server were not listening on UDP 514, and the question states local logging works fine, implying the remote server is reachable. Option D is wrong because the `@` directive correctly specifies UDP transport; using `@@` would switch to TCP, which is not required and would not fix the SELinux block.

Practice this question →
6
Drag & Dropmedium

Order the steps to configure SELinux to allow Apache to read files in a custom directory /webcontent.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

SELinux configuration involves setting proper file context for Apache to access custom directories.

Practice this question →
7
MCQhard

A Red Hat Enterprise Linux 9 system has a logical volume 'lv_data' in the volume group 'vg_data' that needs to be resized from 10G to 15G. The underlying physical volumes have enough free space. Which sequence of commands correctly resizes the logical volume and the ext4 filesystem?

A.lvextend -L 15G /dev/vg_data/lv_data; resize2fs /dev/vg_data/lv_data
B.resize2fs /dev/vg_data/lv_data; lvextend -L 15G /dev/vg_data/lv_data
C.lvextend -L 15G /dev/vg_data/lv_data; xfs_growfs /dev/vg_data/lv_data
D.lvreduce -L 15G /dev/vg_data/lv_data; resize2fs /dev/vg_data/lv_data
AnswerA

lvextend -L 15G /dev/vg_data/lv_data; resize2fs /dev/vg_data/lv_data — This is the correct order. lvextend first expands the logical volume by adding physical extents from the volume group, making a larger block device available to the filesystem. Only after that can resize2fs safely grow the ext4 filesystem into the newly available space; attempting filesystem growth first would have no extra capacity to claim.

Why this answer

To resize an ext4 filesystem on a logical volume, you must first extend the logical volume with `lvextend -L 15G /dev/vg_data/lv_data` to allocate the additional 5G from the volume group, then use `resize2fs /dev/vg_data/lv_data` to grow the filesystem to fill the enlarged block device. This order ensures the underlying block device has sufficient capacity before the filesystem resize operation.

Exam trap

The trap here is that candidates often confuse the filesystem-specific resize commands, mistakenly using `xfs_growfs` for ext4 (option C) or reversing the order of operations (option B), failing to recognize that LVM resizing must precede filesystem resizing.

How to eliminate wrong answers

Option B is wrong because `resize2fs` is run before `lvextend`, which would fail as the filesystem cannot be resized beyond the current logical volume size of 10G. Option C is wrong because `xfs_growfs` is used for XFS filesystems, not ext4; using it on an ext4 filesystem would either fail or produce incorrect results. Option D is wrong because `lvreduce` shrinks the logical volume, which is the opposite of the required operation (resizing from 10G to 15G), and would reduce capacity instead of increasing it.

Practice this question →
8
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.

Practice this question →
9
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.

Practice this question →
10
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.

Practice this question →
11
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.

Practice this question →
12
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.

Practice this question →
13
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.

Practice this question →
14
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.

Practice this question →
15
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.

Practice this question →
16
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.

Practice this question →
17
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.

Practice this question →
18
MCQmedium

Refer to the exhibit. An administrator needs to free up space in the /backup filesystem. Which of the following actions would be MOST effective?

A.Increase the size of the logical volume
B.Remove unnecessary files in /backup
C.Delete old log files in /var/log
D.Use lvreduce to shrink the logical volume
AnswerB

Removing unnecessary files directly from the /backup mount point is the correct remedy because /backup is its own logical volume/filesystem, so freeing blocks there reduces the used capacity. Use commands such as `find /backup -type f -size +100M -ls`, `du -xh --max-depth=1 /backup`, or `rm` to identify and delete obsolete backups, then confirm the change with `df -h /backup`. This is the only action that actually frees space on the target filesystem.

Why this answer

The most direct way to free up space in the /backup filesystem is to remove unnecessary files stored there. This action immediately reclaims available space without altering the underlying logical volume or affecting other filesystems.

Exam trap

The trap here is that candidates may confuse freeing space in a filesystem with managing the underlying logical volume, leading them to choose lvreduce or lvextend instead of the simple file removal that directly addresses the space shortage.

How to eliminate wrong answers

Option A is wrong because increasing the size of the logical volume (e.g., with lvextend) does not free up space; it consumes additional free space from the volume group, potentially worsening the shortage. Option C is wrong because deleting old log files in /var/log frees space in the /var filesystem, not in /backup, unless /var/log is mounted under /backup, which is not indicated. Option D is wrong because using lvreduce to shrink the logical volume reduces the available space in /backup, which is the opposite of freeing up space and could cause data loss if the filesystem is not resized first.

Practice this question →
19
MCQmedium

A cron job fails to run. Which command should the administrator use to verify the cron daemon is active?

A.systemctl status cron
B.systemctl status crond
C.systemctl list-units --type=service
D.service crond status
AnswerB

'systemctl status crond' is the correct systemd command to inspect the cron daemon's runtime state. It displays whether crond.service is active (running), its load status, main process ID (PID), and recent log entries from the journal, which helps quickly identify why jobs are not executing. This is the standard, direct diagnostic action on RHEL 7 and later.

Why this answer

On RHEL-based systems (including Red Hat Enterprise Linux, CentOS, and Fedora), the cron daemon is named `crond`, not `cron`. The `systemctl status crond` command checks whether the `crond` service is active, enabled, and running. This is the correct method for verifying the cron daemon's status on systems using systemd.

Exam trap

A common pitfall is assuming the cron daemon is named 'cron' (as on Debian/Ubuntu) and selecting option A. However, on RHEL-based systems, the service is named 'crond', making option B correct. Always verify the exact service name for the exam's target distribution.

How to eliminate wrong answers

Option A is wrong because `systemctl status cron` references a service named 'cron', but on RHEL-based systems the cron daemon is named 'crond', not 'cron' (Debian/Ubuntu uses 'cron'). Option C is wrong because `systemctl list-units --type=service` lists all loaded service units, but it does not specifically check the status of the cron daemon; it would require additional filtering and does not directly answer whether crond is active. Option D is wrong because `service crond status` is a legacy SysVinit command that may work on older systems, but on modern RHEL 7+ systems using systemd, the recommended and consistent command is `systemctl status crond`; the `service` command is a compatibility wrapper and may not reflect the true systemd state in all cases.

Practice this question →
20
MCQhard

A systems administrator installs a custom hardware device driver kernel module named 'mydevice' on a RHEL 9 system. The module is built and placed in /lib/modules/$(uname -r)/extra/. The administrator loads it manually with modprobe mydevice and it works. However, after a system reboot, the module is not loaded. The administrator checks that the device is present at boot time. Which step should be taken to ensure the module loads automatically at boot?

A.Add the line 'install mydevice /sbin/modprobe --ignore-install mydevice' to /etc/modprobe.d/load.conf
B.Rebuild the initramfs with 'dracut --force --add mydevice'
C.Add the line 'load mydevice' to /etc/rc.local and ensure rc.local is executable.
D.Run 'echo mydevice > /etc/modules-load.d/mydevice.conf'
AnswerD

Writing the module name to a file under /etc/modules-load.d/ is the canonical systemd way to force a kernel module to be loaded at boot. systemd-modules-load.service reads every .conf file in that directory during early boot and passes each line as a module name to modprobe, so 'mydevice' will be loaded reliably. The echo redirection creates the necessary file with the correct content, and because the service runs before most hardware-dependent services, the driver will be present when the device is probed.

Why this answer

Writing the module name to a file in /etc/modules-load.d/ ensures systemd loads the module automatically at boot. The modules-load.d mechanism is the standard RHEL 9 method for specifying kernel modules to be loaded early in the boot process, before the root filesystem is fully available.

Exam trap

The trap here is that candidates confuse the initramfs rebuild (dracut) with the simpler modules-load.d mechanism, thinking all kernel modules must be baked into the initramfs to load at boot, when in fact only modules needed before root is mounted require that treatment.

How to eliminate wrong answers

Option A is wrong because the 'install' directive in modprobe.d is used to override the default installation command for a module, not to specify automatic loading at boot; it would only affect manual modprobe invocations. Option B is wrong because rebuilding the initramfs with dracut --add mydevice is unnecessary for a module already installed in /lib/modules/.../extra/; initramfs is for modules needed during early boot (e.g., storage drivers), and adding a device driver that is not required for mounting root is wasteful and not the standard method. Option C is wrong because /etc/rc.local is a legacy mechanism that runs after the system is fully booted, not during early kernel module loading; it is also not enabled by default on RHEL 9 and would load the module too late for device initialization.

Practice this question →
21
MCQmedium

A system administrator needs to ensure that a specific kernel module 'usb_storage' is not loaded automatically during boot on a RHEL 9 system. Which configuration file should be modified to blacklist this module?

A.Add 'blacklist usb_storage' to /etc/modules-load.d/usb_storage.conf
B.Add 'install usb_storage /bin/false' to /etc/sysconfig/modules/
C.Add 'blacklist usb_storage' to /etc/modprobe.d/blacklist.conf
D.Add 'blacklist usb_storage' to /etc/init.d/rc.local
AnswerC

This is the standard and correct approach: /etc/modprobe.d/ contains configuration consumed by modprobe, and the 'blacklist' directive instructs it to ignore any request to load usb_storage from automatic discovery (e.g., udev or coldplug). Files in this directory follow a .conf naming convention, so blacklist.conf is a conventional choice. This prevents the module from being loaded by alias, though a user could still force it with an explicit full-name modprobe command.

Why this answer

On RHEL 9, the recommended way to prevent a kernel module from loading automatically is to add a 'blacklist' directive in a file under /etc/modprobe.d/. The file /etc/modprobe.d/blacklist.conf is a conventional location for such blacklist entries. When modprobe processes this file, it will ignore the specified module during boot and when loading modules manually, effectively preventing usb_storage from being loaded.

Exam trap

The trap here is that candidates confuse /etc/modules-load.d/ (used for loading modules) with /etc/modprobe.d/ (used for module configuration including blacklisting), leading them to choose Option A.

How to eliminate wrong answers

Option A is wrong because /etc/modules-load.d/ is used to list modules that should be loaded at boot, not to blacklist them; adding 'blacklist usb_storage' there would have no effect. Option B is wrong because /etc/sysconfig/modules/ is not a standard directory for module blacklisting; the 'install usb_storage /bin/false' directive, if placed in a modprobe.d file, would override the module's installation, but the path given is incorrect. Option D is wrong because /etc/init.d/rc.local is a legacy script for local startup commands and is not designed for kernel module blacklisting; it would run too late in the boot process and is not the proper mechanism for preventing module loading.

Practice this question →
22
MCQmedium

A system administrator needs to restore the default SELinux security context on all files under /var/www/html after a misconfiguration. Which command should be used?

A.setfiles -R /var/www/html
B.restorecon -R /var/www/html
C.fixfiles -R /var/www/html
D.chcon -R -t httpd_sys_content_t /var/www/html
AnswerB

restorecon is the correct command because it reads the active policy's `file_contexts` rules and resets each file's SELinux context to the default for its path. With `-R`, it descends recursively through `/var/www/html`, fixing any files whose contexts were altered by copying, misconfiguration, or manual `chcon`. It is the standard tool for restoring contexts on a specific path.

Why this answer

The `restorecon -R /var/www/html` command restores the default SELinux security contexts on all files under /var/www/html by reading the file contexts defined in the SELinux policy (typically from /etc/selinux/targeted/contexts/files/file_contexts). The `-R` flag ensures recursive operation, making it the correct tool to fix misconfigured contexts without manually specifying a type.

Exam trap

The trap here is that candidates confuse `restorecon` with `chcon` or `setfiles`, thinking that manually setting the type with `chcon` is equivalent to restoring the default context, but `chcon` does not consult the policy and can set an incorrect type if the path's default context differs from the specified type.

How to eliminate wrong answers

Option A is wrong because `setfiles` is used to verify or set file contexts based on a file context specification file, but it requires a specification file argument (e.g., `setfiles -c /etc/selinux/targeted/policy/policy.31 file_contexts /var/www/html`) and is not the standard command for restoring contexts on a live system; it is more commonly used for initial labeling or relabeling after policy changes. Option C is wrong because `fixfiles` is a higher-level script that can restore contexts, but its `-R` option is not valid; `fixfiles` uses `-F` to force restoration or `-R` to remove files from the restore list, and the correct syntax for recursive restore is `fixfiles restore /var/www/html` or `fixfiles -R /var/www/html` is not a standard usage. Option D is wrong because `chcon -R -t httpd_sys_content_t /var/www/html` manually sets the type to `httpd_sys_content_t`, which may not match the default context defined in the policy (e.g., `httpd_sys_content_t` is correct for static content, but the default context could be `httpd_sys_rw_content_t` for writable directories or other types depending on the path); this approach bypasses the policy and can lead to further misconfiguration.

Practice this question →
23
MCQmedium

An administrator wants to temporarily disable the firewalld service for troubleshooting. Which command will stop the service and prevent it from starting on subsequent boots?

A.systemctl stop --now firewalld
B.systemctl mask firewalld
C.systemctl stop firewalld
D.systemctl disable firewalld
E.systemctl disable --now firewalld
AnswerE

Running systemctl disable --now firewalld performs both operations atomically: it stops the active firewalld daemon and removes the boot-time enablement symlinks so that the service will not start at the next boot. This is the cleanest way to temporarily take the firewall down across reboots while leaving the unit unmasked and available for manual start later. It is the standard single-command answer for 'temporarily disable' scenarios.

Why this answer

`systemctl disable --now firewalld` both stops the service immediately (via `--now`) and disables it from starting automatically on subsequent boots. This meets the requirement of temporarily disabling the service for troubleshooting while preventing it from starting after reboot.

Exam trap

The trap here is that candidates often confuse `disable` with `mask` or forget that `stop` alone does not affect boot-time behavior, leading them to choose options that either stop the service without disabling it or permanently block it with mask.

How to eliminate wrong answers

Option A is wrong because `systemctl stop --now firewalld` stops the service immediately but does not disable it, so it will start again on the next boot. Option B is wrong because `systemctl mask firewalld` creates a symlink to /dev/null, which prevents the service from being started manually or automatically, but it is a permanent action that is difficult to reverse and not appropriate for temporary troubleshooting. Option C is wrong because `systemctl stop firewalld` stops the service only for the current session; it will restart on the next boot.

Option D is wrong because `systemctl disable firewalld` prevents the service from starting on boot but does not stop it immediately, so the service remains running until manually stopped.

Practice this question →
24
MCQmedium

An administrator wants to optimize system performance for a database workload. Which tool should be used to select a performance profile?

A.performance-tune --profile database
B.setroubleshoot
C.tuned-adm profile throughput-performance
D.systemctl set-profile database
AnswerC

`tuned-adm profile throughput-performance` is the correct command: it tells the `tuned` daemon to activate the `throughput-performance` profile, which tunes the system for maximum throughput by adjusting settings such as the CPU governor, kernel scheduler, and virtual memory parameters. This command requires the `tuned` package to be installed and the `tuned` service to be active; once applied, the profile persists across reboots automatically.

Why this answer

C is correct because `tuned-adm profile throughput-performance` selects a Tuned performance profile optimized for high throughput, which is suitable for database workloads that benefit from increased I/O and network performance. Tuned is the systemd-based dynamic system tuning daemon in RHEL that adjusts kernel parameters, disk schedulers, and other settings based on the selected profile.

Exam trap

The trap here is that candidates may confuse `tuned-adm` with non-existent commands like `performance-tune` or incorrectly assume `systemctl` can manage performance profiles, when in fact Tuned is a separate service controlled via `tuned-adm`.

How to eliminate wrong answers

Option A is wrong because `performance-tune` is not a valid command in RHEL; the correct tool for managing performance profiles is `tuned-adm`. Option B is wrong because `setroubleshoot` is a tool for diagnosing SELinux denials, not for selecting performance profiles. Option D is wrong because `systemctl set-profile` is not a valid systemctl command; systemctl manages systemd units and services, not performance tuning profiles.

Practice this question →
25
Multi-Selecthard

An administrator wants to change the default systemd target to multi-user.target. Which three steps are part of a correct procedure? (Choose three.)

Select 3 answers
A.systemctl enable multi-user.target
B.systemctl start multi-user.target
C.systemctl isolate multi-user.target
D.ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
E.systemctl set-default multi-user.target
AnswersC, D, E

systemctl isolate multi-user.target is correct because it atomically switches the currently running target by stopping all units not required by multi-user.target and starting the required ones, effectively performing a runtime runlevel switch. This is the proper way to change the active target immediately, and while it does not modify the default for future boots, it is the necessary command to apply a target change without a reboot.

Why this answer

`systemctl isolate multi-user.target` immediately switches the current systemd target to multi-user.target, which is the correct way to change the active target at runtime without a reboot. This command stops all units not required by the new target and starts those that are, effectively changing the system's operational state.

Exam trap

The trap here is that candidates confuse `systemctl enable` (which controls whether a unit starts at boot) with `systemctl set-default` (which sets the default target for boot), and they may think `systemctl start` is sufficient to change the active target, not realizing that `isolate` is required to properly transition systemd to a different target.

Practice this question →
26
MCQeasy

A technician needs to configure a network interface to use a static IP address permanently. Which command should be used in RHEL 9?

A.ip
B.vi /etc/sysconfig/network-scripts/ifcfg-eth0
C.nmcli
D.ifconfig
AnswerC

`nmcli` is the correct tool because it interacts with NetworkManager, the default network management service on RHEL 9. Commands like `nmcli con modify eth0 ipv4.addresses 192.0.2.10/24` and `nmcli con up eth0` make changes persist in the connection profile automatically. It also validates the configuration and applies it without requiring a reboot, making it the supported method for permanent network interface configuration.

Why this answer

`nmcli` is the primary command-line tool for managing NetworkManager in RHEL 9, and it allows you to configure a static IP address persistently. Using `nmcli con mod` followed by the connection name and IP settings ensures the configuration survives reboots, as NetworkManager stores the settings in its own configuration files.

Exam trap

The trap here is that candidates familiar with older RHEL versions (e.g., RHEL 7 or 8) may still expect the legacy `ifcfg-*` files to work, but RHEL 9 has fully transitioned to NetworkManager keyfiles, making `nmcli` the correct persistent tool.

How to eliminate wrong answers

Option A is wrong because `ip` is a low-level tool for viewing and temporarily changing network parameters (e.g., IP addresses, routes) at runtime; it does not write persistent configuration to any file, so changes are lost after a reboot. Option B is wrong because RHEL 9 no longer uses the legacy `ifcfg-*` files in `/etc/sysconfig/network-scripts/` by default; NetworkManager ignores these files unless explicitly configured, and the correct persistent method is via `nmcli` or `nmtui`. Option D is wrong because `ifconfig` is deprecated and not installed by default in RHEL 9; it only makes temporary changes and does not support persistent configuration.

Practice this question →
27
Multi-Selectmedium

An administrator needs to configure a static IP address on an interface that will persist across reboots using NetworkManager. Which TWO commands or files can be used to achieve this?

Select 2 answers
A.systemctl restart network
B.nmcli con up eth0
C.nmcli con mod eth0 ipv4.addresses 192.168.1.10/24
D.Edit /etc/sysconfig/network-scripts/ifcfg-eth0
E.ip addr add 192.168.1.10/24 dev eth0
AnswersC, D

This NetworkManager command modifies the persistent connection profile assigned to eth0, storing the IPv4 address 192.168.1.10/24 within that profile's configuration. Because the change is saved to a NetworkManager-backed file (or to /etc/sysconfig/network-scripts/ifcfg-eth0 on RHEL 7), it remains in effect across reboots; to apply it immediately you would reactivate the connection with 'nmcli con up eth0'. Along with the address, you would normally also set 'ipv4.method manual' to fully define a static configuration, but this command is the core persistent address-setting step.

Why this answer

The `nmcli con mod` command modifies the NetworkManager connection profile for the interface, setting a static IPv4 address that is stored persistently in the connection configuration. Option D is correct because editing the `/etc/sysconfig/network-scripts/ifcfg-eth0` file directly defines the static IP address in the ifcfg format, which NetworkManager reads on boot to apply persistent settings.

Exam trap

The trap here is that candidates confuse runtime commands like `ip addr add` (which are temporary) with persistent configuration methods, or they mistakenly think restarting the network service (systemctl restart network) will save the IP address, when in fact it only reloads existing configurations without making changes permanent.

Practice this question →
28
MCQmedium

An administrator wants to install a package 'httpd' but only if it is available in the configured repositories. Which command should be used to check if the package exists?

A.rpm -q httpd
B.dnf search httpd
C.dnf list available httpd
D.dnf install httpd
AnswerC

dnf list available httpd asks DNF to query the enabled repository metadata and display only packages that are not yet installed and whose name exactly matches 'httpd'. The output shows the version and repository source, proving availability. Because it targets the exact package name and filters to available packages, it is the most precise way to verify httpd can be installed.

Why this answer

`dnf list available httpd` queries the configured DNF repositories and displays the package only if it exists in them. This command checks availability without installing, which matches the requirement to verify the package is present in the repositories before proceeding.

Exam trap

The trap here is that candidates often confuse `rpm -q` (which checks local installation status) with repository availability checks, or they mistakenly think `dnf search` is the correct command for listing available packages, when in fact `dnf list available` is the precise tool for this task.

How to eliminate wrong answers

Option A is wrong because `rpm -q httpd` checks if the package is already installed on the system, not whether it is available in repositories. Option B is wrong because `dnf search httpd` searches package names and descriptions across repositories but does not specifically list only available packages; it may return partial matches and is not the standard command for confirming availability. Option D is wrong because `dnf install httpd` attempts to install the package immediately, which does not fulfill the requirement to check existence first without making changes.

Practice this question →
29
MCQmedium

A system has a new disk /dev/sdb that needs to be used as an LVM physical volume for an existing volume group 'vg_data'. Which sequence of commands is correct?

A.vgcreate vg_data /dev/sdb; pvcreate /dev/sdb
B.lvextend vg_data /dev/sdb
C.pvcreate /dev/sdb; vgcreate vg_data /dev/sdb
D.pvcreate /dev/sdb; vgextend vg_data /dev/sdb
AnswerD

This is the correct procedure: pvcreate writes LVM metadata onto /dev/sdb, turning it into a physical volume ready for LVM to use. vgextend then adds that PV to the existing vg_data volume group, increasing the VG's total available physical extents. This is the standard way to grow a volume group with a freshly added disk, after which logical volume capacity can be expanded with lvextend.

Why this answer

The disk /dev/sdb must first be initialized as a physical volume using pvcreate, then added to the existing volume group vg_data using vgextend. This sequence properly extends the volume group with the new physical volume, as required by LVM.

Exam trap

The trap here is that candidates often confuse vgcreate (which creates a new volume group) with vgextend (which adds a physical volume to an existing volume group), leading them to select option C instead of D.

How to eliminate wrong answers

Option A is wrong because vgcreate creates a new volume group, but the question specifies an existing volume group 'vg_data', and the command order also incorrectly places vgcreate before pvcreate. Option B is wrong because lvextend extends a logical volume, not a volume group, and it requires a physical volume or logical volume path, not a volume group name. Option C is wrong because vgcreate would attempt to create a new volume group named 'vg_data', which already exists, causing a conflict; the correct command to add a physical volume to an existing volume group is vgextend, not vgcreate.

Practice this question →
30
MCQhard

A system fails to boot because of a corrupted fstab file. The administrator boots into rescue mode from a RHEL installation ISO. Which command should be run first to mount the root filesystem read-write?

A.mount /dev/mapper/rhel-root /mnt/sysimage
B.mount -o rw,remount /sysroot
C.chroot /mnt/sysimage
D.systemctl rescue
AnswerA

When you enter RHEL rescue mode, the installer mounts the installed system's root logical volume at the /mnt/sysimage directory. This command explicitly mounts the LVM logical volume /dev/mapper/rhel-root to that expected mount point, making the filesystem contents visible so you can later chroot and repair /etc/fstab. Without this mount, the repair tools cannot access the system's configuration files.

Why this answer

In rescue mode, the root filesystem is not mounted by default. The first step is to mount the logical volume containing the root filesystem (e.g., /dev/mapper/rhel-root) to a temporary mount point like /mnt/sysimage so that you can access and repair the corrupted /etc/fstab file. Option A correctly uses the mount command with the device and mount point, which is the standard procedure for RHEL rescue environments.

Exam trap

The trap here is that candidates confuse the rescue mode mount point (/mnt/sysimage) with the emergency mode mount point (/sysroot) or attempt to use chroot before mounting, leading them to select options B or C.

How to eliminate wrong answers

Option B is wrong because /sysroot is not a standard mount point in rescue mode; the correct temporary mount point is /mnt/sysimage, and the -o rw,remount option is used to remount an already mounted filesystem, not to mount one from scratch. Option C is wrong because chroot /mnt/sysimage changes the root directory into the mounted filesystem, but it cannot be run before the filesystem is actually mounted; it is a subsequent step after mounting. Option D is wrong because systemctl rescue switches the system to rescue mode (a systemd target), but the system is already booted into rescue mode from the ISO, and this command does not mount the root filesystem.

Practice this question →
31
MCQmedium

An administrator wants to view only the error messages from the kernel ring buffer since last boot. Which command should be used?

A.cat /var/log/kernel-errors
B.dmesg -p err
C.journalctl -k -p err
D.systemctl status kernel
AnswerC

journalctl -k -p err is the correct command because -k (or --dmesg) tells journalctl to show kernel messages, and -p err (or --priority=err) filters those messages to the err priority level and more severe (emerg, alert, crit, err). This works because systemd-journald captures kernel logs from /dev/kmsg and indexes them by facility and priority. It is the recommended way to view kernel errors on RHEL systems using systemd.

Why this answer

`journalctl -k -p err` filters the kernel messages (`-k`) from the systemd journal by priority level `err` (error), showing only error-level kernel messages since the last boot. This is the standard way to view kernel error messages in modern RHEL/CentOS systems using systemd-journald.

Exam trap

The trap here is that candidates may confuse `dmesg` options (using `-l` for level filtering) with `journalctl` options (using `-p` for priority), or assume a static log file exists for kernel errors, leading them to pick option A or B.

How to eliminate wrong answers

Option A is wrong because `/var/log/kernel-errors` is not a standard log file; kernel messages are stored in the kernel ring buffer and accessed via `dmesg` or `journalctl`, not a dedicated file. Option B is wrong because `dmesg -p err` is invalid syntax; `dmesg` uses `-l` (level) to filter by priority, not `-p`. Option D is wrong because `systemctl status kernel` is not a valid systemctl command; systemctl manages services, not the kernel directly.

Practice this question →
32
MCQmedium

A web server running Apache (httpd) on RHEL 9 serves content from /var/www/custom. Clients get a 403 error. The SELinux context on files is system_u:object_r:default_t:s0. Which command resolves the issue persistently without disabling SELinux?

A.chcon -t httpd_sys_content_t /var/www/custom
B.setsebool -P httpd_enable_custom on
C.restorecon -R /var/www/custom
D.semanage fcontext -a -t httpd_sys_content_t "/var/www/custom(/.*)?" && restorecon -R /var/www/custom
AnswerD

semanage fcontext -a -t httpd_sys_content_t "/var/www/custom(/.*)?" && restorecon -R /var/www/custom first writes a persistent file-context rule using a regex that covers the directory and all descendants. Then restorecon consumes that rule to relabel every matching file to httpd_sys_content_t. Because the rule is stored in the SELinux policy, it survives system relabels and is the proper method for assigning Apache-readable context to files outside the default /var/www locations.

Why this answer

It uses `semanage fcontext` to add a persistent file context rule for `/var/www/custom` and its contents, then applies it with `restorecon`. This ensures the `httpd_sys_content_t` type is set persistently across file system relabeling, resolving the 403 error caused by the default SELinux type (`default_t`) that denies Apache access.

Exam trap

The trap here is that candidates choose `chcon` (Option A) because it immediately fixes the 403 error, but they overlook the requirement for a persistent change, which `semanage fcontext` with `restorecon` provides.

How to eliminate wrong answers

Option A is wrong because `chcon` changes the SELinux context immediately but does not persist after a file system relabel (e.g., `restorecon` or `fixfiles`), making it a temporary fix. Option B is wrong because `setsebool -P httpd_enable_custom on` is not a valid boolean; the correct boolean for allowing Apache to access custom content directories is `httpd_read_user_content` or similar, and this option does not address the file context issue. Option C is wrong because `restorecon` alone will reset the context to the default policy, which is `default_t` for an unlabeled directory, not `httpd_sys_content_t`, so it does not fix the 403 error.

Practice this question →
33
Multi-Selecteasy

Which TWO files are essential in the /boot directory for the kernel to boot?

Select 2 answers
A.fstab
B.grub.cfg
C.initramfs
D.vmlinuz
E.kernel
AnswersC, D

initramfs (the initial RAM filesystem) is an essential boot file because it contains the device modules, LVM/encryption tools, and udev rules needed to discover and mount the real root filesystem. During early boot the kernel extracts initramfs into a tmpfs and executes /init, which probes storage hardware, activates volumes, and then switches to the actual root. Without an initramfs, most Linux systems cannot boot unless every required storage driver is statically built into the kernel, which is rarely the case in distributions.

Why this answer

The initramfs (initial RAM filesystem) is essential because it contains the necessary drivers and tools to mount the root filesystem before the kernel can take over. Without it, the kernel would not be able to access the storage device containing the root partition, especially when using filesystems or hardware that require kernel modules not built into the kernel itself.

Exam trap

The trap here is that candidates often confuse the bootloader configuration file (grub.cfg) with a kernel-essential file, or they think the generic term 'kernel' is an actual filename, when in fact the correct filename is vmlinuz.

Practice this question →
34
Multi-Selecthard

Which TWO commands can be used to display the current SELinux mode?

Select 2 answers
A.setenforce
B.ausearch
C.getenforce
D.sestatus
E.semanage
AnswersC, D

getenforce is the most direct command for displaying the current SELinux execution mode and prints exactly one of Enforcing, Permissive, or Disabled to standard output. It calls the SELinux library's getenforce function, which reads the kernel-enforced mode, making it convenient for shell scripts and monitoring tools. Unlike sestatus, it provides no policy version, configuration file details, or denial counts, but it is the canonical lightweight way to check the mode alone.

Why this answer

The `getenforce` command (option C) displays the current SELinux mode as either Enforcing, Permissive, or Disabled. The `sestatus` command (option D) provides a detailed status report including the current mode, the loaded policy, and the mode from the configuration file. Both are standard tools for querying the SELinux operational state.

Exam trap

Red Hat often tests the distinction between commands that *query* state versus those that *modify* state, so candidates may confuse `setenforce` (which changes mode) with `getenforce` (which displays mode).

Practice this question →
35
MCQmedium

An administrator extends a logical volume by 5GB. The filesystem is XFS. Which command must be run to make the additional space available?

A.xfs_growfs /mount
B.mount -o remount /mount
C.resize2fs /dev/vg/lv_root
D.lvresize -L +5G /dev/vg/lv_root
AnswerA

xfs_growfs /mount is correct because it is the only command that actually expands the XFS filesystem to fill the newly available space in the underlying logical volume. It operates online on a mounted filesystem, takes the mount point as an argument, and grows the filesystem to consume all unallocated space in the LV without requiring an unmount or reboot.

Why this answer

After extending a logical volume with lvresize, the XFS filesystem does not automatically recognize the new space. The xfs_growfs command must be run on the mounted filesystem to expand it to fill the enlarged logical volume. This command can target the mount point directly and works online without unmounting.

Exam trap

The trap here is that candidates confuse the logical volume resize (lvresize) with the filesystem resize, assuming the filesystem automatically expands when the LV grows, or they mistakenly apply ext4 tools like resize2fs to an XFS filesystem.

How to eliminate wrong answers

Option B is wrong because 'mount -o remount /mount' only reapplies mount options and does not resize any filesystem; it is irrelevant for making additional space available after an LV extension. Option C is wrong because 'resize2fs' is the tool for ext2/ext3/ext4 filesystems, not XFS; using it on an XFS filesystem would fail or cause corruption. Option D is wrong because 'lvresize -L +5G /dev/vg/lv_root' is the command that extends the logical volume itself, but the question asks what must be run after that step to make the space available to the filesystem; the LV resize is already assumed to have been done.

Practice this question →
36
MCQhard

A system fails to boot and drops into an emergency shell. The administrator suspects a misconfigured /etc/fstab. Which command should be used to determine which filesystem is causing the boot issue?

A.systemctl status local-fs.target
B.journalctl -xb -p err
C.fsck -A
D.mount -a
AnswerB

Running journalctl -xb -p err reads the persistent journal from the current boot (-b), applies extended explanatory hints (-x) that describe what each message means, and filters to error priority and above (-p err). This will surface kernel driver errors, systemd mount failures, and device not found messages that directly explain why local-fs.target failed. Because the emergency shell runs early in the boot process, the journal still contains the relevant log entries, making this the most reliable diagnostic command.

Why this answer

When a system fails to boot due to a misconfigured /etc/fstab, the emergency shell is entered. The `journalctl -xb -p err` command displays the systemd journal from the current boot (`-b`) with extended information (`-x`) and filters for error-level messages (`-p err`). This will show the exact mount failure and the offending filesystem entry, making it the correct diagnostic tool.

Exam trap

The trap here is that candidates often choose `mount -a` (option D) thinking it will show the error, but it only attempts the mount again without providing the specific fstab line or error context, whereas `journalctl -xb -p err` reveals the exact failure from the boot process.

How to eliminate wrong answers

Option A is wrong because `systemctl status local-fs.target` shows the status of the local-fs target unit, but it does not provide detailed error messages about which specific filesystem failed to mount; it only indicates whether the target is active or failed. Option C is wrong because `fsck -A` checks all filesystems listed in /etc/fstab for consistency, but it does not report which filesystem caused the boot failure—it may run checks on healthy filesystems and does not parse mount errors. Option D is wrong because `mount -a` attempts to mount all filesystems in /etc/fstab, but if the system is already in an emergency shell, this command may fail again without providing clear diagnostic output about the specific misconfiguration.

Practice this question →
37
MCQeasy

Refer to the exhibit. An administrator is unable to write to /tmp because the filesystem is full. What is the most likely cause?

A.The /tmp is a separate filesystem
B.There is a filesystem quota enabled
C.The /boot partition is too small
D.The root filesystem is nearly full at 90% usage
AnswerD

The root filesystem / is at 90% capacity with only 5.2GB free, and since /tmp is not a separate mount, it is part of this same root volume. When the root filesystem is nearly full, write attempts to /tmp can fail due to insufficient free space, especially if the file to be written is large or the filesystem has reserved blocks for root. The df output directly indicates a high usage level that commonly triggers 'no space left on device' errors for temporary file creation.

Why this answer

The exhibit shows that the root filesystem (/) is at 90% usage, while /tmp is not a separate filesystem but a directory under the root. Since /tmp resides on the root filesystem, when the root filesystem is nearly full, there is no space left for writing to /tmp, causing the write failure.

Exam trap

Red Hat often tests the misconception that /tmp is always a separate filesystem, leading candidates to overlook the root filesystem's usage as the cause of write failures.

How to eliminate wrong answers

Option A is wrong because if /tmp were a separate filesystem, it would have its own usage percentage shown in the df output; the exhibit does not list /tmp as a separate mount point, so it is part of the root filesystem. Option B is wrong because there is no indication of a filesystem quota being enabled; quotas are typically shown with commands like `repquota` or `quota`, and the df output does not reflect quota limits. Option C is wrong because the /boot partition being too small would not affect the ability to write to /tmp, as /boot is a separate filesystem used for boot files and does not share space with /tmp.

Practice this question →
38
Multi-Selecteasy

Which TWO are correct ways to check the SELinux context of a file named 'test.txt'? (Choose exactly two.)

Select 2 answers
A.ls -Z test.txt
B.ls -l test.txt
C.sestatus
D.getenforce
E.stat test.txt
AnswersA, E

ls -Z is correct because the -Z flag, when used with ls, appends a column showing the SELinux security context (user:role:type:level) of the specified path. This output is read directly from the file's inode and provides the per-file label that SELinux uses for access control. It is the standard command for quickly checking a file's context in a directory listing.

Why this answer

`ls -Z` displays the SELinux security context of files, including user, role, type, and sensitivity level. The `-Z` option is specifically designed to show SELinux context information for files and processes.

Exam trap

Red Hat often tests the distinction between commands that show SELinux status (`sestatus`, `getenforce`) versus commands that show file-level SELinux context (`ls -Z`, `stat`), trapping candidates who confuse system-wide status with per-file attributes.

Practice this question →
39
MCQeasy

An administrator needs to ensure that the httpd service starts automatically after a system reboot and is set to start immediately without rebooting. Which command should be used?

A.systemctl set-default httpd
B.systemctl add httpd
C.systemctl enable --now httpd
D.systemctl start --enable httpd
AnswerC

systemctl enable --now httpd performs two actions atomically: it enables the httpd service to start automatically at boot by creating the appropriate .wants symlinks, and immediately starts it in the current session. This is the administrator-friendly equivalent of running systemctl enable httpd followed by systemctl start httpd. It is the correct command to satisfy the requirement of ensuring the service is running now and persists across reboots.

Why this answer

`systemctl enable --now httpd` both creates the necessary symlinks to start the httpd service automatically at boot (enable) and starts the service immediately (--now) without requiring a reboot. This combines two operations into one command, satisfying both requirements in the question.

Exam trap

The trap here is that candidates may confuse `systemctl enable` (for boot persistence) with `systemctl start` (for immediate execution), or misremember the `--now` flag as `--enable`, leading them to pick a syntactically invalid option like D or a non-existent subcommand like B.

How to eliminate wrong answers

Option A is wrong because `systemctl set-default` sets the default target (e.g., multi-user.target), not a service; it has no effect on httpd. Option B is wrong because `systemctl add` is not a valid systemctl subcommand; the correct command for enabling a service is `systemctl enable`. Option D is wrong because `systemctl start --enable httpd` uses an invalid option order; the correct syntax is `systemctl enable --now httpd`, and `--enable` is not a valid flag for `systemctl start`.

Practice this question →
40
MCQeasy

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

A.Remove the line from /etc/fstab and run systemctl daemon-reload, then reboot.
B.Add the nofail option to the fstab line, then reboot.
C.Delete the /data directory and reboot.
D.Use a text editor to insert '#' at the beginning of the /dev/sdb1 line in /etc/fstab, then reboot.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
41
MCQeasy

A technician needs to configure a static IPv4 address on a RHEL 9 network interface 'enp1s0' using NetworkManager. Which command should be used to set the IP address?

A.nmcli connection modify enp1s0 ipv4.addresses 192.168.1.100/24
B.nmtui edit enp1s0 --ipv4 192.168.1.100/24
C.ip addr add 192.168.1.100/24 dev enp1s0
D.ifconfig enp1s0 192.168.1.100 netmask 255.255.255.0
AnswerA

`nmcli connection modify` writes the static address into the NetworkManager connection profile for `enp1s0`, satisfying the requirement to configure it through NetworkManager rather than editing ifcfg files or using `ip addr`. The `ipv4.addresses` property accepts the address with prefix length, and the change persists across reboots once the connection is reactivated.

Why this answer

`nmcli connection modify enp1s0 ipv4.addresses 192.168.1.100/24` is the proper NetworkManager command to set a static IPv4 address on a RHEL 9 interface. This command modifies the connection profile for 'enp1s0' by setting the `ipv4.addresses` property to the specified address and prefix length, which is the standard method for persistent static IP configuration via NetworkManager.

Exam trap

The trap here is that candidates often confuse temporary runtime commands (like `ip addr add` or deprecated `ifconfig`) with persistent configuration tools required by NetworkManager, or they misuse `nmtui` syntax expecting inline arguments instead of its interactive interface.

How to eliminate wrong answers

Option B is wrong because `nmtui edit enp1s0 --ipv4 192.168.1.100/24` is not a valid syntax; `nmtui` is an interactive text user interface and does not accept command-line arguments like `--ipv4` — it must be run interactively or with subcommands like `nmtui edit` without inline IP assignment. Option C is wrong because `ip addr add 192.168.1.100/24 dev enp1s0` only adds the IP address temporarily to the kernel's network stack; it does not persist across reboots and does not use NetworkManager, so it is not the correct tool for a persistent static configuration. Option D is wrong because `ifconfig` is deprecated in RHEL 9 and does not integrate with NetworkManager; it also only sets the address temporarily and lacks persistent configuration capabilities.

Practice this question →
42
MCQhard

A company has a RHEL 9 server that hosts a critical application. The server has two network interfaces: enp1s0 (192.168.1.100/24) and enp2s0 (10.0.0.100/24). The default gateway is 192.168.1.1. The application listens on a TCP port 8080 and should be accessible from both networks. Recently, the administrator noticed that clients on the 10.0.0.0/24 network can ping the server's 10.0.0.100 address but cannot connect to port 8080. Clients on 192.168.1.0/24 can connect fine. The firewall is configured with the default zone (public) and the service 'http' is allowed, but port 8080 is not specifically allowed. The administrator checks 'firewall-cmd --list-all' and sees that only services 'ssh' and 'http' are listed. The application is running and listening on 0.0.0.0:8080. What is the most likely cause and the correct course of action?

A.Disable SELinux to allow the application to accept connections.
B.Add a firewall rule to open TCP port 8080 in the public zone using 'firewall-cmd --add-port=8080/tcp --permanent' and reload.
C.Change the application to listen only on the 10.0.0.100 interface.
D.Add a static route for the 10.0.0.0/24 network via the 10.0.0.1 gateway.
AnswerB

This is the correct fix because firewalld's public zone is rejecting incoming TCP connections to port 8080, even though the application is bound to all interfaces. The command 'firewall-cmd --add-port=8080/tcp --permanent' adds the rule to the persistent configuration, and then executing 'firewall-cmd --reload' loads it into the active runtime. This allows external clients on 10.0.0.0/24 to reach the service while preserving all other existing zone rules.

Why this answer

The firewall is blocking incoming connections to port 8080 because only services 'ssh' (port 22) and 'http' (port 80) are allowed in the public zone. Since the application listens on 0.0.0.0:8080, it is reachable from both networks at the IP level, but the firewall drops packets destined for port 8080. Adding a permanent rule to open TCP port 8080 and reloading the firewall configuration resolves the issue.

Exam trap

The trap here is that candidates assume the application is unreachable due to a routing or SELinux issue, overlooking the fact that the firewall's default zone only allows explicitly listed services and ports, and that 'http' does not cover port 8080.

How to eliminate wrong answers

Option A is wrong because SELinux does not block network ports by default; it enforces mandatory access control on processes, and disabling it is unnecessary and insecure—the problem is firewall-related, not SELinux. Option C is wrong because the application already listens on 0.0.0.0 (all interfaces), and restricting it to 10.0.0.100 would break connectivity for clients on the 192.168.1.0/24 network. Option D is wrong because clients on 10.0.0.0/24 can already ping the server's 10.0.0.100 address, indicating routing is functional; the issue is a firewall rule, not a missing static route.

Practice this question →
43
Multi-Selecthard

Which THREE are valid methods to configure network bonding in RHEL 9? (Choose exactly three.)

Select 3 answers
A.Using a configuration file in /etc/NetworkManager/system-connections/.
B.Using nmcli to create a bond connection.
C.Using nmtui interactive interface.
D.Using the teamd service.
E.Editing /etc/sysconfig/network-scripts/ifcfg-bond0 directly.
AnswersA, B, C

This is valid because NetworkManager persists every connection profile as a keyfile in /etc/NetworkManager/system-connections/. You can manually create a file like bond0.nmconnection with a [bond] section, specify the interface-name and bond mode, then run `nmcli connection reload` and `nmcli connection up bond0`. NetworkManager reads these files natively on RHEL 8/9.

Why this answer

In RHEL 9, NetworkManager stores connection profiles in `/etc/NetworkManager/system-connections/`. You can manually create a bond configuration file in this directory with the proper key-value pairs (e.g., `type=bond`, `bond.options=mode=1,miimon=100`), and NetworkManager will read it on restart or reload. This is a valid method for configuring network bonding.

Exam trap

The trap here is that candidates familiar with RHEL 7 or 8 may still expect `ifcfg-*` files or `teamd` to be valid, but RHEL 9 has fully removed both, making only NetworkManager-based methods (files, nmcli, nmtui) correct.

Practice this question →
44
Multi-Selecthard

Which THREE of the following are common steps to configure a system to automatically mount an NFS share at boot?

Select 3 answers
A.Run 'mount -a' after boot
B.Ensure nfs-utils is installed
C.Use autofs
D.Configure /etc/exports
E.Add an entry to /etc/fstab
AnswersB, C, E

The nfs-utils package must be present on the client because it supplies mount.nfs, a helper binary that the kernel's NFS client calls to perform the mount operation, along with tools like showmount. On Red Hat Enterprise Linux, if nfs-utils is not installed, any attempt to mount an NFS share fails with 'mount: unknown filesystem type nfs'. Thus, ensuring nfs-utils is installed is a fundamental prerequisite for an NFS client.

Why this answer

B is correct because the NFS client functionality in Red Hat Enterprise Linux is provided by the nfs-utils package. Without this package installed, the system lacks the necessary tools (such as mount.nfs and rpcbind) to mount NFS shares, making it impossible to configure automatic mounting at boot.

Exam trap

Red Hat often tests the misconception that /etc/exports is a client-side configuration file, when in fact it is strictly a server-side file used to define exported directories, not client-side automount settings.

Practice this question →
45
MCQmedium

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

A.fsck
B.dd
C.smartctl
D.badblocks
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
46
MCQhard

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

A.nmcli con add type bond ifname bond0; nmcli con add type ethernet ifname eth0 master bond0 slave-type bond
B.Edit /etc/sysconfig/network-scripts/ifcfg-bond0 and ifcfg-eth0 manually
C.teamd -d -c '{"device":"bond0","runner":{"name":"activebackup"},"ports":{"eth0":{},"eth1":{}}}'
D.nmcli con add type bond ifname bond0 mode active-backup; nmcli con add type bond-slave ifname eth0 master bond0; nmcli con add type bond-slave ifname eth1 master bond0
AnswerD

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
47
MCQeasy

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

A.The directory has the sticky bit set
B.The filesystem is read-only
C.The user is not the owner of the directory
D.The user is not in the group
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
48
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
49
MCQeasy

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

A.The sshd service is not running
B.The SELinux context is wrong
C.The .ssh/authorized_keys file has incorrect permissions
D.The user's home directory is owned by root
AnswerD

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
50
MCQmedium

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

A.Run 'restorecon -Rv /run' to restore default SELinux contexts for /run
B.Add 'selinux=0' to kernel boot parameters and reboot
C.Edit the systemd-logind service unit to add 'Permissions=yes'
D.Reinstall the systemd-logind package using 'yum reinstall systemd'
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
51
Multi-Selecthard

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

Select 3 answers
A.ntpq
B./etc/ntp.conf
C.chronyc
D.timedatectl
E./etc/chrony.conf
AnswersC, D, E

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

Why this answer

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

Exam trap

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

Practice this question →
52
MCQhard

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

A.powertop --set-profile=throughput-performance
B.sysctl -w kernel.throughput=1
C.systemctl set-profile throughput-performance
D.tuned-adm profile throughput-performance
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
53
MCQhard

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

A./etc/systemd/journald.conf
B./etc/logrotate.d/syslog
C./etc/rsyslog.conf
D./etc/cron.daily/logrotate
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
54
Multi-Selecteasy

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

Select 2 answers
A.systemctl enable multi-user.target
B.systemctl default multi-user
C.systemctl set-default multi-user.target
D.ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
E.systemctl set-default runlevel3.target
AnswersC, D

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

Why this answer

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

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

Exam trap

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

Practice this question →
55
MCQmedium

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

A.find /var/log/myapp -type f -atime +7 -delete
B.find /var/log/myapp -type f -mtime +7 -exec rm {} \;
C.find /var/log/myapp -type f -ctime +7 -delete
D.find /var/log/myapp -type f -mtime +7 -delete
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
56
MCQhard

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

A.umount, e2fsck -f, resize2fs, lvreduce
B.lvreduce, resize2fs, e2fsck, umount
C.resize2fs, lvreduce, umount, e2fsck
D.umount, lvreduce, resize2fs, e2fsck
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
57
MCQhard

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

A.fsck /dev/sda1
B.debugfs -R 'repair'
C.e2fsck -p
D.fsck -A -y
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Ready to test yourself?

Try a timed practice session using only Deploy, configure, and maintain systems questions.

Start 20-question session