Essential Tools practice questions

find /var/log -amin -120

Why wrong: This command is incorrect because `-amin` measures access time (`atime`), not modification time. Access time is updated whenever a file is read, opened, or otherwise accessed, which can happen without any change to the file's content. On modern Linux systems with `relatime` (or `noatime`), accesses may not even update atime reliably, so files modified in the last 120 minutes could be excluded while files merely read are included.

find /var/log -mtime -0.08

Why wrong: The `-mtime` predicate works in 24-hour day increments, not minutes. Although GNU find technically accepts fractional values, `-0.08` is interpreted as a tiny fraction of a day (about 1.9 hours) and is rounded or handled in a way that does not reliably represent a 120-minute window. More importantly, this syntax is non-portable, ambiguous, and not the intended method for fine-grained sub-day searches—`-mmin` exists specifically for this purpose.

find /var/log -cmin -120

Why wrong: The `-cmin` predicate checks inode change time (`ctime`), which is updated whenever file metadata—such as permissions, ownership, link count, or name—changes, not necessarily when the file's content is modified. Even a simple `chmod` or `chown` updates ctime, so this command would return files that were never modified in the last two hours. It is therefore not equivalent to looking for content modification, unlike `-mmin`.

set

Why wrong: The `set` builtin, when invoked without arguments, prints all shell variables and functions for the current shell, which is a verbose dump that is not a focused diagnostic for a specific issue like lost `ls` color output. Although `LS_COLORS` might appear in that listing if it is set, finding it would require grepping through countless lines of variables, and `set` also does not distinguish between exported and non-exported variables. For a quick check, it is far less direct than listing the environment.

declare

Why wrong: The `declare` builtin (synonym `typeset`) is primarily used to declare variables and set attributes, and with no arguments it lists the current shell's variables plus their attributes, much like `set` but with some annotations. It is not the standard tool for inspecting environment variables that child processes like `ls` would see, and it does not indicate whether a variable was exported, so even if `LS_COLORS` is visible, it may not be in the environment. This makes it an unsuitable first diagnostic for color output problems.

alias

Why wrong: The `alias` command only displays shell aliases, such as `ls='ls --color=auto'`, not environment variables like `LS_COLORS`, so it is not the right tool to inspect the data that `ls` actually reads from the environment. An alias could be the cause if it was removed or defined without `--color`, but the user's issue is specifically about missing color output, which is governed by both the alias/option and the `LS_COLORS` variable. To rule out environmental causes, one must check `env` rather than `alias`.

netstat -tulpn

Why wrong: netstat -tulpn is the classic tool for displaying listening sockets, but it belongs to the deprecated net-tools package, which is not installed by default in modern RHEL systems. Even on systems where it exists, the command combines TCP and UDP listeners (-u) and offers no advantage over ss, while pulling in a legacy dependency that may be missing in a minimal or security-hardened environment. In a RHEL administration context, relying on netstat is therefore a portability and compliance risk, not a correct first-line diagnostic.

nmap -sT localhost

Why wrong: nmap -sT localhost is an external TCP connect scan that probes open ports from the perspective of a network client, not a local socket diagnostic. It performs a full three-way handshake, which creates connection records in system logs and may trigger intrusion detection, and it only tells you whether a port is reachable, not which process owns the listening socket or whether it is actually in the LISTEN state. Since the task is to 'list all' local TCP listeners with their processes, nmap cannot provide the required PID or program name and is the wrong tool entirely.

lsof -i TCP:1-65535

Why wrong: lsof -i TCP:1-65535 lists open files related to TCP sockets across the entire port range, but it does not restrict output to listening sockets—you will also see established connections, TIME-WAIT sockets, and other TCP file descriptors. To isolate listeners you would need an extra filter such as -sTCP:LISTEN, and lsof's file-descriptor-centric view makes the output noisier and less directly focused than ss. Additionally, without sudo, lsof hides process details for sockets owned by other users, and the tool may not be installed by default on all RHEL systems.

man -k color

Why wrong: man -k color searches only the man-db whatis database, which stores just the one-line NAME summary from each manual page, not the full text. It returns a list of pages whose title or synopsis mentions 'color', but the ls manual page's NAME section may not even contain 'color', since the color option is discussed in the OPTIONS section. You would still have to open a page and then search inside it, so this command does not directly reveal where --color is documented.

man ls | grep color

Why wrong: Piping man output to grep is unreliable because raw man pages, when rendered on a terminal, contain control sequences such as backspaces and underlining for emphasis. grep interprets those escape characters as part of the lines, so matches may be missed or the output becomes cluttered with formatting artifacts. Additionally, grep prints entire lines, but man page descriptions are wrapped and may span multiple lines, so you get only fragments without context. Unlike the pager's interactive / search, grep cannot let you jump between matches.

man color

Why wrong: This command asks man to display a manual page whose name is literally 'color', meaning it will look for a file like color.1, color.2, or similar in the manual page search path. No such standalone page exists because the color options for ls are documented within the ls(1) manual page itself. If no match is found, man will error out with something like 'No manual entry for color', possibly suggesting 'apropos color', but that still won't show you where in the ls page the option is explained.

kill -15 3456

Why wrong: SIGTERM (signal 15) is the default and polite termination request; it asks process 3456 to exit cleanly and run its cleanup routines, but the process has already ignored this signal. A hung process that is stuck in an uninterruptible sleep or a busy loop may never return to user space to handle SIGTERM, so the request remains pending and the process survives.

kill -19 3456

Why wrong: SIGSTOP (signal 19) is a job-control signal that halts process 3456's execution immediately, leaving it in a stopped state (similar to Ctrl+Z) but still present in memory and the process table. It does not remove the process; it can be resumed with SIGCONT (signal 18), so it stops the hang temporarily but does not fulfill the requirement to terminate the process.

kill -1 3456

Why wrong: SIGHUP (signal 1) originally notifies a process that its controlling terminal has hung up, and many daemons interpret it as an instruction to reload configuration files. For a process that is already hung, SIGHUP is often caught by a handler or ignored altogether, so it neither guarantees termination nor clears the stuck state, leaving the administrator without a resolved process.

--ignore-failed-read

Why wrong: --ignore-failed-read is wrong because it does not omit any files from the archive; it merely instructs tar to continue without aborting when it encounters a file that cannot be read (for example, due to permissions or a broken symlink). In a backup script, this flag would not prevent /tmp from being archived—it only suppresses read-error messages and keeps the tar process running. The desired behavior was to exclude a directory, not to tolerate unreadable files.

--exclude-from=/tmp

Why wrong: --exclude-from=/tmp is wrong because --exclude-from expects a regular file that contains a list of exclude patterns, one per line. When you pass /tmp as its argument, tar attempts to open the directory /tmp as if it were a text file, which fails (or reads binary directory data meaninglessly) and does not exclude the /tmp directory. This option is useful for loading many patterns from a file, but it is completely different from --exclude and cannot be used to exclude the directory path itself.

-X /tmp

Why wrong: -X /tmp is wrong because -X is the short form of --exclude-from, so it has the same semantics: it requires a file whose contents are exclude patterns. Passing /tmp as its value makes tar treat the /tmp directory as a pattern file, which will not work because directories cannot be read like regular text files. The result is an error or incorrect pattern parsing, and the /tmp directory remains part of the archive—so this option does not achieve the intended exclusion.

w

Why wrong: The `w` command also lists currently logged-in users, but it enriches each entry with the user's CPU time, idle time, and the full command line of their current process, topped by a system load and uptime summary. Its primary aim is real-time activity monitoring, not a clean roster, so it is considered the wrong tool when the task is simply to display a list of all logged-in users. The extra workload, JCPU, and PCPU columns are unnecessary for a plain user inventory, making `who` the more appropriate choice.

last

Why wrong: The `last` utility searches /var/log/wtmp to replay a chronological history of login and logout events, showing users who logged in previously, including those who have since logged out or whose sessions were terminated. It does not reflect the current state of the system, so it cannot be used to display the set of users currently logged in. Even with the latest entries, the output is a past record, not a live roster.

users

Why wrong: The `users` command produces a single, space-separated list of only the usernames of current login sessions, stripping away terminal names, login times, and host information. While it does confirm who is logged in, it falls short of a proper 'list' that shows each session's details, which the `who` command provides. For an administrator needing to see all currently logged-in users with contextual session data, the minimal output of `users` is insufficient.

gzip -d archive.tar.gz

Why wrong: Running gzip -d archive.tar.gz strips off the gzip compression layer and writes an uncompressed archive.tar file to disk, but it never examines the tar container itself. This command only reverses the compression; it does not parse the tar header records, so no listing of archive members is produced. To actually view the contents, you would still need to run tar -t on the resulting .tar file.

gunzip -c archive.tar.gz

Why wrong: gunzip -c archive.tar.gz decompresses the gzip stream to standard output, so your terminal receives the raw tar binary payload — not a human-readable directory listing. By itself it only reverses the compression; the tar archive's structure remains unexamined. You would need to pipe that output into tar -t (for example, gunzip -c archive.tar.gz | tar -t) to actually list the files inside the archive.

tar -xf archive.tar.gz

Why wrong: tar -xf archive.tar.gz extracts the entire archive into the current working directory: -x switches tar to extraction mode and -f names the archive. Unlike listing, this command creates or overwrites real files on disk, which can be destructive if you only intended to inspect the contents. Listing requires the -t flag instead of -x, so this command does not show what is inside the archive.

fdisk -l /dev/sda

Why wrong: fdisk -l /dev/sda is wrong for checking disk space usage because it only displays the partition table, including start/end sectors, partition types, and sizes of each partition in bytes. It does not query the filesystem or report how much space is actually consumed or available on any mounted filesystem, so it cannot show usage.

parted /dev/sda print

Why wrong: parted /dev/sda print is wrong for this purpose because it prints the partition layout, such as partition numbers, start and end points, sizes, and file system types, but it never examines the filesystem to report used or free space. Like fdisk, it is a partition management tool, not a filesystem usage reporting tool, so it gives capacity, not consumption.

The user's home directory is missing.

Why wrong: A missing home directory does not cause the shell field to become /sbin/nologin. The home directory field (6th field in /etc/passwd) merely defines $HOME and the starting directory after login; if absent, the system may issue a warning and use '/' as the home directory. The shell field (7th field) independently determines what program is executed after authentication, and that is what displays /sbin/nologin here. Therefore, an absent home directory cannot produce this output.

The user is locked.

Why wrong: A locked account is a distinct concept from a nologin shell. Locking is usually implemented by placing '!' or '*' at the beginning of the password hash in /etc/shadow, which makes password authentication always fail; it does not change the shell field. An account can be locked while still having /bin/bash, or unlocked while still having /sbin/nologin. The exhibit only shows /sbin/nologin, with no indication of an altered password hash, so this is not evidence that the account is locked.

The shell is not installed.

Why wrong: /sbin/nologin is a real, installed executable provided by the util-linux or shadow-utils package, and it is commonly used as the shell for system accounts. If the shell binary were missing, attempts to log in would fail with a 'shell not found' error, and the passwd file would not display a valid shell name. The exhibit's output reflects an intentional entry in /etc/passwd, not a misconfiguration or absence of the shell file. Therefore, claiming the shell is not installed contradicts the fact that nologin is deliberately set.

The file is empty.

Why wrong: An empty file would have a size of 0 bytes in the ls -l output. The /etc/shadow file contains password hashes and account-expiration data, one line per user, so it is normally many bytes and clearly non-empty. Even if the file were empty, it would still show a permission string; emptiness is an attribute of file size, not of access permissions, so this does not explain the observed permission display.

The file is a symbolic link.

Why wrong: A symbolic link appears with an 'l' as the first character in the long listing, and its permissions are shown as lrwxrwxrwx with a '->' pointing to its target. The /etc/shadow file is a regular file, as evidenced by the '-' type character in its ls -l output. Also, symlink permissions are generally ignored by the kernel; access is determined by the target file's permissions, so calling it a symlink would not explain why root can read it.

The file is a character device.

Why wrong: A character device node would show a 'c' as the first character in ls -l, would normally reside in /dev, and would have major and minor device numbers instead of a byte size. The /etc/shadow file is a regular file in /etc, not a device node, and cannot be created by mknod on a standard filesystem. Character devices correspond to hardware or virtual serial/terminal devices, not to password-storage files, so this option does not explain the listing.

The configuration file is missing. Copy config.ini to /root.

Why wrong: The configuration file is not missing; it already exists in /opt/scripts, which is why the script runs correctly when launched manually. Copying config.ini to /root might accidentally match cron's default working directory, but that only masks the symptom and leaves the script dependent on wherever cron happened to start. The proper fix is to reference the file as /opt/scripts/config.ini (or explicitly cd into the script's directory) so the script always finds it regardless of cron's environment. Copying configuration files can additionally cause stale or incorrect settings to be used later.

The cron job runs as a different user. Change the cron job to run as the developer's user.

Why wrong: The cron job is already running as root; changing it to run as the developer's user does not alter cron's minimal PATH or its default working directory, which are the actual failure points. The developer user might not even have read access to /opt/scripts or the encryption keys the backup script uses. Since root is a privileged account, command resolution is no better with the developer identity — relative paths still fail. The root cause is the environment cron provides, not the user account under which the job runs.

The script is not executable. Run chmod +x /opt/scripts/backup.sh.

Why wrong: The script already executes successfully when run manually, so the executable bit is already set; if it were not, the manual run would fail immediately. Many cron entries also invoke scripts with an explicit interpreter such as /bin/sh /opt/scripts/backup.sh, which bypasses the need for the execute permission entirely. Therefore running chmod +x would have no effect on the cron failure mode. The real issue is cron's restricted PATH and a different current working directory, both of which execute permissions cannot alter.

The home directory path in /etc/passwd has a typo. Change it to /home/john.

Why wrong: The home directory field in /etc/passwd simply holds the path string; it is not a symlink or a mount point. You can verify with `grep john /etc/passwd`, which will show `/home/john` exactly. A typo in that field would cause the shell to look in a nonexistent directory, but here the path is correct, so editing it would not resolve the reported 'No such file or directory' error.

The home directory is missing the .bashrc file. Copy default files from /etc/skel.

Why wrong: The `.bashrc` file is a user-specific shell configuration script that resides *inside* the home directory; its presence or absence does not affect the home directory's existence or accessibility. The kernel's path resolution only cares about the directory itself, not its contents. Skipping `/etc/skel` is irrelevant here—those defaults are only used when creating new users with `useradd`; copying them into an existing home directory would not fix an ownership or permission problem.

The user's shell is invalid. Change shell to /bin/bash.

Why wrong: The login shell is defined in the `/etc/passwd` shell field, and you can verify it with `grep john /etc/passwd` which shows `/bin/bash`. An invalid shell entry would cause a different symptom, such as 'User's shell not found' or a failed login at the PAM stage, not a filesystem-level 'No such file or directory' when accessing the home directory. Since the shell is already `/bin/bash`, changing it would have no effect on the reported problem.

chmod u+r script.sh

Why wrong: The chmod u+r command only grants the owning user read permission on script.sh. While reading the file might allow someone to inspect its contents or run it with an explicit interpreter such as bash script.sh, it does not set the execute bit. If you attempt to execute the script directly as ./script.sh, the kernel checks for execute permission and rejects it with 'Permission denied' even though the file is readable. Thus, it fails to resolve the reported problem.

chmod a+x script.sh

Why wrong: chmod a+x sets the execute bit for the user, group, and others, so it would actually allow the owner to run the script directly. However, it is overly permissive for a user-specific script in a home directory, granting execution rights to every system user unnecessarily. The principle of least privilege dictates that only the owner needs the execute bit, so this command works but is not the correct or minimal fix. Security-conscious administrators would avoid extending execute permissions to all users, making chmod u+x the proper choice.

chmod u-x script.sh

Why wrong: chmod u-x explicitly removes the execute bit from the owner's permission set. If the user's script was previously failing because it lacked execute permission, this command would make the situation worse by ensuring the owner definitely cannot execute it. It would guarantee a 'Permission denied' error for direct execution, and no other circumstances would change the outcome. Rather than fixing the reported failure, this command propagates or deepens it.

find /var/log -type f -size -10M

Why wrong: The leading hyphen in `-size -10M` tells find to match files smaller than 10 MiB, not larger ones. Because the size comparison is inverted, this command returns small regular files and therefore misses the intended large-file targets. To select files bigger than 10 MiB, you need a leading plus sign, not a minus sign. This is a common syntax mix-up.

find /var/log -type d -size +10M

Why wrong: The `-type d` predicate restricts results to directories, while the question asks for regular files, so any regular files are ignored. Even with `+10M`, directories are almost certain to be far below 10 MiB in size, so this command typically returns nothing at all. To match regular files, the correct type flag is `f`, as in `-type f`. The size clause is irrelevant when the wrong file type is specified.

find /var/log -type f -size 10M

Why wrong: A plain `10M` without a sign matches only files whose size rounds up to exactly 10 MiB, not every file larger than 10 MiB. Files of 15 MiB or 20 MiB round to 15M or 20M and thus do not satisfy `-size 10M`. This creates a narrow, unintended filter that excludes most large files. In find syntax, `+10M` is required to express "greater than 10 MiB."

Use 'set -o ignoreeof' to ignore Ctrl+C.

Why wrong: `set -o ignoreeof` only affects the end-of-file character (Ctrl+D), causing the shell to ignore EOF input so an accidentally typed Ctrl+D does not log out an interactive shell. Ctrl+C, however, transmits SIGINT to the foreground process group, which is an entirely distinct mechanism and is not influenced by the EOF setting. Because the administrator needs to handle the SIGINT signal, `ignoreeof` cannot prevent or handle Ctrl+C and therefore would not run any cleanup.

Run the script in the background with '&'.

Why wrong: Running the script in the background with `&` starts it as an asynchronous subshell and immediately returns control to the calling shell, but it does not install any signal handler. Under normal job control, a background job is not part of the foreground process group, so pressing Ctrl+C sends SIGINT only to the foreground group; the background script may never receive the signal, and if it does, the default action is immediate termination without cleanup. Thus backgrounding neither catches the interrupt nor provides an opportunity for the administrator's cleanup logic to execute.

Use 'set -e' to exit on any error.

Why wrong: `set -e` instructs the shell to exit immediately whenever a command, pipeline, or list returns a non-zero exit status, serving only as an error-handling mechanism for command failures. It has no role in signal delivery: pressing Ctrl+C still sends SIGINT to the shell and its children, and the script terminates according to the default signal disposition rather than running a cleanup routine. Moreover, `set -e` gives the administrator no way to define what actions should happen when an interrupt arrives, so it cannot ensure cleanup on Ctrl+C.

tail -f /var/log/messages

Why wrong: tail -f /var/log/messages does not simply show the last 15 lines; the -f (follow) flag makes tail output the last 10 lines by default and then remain attached to the file, continuously printing every new line that is appended. This means the command never terminates on its own, making it useless for a one-off requirement of viewing exactly 15 lines, and it floods the terminal with ongoing updates instead.

cat /var/log/messages

Why wrong: cat /var/log/messages prints the entire contents of the file from the very first line to the last, which for a long-running system log can be thousands of lines or more. It does not apply any line-count limit, so it far exceeds the requested 15 lines and could overwhelm the terminal or scroll those last lines off the screen entirely.

head -15 /var/log/messages

Why wrong: head -15 /var/log/messages displays the first 15 lines of the log file, which correspond to the oldest records in the file, not the newest. This is the functional opposite of what the user wants; the last lines of a log are typically the most relevant for troubleshooting, and head provides no option to count from the end.

gzip -r data > backup.tar.gz

Why wrong: gzip -r data > backup.tar.gz is incorrect because gzip's recursive mode compresses each file inside data individually, creating compressed siblings like file.gz and leaving the directory structure unchanged; it does not bundle them into a single tar stream. Redirecting stdout over a pipe is ineffective since gzip writes compressed files in place unless -c is explicitly used, and even then you would get a raw gzip stream rather than a tar archive.

tar -cjf backup.tar.gz data

Why wrong: tar -cjf backup.tar.gz data is incorrect because the -j flag selects bzip2 as the compression filter, not gzip. This command does create a valid compressed archive, but the resulting file would be bzip2-compressed tarball, making the .tar.gz extension misleading and causing extraction problems with tools that expect gzip content. The correct gzip flag is -z.

tar -xzf backup.tar.gz data

Why wrong: tar -xzf backup.tar.gz data is incorrect because the -x flag places tar in extract mode, so it reads the existing backup.tar.gz and tries to extract the member named data from it; it does not compress or create an archive. The data directory is treated as a member name to extract, not as input, and if backup.tar.gz does not exist, tar will fail.

find /var/log -ctime -1

Why wrong: The -ctime -1 predicate filters on the inode change time (ctime), not the modification time. ctime is updated not only when file content changes, but also whenever metadata such as permissions, ownership, or link count is altered, so this command would return files that had a chmod or chown in the last 24 hours even if their content was not modified. That makes it unsuitable for finding files whose data was edited.

find /var/log -atime -1

Why wrong: Using -atime -1 selects files based on access time (atime), which is updated whenever a file is read, examined, or executed. Log files are frequently read by system utilities, admins, or monitoring agents, so this predicate would include many false positives that were merely opened but never modified. Access time does not reflect content changes, so it is the wrong basis for locating recently modified log files.

find /var/log -mmin 1440

Why wrong: The -mmin predicate expects a number of minutes, and 1440 minutes equals exactly 24 hours; however, without a leading minus sign, -mmin 1440 matches files modified exactly 1440 minutes ago, not within the last 24 hours. To find files modified in the past 24 hours with minute granularity, the correct expression is -mmin -1440, meaning 'less than 1440 minutes ago.' Since the proposed command omits the negative sign, it will typically return no files unless a log was modified at that precise instant.

Set the 'permissive' mode for systemd via systemd.conf

Why wrong: There is no systemd.conf file or 'permissive' mode in systemd's own configuration; systemd defers authorization for systemctl operations to PolicyKit (polkit). Setting SELinux to permissive would affect MAC policy but would not grant a standard user the right to manage services, so this option does not address the user's restriction.

Add the user to the 'systemd-journal' group

Why wrong: The systemd-journal group grants access to journal logs and systemd-journald's /var/log/journal files, allowing users to read log entries without elevated privileges. Membership does not confer any permission to start, stop, or enable units, which are governed by polkit rules. So adding the user to this group would not solve the systemctl authorization failure.

Add the user to /etc/sudoers with 'ALL ALL=(ALL) ALL'

Why wrong: Editing /etc/sudoers to grant the user a blanket ALL rule would allow them to run systemctl as root via sudo, but it does not affect systemctl's own authorization mechanism, which relies on polkit for unprivileged invocation. Granting unconditional sudo access is also a security risk and is not the expected administrative fix for routine service management permissions. The correct approach is a polkit rule that permits the user to perform the action directly.