Courseiva

CCNA Operate running systems Questions

26 questions · Operate running systems · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

An administrator needs to combine two physical network interfaces into a single logical interface for redundancy. Which RHEL tool is recommended to configure this in RHEL 8/9?

A.teamd
B.ip link
C.brctl
D.nmcli
AnswerD

nmcli is the NetworkManager command-line utility and is the recommended way to configure a bond or team on RHEL systems. For example, you can run nmcli connection add type bond to create the bond master, then add slave interfaces, and NetworkManager will persist the configuration and manage the underlying teamd or bonding driver automatically.

Why this answer

In RHEL 8/9, NetworkManager is the default networking service, and `nmcli` is its command-line tool. For bonding (combining two physical interfaces into a single logical interface for redundancy or increased throughput), the recommended approach is to use `nmcli` to create a bond connection, which uses the Linux kernel bonding driver. The `teamd` service was deprecated in RHEL 8 and removed in RHEL 9, making `nmcli` the correct and supported method.

Exam trap

The trap here is that candidates familiar with older RHEL versions (RHEL 7 or earlier) may remember `teamd` as the recommended tool for teaming, but RHEL 8/9 deprecated and removed it, making `nmcli` the correct answer for bonding.

How to eliminate wrong answers

Option A is wrong because `teamd` (libteam) was deprecated in RHEL 8 and removed in RHEL 9; it is no longer a supported tool for interface aggregation. Option B is wrong because `ip link` is a low-level tool for managing network interfaces individually (e.g., creating VLANs or bridges) but cannot create a persistent bond configuration that integrates with NetworkManager; it lacks the abstraction and persistence needed for a production bond setup. Option C is wrong because `brctl` is used to manage Ethernet bridges (for bridging/switching, not bonding/aggregation); it creates a bridge that forwards traffic based on MAC addresses, not a redundant logical interface that combines bandwidth or provides failover.

Practice this question →
2
Multi-Selecteasy

A system administrator needs to ensure a service called 'myapp' starts automatically at boot and also start it immediately without affecting the current boot configuration. Which TWO commands should be used?

Select 2 answers
A.systemctl daemon-reload myapp
B.systemctl start myapp
C.systemctl restart myapp
D.systemctl activate myapp
E.systemctl enable myapp
AnswersB, E

`systemctl start myapp` immediately activates the unit by loading it into memory, satisfying its dependencies, and launching the main process defined in `ExecStart`. This changes the unit's *active* state but not its *enabled* state, so myapp will not automatically start after a reboot unless it is also enabled.

Why this answer

The 'systemctl enable myapp' command creates the necessary symlinks so that the service starts automatically at boot, while 'systemctl start myapp' launches the service immediately in the current session without altering the boot configuration. Together, they satisfy both requirements without affecting the existing boot setup.

Exam trap

The trap here is that candidates confuse 'enable' with 'start' or think 'restart' or 'daemon-reload' can achieve both goals, but only the combination of 'enable' (for boot persistence) and 'start' (for immediate activation) meets the exact requirements.

Practice this question →
3
MCQeasy

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

A.The system is under a denial-of-service attack because the connections are being closed before authentication.
B.The SSH service is malfunctioning and dropping connections due to a configuration error.
C.Multiple hosts are attempting to connect to the SSH service simultaneously, causing connection errors.
D.The system experienced a brute-force attack on the root account originating from IP 192.168.1.100, which eventually succeeded.
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
4
Matchingmedium

Match each file system type to its description.

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

Concepts
Matches

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

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

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

Used for virtual memory, typically as a partition or file

Why these pairings

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

Practice this question →
5
MCQhard

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

A.The SSH daemon is already running on another port.
B.Another process is already listening on port 22.
C.The sshd configuration file has a syntax error.
D.The service is not enabled.
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
6
Matchingmedium

Match each user/group management command to its function.

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

Concepts
Matches

Create a new user account

Modify an existing user account

Create a new group

Set or change a user's password

Why these pairings

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

Practice this question →
7
MCQeasy

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

A.OnFailure=
B.Requires=
C.Restart=always
D.Wants=
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
8
Multi-Selecteasy

Which TWO commands can be used to view recent systemd journal logs for the current boot?

Select 2 answers
A.journalctl -p err
B.journalctl --list-boots
C.journalctl -b
D.journalctl --boot
E.journalctl --since today
AnswersC, D

journalctl -b is correct because it is the shorthand form of the --boot option, which instructs journald to display only the log messages from the current boot. This is the standard, concise way to view the most recent journal entries generated since the system started, making it ideal for troubleshooting issues in the current session. The -b flag accepts an optional argument like -1 to inspect previous boots, but with no argument it defaults to the current boot.

Why this answer

`journalctl -b` displays logs from the current boot, which is the default behavior when no boot ID is specified. This command directly queries the systemd journal for messages generated during the current system session.

Exam trap

The trap here is that candidates may confuse `--list-boots` (which lists boot IDs) with actually viewing logs, or think that `--since today` is equivalent to `-b`, when in fact `--since today` can span multiple boots if the system has been running for days.

Practice this question →
9
MCQeasy

Which systemctl command configures a service to start automatically at boot without starting it now?

A.systemctl set-default service
B.systemctl start service
C.systemctl enable service
D.systemctl reenable service
AnswerC

systemctl enable is the correct command to configure a service to start automatically at boot because it creates symlinks from the service unit into the appropriate .wants or .requires directories, based on the [Install] section of the unit file. For example, a service with WantedBy=multi-user.target will get a symlink in /etc/systemd/system/multi-user.target.wants/. This action does not start the service immediately, but it ensures systemd activates it when the target is reached during boot.

Why this answer

`systemctl enable service` creates the necessary symlinks in the systemd unit configuration directories (e.g., `/etc/systemd/system/multi-user.target.wants/`) to ensure the service starts automatically at boot, but it does not start the service immediately. This matches the requirement of configuring automatic startup without starting the service now.

Exam trap

The trap here is confusing `systemctl enable` with `systemctl start`; candidates often think enabling a service also starts it, but systemd separates these actions to allow administrators to schedule automatic startup without immediate execution.

How to eliminate wrong answers

Option A is wrong because `systemctl set-default` sets the default target (e.g., multi-user.target) for the system, not a service; it does not configure a service to start at boot. Option B is wrong because `systemctl start service` starts the service immediately but does not enable it for automatic startup at boot; it only affects the current runtime state. Option D is wrong because `systemctl reenable service` removes and recreates the enable symlinks, which is used to fix broken enablement but does not specifically address the requirement of not starting the service now; it also implies the service is already enabled.

Practice this question →
10
MCQmedium

A server running Red Hat Enterprise Linux 9 experiences high system load (load average 15 on a 4-core system) and slow response times. The administrator runs 'top' and sees that the 'kworker' processes are consuming significant CPU time. Further investigation reveals that the system is performing heavy I/O operations on the root filesystem, which is formatted as XFS. The administrator wants to reduce the impact of filesystem maintenance tasks on system performance. Which of the following actions should the administrator take?

A.Increase the value of the 'nr_requests' queue parameter for the underlying block device.
B.Mount the filesystem with the 'noatime' option to reduce metadata updates.
C.Schedule filesystem checks (fsck) to run during off-peak hours using a cron job.
D.Set the dirty ratio sysctl parameters (vm.dirty_ratio and vm.dirty_background_ratio) to lower values.
AnswerD

Lowering vm.dirty_ratio and vm.dirty_background_ratio reduces the amount of dirty page cache allowed to accumulate before the kernel forces writeback. This causes the flusher threads to run more frequently with smaller batches, which smooths I/O bursts and prevents the CPU and disk from being pegged by large writeback spikes. These parameters directly control the dirty-page writeback behavior described in the scenario, making them the correct tuning target.

Why this answer

The high system load is caused by heavy I/O operations, and the kworker processes indicate kernel threads handling writeback. Lowering vm.dirty_ratio and vm.dirty_background_ratio reduces the amount of dirty pages that accumulate before writeback begins, which prevents large bursts of I/O and smooths out disk writes, thereby reducing the impact on system performance.

Exam trap

The trap here is that candidates confuse filesystem maintenance tasks (like fsck or atime updates) with kernel writeback mechanisms, and incorrectly choose options that address metadata or integrity checks rather than the actual I/O load caused by dirty page flushing.

How to eliminate wrong answers

Option A is wrong because increasing 'nr_requests' for the block device queue allows more I/O requests to be queued, which can increase latency and worsen the problem under heavy I/O, not reduce it. Option B is wrong because 'noatime' reduces metadata updates for file access times, but the issue here is heavy I/O from filesystem maintenance tasks, not atime updates; it would not address the kworker writeback load. Option C is wrong because scheduling fsck with cron is for checking filesystem integrity, not for reducing the impact of ongoing maintenance tasks; fsck is run on unmounted filesystems and does not affect runtime I/O performance.

Practice this question →
11
Multi-Selectmedium

Which two commands can be used to view systemd journal entries for the sshd service?

Select 2 answers
A.journalctl -u sshd
B.systemctl status sshd
C.journalctl _SYSTEMD_UNIT=sshd.service
D.grep sshd /var/log/messages
E.tail -f /var/log/secure
AnswersA, C

The `journalctl -u sshd` command is the standard way to query the systemd journal for all log messages associated with the sshd unit. The `-u` flag filters by unit name, showing entries from both the current boot and previous boots if persistent journaling is enabled. This command reads the binary journal directly, making it the accurate and complete method for viewing a service's logs.

Why this answer

`journalctl -u sshd` filters the systemd journal to show only log entries associated with the `sshd.service` unit. This is the standard way to view service-specific logs in a systemd-based system, as it uses the unit name directly. Option C is also correct because `_SYSTEMD_UNIT=sshd.service` is a systemd journal field that matches the exact unit name, providing an equivalent filter to `-u sshd`.

Exam trap

On Red Hat Enterprise Linux (RHEL) systems with systemd, the primary logging mechanism is the journal. The trap is that candidates may mistakenly use `systemctl status sshd` (which only shows a snippet) or rely on legacy syslog files like `/var/log/messages` or `/var/log/secure` instead of `journalctl`.

Practice this question →
12
Multi-Selectmedium

Which three network configuration methods are valid in RHEL 8/9?

Select 3 answers
A.system-config-network
B./etc/sysconfig/network-scripts/ifcfg-* files
C.nmcli
D.ip command
E.ifconfig
AnswersB, C, D

The /etc/sysconfig/network-scripts/ifcfg-* files define persistent network interface settings such as IP addressing, boot protocol, and device name. While NetworkManager by default does not automatically manage interfaces configured only via these files, it can still read them, and they are recognized by the system as a valid legacy configuration mechanism. In fact, RHEL 8 and RHEL 9 continue to support ifcfg files, though they are deprecated in favor of NetworkManager keyfiles.

Why this answer

In RHEL 8/9, the traditional `/etc/sysconfig/network-scripts/ifcfg-*` files are still supported for backward compatibility, though NetworkManager is the default service. These files define interface configurations using variables like `DEVICE`, `BOOTPROTO`, and `ONBOOT`, and are read by the `ifup`/`ifdown` scripts or NetworkManager when configured to use them. This method remains valid for static or DHCP-based network setup without requiring a GUI.

Exam trap

The trap here is that candidates confuse deprecated tools (like `ifconfig` and `system-config-network`) with valid configuration methods, or assume that any command that can set an IP address qualifies as a persistent network configuration method.

Practice this question →
13
MCQeasy

Which command checks if a specific systemd service is currently running?

A.systemctl is-active
B.systemctl status
C.systemctl list-units
D.systemctl show
AnswerA

systemctl is-active directly queries the systemd manager over the D-Bus interface for the unit's current runtime state and prints a single word such as 'active', 'inactive', 'activating', or 'failed'. Its exit code is also set to 0 only when the service is active, making it the ideal tool for shell conditionals and monitoring scripts because it requires no output parsing or filtering.

Why this answer

The `systemctl is-active` command is specifically designed to check whether a systemd service is currently in the 'active' (running) state. It returns an exit code of 0 if the service is active, and a non-zero exit code otherwise, making it ideal for scripting and direct status checks.

Exam trap

Candidates often confuse `systemctl status` with `systemctl is-active`. While `systemctl status` displays detailed information including whether the service is running, it does not return a simple exit code for scripting. The question specifically asks for a command that *checks* if a service is currently running, which `systemctl is-active` does via its exit code, making it the correct choice for automation and direct status queries in Red Hat Enterprise Linux.

How to eliminate wrong answers

Option B is wrong because `systemctl status` displays detailed information about a service, including its current state, but it is not the command specifically designed to return a simple active/inactive exit code for scripting; it outputs human-readable text. Option C is wrong because `systemctl list-units` lists all loaded units and their states, but it does not target a specific service and requires parsing output to determine if a single service is running. Option D is wrong because `systemctl show` displays all properties of a unit in key-value format, which is useful for detailed configuration inspection but not for a direct running/not-running check.

Practice this question →
14
Multi-Selecthard

Which three commands can be used to display overall memory usage information?

Select 3 answers
A.free
B.uptime
C.top
D.ps aux
E.vmstat
AnswersA, C, E

`free` is a dedicated memory-reporting utility that reads from `/proc/meminfo` and displays a concise summary of total, used, free, shared, buff/cache, and available physical memory, along with swap usage. Modern versions emphasize the `available` field, which estimates how much memory can be allocated without swapping, unlike the more misleading `free` column. This makes `free` a straightforward and accurate command for quickly checking overall memory utilization.

Why this answer

The 'free' command displays the total, used, and available physical and swap memory on the system. It reads /proc/meminfo and presents a concise summary of memory usage, making it a primary tool for checking overall memory consumption.

Exam trap

Red Hat often tests the distinction between commands that show per-process memory (like ps aux) versus those that show system-wide memory totals (like free, top, vmstat), leading candidates to incorrectly select ps aux as a memory usage command.

Practice this question →
15
Multi-Selectmedium

Which TWO statements about systemd journal and rsyslog are correct?

Select 2 answers
A.rsyslog reads log messages directly from the journal files in /var/log/journal.
B.The command 'journalctl --list-boots' lists only the current boot's journal entries.
C.The command 'journalctl -u sshd.service' outputs the same as 'tail -f /var/log/messages' for SSH logs.
D.The journal stores logs in a structured binary format, allowing filtering by fields like _UID or _SYSTEMD_UNIT.
E.The journal can forward log messages to rsyslog by setting ForwardToSyslog=yes in /etc/systemd/journald.conf.
AnswersD, E

The systemd journal is stored as a compact, indexed binary database, not as text. Each entry includes a rich set of structured metadata fields, such as _UID, _SYSTEMD_UNIT, _PID, and _COMM, which can be used for powerful filtering with journalctl, e.g., journalctl _UID=1000. This design enables more precise querying than plain-text log files.

Why this answer

The systemd journal stores log data in a structured binary format (using the journald protocol), which allows filtering by specific fields such as _UID, _SYSTEMD_UNIT, or _COMM. This enables precise queries via journalctl, unlike plain-text log files.

Exam trap

The trap here is that candidates confuse the journal's structured binary format with plain-text log files, or assume rsyslog reads journal files directly, when in fact forwarding is configured via journald.conf.

Practice this question →
16
MCQhard

An ext4 filesystem on a logical volume has been extended with lvextend, but df -h still shows the old size. Which command must be run to make the filesystem aware of the new size?

A.lvextend -r
B.fsadm resize
C.resize2fs
D.xfs_growfs
AnswerC

resize2fs is the correct command because the logical volume has already been grown and only the ext4 filesystem's metadata still reflects the old smaller size. Running resize2fs /dev/yourvg/yourlv without a size argument makes the filesystem expand to use all available space in the enlarged logical volume. It can be used online for mounted ext4 filesystems, making it the direct and standard method to complete the extension.

Why this answer

The `resize2fs` command is the correct tool to resize an ext4 filesystem after the underlying logical volume has been extended with `lvextend`. While `lvextend` expands the block device, the filesystem itself is not automatically aware of the new space; `resize2fs` adjusts the filesystem metadata to utilize the additional capacity.

Exam trap

The trap here is that candidates may confuse the filesystem-specific commands (resize2fs for ext4 vs. xfs_growfs for XFS) or assume that extending the logical volume automatically resizes the filesystem, which is only true if the `-r` flag is used with `lvextend`.

How to eliminate wrong answers

Option A is wrong because `lvextend -r` is a valid shortcut that combines extending the logical volume and resizing the filesystem, but the question asks which command must be run after `lvextend` has already been executed without the `-r` flag. Option B is wrong because `fsadm resize` is a utility for resizing filesystems on LVM volumes, but it is not the standard command for ext4; `resize2fs` is the direct and preferred tool. Option D is wrong because `xfs_growfs` is used to grow XFS filesystems, not ext4 filesystems.

Practice this question →
17
MCQeasy

To mount an ext4 filesystem with the noatime option and remount read-only on errors, which file should be edited?

A./etc/mtab
B./etc/sysconfig/network
C./etc/fstab
D./etc/rc.d/rc.local
AnswerC

/etc/fstab is the static filesystem table read by mount when you run 'mount -a' and by systemd-fstab-generator at boot. To make an ext4 filesystem mount with noatime persistently, you add that option to the fourth field (options) of its /etc/fstab entry. After editing, running 'mount -o remount /mountpoint' applies the change without rebooting. This is the canonical place for persistent mount options, including noatime.

Why this answer

The /etc/fstab file is the system configuration file that defines how disk partitions, block devices, and remote filesystems should be mounted into the filesystem tree. To mount an ext4 filesystem with the noatime option and to remount it read-only on errors, you add the options 'noatime,errors=remount-ro' in the fourth field (mount options) of the corresponding entry in /etc/fstab. This ensures the options are applied automatically at boot and during subsequent mount operations.

Exam trap

The RHCSA exam often tests the distinction between /etc/fstab (persistent configuration) and /etc/mtab (current mount state), leading candidates to mistakenly think editing /etc/mtab will persist mount options across reboots.

How to eliminate wrong answers

Option A is wrong because /etc/mtab is a dynamically maintained file that lists currently mounted filesystems; editing it does not persist mount options across reboots and is not used for configuration. Option B is wrong because /etc/sysconfig/network is a Red Hat Enterprise Linux file used for network configuration (e.g., hostname, gateway), not for filesystem mount options. Option D is wrong because /etc/rc.d/rc.local is a legacy script executed at the end of the boot process; while you could add mount commands there, it is not the standard or recommended location for defining persistent mount options, and it would not be used by the mount command automatically.

Practice this question →
18
MCQhard

A system administrator is troubleshooting a custom service called 'database.service' that fails intermittently. The service is a proprietary database that requires large amounts of memory. The administrator runs systemctl status database and sees 'Active: failed (Result: core-dump)' and the journal shows 'Out of memory: Killed process (database) total-vm:...' The server has 8GB RAM and 2 CPU cores. The service unit file does not contain any memory limits. The application is configured to use up to 4GB. The administrator suspects the systemd service is being killed by the OOM killer. Which action should the administrator take to prevent this issue?

A.Set MemoryMax=6G in the service unit file.
B.Set OOMScoreAdjust=-1000 in the service unit file.
C.Modify kernel parameters to disable the OOM killer.
D.Increase swap space to 16GB.
AnswerB

Setting OOMScoreAdjust=-1000 in the service unit file writes -1000 to /proc/<pid>/oom_score_adj, making the process's OOM score effectively zero and marking it as the kernel's last choice for OOM victim selection. This is a direct, unit-level mitigation that applies only to the custom service, so it doesn't weaken system-wide OOM behavior. It is the recommended way to protect a critical service from being killed.

Why this answer

Setting OOMScoreAdjust=-1000 makes the systemd service less likely to be targeted by the OOM killer. The OOM killer selects processes based on a badness score; a lower score (down to -1000) reduces the likelihood of being killed. Since the service is already configured to use up to 4GB and the server has 8GB RAM, adjusting the OOM score is the targeted fix without disabling kernel protections or over-allocating resources.

Exam trap

The trap here is that candidates confuse systemd's cgroup memory limits (MemoryMax) with the kernel OOM killer's scoring mechanism, or they think disabling the OOM killer or adding swap is a safe solution, when the correct approach is to adjust the OOM score to protect the specific service.

How to eliminate wrong answers

Option A is wrong because MemoryMax=6G would set a cgroup memory limit that could cause the service to be killed by systemd's own OOM logic before the kernel OOM killer acts, and it does not address the kernel OOM killer's scoring; the service already uses up to 4GB, so a 6GB limit may still trigger OOM kills if other processes consume memory. Option C is wrong because disabling the OOM killer entirely (e.g., via vm.oom_kill_allocating_task=0 or panic_on_oom=0) is dangerous and not recommended; it can lead to system hangs or unresponsive states, and it is not a targeted fix for a single service. Option D is wrong because increasing swap space to 16GB only delays OOM conditions and can cause severe performance degradation (thrashing); the OOM killer may still kill the process if memory pressure persists, and it does not address the root cause of the service being scored high by the OOM killer.

Practice this question →
19
MCQmedium

A storage administrator has added a new 10 GiB disk (/dev/vdb) to a Red Hat Enterprise Linux 9 server. The requirement is to create a single XFS filesystem on the entire disk and mount it persistently at /data. The administrator runs mkfs.xfs /dev/vdb and then adds the line '/dev/vdb /data xfs defaults 0 0' to /etc/fstab. After running mount -a, the mount succeeds and df -h shows the expected size. However, after a reboot the system drops into emergency mode and reports that /data cannot be mounted. The administrator verifies that the disk is still present and the filesystem is intact. Which of the following is the most likely cause of the failure?

A.The XFS filesystem was created directly on /dev/vdb instead of on a partition such as /dev/vdb1, so the kernel cannot resolve the device at boot.
B.The /etc/fstab entry relies on the kernel device name /dev/vdb, which is not guaranteed to be stable across reboots; a persistent identifier such as a UUID or label should be used instead.
C.The XFS filesystem must be registered with the kernel using xfs_admin before it can be mounted automatically at boot.
D.The XFS filesystem must be mounted with the 'nofail' option in /etc/fstab, otherwise any filesystem mount failure will always halt the boot process.
AnswerB

Kernel-assigned names like /dev/vdb are not guaranteed to remain the same across reboots, especially when other devices are added or removed. If the device is renumbered, the fstab entry points at the wrong block device and the mount fails, dropping the system into emergency mode. Using the filesystem UUID or a label makes the entry stable and is the recommended practice for persistent mounts.

Why this answer

Persistent mounts should reference a stable identifier rather than a kernel-assigned device name. When /etc/fstab uses /dev/vdb, a reboot that reorders block devices can cause the mount unit to fail and the system to enter emergency mode. Querying the filesystem UUID with blkid and substituting UUID=... in /etc/fstab makes the entry resilient to device renaming and restores normal boot behavior.

Exam trap

The trap here is assuming that a mount that works interactively will always work after a reboot, overlooking that kernel device names are not stable identifiers.

Practice this question →
20
MCQhard

After restoring files from backup, an SELinux context of a directory is not correct. Which command will restore the file contexts to the system defaults?

A.chcon -R default_t /directory
B.restorecon -R /directory
C.semanage fcontext -R /directory
D.setfiles -v /directory
AnswerB

restorecon -R /directory reads the current file_contexts database to determine the policy-defined default context for every path under /directory and, with -R, recursively resets the security.selinux extended attribute on any file whose label differs from that default. It does not alter permissions or ownership and only touches files that are actually mislabeled, making it the standard, safe repair tool after a backup restore. Unlike chcon, it uses authoritative policy rules, so it guarantees a consistent context that will survive a future autorelabel.

Why this answer

The `restorecon -R /directory` command reads the default SELinux contexts from the policy (stored in the file_contexts database) and applies them recursively to the specified directory. This is the standard method to reset file contexts to system defaults after a restore or misconfiguration.

Exam trap

The trap here is that candidates confuse `chcon` (which sets an arbitrary context) with `restorecon` (which sets the default context from policy), or they think `semanage fcontext` directly modifies file contexts rather than the policy database.

How to eliminate wrong answers

Option A is wrong because `chcon` sets a context manually but does not reference the system defaults; `default_t` is not a valid SELinux type and the command would fail or set an incorrect context. Option C is wrong because `semanage fcontext` is used to add, modify, or delete default context rules in the policy database, not to apply them to files; it requires a subsequent `restorecon` to take effect. Option D is wrong because `setfiles` is a low-level tool typically used to verify or relabel entire filesystems during boot or maintenance, not for targeted restoration of a single directory; it also requires a specification file and is not the standard interactive command for this task.

Practice this question →
21
MCQhard

After a system crash, an administrator needs to review logs from the previous boot. Which command shows only logs from the boot before the current one?

A.journalctl -b -1
B.dmesg -b -1
C.cat /var/log/boot.log
D.journalctl -b 0
AnswerA

journalctl -b -1 displays the journal entries from the boot immediately preceding the current one, using a boot offset of -1. This is the appropriate command after a system crash because it lets you inspect the logs from the crashed boot without including the current recovery boot's messages. For this to work, the journal must be persisted across reboots, typically in /var/log/journal, rather than only in memory.

Why this answer

The `journalctl -b -1` command shows logs from the previous boot by using the `-b` (boot) option with an offset of `-1`, which refers to the boot session immediately before the current one. This is the correct way to access historical boot logs in systems using systemd-journald, as the journal retains logs from multiple boots by default.

Exam trap

The trap here is that candidates confuse the offset numbering: `-b 0` refers to the current boot, not the previous one, leading them to select option D, while the correct offset for the previous boot is `-1`.

How to eliminate wrong answers

Option B is wrong because `dmesg` does not support a `-b` flag; `dmesg` reads kernel ring buffer messages for the current boot only and cannot access logs from previous boots. Option C is wrong because `/var/log/boot.log` is a legacy file used by sysvinit or early boot scripts, not by systemd, and it only contains messages from the current boot, not previous ones. Option D is wrong because `journalctl -b 0` shows logs from the current boot (offset 0), not the previous boot.

Practice this question →
22
MCQmedium

A system administrator receives reports that a web server service (httpd) fails to start after a reboot. The administrator checks the service status and sees it is disabled. Which of the following is the most appropriate command to ensure the service starts automatically on future reboots?

A.systemctl start httpd
B.systemctl enable httpd
C.systemctl restart httpd
D.systemctl daemon-reload
AnswerB

This is the correct command because it creates symbolic links in /etc/systemd/system/ (typically into multi-user.target.wants or similar) that instruct systemd to start httpd automatically at boot. It does not start the service immediately; it only establishes the persistent configuration for future boots. This directly addresses the requirement that the web server starts automatically after a reboot.

Why this answer

The `systemctl enable httpd` command creates the necessary symlinks in the systemd unit configuration directory (typically `/etc/systemd/system/multi-user.target.wants/`) to ensure the httpd service starts automatically at boot. Since the service is disabled after reboot, enabling it is the correct action to set it to start on future reboots.

Exam trap

The trap here is that candidates confuse `systemctl start` (immediate runtime action) with `systemctl enable` (boot-time configuration), leading them to choose a command that works now but fails to persist across reboots.

How to eliminate wrong answers

Option A is wrong because `systemctl start httpd` starts the service immediately but does not configure it to start automatically on future reboots; it only affects the current session. Option C is wrong because `systemctl restart httpd` stops and then starts the service immediately, which is irrelevant to setting the service to start at boot. Option D is wrong because `systemctl daemon-reload` reloads systemd manager configuration and unit files, but it does not enable or disable services; it is used after modifying unit files, not to set boot-time behavior.

Practice this question →
23
MCQmedium

Refer to the exhibit. What is the most likely cause of the httpd service failure?

A.The httpd service is disabled.
B.The Apache configuration has a syntax error.
C.The /var/www/html directory does not exist.
D.SELinux context on /var/www/html/index.html is incorrect.
AnswerB

A syntax error in Apache's configuration would prevent the server from starting or reloading cleanly, typically producing an explicit error like `Syntax error on line ...` in the error log or when running `apachectl configtest`. The exhibited log contains no such configuration complaint; instead, it shows an active request ending with `Permission denied`. Since Apache is running and serving the request, a configuration syntax error is not the cause.

Why this answer

The most likely cause of the httpd service failing to start is a configuration syntax error (option B). When the Apache configuration contains an invalid directive or syntax mistake, `httpd` will refuse to start and report the error via `apachectl configtest` or `systemctl start httpd`. A missing document root may cause a warning but does not prevent startup; incorrect SELinux context leads to 403 errors but does not stop the service; and a disabled service only affects boot-time startup, not manual starts.

Exam trap

Candidates may overlook that some issues (like SELinux or file permissions) prevent serving content but do not crash the service. Always distinguish between the service failing to start vs. failures in serving requests.

How to eliminate wrong answers

Option A is wrong because a disabled service would not attempt to start at all; the systemctl status would show 'disabled' but the service could still be started manually, and the failure here is during runtime. Option B is wrong because a syntax error in Apache configuration would cause the service to fail to start with a specific error message (e.g., 'Syntax error on line ...'), not a silent failure after starting. Option C is wrong because if /var/www/html did not exist, Apache would log a clear 'Directory not found' error and fail to serve content, but the service itself would start; the question implies the service fails entirely, not just content delivery.

Practice this question →
24
MCQmedium

Refer to the exhibit. What is the most likely cause of this failure?

A.Another process is already bound to port 22.
B.The sshd service is not enabled.
C.SELinux is blocking the service.
D.The /etc/ssh/sshd_config file is missing.
AnswerA

The log message 'Cannot bind any address' is what OpenSSH emits when bind(2) returns EADDRINUSE, meaning another process already holds a listening socket on 0.0.0.0:22 or the specific address configured in sshd_config. This can happen after a failed shutdown leaves an old sshd running, or if another daemon (e.g., a second sshd, a proxy) grabbed port 22. Confirm by checking `ss -tlnp` or `sudo lsof -i :22` to identify the PID holding the port.

Why this answer

The error message in the exhibit indicates that the sshd service failed to start because port 22 is already in use. This is a classic port conflict, where another process (e.g., another SSH daemon, a web server misconfigured to use port 22, or a leftover process) has bound to the same TCP port. The system log or `ss -tlnp` would show the PID and name of the conflicting process, confirming that port 22 is unavailable for the new sshd instance.

Exam trap

Red Hat often tests the distinction between service startup failures caused by port conflicts versus configuration or SELinux issues, and the trap here is that candidates may assume SELinux or a missing config file is the cause when the error message explicitly states 'address already in use'.

How to eliminate wrong answers

Option B is wrong because if the sshd service were not enabled, the error would occur at boot time (service not started) or when manually starting it, but the specific 'address already in use' message points to a port conflict, not a disabled service. Option C is wrong because SELinux blocking the service would produce an AVC denial message in the audit log (e.g., 'SELinux is preventing sshd from binding to port 22'), not a generic 'address already in use' error. Option D is wrong because a missing /etc/ssh/sshd_config file would cause sshd to fail with a configuration file error (e.g., 'Could not load host key' or 'fatal: Cannot open /etc/ssh/sshd_config'), not a port binding failure.

Practice this question →
25
MCQeasy

A security policy requires user passwords to expire 60 days after last change. Which command sets this for user 'jdoe'?

A.usermod -f 60 jdoe
B.passwd -x 60 jdoe
C.chage -m 60 jdoe
D.chage -M 60 jdoe
AnswerD

chage -M 60 jdoe sets the MAX_DAYS field in /etc/shadow, which defines the maximum number of days a password is valid before the system forces the user to choose a new one. With this command, jdoe's password will expire 60 days after the most recent password change, directly implementing the security policy. chage is the standard utility for password aging because it lets an administrator read and write the aging fields clearly and predictably.

Why this answer

The `chage -M 60 jdoe` command sets the maximum number of days a password is valid for user 'jdoe' to 60 days. The `-M` flag in `chage` directly controls the password expiration period, counting from the last password change, which matches the security policy requirement.

Exam trap

The trap here is confusing the `-m` and `-M` flags in `chage`, where candidates often mistakenly think `-m` sets the maximum age (expiration) when it actually sets the minimum days between changes, or they incorrectly recall `usermod -f` as the password expiration command.

How to eliminate wrong answers

Option A is wrong because `usermod -f` sets the number of days after a password expires until the account is permanently disabled (inactive lockout), not the password expiration period itself. Option B is wrong because `passwd -x 60` is not a valid syntax; the `passwd` command does not have a `-x` flag for setting maximum password age (that flag is used by `chage`). Option C is wrong because `chage -m 60` sets the minimum number of days required between password changes, not the maximum age (expiration) of the password.

Practice this question →
26
MCQhard

A junior administrator configured a new network interface (ens224) with a static IP address using a configuration file in /etc/sysconfig/network-scripts/ifcfg-ens224. After restarting the network service, the interface comes up but does not get the IP address. The administrator runs 'ip addr show ens224' and sees no IP address assigned. The interface is listed as DOWN. The administrator then runs 'ifup ens224' manually, which succeeds, and the IP address appears. What is the most likely cause?

A.The ONBOOT directive is set to no in the ifcfg file.
B.The network service is not enabled to start at boot.
C.The interface name does not match the device file.
D.There is a conflict with NetworkManager managing the interface.
AnswerA

The ONBOOT directive in the interface's ifcfg file (e.g., /etc/sysconfig/network-scripts/ifcfg-eth0) explicitly controls whether the interface is activated when the system boots. When ONBOOT=no, the interface is fully configured but is deliberately skipped by the boot-time startup sequence, so it stays down until an administrator runs ifup or uses NetworkManager to connect manually. Manual activation succeeds because the rest of the configuration (e.g., IP address, netmask, gateway) is valid, and the service that performs ifup is already running. This exactly matches the symptom of an interface that is correctly configured but not active after a reboot.

Why this answer

The ONBOOT directive controls whether the interface is automatically brought up at system boot. When set to 'no', the interface configuration file is read but the interface remains DOWN after a network service restart, requiring manual intervention via 'ifup'. The junior administrator's observation that 'ifup ens224' succeeds confirms the configuration is valid, but the interface fails to activate automatically due to ONBOOT=no.

Exam trap

In Red Hat Enterprise Linux, the ONBOOT directive in ifcfg files controls whether the interface is brought up automatically at boot. Candidates often mistakenly think that enabling the network service at boot is sufficient, but each interface must have ONBOOT=yes to activate automatically. Without it, the interface remains DOWN until manually started with ifup.

How to eliminate wrong answers

Option B is wrong because the network service being enabled or disabled at boot affects whether the service itself starts, not whether individual interfaces are activated after the service is already running; the administrator restarted the service manually, so the service was running. Option C is wrong because if the interface name did not match the device file, the 'ifup ens224' command would fail or the interface would not appear at all in 'ip addr show'; the manual activation succeeded, proving the name matches. Option D is wrong because NetworkManager managing the interface would typically cause a conflict only if both network scripts and NetworkManager try to control it, but the manual 'ifup' would still fail or be overridden; the successful manual activation indicates NetworkManager is not interfering, or the interface is explicitly configured to be controlled by network scripts.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Operate running systems questions.

Start 20-question session