Operate running systems practice questions

Restart=on-failure and RestartSec=30

Why wrong: Restart=on-failure triggers a service restart only when the process exits with a non-zero status or is terminated by a signal such as SIGKILL, but it intentionally ignores clean exit codes (0) and signals like SIGTERM that indicate a normal shutdown. Since the requirement is to restart the service after every crash, including those that might be recorded as a clean exit, and because this directive does not disable systemd's default start rate limiting (StartLimitIntervalSec=10, StartLimitBurst=5), systemd will still cease restart attempts after 5 rapid starts. Consequently, the service is left dead after repeated failures, violating the indefinite restart requirement.

Restart=always and RestartSec=30

Why wrong: Restart=always does force a restart after any exit, whether clean or unclean, and RestartSec=30 inserts a 30-second pause between attempts. However, this configuration omits any override of systemd's start rate limit, so the default StartLimitIntervalSec=10 and StartLimitBurst=5 apply: if the service crashes and is restarted more than 5 times within 10 seconds, systemd marks the unit as failed and stops trying. Even though Restart=always would otherwise restart forever, the built-in rate limiter silently overrides that behavior, meaning the service will eventually stop restarting and enter a failed state.

rsyslog reads log messages directly from the journal files in /var/log/journal.

Why wrong: rsyslog does not read the journal's binary files directly. Instead, it receives log messages either through its own input modules (like imjournal, which uses the journald API) or via forwarding from journald, such as when ForwardToSyslog is enabled. The files under /var/log/journal are in a format readable by journalctl and libsystemd, not by rsyslog.

The command 'journalctl --list-boots' lists only the current boot's journal entries.

Why wrong: The journalctl --list-boots option displays a numbered list of every boot for which the persistent journal contains records, not just the current one. Each line includes the boot ID and the time range for that boot. This allows administrators to select a specific boot with --boot= to view historical logs.

The command 'journalctl -u sshd.service' outputs the same as 'tail -f /var/log/messages' for SSH logs.

Why wrong: journalctl -u sshd.service queries the structured binary journal for records associated with the sshd service unit, and its output includes metadata fields and can reflect all journaled messages. In contrast, tail -f /var/log/messages follows a plain-text syslog file generated by rsyslog, which may have been modified or rotated and contains only messages that rsyslog chose to write. These two sources are not identical because the journal captures more information and the syslog file is a secondary, text-based representation.

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

Why wrong: A denial-of-service (DoS) attack seeks to exhaust the SSH daemon's resources or flood the TCP handshake queue, preventing legitimate users from connecting. The journal shows a sequential stream of 'Failed password' and one 'Accepted password' event, all from the same IP, which is not the signature of a DoS. In a DoS, you would expect incomplete handshakes, SYN floods, or a high volume of half-open connections, not repeated authentication attempts that reach the password prompt. The presence of a successful login further rules out a service-closing or resource-exhaustion scenario.

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

Why wrong: If sshd had a configuration error such as an invalid Match rule, a misconfigured MaxAuthTries value, or a broken PAM stack, connections might be abruptly terminated or never reach the authentication stage. However, the log shows each connection proceeding normally to a password check, with a 'Failed password' result for incorrect credentials and finally an 'Accepted password' entry. This proves that sshd is functional, logging properly, and successfully completing authentication. The failed attempts are simply due to wrong passwords supplied by a remote client, not a daemon malfunction.

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

Why wrong: The journal entries all originate from the same source address: 192.168.1.100. A coordinated attack from multiple hosts would scatter source IPs across the log, with each host trying its own set of passwords. Here, a single IP is responsible for all the failed attempts, which is typical of a single brute-force tool iterating through a dictionary of passwords. Therefore, the claim of 'multiple hosts' is not supported by the evidence shown.

Restart the network service → Edit the interface configuration file → Add GATEWAY and NETMASK directives → Identify the network interface

Why wrong: Starting with a network service restart is ineffective because the service simply re-reads the existing configuration files, which have not yet been modified to include the GATEWAY and NETMASK directives. After editing the file and adding the directives, you would need another restart to actually apply the new route, meaning this order adds a redundant restart and still leaves the interface identification for last, when it logically must come first to know which file to edit.

Edit the interface configuration file → Add GATEWAY and NETMASK directives → Restart the network service → Identify the network interface

Why wrong: Editing the interface configuration file before identifying the network interface is a critical error because every interface has its own ifcfg file (e.g., ifcfg-ens33), and without knowing which interface is in use you are likely to edit a file that is not active in the system. Even after adding the directives and restarting the service, you cannot retroactively identify the correct interface, so the route may be written to the wrong file or the wrong device, causing configuration drift and no functional static route.

Identify the network interface → Restart the network service → Edit the interface configuration file → Add GATEWAY and NETMASK directives

Why wrong: This order places the network service restart immediately after identifying the interface but before any configuration changes, so the restart applies the existing, unchanged configuration and does not load the new route. Once you then edit the file and add GATEWAY and NETMASK, those changes are not in effect until a second restart, making this sequence both redundant and incomplete—the service must be restarted only after all edits are saved.

First set the password for user 'jdoe', then create the user with useradd, then create the group 'staff', then verify the user and group memberships.

Why wrong: This is incorrect because you cannot set a password for a user that does not yet exist; the group must be created before the user if it is to be assigned as the secondary group.

First create the user 'jdoe' with useradd, then create the group 'staff', then set the password, then verify the user and group memberships.

Why wrong: This is incorrect because the group must exist before creating the user if it is to be assigned as the secondary group; otherwise, the group assignment will fail or the user will not be assigned the group correctly.

First create the user 'jdoe' with useradd, then set the password, then verify the user and group memberships, then create the group 'staff'.

Why wrong: Creating the user before the 'staff' group exists means that during useradd, the -g staff option cannot be applied correctly (or is absent entirely), so the user never gets 'staff' as a secondary group at creation time. Even after the group is created later, the user account is not automatically added to it, and verification performed before the group exists would falsely report an incomplete configuration. To achieve the intended result, the group must be created first or the user must be added via usermod -a -G staff after the group exists, but the sequence as given does neither, leaving jdoe without the required group membership.

swap: A file system used for storing temporary files (/var/tmp).

Why wrong: Swap is not a file system at all; it is a dedicated partition or a specially formatted file that the Linux kernel uses as virtual memory to page out inactive memory pages when RAM is full. The /var/tmp directory is ordinary persistent storage for temporary user files, typically placed on the root or a dedicated filesystem, and is completely unrelated to swap usage. Therefore, describing swap as a file system for /var/tmp confuses virtual memory management with temporary file storage.

ext4: A file system that supports subvolumes and snapshots.

Why wrong: While ext4 is the workhorse Linux filesystem with journaling and online growth, it does not provide subvolumes or snapshots; these capabilities belong to Btrfs. Subvolumes allow separate mountable tree instances within one filesystem, and snapshots create point-in-time views of the data, both of which are built upon Btrfs's copy-on-write design. This option is incorrect because it incorrectly credits ext4 with features that are unique to Btrfs, a distinction that often appears in filesystem comparison questions.

useradd: Modifies an existing user account

Why wrong: useradd cannot modify an existing account; if the username already exists, the command exits with an error such as 'useradd: user 'foo' already exists'. Modifications like changing the home directory, UID, or login shell are performed with usermod, which is specifically designed to alter attributes of already-created accounts. Attempting to use useradd for this purpose is a category error, because useradd only populates new entries.

usermod: Deletes a user account

Why wrong: usermod has no option to delete a user account; its sole purpose is to modify existing accounts. Deleting an account is exclusively the job of userdel, which removes the user's entries from /etc/passwd, /etc/shadow, and /etc/group. Running usermod with deletion in mind would not achieve the goal and could leave the account in an inconsistent state. Therefore, this pairing is incorrect.

userdel: Creates a new group

Why wrong: userdel is limited to deleting user accounts; it has no functionality to create groups. Group creation is handled by groupadd, which inserts a new entry into /etc/group and /etc/gshadow. The commands are separated by their purpose: userdel works with user entities, while groupadd manages group entities. This pairing confuses two distinct commands from the same suite.

groupadd: Modifies an existing group

Why wrong: groupadd only creates groups; it cannot modify an existing group. If the group already exists, groupadd returns an error indicating the group exists. To modify a group's name, GID, or other attributes, the correct command is groupmod, which updates the /etc/group and /etc/gshadow entries. Thus using groupadd to modify is functionally impossible and incorrect.

OnFailure=

Why wrong: OnFailure= is a unit dependency directive that specifies another unit to activate when the current unit enters a failed state. It does not cause the failed unit itself to be restarted; instead, it launches a separate designated unit (e.g., a notification or rescue service). To automatically restart the original service, you must set Restart= in the [Service] section, not rely on OnFailure=.

Requires=

Why wrong: Requires= declares a hard dependency: the listed unit must be active for this unit to start, and if the required unit stops or fails, this unit will be deactivated or stopped as well. This directive controls startup ordering and activation, not post-crash behavior. It does not monitor the service's process or schedule restarts; it simply enforces that dependencies remain satisfied at the time of start.

Wants=

Why wrong: Wants= is a weak dependency directive: it attempts to start the specified unit when this unit starts, but if that unit fails, the current unit continues running normally. It is about startup activation and ordering, not about reacting to crashes or restarting the service. Unlike Restart=always, Wants= contains no logic to monitor the service's runtime status or issue automatic restarts.

systemctl status

Why wrong: systemctl status is a diagnostic command that produces a detailed, human-readable snapshot of a unit, including the active state, main PID, memory usage, recent journal logs, and cgroup hierarchy. While the active state does appear in this output, status is not meant for programmatic checks; using it for that purpose forces you to parse multi-line text and extract the relevant state line, which is brittle and unnecessary when a dedicated check command exists.

systemctl list-units

Why wrong: systemctl list-units enumerates all loaded units and displays them in a table with columns for UNIT, LOAD, ACTIVE, SUB, and DESCRIPTION. To determine whether a single service is active this way, you would need to run the entire list, filter for the exact unit name, and then parse the ACTIVE column, which is indirect and unreliable because output can be truncated in narrow terminals or exclude inactive units unless --all is given. It answers the question of what units are loaded, not whether one specific unit is currently active.

systemctl show

Why wrong: systemctl show exposes the complete set of systemd unit properties as key-value pairs, including ActiveState, SubState, ExecMainPID, and many other configuration and runtime fields. While you can extract the ActiveState property using -p ActiveState, this command is designed for retrieving detailed property data, not for a quick, simple check; invoking it pulls a large amount of information and requires additional parsing to isolate the state, making it an unnecessarily heavy approach compared to systemctl is-active.

lvextend -r

Why wrong: lvextend -r combines the two steps: it first expands the logical volume to a specified size and then immediately invokes the filesystem resize tool (for ext4, resize2fs) to match. Because the logical volume has already been enlarged, running lvextend -r now would take the LV size even further, consuming additional free physical extents and possibly producing a filesystem larger than needed. It would have been a correct one-shot solution if used during the initial extension, but after the fact it is the wrong fix because it does not simply reconcile the existing filesystem with the current LV size.

fsadm resize

Why wrong: fsadm resize is an LVM helper that can resize filesystems, but for ext4 it merely wraps the same resize2fs logic behind a generic interface. The accepted and expected tool in an LVM/ext4 workflow is resize2fs directly; fsadm is intended for automated operations and its documentation points to resize2fs as the definitive ext4 resizer. Using fsadm now could work, but it is not the standard choice and introduces an unnecessary abstraction layer, so it is less precise than the correct answer.

xfs_growfs

Why wrong: xfs_growfs is specifically designed for the XFS filesystem, which has a different on-disk format, block bitmap structure, and resizing mechanism that relies on the mounted filesystem and magic number checks. It cannot parse or modify an ext4 superblock, block group descriptors, or inode tables, so it would fail immediately with an error indicating the target is not an XFS filesystem. Additionally, xfs_growfs requires a mount point argument rather than a block device, further demonstrating it is not appropriate for ext4.

usermod -f 60 jdoe

Why wrong: usermod -f 60 jdoe alters the INACTIVE field in /etc/shadow, defining how many days after a password has already expired the account is disabled. It does not set the password lifetime itself, so a user whose password never expires would never reach the inactivity grace period. To enforce a 60-day expiration, the MAX_DAYS field must be set, which is exactly what chage -M 60 jdoe does.

passwd -x 60 jdoe

Why wrong: The passwd -x 60 jdoe command does write the maximum password age (MAX_DAYS) to /etc/shadow, but it is a legacy interface that is not recommended for managing password aging policy. The EX200 exam expects chage because it provides a consistent, scriptable way to view and modify the full set of aging fields (-m, -M, -W, -I), whereas passwd mixes account maintenance with policy changes. Using chage -M 60 jdoe is the correct, unambiguous method to satisfy the requirement.

chage -m 60 jdoe

Why wrong: chage -m 60 jdoe sets the MIN_DAYS field in /etc/shadow, which is the minimum number of days that must pass before a user is allowed to change their password again. This is a password-history control designed to prevent users from cycling back to an old password immediately, not a lifetime limit. The security policy demands that passwords stop working after 60 days, so the correct field is MAX_DAYS, set with chage -M 60 jdoe.

systemctl set-default service

Why wrong: systemctl set-default is designed to select the default systemd target (such as multi-user.target or graphical.target) that the boot process loads, not to manage individual services. When given a service name, it attempts to treat that service as a target unit, which either fails or results in a meaningless boot target. Configuring a service to launch at boot requires creating unit-file symlinks in a .wants directory, which this command never does.

systemctl start service

Why wrong: systemctl start activates the service immediately in the current runtime session, but it does not create any persistent symlinks under /etc/systemd/system/*.wants/, so the service will not be triggered on subsequent reboots. This command is meant for one-time, immediate control of a unit's state, not for defining boot-time behavior. A service that is only started (and not enabled) will remain inactive after the next system boot unless another mechanism pulls it in.

systemctl reenable service

Why wrong: systemctl reenable is not the standard way to first configure a service to start at boot; it is primarily used to recreate the existing enablement symlinks after a unit file has been modified. The command performs a disable followed by an enable, which can temporarily remove the service's autostart links and then recreate them, but it is intended for refreshing configuration, not for the initial setup. While it may create the symlinks if they are missing, the canonical and expected command for configuring autostart is 'enable'.

dmesg -b -1

Why wrong: The dmesg command reads the kernel ring buffer, which by design contains only messages from the currently running kernel; it does not retain logs from previous boots. There is no -b option in dmesg to select a boot, unlike journalctl, so invoking dmesg -b -1 would produce an invalid option error. To read earlier boot messages, you must rely on the systemd journal rather than dmesg.

cat /var/log/boot.log

Why wrong: The /var/log/boot.log file, when it exists, is written during the current boot and typically holds only that boot's early startup messages. It is not a historical log and does not capture the previous crashed boot; in fact, on modern systemd-based distributions such as RHEL 8/9, this file may not even be present because boot logging is handled by journald. Therefore, reading this file cannot satisfy the need to review logs from before the crash.

journalctl -b 0

Why wrong: journalctl -b 0 selects the current boot (offset 0), which is the boot that started after the crash. While this is a valid journalctl command, it shows only the post-crash boot's messages, not the logs from the boot that failed. To examine the previous boot, you need -b -1; using -b 0 would show the recovery process, not the cause of the crash.

teamd

Why wrong: teamd is the user-space daemon that manages a team device, but for an administrator the correct workflow is to define the team via NetworkManager with nmcli. Running teamd directly is a low-level way to configure teaming, and it does not create persistent NetworkManager connection profiles, so it is not the recommended tool for combining two physical interfaces.

ip link

Why wrong: The ip link command can manually create a bond master and enslave interfaces (e.g., using ip link add and ip link set), but this configuration is ephemeral and does not survive a reboot. ip link lacks the abstraction of NetworkManager connection profiles, and RHEL expects bonds to be configured persistently, so while possible, it is not the recommended method.

brctl

Why wrong: brctl is the legacy tool for configuring Ethernet bridges, which forward traffic between network segments at layer 2 and behave like a virtual switch. Combining two physical interfaces into a bond or team is a different task entirely — it is link aggregation for redundancy or throughput, not bridging — so brctl is conceptually wrong.

/etc/mtab

Why wrong: /etc/mtab is a dynamically maintained file (a symlink to /proc/self/mounts) that lists currently mounted filesystems and their active options. It is written by the kernel, not read by the mount command to determine configuration, so editing it does not affect mounting behavior and changes are lost at reboot. To make noatime permanent, it must be specified in a persistent configuration file, not in this runtime status file.

/etc/sysconfig/network

Why wrong: /etc/sysconfig/network is a RHEL-specific file used to define host-level network settings such as HOSTNAME and default gateway. It is never parsed by mount, mountall, or systemd's filesystem generators, so adding noatime there has no effect on filesystem mounting. Mount options are handled exclusively by the filesystem table and mount command, not by network configuration scripts.

/etc/rc.d/rc.local

Why wrong: /etc/rc.d/rc.local is a boot-time script for local admin commands and is not consulted by the mounting infrastructure. Although you could place a 'mount -o noatime' command inside it, that is a one-off imperative workaround, not a persistent declarative configuration, and it runs only if the script is executable and the service is enabled. Standard RHEL practice and systemd tooling expect filesystem options to be declared in /etc/fstab, making rc.local incorrect for permanent noatime configuration.

chcon -R default_t /directory

Why wrong: chcon -R default_t /directory directly writes the specified SELinux type to the files' extended attributes, but it does not consult the policy's file_contexts rules. The label default_t is a generic unconfined type, not the proper context assigned to regular directories by the installed policy, so this would create further mislabeling. Additionally, any label set by chcon is temporary: the next full filesystem relabel or restorecon will overwrite it based on policy defaults.

semanage fcontext -R /directory

Why wrong: semanage fcontext -R /directory manages the persistent policy rules that associate path patterns with SELinux contexts, but it never directly modifies the extended attributes of existing files. In this command, -R means 'replace' for an existing rule (or is misread as recursive), not recursion over a directory; a newly added or modified fcontext rule only takes effect after you run restorecon on the target paths. Therefore this command changes policy configuration but leaves the restored files mislabeled until a separate relabeling step.

setfiles -v /directory

Why wrong: setfiles -v /directory is a low-level utility designed to apply a file_contexts specification to an entire filesystem or a large file tree, typically invoked during initial system installation or a full autorelabel, not for a single user directory. It accepts a file_contexts file as an argument and traverses the given path recursively, outputting verbose information with -v, but this approach is overkill and risks relabeling unrelated system directories if the path or context files are not carefully specified. For a targeted repair after a backup restore, restorecon is the proper tool because it relies on the active policy defaults without re-reading a custom specification.

systemctl status sshd

Why wrong: `systemctl status sshd` is primarily a status inquiry, not a journal query tool. While it does display a brief snippet of the most recent journal entries in its output, that snippet is limited to a handful of lines and is intended for a quick health check, not for browsing or filtering logs. It also does not support the full filtering and time-range options that `journalctl` offers, so it is not a substitute for viewing journal entries.

grep sshd /var/log/messages

Why wrong: `grep sshd /var/log/messages` is incorrect because `/var/log/messages` is a traditional text log file written by rsyslog, not the binary systemd journal. On a modern systemd-based system, the journal is the primary log repository, and `/var/log/messages` may not exist, may not contain all service-level entries, or may contain only messages forwarded by rsyslog at a lower verbosity. Grepping this file is a legacy approach that lacks the structured filtering and metadata that `journalctl` provides.

tail -f /var/log/secure

Why wrong: `tail -f /var/log/secure` is wrong because `/var/log/secure` is the traditional authentication and security log file, typically containing only messages related to auth events such as logins and sudo, not full service output. Furthermore, `tail -f` is a file-following command that monitors one specific text file in real time; it does not query the systemd journal at all. The journal stores logs in a binary format, so reading this legacy text file cannot give you complete unit logs for sshd.

system-config-network

Why wrong: system-config-network was a graphical and text-based tool used in RHEL 6 and earlier to manage network settings and write configuration files. It was removed from RHEL 8 and is not provided in RHEL 9, so it is unavailable on current systems. Because it no longer exists in the base distribution, it cannot be used as a valid network configuration method.

ifconfig

Why wrong: The ifconfig utility is part of the deprecated net-tools package, which is considered legacy and is not maintained in current RHEL releases. It lacks support for features such as multiple IPv6 addresses per interface or detailed flag reporting, and its use is discouraged in favor of ip. Therefore it is not a valid configuration method for modern RHEL systems.

uptime

Why wrong: The `uptime` command displays the current time, how long the system has been running, how many users are logged on, and the system load averages for 1, 5, and 15 minutes. Because it reports only processor load queue information and no memory counters, it cannot show overall memory utilization. While a high load average might indirectly correlate with memory pressure, uptime never reads from `/proc/meminfo`, so it is not a valid tool for this task.

ps aux

Why wrong: The `ps aux` command lists every process on the system with columns such as `%MEM`, `RSS`, and `VSZ`, which are per-process memory metrics obtained from `/proc/<pid>/statm` and `/proc/<pid>/status`. It does not aggregate these numbers to show a single system-wide total of used or free memory, nor does it include system-level caches and buffers in a summary line. Summing the RSS values manually would double-count shared pages and ignore kernel memory, so `ps aux` is not reliable for reporting overall memory usage.

yum clean all

Why wrong: yum clean all only removes cached RPM metadata and packages from /var/cache/yum, not any files under /var/log. It does not affect the journald binary journal or other log files, so it cannot free space in the location the question targets. Since the journal is the source of the disk pressure, using yum clean all is entirely orthogonal to the problem.

rm -rf /var/log/*

Why wrong: rm -rf /var/log/* is a dangerous, blunt-force command that deletes every regular file and subdirectory in /var/log, including active system logs needed for auditing and troubleshooting. Even worse, journald may keep deleted files open, so the space is not reclaimed until the journal service restarts, and system services that still write to those paths will recreate them and potentially fail. This approach breaks system logging best practices and is not a justified way to free space, especially when journald provides a safe, targeted command.

logrotate -f /etc/logrotate.conf

Why wrong: logrotate -f /etc/logrotate.conf forces a rotation cycle, which renames and compresses logs, but it does not necessarily delete old rotation archives unless the configuration specifies a low rotate count or a maxage policy. Typical logrotate configs retain four or more rotated logs, so the total disk usage in /var/log may stay similar or even increase temporarily due to new empty log files. Additionally, logrotate does not manage journald's binary journal files, so it cannot reduce the journal size, which is the core issue here.