Hard Difficulty Questions

A proprietary license with a source-code escrow agreement, because escrow guarantees permanent access to the code.

Why it fails: Source-code escrow typically releases code only under specific conditions such as vendor bankruptcy, and it does not grant the right to modify or redistribute. The hospital could audit only if the escrow terms allowed it, and improvements would remain under the vendor's proprietary control, violating counsel's requirements.

A public domain dedication, because it removes all restrictions and lets the hospital do anything it wants.

Why it fails: Public domain dedication eliminates licensing restrictions, which sounds permissive, but it also allows anyone to take the code and release modified versions under proprietary terms. There is no mechanism to keep redistributed improvements open, so counsel's condition that downstream versions preserve the same freedoms would not be met.

A permissive license such as MIT, because it allows modification without any redistribution conditions.

Why it fails: MIT does allow modification and redistribution, but it also permits derivative works to be relicensed under proprietary terms. That means a downstream party could incorporate the hospital's improvements into a closed product, which fails counsel's requirement that redistributed improvements keep the same freedoms.

It qualifies as open source because users can read and audit the code.

Why it fails: Reading and auditing code is valuable for security and transparency, but it is only one aspect of open source. The definition also demands the freedom to modify and redistribute, which this application denies. Auditable source alone describes source-available software, not open source software.

It qualifies as open source because the source code is publicly available.

Why it fails: Availability of source code alone does not make software open source. The Open Source Initiative definition requires freedoms to modify and redistribute, which this application forbids. Public visibility without those rights is sometimes called shared source or source-available, not open source, so the administrator should not accept this claim.

It qualifies as open source if the vendor provides the source code on request.

Why it fails: Providing source code on request addresses availability but not the essential freedoms. Open source requires the rights to modify and redistribute, which this application withholds. On-request access is a common practice in shared-source models, but it does not satisfy the Open Source Initiative criteria the administrator should apply.

program 2> results.txt

Why it fails: The `2>` operator redirects only standard error to the file. That would save progress messages and leave results on the terminal, which is the opposite of what is needed. To capture standard output, you must redirect file descriptor 1, as with plain `>` or `1>`.

program > results.txt 2>&1

Why it fails: This redirects standard output to the file and then points standard error to the same file. Both streams end up in results.txt, so progress messages would not appear on the terminal. It merges the streams rather than separating them as required.

program &> results.txt

Why it fails: The `&>` operator redirects both standard output and standard error to the file. This would save results and progress messages together in results.txt, so the developer would no longer see progress on the terminal. That violates the requirement to keep progress visible.

Environment variables can only be set by the root user.

Why it fails: Any user can set environment variables in their own shell session, typically with export VAR=value. These affect only that user's processes and are not system-wide unless placed in global configuration files by an administrator. Restricting to root is incorrect and would hinder normal user customization.

The PS1 variable controls the system's primary network interface.

Why it fails: PS1 defines the primary shell prompt string, controlling what the user sees before typing commands. It has no relation to network interfaces. Network interface configuration is handled by tools like ip or configuration files, so this statement misrepresents the purpose of PS1.

The HOME variable stores the system's hostname.

Why it fails: HOME specifies the current user's home directory, used by shells and applications to locate configuration files. The hostname is stored in HOSTNAME or obtained via hostname command. Confusing these two variables would lead to incorrect assumptions about where user files reside.

;

Why it fails: The semicolon runs the second command unconditionally, ignoring whether the first succeeded. It is tempting because it does execute commands sequentially, and would be correct when order matters but the outcome of the first command is irrelevant to running the second.

||

Why it fails: The || operator runs the right-hand command only when the left command fails, which is the inverse of the requirement. It is tempting because it also sequences commands conditionally, and would be correct for fallback logic, such as running a backup command only if the primary one returns non-zero.

|

Why it fails: The pipe connects stdout of the left command to stdin of the right, running both concurrently; it never tests exit status, so the second command runs regardless of success. It is tempting because piping is the standard way to chain commands, and would be correct when passing one command's output as another's input.

df -h /var/log

Why it fails: df -h shows the overall disk usage of the filesystem containing /var/log, not the sizes of individual files or directories. It provides total space used and available, but cannot identify which specific files are large. Thus, it does not help in pinpointing the space consumers within the directory.

ls -lS /var/log

Why it fails: ls -lS sorts files by size within a single directory, but it does not recurse into subdirectories. The /var/log directory typically contains subdirectories, and the largest file might be nested. Therefore, this command would not show the largest files in the entire tree, only those directly in /var/log.

find /var/log -type f -size +100M

Why it fails: find with -size +100M lists files larger than 100MB, but it does not sort them by size or show the largest overall. It only filters by a threshold, so if the largest file is 80MB, it would be missed. The administrator wants to identify the largest files, not just those above a fixed size.

Because the latest kernel is always incompatible with proprietary software.

Why it fails: Proprietary drivers are often built as out-of-tree modules, yet vendors and distributions regularly rebuild them for new kernels, so universal incompatibility is false. The claim appeals because proprietary modules do lag behind kernel API changes, which is a maintenance burden rather than an absolute blocker.

Because they are legally required to wait 12 months.

Why it fails: No regulation imposes a twelve-month waiting period on kernel adoption; the delay stems from stabilisation and certification cycles. The option is tempting because compliance frameworks do mandate validation before deployment, but that validation is vendor-driven, not a fixed statutory interval.

Because they lack the technical staff to compile new kernels.

Why it fails: Enterprise distributions employ large kernel engineering teams who backport fixes and build their own kernels routinely. The option tempts because compiling upstream kernels is genuinely difficult for individuals, but the delay reflects deliberate stabilisation and long-term support commitments, not a staffing shortage.

Set the directory permissions to 777 so the contractor can read and write regardless of ownership.

Why it fails: Mode 777 grants read, write, and execute to every user on the system, far exceeding the contractor's needed access and creating a serious security exposure. This approach ignores the principle of least privilege and would also allow other unrelated users to modify or delete project files.

Change the directory's group to the contractor's primary group and set permissions to 770.

Why it fails: Changing the group affects every member of that group and removes access from the original owning group, which violates the requirement to avoid altering ownership semantics. It also grants access to anyone else in the contractor's group, making the permission broader and less controlled than the scenario demands.

Create a hard link to the directory inside the contractor's home directory.

Why it fails: Hard links to directories are not permitted on Linux because they would create cycles in the filesystem tree, so this approach cannot even be performed. Even if linking were possible, it would not confer permissions, since access is still evaluated against the target directory's mode and ownership.

stat

Why it fails: stat displays detailed metadata including permissions, inode, size, and timestamps, but it does not identify the file type in a human-readable way beyond the mode bits. It is useful for permissions but does not classify content type like file does. The scenario asks for two commands that together cover type and permissions, and stat overlaps with ls -l on permissions without adding type detection.

cat

Why it fails: cat concatenates and displays file contents. It does not report file type or permissions, and it opens the file to read its data, which the scenario explicitly wants to avoid. Using cat on a binary file can also corrupt the terminal. It is not a tool for inspecting metadata or file type.

less

Why it fails: less is a pager used to view file contents one screen at a time. It does not report file type or permissions and opens the file for reading, which contradicts the goal of identifying files without opening them. It is not a metadata inspection tool and therefore does not meet the requirement.

It can only be set by root.

Why it fails: Any user may set their own umask for the current shell and its children; root privilege is not required. Restricting it to root would be relevant only for system-wide defaults configured in profile files, not for the command itself.

It is stored in /etc/shadow.

Why it fails: The umask is a per-process attribute inherited from the shell, set via the umask builtin or shell profile, not a credential stored in /etc/shadow. That file holds hashed user passwords, so this confuses file-permission defaults with authentication data.

It applies to existing files immediately.

Why it fails: The umask only affects permissions assigned to files and directories created after it is set; existing entries retain their modes. It is correctly used to shape defaults for new creations, not to retroactively alter permissions on files already on disk.

userdel jdoe

Why it fails: userdel removes the account and, without the -r flag, leaves files orphaned with no owner, so it neither locks the account nor cleanly preserves access. It is tempting because it immediately revokes login, which suits permanently decommissioning a departed user rather than a temporary compromise lockout.

killall -u jdoe

Why it fails: killall -u terminates the user's running processes but leaves the account able to authenticate and log in again, so it does not lock anything. It is tempting because it instantly severs active sessions, which suits stopping runaway processes rather than preventing future credential-based access.

chsh -s /bin/false jdoe

Why it fails: chsh changes the login shell to /bin/false, blocking interactive logins, but the account remains enabled and usable through other services such as FTP or scheduled jobs. It is tempting because it is non-destructive, which suits restricting shell access for service accounts rather than fully locking a compromised one.

find

Why it fails: find locates files by name, size or timestamp within a directory tree; it does not read, extract or create archive contents. It is tempting because find can locate an archive file before you operate on it, which suits filesystem searches, but managing archive contents requires tar, gzip or zip.

cat

Why it fails: cat concatenates and prints file contents to standard output; it neither decompresses nor extracts archive members. It is tempting because cat can display a plain tar file's raw bytes, which suits inspecting uncompressed text, but managing compressed archives requires tar, gzip or zip.

grep

Why it fails: grep searches text patterns within files or streams; it cannot list, extract or create archive members. It is tempting because piping an archive's file listing through grep filters entries by name, which suits locating a file, but managing archive contents requires tar, gzip or zip.

netstat

Why it fails: netstat lists existing socket connections, routing tables and interface statistics; it does not capture or display individual packet contents in real time. It would be correct for checking open ports and connection states, not for the stem's packet capture requirement.

iptables

Why it fails: iptables is a packet-filtering firewall that accepts, drops or forwards traffic; it neither captures nor displays packet contents. It would be correct for enforcing host-based network access rules, not for the stem's real-time traffic capture and inspection requirement.

nmap

Why it fails: nmap performs port scanning and host discovery by sending probe packets, then reports open ports and services; it does not capture and display live packet payloads. It would be correct for network inventory and security auditing, not the stem's real-time traffic monitoring.

Network protocols (10)

Why it fails: Section 10 of the Linux manual covers miscellaneous conventions and administrative commands, not network protocols. It is tempting because networking is a technical topic, but protocol documentation lives in section 7 (overview conventions) or section 3 (library calls), not the miscellaneous section.

Kernel hardware (20)

Why it fails: Section 20 is not a standard Linux manual section; kernel and hardware interfaces are documented in section 4 (special files) and section 9 (kernel routines). It is tempting because kernel topics are real, but the numbering is wrong: section 20 does not exist in the conventional manual layout.

find

Why it fails: find searches the entire filesystem, which is overkill for executables in PATH.

locate

Why it fails: locate uses a database and might not be up-to-date.

whereis

Why it fails: whereis finds binaries, sources, and man pages, but 'which' is the specific tool for the command in PATH.

tail -n 5 file

Why it fails: tail shows the end of the file.

cat -n 5 file

Why it fails: cat -n adds line numbers to all lines.

ls -lt

Why it fails: This puts the newest files at the bottom.

ls -lr

Why it fails: This sorts alphabetically in reverse.

ls -Rlt

Why it fails: This adds recursion, which is unnecessary here.

/etc/network/interfaces

Why it fails: This configures the network interface, not DNS lookups.

/etc/sysconfig/network

Why it fails: This file is for global networking parameters on some distributions.

/etc/hosts

Why it fails: /etc/hosts is for static local mappings, not dynamic DNS resolution.

cat file1 + file2 | wc -l

Why it fails: Invalid syntax.

cat file1 file2 > wc -l

Why it fails: '>' redirects to a file named 'wc', it does not pipe.

cat file1 | cat file2 | wc -l

Why it fails: The first cat output is lost, only file2 is processed.

/etc/hosts

Why it fails: This maps hostnames to IP addresses.

/etc/sysconfig/network-scripts/ifcfg-eth0

Why it fails: This is the location used on RHEL/CentOS systems.

/etc/resolve.conf

Why it fails: This is for DNS configuration.