Deploy, configure, and maintain systems practice questions

Add 'blacklist usb_storage' to /etc/modules-load.d/usb_storage.conf

Why wrong: The /etc/modules-load.d/ directory is handled by the systemd-modules-load.service and is intended only to specify modules to load at boot, not to block them. A 'blacklist usb_storage' line there would be misinterpreted—either as an invalid directive or as an attempt to load a module named 'blacklist'—resulting in boot-time failures. Blacklisting belongs in modprobe configuration under /etc/modprobe.d/.

Add 'install usb_storage /bin/false' to /etc/sysconfig/modules/

Why wrong: The /etc/sysconfig/ tree is a SysVinit-era location for environment variables and service configuration, and /etc/sysconfig/modules/ is not a standard directory for module blacklist rules. Even though 'install usb_storage /bin/false' is a valid modprobe directive when placed in a modprobe.d file, the udev/modprobe machinery will never read it from this path, so the module remains loadable.

Add 'blacklist usb_storage' to /etc/init.d/rc.local

Why wrong: The /etc/init.d/rc.local script is executed near the end of the boot sequence, after udev has already probed devices and automatically loaded needed modules—so usb_storage may have been loaded long before this line ever runs. Moreover, simply writing a 'blacklist' directive in a shell script has no effect on the kernel's module autoloading mechanism; it must be processed by modprobe in its configuration files. This option neither prevents the module from loading nor configures the system declaratively.

resize2fs /dev/vg_data/lv_data; lvextend -L 15G /dev/vg_data/lv_data

Why wrong: resize2fs /dev/vg_data/lv_data; lvextend -L 15G /dev/vg_data/lv_data — Running resize2fs before lvextend attempts to grow the filesystem while the underlying logical volume still has its original size. The kernel block device size has not changed, so resize2fs will either report there is no space at the end of the device or fail to expand to the requested size. The filesystem must always be resized after the device layer is enlarged, not before.

lvextend -L 15G /dev/vg_data/lv_data; xfs_growfs /dev/vg_data/lv_data

Why wrong: lvextend -L 15G /dev/vg_data/lv_data; xfs_growfs /dev/vg_data/lv_data — Although the lvextend step is correct for growing the LV, xfs_growfs is the wrong tool because it is designed for XFS filesystems, not ext4. On RHEL 9, ext4 requires resize2fs to update its block group descriptors and superblock, whereas xfs_growfs manages XFS-specific allocation group structures and normally takes a mount point argument. Pointing xfs_growfs at an ext4 device will simply fail or have no effect.

lvreduce -L 15G /dev/vg_data/lv_data; resize2fs /dev/vg_data/lv_data

Why wrong: lvreduce -L 15G /dev/vg_data/lv_data; resize2fs /dev/vg_data/lv_data — This does the opposite of what is requested: lvreduce shrinks the logical volume to 15G instead of extending it to 15G. Shrinking an ext4 LV without first reducing the filesystem is dangerous and likely to corrupt data, though in this scenario the desired action is growth. The correct direction is to expand the LV first, then grow the filesystem to match.

nmtui edit enp1s0 --ipv4 192.168.1.100/24

Why wrong: nmtui is an interactive text-based interface; the 'edit' subcommand opens a full-screen editor where you navigate with arrow keys and tab, so it cannot accept inline arguments like '--ipv4 192.168.1.100/24'. The correct invocation would simply be 'nmtui edit enp1s0' followed by manual entry of the address. Providing extra CLI arguments causes nmtui to ignore them or exit with an error, so this does not configure anything.

ip addr add 192.168.1.100/24 dev enp1s0

Why wrong: The 'ip addr add' command applies the address immediately at the kernel level, but the change is volatile: it vanishes on reboot or whenever NetworkManager restarts or takes over the interface, since no connection profile is updated. It also does not set a default gateway or other properties, and it can conflict with NetworkManager's management of the device. This is useful for temporary testing but not a persistent configuration.

ifconfig enp1s0 192.168.1.100 netmask 255.255.255.0

Why wrong: ifconfig is part of the deprecated net-tools package and is no longer installed by default on modern RHEL releases. Even if present, 'ifconfig enp1s0 192.168.1.100 netmask 255.255.255.0' only changes the runtime configuration and is lost after a reboot; it also fails to set additional parameters like gateway or DNS. The command is considered obsolete in favor of the ip command and NetworkManager's nmcli.

192.168.1.10 /export/data /mnt/data nfs4 defaults 0 0

Why wrong: This line erroneously splits the remote source into two whitespace-delimited fields: the server IP (192.168.1.10) and the export path (/export/data). In /etc/fstab, an NFS mount must place the server and path together in a single fs_spec field separated by a colon, e.g., 192.168.1.10:/export/data. As written, the parser treats /export/data as the mount point and /mnt/data as an extra field, causing the mount to fail because there is no valid NFS source token.

/mnt/data 192.168.1.10:/export/data nfs4 defaults 0 0

Why wrong: This entry reverses the required column order. The first field in fstab must be the remote source (server:/export/data), and the second field must be the local mount point (/mnt/data). Here /mnt/data is placed in the fs_spec position and 192.168.1.10:/export/data in the fs_file position, which would make mount try to attach a local device named /mnt/data at a mount point named 192.168.1.10:/export/data—neither of which exists.

192.168.1.10:/export/data /mnt/data nfs defaults 0 0

Why wrong: The only deviation from the correct entry is the file system type nfs instead of nfs4. While nfs is a recognized fstab type, it permits negotiated NFS version selection, which can cause the client to fall back to NFSv3 depending on server settings or mount options. Since the task explicitly requires configuring an NFSv4 mount, nfs4 must be used to guarantee the v4 protocol; nfs is therefore incorrect because it does not pin the NFS version as required.

/etc/systemd/journald.conf

Why wrong: This file contains settings for systemd-journald, a separate logging daemon that manages its own binary journal. It does not control rotation of text-based syslog files like /var/log/messages. Although journald has size and retention limits (e.g., SystemMaxUse), those are not logrotate directives, and this path is not read by logrotate.

/etc/rsyslog.conf

Why wrong: This is the main configuration file for the rsyslog daemon. It defines input modules, rule sets, and output destinations, such as writing to /var/log/messages. It does not contain rotate, daily, weekly, size, or count directives, and logrotate does not parse this file; therefore changing it will not alter log rotation behavior.

/etc/cron.daily/logrotate

Why wrong: This path is a cron script maintained in the /etc/cron.daily directory that runs the logrotate utility each day. It is the scheduler or trigger that invokes /usr/sbin/logrotate with /etc/logrotate.conf, not a configuration file for individual log files. Any rotation settings for /var/log/messages belong in /etc/logrotate.d, so editing or replacing this script would be the wrong layer.

The SSH service is not running.

Why wrong: If sshd is not running, no user can access the system via SSH, but a single user reporting a login problem suggests a user-specific issue. The SSH service is a system-wide resource; its failure would affect all remote users simultaneously, not just one account. Furthermore, if the user is attempting a local console login, SSH is irrelevant entirely. Therefore, this cannot explain a single user's inability to log in.

The user account has been locked by pam_tally2.

Why wrong: pam_tally2 is deprecated in RHEL 9, replaced by pam_faillock, and it locks an account only after a specific number of failed authentication attempts. A lockout from pam_tally2 would produce a distinct message, such as 'Account locked due to N failed logins,' and would be visible via the faillock command or in /etc/shadow with a lock indicator. The user's issue is that the account is intentionally disabled, which is a different administrative state not caused by failed attempts. Thus, this is not the correct diagnosis.

The user's password has expired.

Why wrong: Password expiration is controlled by the chage policy and is stored in the expiration fields of /etc/shadow. When a password has expired, the user is not outright denied login; instead, the system forces an interactive password change before allowing access. Only an expired account (account expiration, not password expiration) would completely block authentication, and that is represented by a different shadow field. The user's inability to log in is due to an intentional account disablement, not a password aging issue.

rpm -q httpd

Why wrong: The rpm command queries the local RPM database, not any remote repository metadata. Running rpm -q httpd will only tell you whether that exact package is already installed on the system; if it is absent, the command exits with a non-zero status and prints nothing. This says nothing about whether httpd is available from configured DNF repositories, so it cannot be used to check availability.

dnf search httpd

Why wrong: dnf search httpd searches the package name, summary, and description fields for the keyword 'httpd' and returns a list of possibly many unrelated matches. It is broad and imprecise, and because it does not isolate a single package, you cannot conclude definitively whether the exact package httpd is available. The task calls for a precise availability check, not a keyword sweep.

dnf install httpd

Why wrong: dnf install httpd is the action of downloading and installing the package, which requires root privileges and permanently modifies the system. The question asks how to check availability, not to perform the installation. Running this command would change system state before you have confirmed what version or repository is available, making it inappropriate for a verification task.

'systemctl enable' starts the service immediately.

Why wrong: This is incorrect because 'systemctl enable' only creates symbolic links in the appropriate target dependencies (e.g., multi-user.target.wants) so the service starts automatically at boot time. It does not transition the unit to the running state in the current session. To both enable and immediately start the service, an administrator must combine it with 'systemctl start' or use 'systemctl enable --now'.

'systemctl mask' disables a service but allows manual start.

Why wrong: This claim is false because 'systemctl mask' does far more than simply disable a service. It creates a symlink to /dev/null for the unit's configuration, which effectively tells systemd that the unit does not exist, so both automatic and explicit manual start attempts are blocked. The only way to allow the service to start again is to run 'systemctl unmask' first, which removes the /dev/null link.

'systemctl disable' stops the service immediately.

Why wrong: This is incorrect because 'systemctl disable' only removes the startup symlinks that are checked at boot time; it has no effect on a service that is currently running. The daemon or process continues to run until it is explicitly stopped with 'systemctl stop' or it exits on its own. Disabling is therefore a boot-time setting, not a runtime control, and it is often used alongside 'systemctl stop' when the administrator wants the service off both now and at the next reboot.

Using the teamd service.

Why wrong: teamd is a user-space daemon that manages 'team' devices, a distinct link-aggregation mechanism built around the kernel team driver. It does not create bond interfaces; instead it configures teaming with its own syntax and is administered via teamdctl. On RHEL, teaming is also being deprecated, so using teamd is not a valid way to configure network bonding.

Editing /etc/sysconfig/network-scripts/ifcfg-bond0 directly.

Why wrong: On RHEL 8 and later, the legacy network-scripts package is deprecated and NetworkManager no longer reads ifcfg files by default unless NetworkManager.conf specifies `plugins=ifcfg-rh`. Manually editing /etc/sysconfig/network-scripts/ifcfg-bond0 without also creating slave ifcfg files, and without NetworkManager managing those devices, is unsupported and will not reliably bring up a bond.

ls -l test.txt

Why wrong: ls -l is incorrect because the long format displays permission bits, link count, owner, group, file size, and modification time, but it does not include any SELinux metadata. The -l option has no effect on whether contexts appear; to see contexts with ls, the -Z option must be added (e.g., ls -Z test.txt). Thus, ls -l alone cannot reveal the SELinux label.

sestatus

Why wrong: sestatus is incorrect because it reports system-wide SELinux state, such as whether SELinux is enabled, the current enforcing or permissive mode, and the configured policy (e.g., targeted, minimum, or mls). It does not accept a filename argument and has no mechanism to inspect the label of a specific object like test.txt. It answers the question 'Is SELinux on and what mode?' not 'What is this file's context?'

getenforce

Why wrong: getenforce is incorrect because it only prints the current SELinux mode as one of Enforcing, Permissive, or Disabled. This is a system-wide runtime setting, not a per-file attribute. Because it takes no file operand and returns only the enforcement state, it cannot show the security context of an individual file such as test.txt.

The Restart=on-failure directive is misconfigured.

Why wrong: The Restart=on-failure directive is not the reason for the exited state; it is a valid restart policy, but it only restarts a unit when the main process exits with a non-zero status, is terminated by a signal, or times out. If example.sh exits cleanly with status 0, systemd treats that as success and leaves the unit in the inactive/exited state. Even if a non-zero exit occurred, Restart=on-failure would trigger a new start attempt, not the 'exited' status, so the directive is not misconfigured.

The network.target dependency is not met.

Why wrong: network.target is a passive synchronization target that is reached very early in the boot process; it does not guarantee that networking is fully configured. If this dependency were unsatisfied, systemd would fail to order the unit or would not start it at all, rather than allowing it to run and exit. Because the service did run (it exited), network.target dependency was already satisfied, so this is not the cause of the status.

The administrator forgot to run systemctl daemon-reload after starting.

Why wrong: The systemctl daemon-reload command merely re-reads unit files after a change on disk; it has no effect on the runtime behavior of an already loaded unit. Forgetting to run it after starting a service is not meaningful because a freshly started unit has just loaded from disk, and no reload is needed. More importantly, daemon-reload cannot keep a process alive or change the fact that example.sh exits immediately; the observed status comes from the short-lived script, not from stale unit-file state.

Disable SELinux to allow the application to accept connections.

Why wrong: Disabling SELinux is a disproportionate response that does not target the actual failure. While SELinux can confine an application's network access through booleans such as httpd_can_network_connect, the symptom of an unreachable port with ping working points to firewalld filtering at the network layer, not a denial logged by SELinux. Furthermore, setting SELinux=disabled requires a reboot and severely weakens the system's mandatory access control protections; instead, one should inspect audit logs for AVC denials and, if needed, adjust a specific boolean or port label.

Change the application to listen only on the 10.0.0.100 interface.

Why wrong: Changing the application to listen only on 10.0.0.100 would not resolve the problem because the service is already listening on 0.0.0.0:8080, and the inbound SYN packets are being dropped by the firewall before they ever reach the application's socket. Restricting the bind address would actually reduce reachability, as it would prevent clients from using the server's other IP addresses or hostnames, and would still require the same firewall rule to allow traffic on that specific interface. The correct diagnosis is to examine firewalld rules rather than modify the application's configuration.

Add a static route for the 10.0.0.0/24 network via the 10.0.0.1 gateway.

Why wrong: Adding a static route is unnecessary because the clients already have reachability to the server — ping succeeds — meaning the routing tables are correct for the 10.0.0.0/24 network. A static route via 10.0.0.1 would only be relevant if the server needed to forward traffic to a different subnet, and it does not address the OSI Layer 4 filtering that is silently discarding TCP packets on port 8080. The drop is happening at the local host's firewall, not at the router.

setenforce

Why wrong: setenforce is an administrative utility used to change the running SELinux mode at runtime, passing 0 for permissive or 1 for enforcing; it requires root privileges and immediately alters kernel enforcement, but it never prints the current mode. When invoked without arguments it displays usage information rather than status, and it cannot be used to query whether SELinux is disabled. Because its entire purpose is to mutate policy state, it is not a valid command for merely displaying the current mode.

ausearch

Why wrong: ausearch queries the Linux audit logs, most commonly /var/log/audit/audit.log, filtering events by type, time, user, or to search for specific AVC denial messages tied to SELinux policy decisions. It reads historical records after an event has occurred and can help an administrator understand why a process was denied, but it has no mechanism to report the live SELinux mode. Therefore while it is SELinux-related in the broad sense, it is not a status-display tool.

semanage

Why wrong: semanage is part of the policycoreutils suite and is used to manage persistent SELinux policy configuration, including file contexts, port labels, booleans, and user-to-role mappings. It reads and writes the policy store underneath /etc/selinux rather than querying the kernel's current enforcement state. Since it is designed for modifying policy, not for reporting runtime status, it cannot display the current SELinux mode.

du -sh /data

Why wrong: Using `-s` on `/data` suppresses all recursion and prints a single summary line for the `/data` directory itself. This tells you the total size of the entire directory, but it hides the sizes of the individual files and subdirectories inside it. The command therefore fails to provide the per-top-level-item breakdown that the wildcard `du -sh /data/*` would produce.

du -h --max-depth=1 /data

Why wrong: The `--max-depth=1` option is a GNU extension rather than a POSIX-standard du flag, and it changes the recursion depth relative to the starting path. With `/data`, depth 1 means du prints a line for `/data` itself plus lines for each immediate child, so the output includes an extra parent entry. Additionally, if `/data` contains regular files, their sizes are folded into the parent line, not listed separately; thus the output is not a clean list of only the items inside `/data`.

Create /webcontent directory → Apply context with restorecon → Set SELinux context using semanage fcontext → Verify with ls -Z

Why wrong: Running restorecon before defining the fcontext rule is futile because restorecon has no policy entry to reference—it will apply the default context for the parent directory, which is typically not httpd_sys_content_t. The subsequent semanage fcontext command does not retroactively relabel the already-restored directory; it only writes a rule for future restorecon runs. The verification with ls -Z at the end will show the default context, so the directory remains inaccessible to Apache despite the rule existing later.

Set SELinux context using semanage fcontext → Apply context with restorecon → Create /webcontent directory → Verify with ls -Z

Why wrong: While semanage fcontext can be run before the directory exists (the rule is persistent), the subsequent restorecon runs when /webcontent is absent, so it has no target and completes with no effect. When the directory is then created, it inherits the default security context from its parent directory, not the custom httpd_sys_content_t defined in the fcontext rule. Since restorecon was already attempted too early, the final ls -Z reveals the wrong context, and the rule never gets applied to the actual directory.

Create /webcontent directory → Set SELinux context using semanage fcontext → Verify with ls -Z → Apply context with restorecon

Why wrong: Setting the fcontext rule establishes the intended type in policy, but ls -Z only reads the existing on-disk context—it does not trigger relabeling. At this point in the sequence, the directory still carries its original default context, so the verification shows the old type, giving a misleading result. Despite running restorecon later, that premature verification invalidates the order: the evidence that the context was correctly applied is generated before application actually happens, so the final state is not verified as required.

Enforcing: SELinux logs all actions but does not block them.

Why wrong: This option describes Permissive mode, not Enforcing mode: Enforcing does not merely log all actions without blocking; it actively denies unauthorized operations while recording only the denial events, not every action. If SELinux merely logged and never blocked, it would have no ability to contain a compromised process or prevent an administrator error from violating policy, leaving the system as unprotected as if SELinux were off.

Permissive: SELinux enforces the policy and blocks violations.

Why wrong: This option describes Enforcing mode's behavior, not Permissive mode. Permissive never blocks; it intentionally allows every action to proceed while logging AVC denials to the audit log. The entire point of Permissive mode is to observe what would be denied, so if it also enforced the policy and blocked violations, it would defeat its role as a troubleshooting and policy-validation tool.

Disabled: SELinux warns but does not block.

Why wrong: A disabled SELinux system does not warn at all—there is no policy engine running, no access control decision is made, and thus no denial or warning can be generated. The behavior of printing warnings while allowing actions to proceed is exactly what Permissive mode does; disabled mode is the complete absence of SELinux, not a weakened warning version of it.

The sshd service is not running

Why wrong: If the sshd service were not running, the SSH client would never reach the authentication stage. The TCP connection to port 22 would be refused or time out, producing errors such as 'Connection refused' or 'No route to host', not 'Permission denied (publickey)' or a repeated password prompt. The fact that the user receives an authentication error proves that the server is listening and the SSH handshake is completing, so sshd is definitely running.

The SELinux context is wrong

Why wrong: A wrong SELinux context on the user's SSH files would typically cause sshd to fail before any authentication prompt appears. The audit.log would show an AVC denial with a message like 'SELinux is preventing sshd from stat() access on the file authorized_keys'. This usually results in 'Connection closed by remote host' or 'Permission denied' only after a delay, but the log message and behavior differ from the direct strict-modes error about file permissions on .ssh/authorized_keys.

The .ssh/authorized_keys file has incorrect permissions

Why wrong: This is the correct diagnosis because sshd explicitly validates the ownership and mode of ~/.ssh and ~/.ssh/authorized_keys during public key authentication. If the authorized_keys file is group-writable, world-writable, or owned by the wrong user, sshd refuses to use it and reports 'Authentication refused: bad ownership or modes for /home/user/.ssh/authorized_keys'. The standard fix is to set the file to 600 and ensure it is owned by the user, then restart the SSH session.

vgcreate vg_data /dev/sdb; pvcreate /dev/sdb

Why wrong: This sequence is invalid because it calls vgcreate before the disk has been initialized as a physical volume. LVM will reject /dev/sdb as a vgcreate argument since no PV metadata exists on it; pvcreate must write that metadata first. Moreover, vgcreate is meant only for creating a new volume group, so it cannot be used to add a disk to the already-existing vg_data — that operation requires vgextend.

lvextend vg_data /dev/sdb

Why wrong: This command targets the wrong LVM object: lvextend extends a logical volume (an LV path such as /dev/vg_data/lvname), not a volume group. It also expects a size argument and a mounted or active LV, not a raw block device. Extending the vg_data volume group to include /dev/sdb is the role of vgextend, and even then the disk must first be converted to a PV with pvcreate.

pvcreate /dev/sdb; vgcreate vg_data /dev/sdb

Why wrong: Although this correctly initializes /dev/sdb as a PV with pvcreate, the subsequent vgcreate is wrong because vg_data already exists; running vgcreate with an existing VG name will fail with a 'Volume group vg_data already exists' error. vgcreate is only for carving out a brand-new volume group from one or more PVs. To add a new PV to an existing VG, the correct command is vgextend, which absorbs the PV into vg_data's pool of physical extents.

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

Why wrong: The -atime primary matches files whose access time (atime) is older than the specified number of days. Log files are typically written by a cron job and are almost never read afterward, so a log can be old and unread without its atime changing; conversely, a single read (e.g., by an operator or monitoring tool) can update atime, making a recent file appear old. This makes atime unreliable for deciding whether a log is stale, so this command will not target the intended files. Use -mtime to match when the log content was last modified.

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

Why wrong: Using -exec rm {} \; is functionally correct but much less efficient than -delete. For every matched file, find spawns a separate /bin/rm process, which costs time and system resources—especially problematic when a log directory has thousands of files. Additionally, -delete is implemented directly inside find without invoking an external program, reducing overhead and avoiding potential issues with command-line length or process limits. While -exec does pass filenames safely as arguments, it is an unnecessarily heavy way to remove a large batch of files.

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

Why wrong: The -ctime primary matches the inode change time, which records when the file's metadata (permissions, owner, link count, or rename status) last changed, and it is also updated whenever the file content is modified. For cleanup purposes, -mtime is the precise indicator of when the log data was written, whereas ctime can be misleadingly recent if, for example, a log was chowned or had its permissions tweaked after the last write. Even if the content is old, a metadata change would make -ctime +7 exclude that file, causing old logs to be kept. Therefore, -mtime is the correct time stamp for log retention.

sec=sys,ro

Why wrong: The sec=sys option (AUTH_SYS) simply trusts the uid and gid numbers sent by the client, so a root user on the client can spoof any user identity and there is no cryptographic authentication at all. Adding ro only forces the filesystem to be read-only; it does not add Kerberos authentication, encryption, or any proof of the client user's identity. This mount cannot ensure that only authorized users can access the NFS data.