Scenario practice questions

Refer to the exhibit. An administrator attempts to mount all filesystems using 'mount -a' and receives an error. What is the most likely cause?

Exhibit

# cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Mon Jul 19 10:15:30 2021
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=12345678-1234-1234-1234-123456789abc /                       xfs     defaults        0 0
UUID=abcdef12-3456-7890-abcd-ef1234567890 /boot                   ext4    defaults        1 2
UUID=deadbeef-cafe-babe-1234-567890abcdef swap                    swap    defaults        0 0
/dev/vdb1 /mnt/data ext4 defaults 0 0

# blkid /dev/vdb1
/dev/vdb1: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" TYPE="ext4"

# mount -a
mount: /mnt/data: can't find /dev/vdb1 in /etc/fstab.

Trap 1: The ext4 filesystem on /dev/vdb1 is corrupted.

Filesystem corruption would produce errors like 'wrong fs type, bad option, bad superblock' or 'Input/output error' during mount, not a message that the device itself cannot be found. The error 'can't find /dev/vdb1' explicitly indicates that the kernel cannot locate the block device node, meaning the problem lies at the device level, not the filesystem level. Corruption could be present, but it is not the cause of this specific failure.

Trap 2: The filesystem type specified in /etc/fstab is incorrect.

If the filesystem type in /etc/fstab were incorrect, mount would complain with 'wrong fs type, bad option, bad superblock' or 'unknown filesystem type', not that the device is missing. Furthermore, the blkid output shows the filesystem is ext4, which matches the 'ext4' entry in fstab, so the type is already consistent. The mount failure occurs before the filesystem type is even inspected because the device node itself is absent.

Trap 3: The mount point /mnt/data does not exist.

If the mount point /mnt/data were missing, the error would explicitly say 'mount point /mnt/data does not exist' and would still attempt to look up the device. In this case, the error is about the device, not the mount point, indicating that mount fails at the device lookup stage before it ever checks the mount directory. Even if /mnt/data existed, the mount would still fail because the device itself is unavailable.

A
The ext4 filesystem on /dev/vdb1 is corrupted.
Why it fails: Filesystem corruption would produce errors like 'wrong fs type, bad option, bad superblock' or 'Input/output error' during mount, not a message that the device itself cannot be found. The error 'can't find /dev/vdb1' explicitly indicates that the kernel cannot locate the block device node, meaning the problem lies at the device level, not the filesystem level. Corruption could be present, but it is not the cause of this specific failure.
B
The filesystem type specified in /etc/fstab is incorrect.
Why it fails: If the filesystem type in /etc/fstab were incorrect, mount would complain with 'wrong fs type, bad option, bad superblock' or 'unknown filesystem type', not that the device is missing. Furthermore, the blkid output shows the filesystem is ext4, which matches the 'ext4' entry in fstab, so the type is already consistent. The mount failure occurs before the filesystem type is even inspected because the device node itself is absent.
C
The entry for /dev/vdb1 in /etc/fstab uses a device name that does not exist.
The fstab entry specifies the device path /dev/vdb1, but that block device is not present in the system (e.g., the disk was removed, or the kernel assigned a different name after a reboot). The error message 'can't find /dev/vdb1' directly states that the kernel cannot resolve that device path, which is why mount -a fails. This demonstrates a common pitfall of using static device names in fstab; using persistent identifiers like UUID= or LABEL= would avoid this issue.
D
The mount point /mnt/data does not exist.
Why it fails: If the mount point /mnt/data were missing, the error would explicitly say 'mount point /mnt/data does not exist' and would still attempt to look up the device. In this case, the error is about the device, not the mount point, indicating that mount fails at the device lookup stage before it ever checks the mount directory. Even if /mnt/data existed, the mount would still fail because the device itself is unavailable.

Question 2easymultiple choice

A system administrator needs to create a file system on a new 10GB partition /dev/sdb1 for use with a database that requires high reliability and supports snapshots. Which file system type should be chosen?

Trap 1: ext4

Although ext4 can support snapshots when paired with LVM, it is not the default filesystem on RHEL 9, and it is not optimized for very large databases. Ext4 uses extents and delayed allocation effectively for general-purpose storage, but its single-threaded journal and less aggressive scaling under parallel I/O make it a weaker choice for high-volume database servers. Because XFS is specifically tuned for scale and is Red Hat's recommended default, ext4 does not meet the requirement as well.

Trap 2: vfat

VFAT is entirely unsuitable for a database filesystem because it is a legacy compatibility filesystem based on FAT32, lacking journaling, POSIX permissions, and native snapshot support. Without a journal, a sudden power failure can leave the filesystem inconsistent, risking data corruption. VFAT is designed for removable media and cross-platform file exchange, not for performance-sensitive database storage, making it an automatic wrong answer.

Trap 3: btrfs

Btrfs is not the correct answer because Red Hat does not support it as a fully integrated filesystem in RHEL 9; it was removed from Red Hat's supported filesystem list and is not the default. Although btrfs offers native snapshots and copy-on-write, it is explicitly outside the RHCSA exam objectives and lacks the production-grade support that XFS receives. In an RHCSA scenario, the expected and supported choice is XFS, not btrfs.

A
xfs
XFS is the correct choice because it is the default filesystem on RHEL 9, and Red Hat fully supports it for production workloads. While XFS itself does not have native snapshot capabilities, it works seamlessly with LVM, which provides snapshot functionality for consistent backups and recovery. Its allocation groups, scalable inode handling, and high concurrency support make it ideal for large database files, exactly what the administrator needs.
B
ext4
Why it fails: Although ext4 can support snapshots when paired with LVM, it is not the default filesystem on RHEL 9, and it is not optimized for very large databases. Ext4 uses extents and delayed allocation effectively for general-purpose storage, but its single-threaded journal and less aggressive scaling under parallel I/O make it a weaker choice for high-volume database servers. Because XFS is specifically tuned for scale and is Red Hat's recommended default, ext4 does not meet the requirement as well.
C
vfat
Why it fails: VFAT is entirely unsuitable for a database filesystem because it is a legacy compatibility filesystem based on FAT32, lacking journaling, POSIX permissions, and native snapshot support. Without a journal, a sudden power failure can leave the filesystem inconsistent, risking data corruption. VFAT is designed for removable media and cross-platform file exchange, not for performance-sensitive database storage, making it an automatic wrong answer.
D
btrfs
Why it fails: Btrfs is not the correct answer because Red Hat does not support it as a fully integrated filesystem in RHEL 9; it was removed from Red Hat's supported filesystem list and is not the default. Although btrfs offers native snapshots and copy-on-write, it is explicitly outside the RHCSA exam objectives and lacks the production-grade support that XFS receives. In an RHCSA scenario, the expected and supported choice is XFS, not btrfs.

Question 3hardmultiple choice

A system has two logical volumes in the same volume group: 'lv_prod' (100% used) and 'lv_backup' (20% used). The administrator wants to allocate 5 GiB from 'lv_backup' to 'lv_prod' without unmounting any filesystems. Is this possible and why?

Trap 1: Yes, use lvreduce and lvextend while mounted; ext4 supports online…

ext4 does not support online shrinking. While resize2fs can grow a mounted ext4 filesystem, the shrink operation requires the filesystem to be unmounted, so running lvreduce and lvextend while the LV is mounted and the ext4 filesystem is active risks severe corruption or a failed reduction.

Trap 2: No, because LVM does not allow freeing extents from an LV while it…

LVM does allow an LV to be reduced while it is active; the restriction is on the filesystem, not the volume manager. After shrinking the ext4 filesystem offline with resize2fs, lvreduce can free extents from the LV, but because ext4 must be unmounted first, the entire operation cannot be done online.

Trap 3: Yes, use lvresize to move extents between LVs directly.

lvresize is used to change the size of a single logical volume, not to move extents between volumes. To transfer space, you must first shrink the filesystem and LV on the source, then extend the destination LV, a process that cannot be performed online for ext4.

A
Yes, use lvreduce and lvextend while mounted; ext4 supports online shrinking.
Why it fails: ext4 does not support online shrinking. While resize2fs can grow a mounted ext4 filesystem, the shrink operation requires the filesystem to be unmounted, so running lvreduce and lvextend while the LV is mounted and the ext4 filesystem is active risks severe corruption or a failed reduction.
B
No, because LVM does not allow freeing extents from an LV while it is active.
Why it fails: LVM does allow an LV to be reduced while it is active; the restriction is on the filesystem, not the volume manager. After shrinking the ext4 filesystem offline with resize2fs, lvreduce can free extents from the LV, but because ext4 must be unmounted first, the entire operation cannot be done online.
C
No, because ext4 filesystems cannot be shrunk online; they must be unmounted.
ext4 filesystems can only be shrunk while unmounted; the resize2fs tool does not support online shrink. Therefore, to free space from an ext4 LV, the filesystem must be unmounted, shrunk, and then the LV reduced, meaning the operation cannot occur while the volume is in use.
D
Yes, use lvresize to move extents between LVs directly.
Why it fails: lvresize is used to change the size of a single logical volume, not to move extents between volumes. To transfer space, you must first shrink the filesystem and LV on the source, then extend the destination LV, a process that cannot be performed online for ext4.

Question 4mediummultiple choice

An IT department runs a web server that stores user uploads on an ext4 filesystem on /dev/sdb1 mounted at /uploads. Recently, the partition has run out of space. The administrator checks with df -h and sees 100% usage. However, du -sh /uploads shows only 2GB used. The administrator suspects deleted files still held open by processes. Which command should be used to identify and resolve the issue?

Trap 1: rm -rf /uploads/* to clean all files

Running `rm -rf /uploads/*` would delete every regular file currently present in that directory, including legitimate user uploads, causing permanent data loss. More importantly, it cannot remove or reclaim space for files that were already deleted (unlinked) but are still held open by a process, because those files no longer appear in the directory tree. This command only targets existing directory entries, so it does not address the open-deleted-file problem that is consuming disk space.

Trap 2: fsck /dev/sdb1 to repair filesystem

`fsck` checks and repairs filesystem metadata such as inodes, block bitmaps, and directory entries; it does not alter the allocation state of files that are open but unlinked. Those inodes remain marked as allocated because the kernel still references them via the open file description, so a consistency check will not free their blocks. Running fsck on a live, mounted filesystem is also unsafe and would require downtime, and even after a successful check the disk would still be full.

Trap 3: resize2fs /dev/sdb1 to shrink filesystem

Shrinking the filesystem with `resize2fs` first requires free space to move data blocks into the new, smaller footprint, but this filesystem is at 100% capacity, so the shrink operation cannot even begin. Additionally, for ext-family filesystems, the partition must be unmounted (or only read-only) before an offline shrink, which is impossible on a busy production web server. Most fundamentally, resizing does not release the space held by open deleted inodes; it merely changes the filesystem boundaries, so the underlying disk-space leak remains.

A
rm -rf /uploads/* to clean all files
Why it fails: Running `rm -rf /uploads/*` would delete every regular file currently present in that directory, including legitimate user uploads, causing permanent data loss. More importantly, it cannot remove or reclaim space for files that were already deleted (unlinked) but are still held open by a process, because those files no longer appear in the directory tree. This command only targets existing directory entries, so it does not address the open-deleted-file problem that is consuming disk space.
B
fsck /dev/sdb1 to repair filesystem
Why it fails: `fsck` checks and repairs filesystem metadata such as inodes, block bitmaps, and directory entries; it does not alter the allocation state of files that are open but unlinked. Those inodes remain marked as allocated because the kernel still references them via the open file description, so a consistency check will not free their blocks. Running fsck on a live, mounted filesystem is also unsafe and would require downtime, and even after a successful check the disk would still be full.
C
resize2fs /dev/sdb1 to shrink filesystem
Why it fails: Shrinking the filesystem with `resize2fs` first requires free space to move data blocks into the new, smaller footprint, but this filesystem is at 100% capacity, so the shrink operation cannot even begin. Additionally, for ext-family filesystems, the partition must be unmounted (or only read-only) before an offline shrink, which is impossible on a busy production web server. Most fundamentally, resizing does not release the space held by open deleted inodes; it merely changes the filesystem boundaries, so the underlying disk-space leak remains.
D
lsof +L1 /uploads to find deleted open files, then kill processes
`lsof +L1 /uploads` enumerates open files whose link count is zero — exactly the deleted-but-still-in-use files that are consuming space. Once identified, you can either close the file gracefully (e.g., by restarting the application) or terminate the offending process, causing the kernel to drop the last reference and free the inode's blocks. This is the targeted, surgical remedy: it doesn't touch valid uploads and it directly releases the missing space. After the process is killed, the directory will show no trace of the file, but df will report the reclaimed capacity.

Question 5hardmultiple choice

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

Exhibit

● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2024-03-11 09:23:45 EDT; 5min ago
  Process: 1234 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=255)
 Main PID: 1234 (code=exited, status=255)
   Status: "Failed to start sshd: Address already in use"

Trap 1: The SSH daemon is already running on another port.

The error 'Address already in use' indicates a socket bind failure on the configured port, not that sshd is bound to a different port. If sshd were already running on another port, it would have successfully bound to that alternate port and the system would show an active listener there, not a conflict for port 22. The symptom is exclusive: port 22 is occupied, so the daemon cannot bind to it regardless of what other ports are in use.

Trap 2: The sshd configuration file has a syntax error.

A syntax error in /etc/ssh/sshd_config would cause sshd to print messages like 'Bad configuration option' or 'invalid argument' during its configuration parse phase, and the service would fail with a different status, not a socket bind error. The 'Address already in use' message demonstrates that sshd parsed its configuration sufficiently to know it must bind to port 22, and then failed at the operating system level during the bind() call. Therefore, while a syntax error can prevent startup, it produces a distinct error signature that is absent here.

Trap 3: The service is not enabled.

The exhibit's `systemctl status sshd` output explicitly shows the service is 'enabled', meaning systemd has symlinked it to start at boot. Enablement affects whether the unit is launched automatically after reboot or after a manual `systemctl enable`, but it has no bearing on whether the daemon can bind to its listening port at runtime. A service can be enabled and still fail immediately due to a port conflict, so this option does not explain the displayed 'Address already in use' error.

A
The SSH daemon is already running on another port.
Why it fails: The error 'Address already in use' indicates a socket bind failure on the configured port, not that sshd is bound to a different port. If sshd were already running on another port, it would have successfully bound to that alternate port and the system would show an active listener there, not a conflict for port 22. The symptom is exclusive: port 22 is occupied, so the daemon cannot bind to it regardless of what other ports are in use.
B
Another process is already listening on port 22.
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.
C
The sshd configuration file has a syntax error.
Why it fails: A syntax error in /etc/ssh/sshd_config would cause sshd to print messages like 'Bad configuration option' or 'invalid argument' during its configuration parse phase, and the service would fail with a different status, not a socket bind error. The 'Address already in use' message demonstrates that sshd parsed its configuration sufficiently to know it must bind to port 22, and then failed at the operating system level during the bind() call. Therefore, while a syntax error can prevent startup, it produces a distinct error signature that is absent here.
D
The service is not enabled.
Why it fails: The exhibit's `systemctl status sshd` output explicitly shows the service is 'enabled', meaning systemd has symlinked it to start at boot. Enablement affects whether the unit is launched automatically after reboot or after a manual `systemctl enable`, but it has no bearing on whether the daemon can bind to its listening port at runtime. A service can be enabled and still fail immediately due to a port conflict, so this option does not explain the displayed 'Address already in use' error.

Question 6hardmultiple choice

A company runs a web application on a Red Hat Enterprise Linux 8 server. The application is served by Apache HTTPD, and it requires read/write access to a custom directory /var/www/app_data. The SELinux context for the directory is set to httpd_sys_rw_content_t. Apache runs in enforcing mode. Recently, a new feature was added that requires Apache to connect to a database on the same server via a Unix socket. The database serves on /var/run/mysqld/mysqld.sock. After the feature deployment, the web application fails to connect to the database. The error logs show permission denied on the socket file. The socket file has permissions 660 and is owned by mysql:mysql. SELinux audit logs show AVC denials for httpd_t trying to connect to mysqld_var_run_t. Which of the following solutions should the administrator implement to allow Apache to read the database socket while maintaining security?

Trap 1: Change the SELinux context of the socket file to…

Changing the socket file's context to httpd_sys_rw_content_t with chcon mislabels it as a web content type, while SELinux assigns dedicated types to Unix sockets such as httpd_var_run_t. chcon only alters the label on the specific file and does not persist after a filesystem relabel, and this context does not grant the permission required for httpd to connect to a local database socket. The proper fix is to toggle the httpd_can_connect_db boolean, not attempt to relabel the socket.

Trap 2: Enable the SELinux boolean httpd_can_network_connect_db using…

The httpd_can_network_connect_db boolean governs outbound TCP/IP connections from Apache to a remote database server, not local Unix socket connections. Enabling it would leave the local socket path still blocked by SELinux, so the web application would continue to fail when connecting via /var/run/mysql/mysql.sock. You need httpd_can_connect_db instead, which specifically permits Apache to connect to database server sockets on the local filesystem.

Trap 3: Use semanage to add a context mapping for the socket file to…

Using semanage fcontext to map a socket file to httpd_var_run_t is unnecessary because sockets already receive a type like httpd_var_run_t through the default labeling process, and semanage without restorecon would not even change the existing label. More critically, switching httpd to permissive mode disables SELinux protection for the entire daemon, which is an unacceptable security trade-off and does not actually diagnose whether the boolean policy is correct. Even with a proper socket context, SELinux still requires httpd_can_connect_db to be enabled for the connection to succeed.

A
Change the SELinux context of the socket file to httpd_sys_rw_content_t using chcon.
Why it fails: Changing the socket file's context to httpd_sys_rw_content_t with chcon mislabels it as a web content type, while SELinux assigns dedicated types to Unix sockets such as httpd_var_run_t. chcon only alters the label on the specific file and does not persist after a filesystem relabel, and this context does not grant the permission required for httpd to connect to a local database socket. The proper fix is to toggle the httpd_can_connect_db boolean, not attempt to relabel the socket.
B
Enable the SELinux boolean httpd_can_network_connect_db using setsebool -P httpd_can_network_connect_db on.
Why it fails: The httpd_can_network_connect_db boolean governs outbound TCP/IP connections from Apache to a remote database server, not local Unix socket connections. Enabling it would leave the local socket path still blocked by SELinux, so the web application would continue to fail when connecting via /var/run/mysql/mysql.sock. You need httpd_can_connect_db instead, which specifically permits Apache to connect to database server sockets on the local filesystem.
C
Enable the SELinux boolean httpd_can_connect_db using setsebool -P httpd_can_connect_db on.
This is the correct boolean because httpd_can_connect_db allows the httpd daemon to connect to a database through local Unix socket files, such as /var/run/mysql/mysql.sock, while leaving network controls unchanged. Using setsebool with -P is essential because it writes the change to the persistent policy so the permission survives a reboot, matching the intended production configuration. The boolean directly addresses the SELinux denial shown in the audit log instead of masking the problem.
D
Use semanage to add a context mapping for the socket file to httpd_var_run_t and set the httpd to permissive mode.
Why it fails: Using semanage fcontext to map a socket file to httpd_var_run_t is unnecessary because sockets already receive a type like httpd_var_run_t through the default labeling process, and semanage without restorecon would not even change the existing label. More critically, switching httpd to permissive mode disables SELinux protection for the entire daemon, which is an unacceptable security trade-off and does not actually diagnose whether the boolean policy is correct. Even with a proper socket context, SELinux still requires httpd_can_connect_db to be enabled for the connection to succeed.

Question 7mediummultiple choice

A system administrator needs to create a file system on /dev/sdb1 with a size of 10 GB and mount it persistently at /data. The file system should support extended attributes and be suitable for large files. Which command sequence achieves this?

Trap 1: mkfs.xfs /dev/sda1 && mkdir /data && echo '/dev/sda1 /data xfs…

This command formats /dev/sda1, but the intended device is /dev/sdb1; writing a filesystem to /dev/sda1 could destroy the operating system or an existing data partition. Even if the device were correct, the filesystem is never mounted, so /data would remain an empty directory until a reboot or a manual mount command is issued, making the fstab entry insufficient for immediate use.

Trap 2: mkfs.ext4 /dev/sdb1 && mkdir /data && mount /dev/sdb1 /data && echo…

This command uses ext4 instead of the required XFS filesystem type, so it fails the task specification even though it mounts correctly. Additionally, the fstab entry uses the defaults option, which does not enable user extended attributes; ext4 requires a separate user_xattr mount option to support user xattrs, so the resulting configuration may not meet applications that depend on extended attributes. Thus it is incorrect for this scenario.

Trap 3: mkswap /dev/sdb1 && mkdir /data && swapon /dev/sdb1 && echo…

This command mistakenly treats /dev/sdb1 as a swap device, but swap is not a filesystem for holding data and cannot be mounted to a /data directory. The fstab line is also invalid because a swap entry uses the swap type with a mount point of none or swap, not a directory, and swap is activated with swapon, not mount. Therefore this option is fundamentally wrong.

A
mkfs.xfs /dev/sda1 && mkdir /data && echo '/dev/sda1 /data xfs defaults 0 0' >> /etc/fstab
Why it fails: This command formats /dev/sda1, but the intended device is /dev/sdb1; writing a filesystem to /dev/sda1 could destroy the operating system or an existing data partition. Even if the device were correct, the filesystem is never mounted, so /data would remain an empty directory until a reboot or a manual mount command is issued, making the fstab entry insufficient for immediate use.
B
mkfs.xfs /dev/sdb1 && mkdir /data && mount /dev/sdb1 /data && echo '/dev/sdb1 /data xfs defaults 0 0' >> /etc/fstab
This is the correct sequence because it creates an XFS filesystem on the intended /dev/sdb1, creates the /data mount point, immediately mounts the device with the mount command, and appends a persistent fstab entry using the xfs type. The && chain stops if any step fails, preventing a broken configuration. XFS is the default and supported filesystem for RHEL/CentOS 8+ and supports extended attributes.
C
mkfs.ext4 /dev/sdb1 && mkdir /data && mount /dev/sdb1 /data && echo '/dev/sdb1 /data ext4 defaults 0 0' >> /etc/fstab
Why it fails: This command uses ext4 instead of the required XFS filesystem type, so it fails the task specification even though it mounts correctly. Additionally, the fstab entry uses the defaults option, which does not enable user extended attributes; ext4 requires a separate user_xattr mount option to support user xattrs, so the resulting configuration may not meet applications that depend on extended attributes. Thus it is incorrect for this scenario.
D
mkswap /dev/sdb1 && mkdir /data && swapon /dev/sdb1 && echo '/dev/sdb1 /data swap defaults 0 0' >> /etc/fstab
Why it fails: This command mistakenly treats /dev/sdb1 as a swap device, but swap is not a filesystem for holding data and cannot be mounted to a /data directory. The fstab line is also invalid because a swap entry uses the swap type with a mount point of none or swap, not a directory, and swap is activated with swapon, not mount. Therefore this option is fundamentally wrong.

Question 8mediummultiple choice

A system is experiencing high CPU usage. The administrator suspects a process is stuck in an infinite loop. Which command can be used to identify the most CPU-intensive process in real-time?

Trap 1: lsof

lsof lists all open files and the processes that hold them, including regular files, sockets, pipes, and device files. It does not report CPU utilization or any process performance metrics, so it cannot be used to diagnose high CPU usage directly. While it might be useful later to investigate what resources a suspicious process has open, it is not a CPU monitoring tool.

Trap 2: ps aux

ps aux generates a static snapshot of the current process table, showing columns such as PID, %CPU, and %MEM, but that %CPU value is calculated over the process's entire lifetime, not the current moment. The output does not auto-refresh, so a rapid CPU spike can be missed unless the command is run repeatedly at the exact right time. For an evolving high CPU situation, top provides a fresh view every few seconds rather than a one-time snapshot.

Trap 3: strace

strace traces system calls and signals made by a process, printing each call, its arguments, and the return value, which is invaluable for debugging kernel interactions and I/O behavior. It does not measure CPU usage or show a process's overall resource consumption, and the tracing overhead actually perturbs the system's performance. Using strace solely to check CPU usage is an indirect and heavyweight approach, so top remains the appropriate first-line diagnostic tool.

A
top
top is a real-time process monitoring utility that continuously updates the list of running processes and sorts by CPU usage by default, making it easy to spot which process is consuming high CPU. It refreshes every few seconds and provides interactive sorting and filtering options, allowing administrators to quickly identify and act on the CPU-intensive process.
B
lsof
Why it fails: lsof lists all open files and the processes that hold them, including regular files, sockets, pipes, and device files. It does not report CPU utilization or any process performance metrics, so it cannot be used to diagnose high CPU usage directly. While it might be useful later to investigate what resources a suspicious process has open, it is not a CPU monitoring tool.
C
ps aux
Why it fails: ps aux generates a static snapshot of the current process table, showing columns such as PID, %CPU, and %MEM, but that %CPU value is calculated over the process's entire lifetime, not the current moment. The output does not auto-refresh, so a rapid CPU spike can be missed unless the command is run repeatedly at the exact right time. For an evolving high CPU situation, top provides a fresh view every few seconds rather than a one-time snapshot.
D
strace
Why it fails: strace traces system calls and signals made by a process, printing each call, its arguments, and the return value, which is invaluable for debugging kernel interactions and I/O behavior. It does not measure CPU usage or show a process's overall resource consumption, and the tracing overhead actually perturbs the system's performance. Using strace solely to check CPU usage is an indirect and heavyweight approach, so top remains the appropriate first-line diagnostic tool.