Courseiva

CCNA Deploy, configure, and maintain systems Questions

20 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

Enables the service to start at boot.

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

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 →
3
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 →
4
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

Enables the service to start at boot.

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 →
5
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 →
6
MCQmedium

Refer to the exhibit. Which entry is most likely to cause the system to fail to boot if the NFS server is unavailable?

A.The third entry (/home)
B.The fourth entry (/mnt)
C.The second entry (/boot)
D.The first entry (/)
AnswerB

NFS mount without _netdev option; network may not be ready, causing boot delay or failure.

Why this answer

The /mnt entry in /etc/fstab is configured with the default mount options, which include the _netdev option being absent. Without _netdev, the system will attempt to mount the NFS filesystem during the boot process before the network is fully operational. If the NFS server is unavailable, the mount will fail, and because the default mount behavior for non-root filesystems in /etc/fstab is to cause a boot failure if the mount fails (unless the 'nofail' option is specified), the system will drop into emergency mode and fail to complete the boot process.

Exam trap

Red Hat often tests the misconception that any NFS mount in /etc/fstab will cause a boot failure if the server is unavailable, but the trap here is that only mounts without the _netdev or nofail options will cause the system to fail to boot, and candidates may overlook the absence of these options in the default /mnt entry.

How to eliminate wrong answers

Option A is wrong because /home is a local filesystem (typically on a local disk or LVM), not a network filesystem, so its availability does not depend on the NFS server. Option C is wrong because /boot is a critical local filesystem that must be mounted early in the boot process; it is never an NFS mount in standard Red Hat Enterprise Linux configurations, and its failure would be due to local disk issues, not NFS server unavailability. Option D is wrong because the root filesystem (/) is mounted by the kernel or initramfs before /etc/fstab is processed, and its entry in /etc/fstab is typically ignored or used for remount options; a failure of the root entry in fstab does not cause a boot failure in the same way as a missing NFS server.

Practice this question →
7
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 →
8
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 →
9
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 →
10
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 →
11
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 →
12
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 →
13
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 →
14
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 →
15
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 →
16
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 →
17
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 →
18
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 →
19
Multi-Selecteasy

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

Select 1 answer
A.blkid
B.df -h
C.ls -lh
D.du -sh
E.fdisk -l
AnswersB

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

Why this answer

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

Exam trap

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

Practice this question →
20
MCQhard

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

A.Use resize2fs /dev/sdb1 to expand filesystem.
B.Add a new disk, create a physical volume, extend volume group, and extend logical volume.
C.Use fdisk to delete and recreate /dev/sdb1 with larger size, run partprobe, then xfs_growfs /mnt/data.
D.Use fdisk to delete and recreate /dev/sdb1 with larger size, then mount.
AnswerC

Correct steps for XFS on a partition.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Ready to test yourself?

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

Start 20-question session