Troubleshooting practice questions

While troubleshooting a script, you run `grep -n 'error' /var/log/app.log` and see output lines prefixed with numbers. A colleague asks what those numbers represent. What do they indicate?

Trap 1: The total count of matching lines found in the file.

A total count would be a single number, not a prefix on every matching line. The option that produces a count is -c, which prints only the number of matching lines. Here, each matching line has its own distinct number, so these are positions, not a total count.

Trap 2: The process ID of the application that wrote each log entry.

grep does not inspect or report process IDs from file content. Those would only appear if the application itself wrote them into the log. The -n flag is a grep output formatting option that adds line numbers to matches, independent of who produced the file.

Trap 3: The byte offset from the start of the file to each match.

Byte offsets are not shown by -n; that is the behavior of the -b option, which prefixes each match with its byte offset. The numbers here increment by one per line, consistent with line numbers, not byte positions which would jump by varying amounts based on line length.

A
The total count of matching lines found in the file.
Why it fails: A total count would be a single number, not a prefix on every matching line. The option that produces a count is -c, which prints only the number of matching lines. Here, each matching line has its own distinct number, so these are positions, not a total count.
B
The line number in the file where each matching line occurs.
The -n option to grep prefixes each matching line with its 1-based line number within the input file. This is useful for locating matches in large files or when you need to reference a specific line later. In this scenario, the numbers identify where in /var/log/app.log each 'error' match appears.
C
The process ID of the application that wrote each log entry.
Why it fails: grep does not inspect or report process IDs from file content. Those would only appear if the application itself wrote them into the log. The -n flag is a grep output formatting option that adds line numbers to matches, independent of who produced the file.
D
The byte offset from the start of the file to each match.
Why it fails: Byte offsets are not shown by -n; that is the behavior of the -b option, which prefixes each match with its byte offset. The numbers here increment by one per line, consistent with line numbers, not byte positions which would jump by varying amounts based on line length.

Question 2hardmultiple choice

A Linux administrator is troubleshooting a server that fails to boot completely. The system starts but drops into an emergency shell. Which command should the administrator use to view the most recent kernel messages that might indicate the cause?

Trap 1: journalctl -b -p err

The journalctl command with -b shows messages from the current boot, and -p err filters for error priority. While useful, it depends on systemd-journald being running and the journal being persistent. In an emergency shell, journald might not be available, and the filter could miss important non-error messages. It is not as straightforward as dmesg for kernel-specific messages.

Trap 2: cat /var/log/syslog

The /var/log/syslog file contains system logs from various services, but it may not include all kernel messages, especially early boot messages. On many systems, kernel messages are logged to /var/log/kern.log or captured by journald. Also, if the system failed early, syslog may not have been written. Thus, it is not the most reliable source for recent kernel messages.

Trap 3: last -x

The last command shows a list of last logged-in users and system reboots, with -x including shutdown and runlevel changes. It does not display kernel messages or boot errors. It is useful for tracking login history but provides no technical details about why the boot process failed. Therefore, it is not appropriate for this troubleshooting task.

A
journalctl -b -p err
Why it fails: The journalctl command with -b shows messages from the current boot, and -p err filters for error priority. While useful, it depends on systemd-journald being running and the journal being persistent. In an emergency shell, journald might not be available, and the filter could miss important non-error messages. It is not as straightforward as dmesg for kernel-specific messages.
B
dmesg | tail -50
The dmesg command displays the kernel ring buffer, which contains messages from the kernel, including hardware detection, driver initialization, and errors during boot. Piping to tail -50 shows the most recent 50 lines, which are likely to include the last messages before the failure. This is the most direct way to view recent kernel messages and diagnose boot issues.
C
cat /var/log/syslog
Why it fails: The /var/log/syslog file contains system logs from various services, but it may not include all kernel messages, especially early boot messages. On many systems, kernel messages are logged to /var/log/kern.log or captured by journald. Also, if the system failed early, syslog may not have been written. Thus, it is not the most reliable source for recent kernel messages.
D
last -x
Why it fails: The last command shows a list of last logged-in users and system reboots, with -x including shutdown and runlevel changes. It does not display kernel messages or boot errors. It is useful for tracking login history but provides no technical details about why the boot process failed. Therefore, it is not appropriate for this troubleshooting task.

Question 3hardmultiple choice

A system administrator is troubleshooting a Linux server that has become unresponsive. The administrator wants to view a snapshot of all currently running processes, including those not attached to a terminal, along with their process IDs and CPU usage. Which command should the administrator use?

Trap 1: pstree

The pstree command displays running processes as a tree, showing parent-child relationships, but by default it does not include CPU usage or detailed process IDs in a tabular format. While it can show all processes with options, it is primarily used to visualize process hierarchy rather than resource consumption. The administrator needs PIDs and CPU usage, which pstree does not readily provide, making it less appropriate for this specific troubleshooting task.

Trap 2: jobs

The jobs command lists background and suspended jobs belonging to the current shell session only. It does not show system-wide processes and provides no information about process IDs or CPU usage for other users or daemons. In a troubleshooting scenario where the server is unresponsive, jobs would reveal nothing about the problematic processes. It is a shell built-in for job control, not a system process inspection tool.

Trap 3: top

The top command provides a real-time, interactive view of processes, but it continuously updates and is not a single snapshot. It can be useful for live monitoring, yet the administrator specifically wants a static snapshot of all processes. While top can display process IDs and CPU usage, its dynamic nature makes it less suitable when a one-time capture is needed, and it may not show all processes depending on terminal settings.

A
pstree
Why it fails: The pstree command displays running processes as a tree, showing parent-child relationships, but by default it does not include CPU usage or detailed process IDs in a tabular format. While it can show all processes with options, it is primarily used to visualize process hierarchy rather than resource consumption. The administrator needs PIDs and CPU usage, which pstree does not readily provide, making it less appropriate for this specific troubleshooting task.
B
jobs
Why it fails: The jobs command lists background and suspended jobs belonging to the current shell session only. It does not show system-wide processes and provides no information about process IDs or CPU usage for other users or daemons. In a troubleshooting scenario where the server is unresponsive, jobs would reveal nothing about the problematic processes. It is a shell built-in for job control, not a system process inspection tool.
C
ps aux
The ps aux command produces a snapshot of all running processes, including those not attached to a terminal, and displays details such as user, PID, CPU percentage, memory usage, and the command line. It is the standard tool for capturing a static list of processes on a Linux system. This directly satisfies the administrator's need to inspect all processes with their PIDs and CPU usage during troubleshooting.
D
top
Why it fails: The top command provides a real-time, interactive view of processes, but it continuously updates and is not a single snapshot. It can be useful for live monitoring, yet the administrator specifically wants a static snapshot of all processes. While top can display process IDs and CPU usage, its dynamic nature makes it less suitable when a one-time capture is needed, and it may not show all processes depending on terminal settings.

Question 4easymultiple choice

While troubleshooting a service, a technician runs `ps aux` and sees a process in state `Z`. The process's parent is PID 1. Which statement best describes what the technician is observing?

Trap 1: The process is sleeping and is waiting for a signal to wake it.

A process waiting for a signal is typically in state S (interruptible sleep) or D (uninterruptible sleep), not Z. State Z specifically means the process has already exited but has not been reaped. Confusing Z with S or D would lead the technician to look for a wake-up source that does not exist, because the process is already dead.

Trap 2: The process is running in the foreground and has high CPU priority.

Foreground running processes appear as state R (running) or S (sleeping) and have no relation to the Z state. CPU priority is shown in the NI column, not the STAT column. Interpreting Z as a priority or foreground issue would send the technician toward nice/renice commands that cannot fix an unreaped child process.

Trap 3: The process is stopped by a job control signal and can be resumed…

Stopped processes show state T in `ps` output, not Z. A stopped process is still alive and can be resumed with `fg` or `bg`. A zombie is already dead and cannot be resumed. Misreading Z as T would make the technician try to restart a process that no longer exists, wasting time and missing the real reaping issue.

A
The process is sleeping and is waiting for a signal to wake it.
Why it fails: A process waiting for a signal is typically in state S (interruptible sleep) or D (uninterruptible sleep), not Z. State Z specifically means the process has already exited but has not been reaped. Confusing Z with S or D would lead the technician to look for a wake-up source that does not exist, because the process is already dead.
B
The process is running in the foreground and has high CPU priority.
Why it fails: Foreground running processes appear as state R (running) or S (sleeping) and have no relation to the Z state. CPU priority is shown in the NI column, not the STAT column. Interpreting Z as a priority or foreground issue would send the technician toward nice/renice commands that cannot fix an unreaped child process.
C
The process is stopped by a job control signal and can be resumed with `fg`.
Why it fails: Stopped processes show state T in `ps` output, not Z. A stopped process is still alive and can be resumed with `fg` or `bg`. A zombie is already dead and cannot be resumed. Misreading Z as T would make the technician try to restart a process that no longer exists, wasting time and missing the real reaping issue.
D
The process has terminated, but its exit status has not yet been read by its parent.
A zombie process has finished execution, but the parent has not yet called wait() to collect its exit status. The kernel keeps a minimal process table entry until the parent reaps it. Because the parent here is PID 1 (init/systemd), it normally reaps children quickly; a lingering zombie usually indicates a bug or a stuck reaping loop.

Question 5easymulti select

Which THREE of the following represent ways to gain practical experience with Linux?

Trap 1: Buying a pre-configured, locked-down appliance

A locked-down appliance hides the Linux internals, so you cannot explore the shell, permissions or services that hands-on practise requires. It is tempting because appliances are a legitimate deployment method for turnkey network or security functions, where the vendor manages the underlying OS and administration is deliberately abstracted away.

Trap 2: Only reading documentation without using the terminal

Reading alone never exercises the command line, so no practical skill is built; the question demands hands-on experience. Documentation is genuinely valuable as a reference while working in a terminal, and would be the right choice when the goal is researching syntax, options or configuration details before or during a task.

A
Installing and configuring Linux in a virtual machine
Installing Linux in a virtual machine provides hands-on exposure to partitioning, package management and system configuration without risking existing hardware. This directly satisfies the stem's requirement for practical experience, since the learner performs real installation and administration tasks rather than merely reading about Linux concepts.
B
Buying a pre-configured, locked-down appliance
Why it fails: A locked-down appliance hides the Linux internals, so you cannot explore the shell, permissions or services that hands-on practise requires. It is tempting because appliances are a legitimate deployment method for turnkey network or security functions, where the vendor manages the underlying OS and administration is deliberately abstracted away.
C
Setting up a home lab server
Setting up a home lab server provides hands-on practise installing, configuring and troubleshooting a real Linux system, satisfying the stem's requirement for practical experience. Unlike reading or watching demonstrations, it forces direct interaction with the command line, package management and services, building genuine operational familiarity.
D
Contributing code to an open source project
Contributing code to an open source project provides hands-on Linux practise, satisfying the stem's requirement for practical experience. Developers work directly within Linux environments, using shells, package managers and version control, which builds genuine command-line fluency beyond theoretical study. This active participation cements skills that reading alone cannot deliver.
E
Only reading documentation without using the terminal
Why it fails: Reading alone never exercises the command line, so no practical skill is built; the question demands hands-on experience. Documentation is genuinely valuable as a reference while working in a terminal, and would be the right choice when the goal is researching syntax, options or configuration details before or during a task.

Question 6mediummultiple choice

A junior administrator is troubleshooting a script and needs to know the exact location of the executable that runs when the command 'grep' is typed, without executing it. Which command should be used?

Trap 1: locate grep

The locate command searches a prebuilt database of file paths for any file or directory containing the string 'grep', returning many unrelated results such as documentation or source files. It does not resolve which executable the shell would run, and the database may be outdated, so it fails to provide the precise answer needed here.

Trap 2: whereis grep

The whereis command locates the binary, source, and manual page files for a command, but it searches standard locations rather than the current shell's PATH order, and it may return multiple paths, making it less precise for identifying the exact executable that would run. It is not the best tool when the goal is to resolve the command as the shell would.

Trap 3: find / -name grep

The find command recursively searches the filesystem for files named 'grep', which can be extremely slow and may return multiple matches, including directories or files not in the PATH. It does not indicate which one the shell would execute, and it unnecessarily scans the entire filesystem, making it inefficient and imprecise for this scenario.

A
locate grep
Why it fails: The locate command searches a prebuilt database of file paths for any file or directory containing the string 'grep', returning many unrelated results such as documentation or source files. It does not resolve which executable the shell would run, and the database may be outdated, so it fails to provide the precise answer needed here.
B
whereis grep
Why it fails: The whereis command locates the binary, source, and manual page files for a command, but it searches standard locations rather than the current shell's PATH order, and it may return multiple paths, making it less precise for identifying the exact executable that would run. It is not the best tool when the goal is to resolve the command as the shell would.
C
which grep
The which command searches the directories listed in the PATH environment variable and prints the full path of the executable that would be run when the command is invoked. This directly answers the administrator's need to know the exact location without executing the command, and it respects the current shell's PATH order, making it the most appropriate choice.
D
find / -name grep
Why it fails: The find command recursively searches the filesystem for files named 'grep', which can be extremely slow and may return multiple matches, including directories or files not in the PATH. It does not indicate which one the shell would execute, and it unnecessarily scans the entire filesystem, making it inefficient and imprecise for this scenario.

Question 7mediummultiple choice

A junior administrator is troubleshooting a payroll application and runs 'ls -l /srv/payroll/run.sh'. The output shows '-rwxr-x--- 1 root finance 2048 Apr 10 09:14 /srv/payroll/run.sh'. A member of the 'marketing' group complains the script fails with 'Permission denied'. What is the most likely reason?

Trap 1: The script lacks the setuid bit, so it cannot run with root…

Lack of setuid explains why the script would not run with root's effective UID, but it does not cause 'Permission denied' for a non-owner. A script can execute fine under the caller's own UID if the appropriate class grants execute, so setuid is unrelated to the reported failure here.

Trap 2: The 'others' class has write permission removed, and Linux requires…

Write permission is never a prerequisite for executing a file; only the relevant execute bit matters for the class the caller falls into. Here the others class has no bits at all, so the denial stems from the missing execute bit rather than from the absence of write access.

Trap 3: The execute bit is missing from the group class, so even finance…

The group class in '-rwxr-x---' is 'r-x', which includes the execute bit, so finance members can run the script. The failure is reported by a marketing user, not a finance member, and the shell does not 'fall back' to the others class when the group class lacks a bit; class selection is determined solely by UID and group membership, not by which bits happen to be set.

A
The script lacks the setuid bit, so it cannot run with root privileges and the kernel refuses execution for non-owners.
Why it fails: Lack of setuid explains why the script would not run with root's effective UID, but it does not cause 'Permission denied' for a non-owner. A script can execute fine under the caller's own UID if the appropriate class grants execute, so setuid is unrelated to the reported failure here.
B
The marketing user is not the file owner and is not a member of the finance group, so the 'others' permission set applies and grants no access.
The permission string ends in '---', which is the others class. Since the marketing user is neither root nor in the finance group, Linux evaluates the others class, which has no read, write, or execute bits set. Any attempt to run the script is denied before the kernel even parses the interpreter, so the observed error is expected behavior for this ownership and mode combination.
C
The 'others' class has write permission removed, and Linux requires write access on a file before it can be executed by a non-owner.
Why it fails: Write permission is never a prerequisite for executing a file; only the relevant execute bit matters for the class the caller falls into. Here the others class has no bits at all, so the denial stems from the missing execute bit rather than from the absence of write access.
D
The execute bit is missing from the group class, so even finance members cannot run the script and the shell falls back to the others class.
Why it fails: The group class in '-rwxr-x---' is 'r-x', which includes the execute bit, so finance members can run the script. The failure is reported by a marketing user, not a finance member, and the shell does not 'fall back' to the others class when the group class lacks a bit; class selection is determined solely by UID and group membership, not by which bits happen to be set.

Question 8mediummultiple choice

A junior administrator is asked to determine which shell will be launched for a user named 'alex' upon login. The administrator inspects the /etc/passwd file and sees the following line: alex:x:1001:1001:Alex Smith:/home/alex:/bin/bash. Which field in this line specifies the login shell?

Trap 1: The third field, 1001

The third field in /etc/passwd is the user ID (UID), not the login shell. Here, 1001 is alex's numeric UID. While important for permissions and ownership, it does not determine which shell starts at login. The shell is specified later in the line.

Trap 2: The fifth field, Alex Smith

The fifth field is the GECOS field, typically holding the user's full name or other descriptive information. 'Alex Smith' here is informational only and has no role in selecting the login shell. The shell is defined in the seventh field.

Trap 3: The sixth field, /home/alex

The sixth field is the user's home directory, which becomes the working directory after login. It is not the shell. In this line, /home/alex is the home directory. The shell is the final field, so this option misidentifies the field's purpose.

A
The third field, 1001
Why it fails: The third field in /etc/passwd is the user ID (UID), not the login shell. Here, 1001 is alex's numeric UID. While important for permissions and ownership, it does not determine which shell starts at login. The shell is specified later in the line.
B
The fifth field, Alex Smith
Why it fails: The fifth field is the GECOS field, typically holding the user's full name or other descriptive information. 'Alex Smith' here is informational only and has no role in selecting the login shell. The shell is defined in the seventh field.
C
The seventh field, /bin/bash
In /etc/passwd, fields are colon-separated: username, password placeholder, UID, GID, GECOS, home directory, and login shell. The seventh field, /bin/bash, is the login shell that runs when alex logs in. This is the correct identification for this scenario.
D
The sixth field, /home/alex
Why it fails: The sixth field is the user's home directory, which becomes the working directory after login. It is not the shell. In this line, /home/alex is the home directory. The shell is the final field, so this option misidentifies the field's purpose.