Select Two (Multi-Select) Questions

/etc/shadow

Why it fails: This file holds password hashes and aging information rather than account enumeration or group membership. It is readable only by root, so a general audit of which accounts exist and what groups they belong to cannot rely on it. It answers password policy questions, not the membership questions posed here.

/etc/skel

Why it fails: This directory contains template files copied into a new user's home directory at creation time. It contains no account records or group mappings. While it influences the initial environment of new users, it cannot tell an auditor which accounts exist or which groups they belong to.

/etc/nsswitch.conf

Why it fails: This file controls the order in which name service sources such as files, ldap, or systemd are consulted for users, groups, and hosts. It determines where lookups go but stores no actual account or group data itself. It is useful context but not an authoritative listing for the audit.

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.

Recipients must always pay a licensing fee to the original author before deploying the software

Why it fails: Free and open source licenses do not require royalty payments to the original author for deployment or redistribution. While a company may charge for support, hosting, or packaged distributions, the license itself grants the software at no licensing cost. Stating that a mandatory fee exists misrepresents the permissions and would incorrectly discourage staff from using otherwise freely available software.

Recipients may remove the original author's copyright notice before publishing modified versions

Why it fails: Copyright notices and license texts must generally be preserved when redistributing, even under permissive licenses like MIT or BSD. Removing attribution can violate the license terms and expose the organization to legal risk. Although recipients may modify the code itself, stripping the author's notice is not one of the granted freedoms and would misstate the policy the nonprofit is drafting.

Recipients may redistribute the software only within the same organization that originally obtained it

Why it fails: Redistribution rights extend beyond the original recipient's organization; that is central to how open source spreads. Licenses may impose conditions, such as providing source under copyleft terms, but they do not confine distribution to a single entity. This statement would wrongly restrict the nonprofit from sharing tools with partners or the public, contradicting the freedoms the policy is meant to describe.

cat

Why it fails: cat concatenates and displays file contents; it performs no partition table manipulation. It is tempting because it is a core Unix utility frequently used alongside administrative commands, but partitioning requires tools such as fdisk, parted or gdisk that write partition tables. cat would be correct for reading or joining files.

sed

Why it fails: sed is a stream editor that transforms text line by line; it has no mechanism to read or write partition tables. It is tempting because it is a standard Unix tool used in administrative scripting, but partitioning requires fdisk, parted or gdisk. sed would be correct for automated in-place edits of configuration files.

grep

Why it fails: grep searches text streams for lines matching a pattern; it cannot create, delete or resize disk partitions. It is tempting because it is a ubiquitous command-line utility often used in administration scripts, but partition management needs fdisk, parted or gdisk. grep would be correct for filtering log or configuration output.

Avoiding version control systems and keeping configuration changes only in local notes on each administrator's workstation for speed.

Why it fails: Version control is essential in DevOps for tracking configuration, scripts, and pipeline definitions. Keeping changes only in local notes prevents collaboration, auditability, and rollback, and directly undermines automation and reproducibility. This practice is contrary to DevOps principles and would not help the administrator build relevant skills.

Manually installing each server from physical installation media and configuring every service by hand to ensure unique, tailored setups.

Why it fails: Manual, per-server installation and hand configuration is the opposite of DevOps practice, which favors automation, consistency, and repeatability. While manual setup may occasionally be needed for legacy systems, treating it as characteristic of a DevOps role misrepresents the discipline and would not develop the automation skills the administrator seeks.

Restricting all application changes to an annual release window and freezing the environment for the rest of the year to minimize risk.

Why it fails: Annual release windows and long change freezes reflect traditional, slow release cycles rather than DevOps, which emphasizes frequent, small, automated changes with strong testing. This practice would conflict with continuous delivery goals. It is therefore not characteristic of a DevOps-oriented Linux role and does not align with the administrator's interests.

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.

wc -c /var/tmp

Why it fails: The wc utility counts bytes, words, or lines in its input. Given a directory path, it cannot read the directory as a stream and returns an error rather than a classification. It is designed for measuring text files, not for determining whether an entry is a directory.

cat /var/tmp/*

Why it fails: The cat command concatenates and prints file contents to standard output. If a directory is among the arguments, cat reports an error such as 'Is a directory' and skips it, and for regular files it dumps raw data, which does not classify entries. It cannot be used to distinguish directories from regular files.

du -sh /var/tmp

Why it fails: The du command summarizes disk usage. With -s it prints a single total for the named path, and -h makes that total human-readable. It reports how much space /var/tmp consumes as a whole; it does not list individual entries or indicate which of them are directories.

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.

cd

Why it fails: cd changes the shell's working directory; it neither reads standard input nor writes standard output, so it cannot participate in a pipeline. It is tempting as a common shell builtin, and would be correct when navigating directories before constructing a pipeline.

pwd

Why it fails: pwd prints the working directory path to standard output and reads no input, so it cannot transform piped data. It is tempting because it is a standard shell command producing output, and would be correct when you need to confirm your current location before running a pipeline.

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.

It guarantees that all configuration files are stored in a single directory regardless of the software package.

Why it fails: While /etc is the conventional home for system configuration, many applications also place configuration under /usr/local/etc, within their own directories under /opt, or in per-user dotfiles. The standard recommends conventions rather than an absolute single directory, and real deployments vary. This overstatement does not match how the hierarchy is actually applied.

It specifies the exact kernel version that a conforming distribution must ship.

Why it fails: Kernel version selection is entirely outside the scope of the Filesystem Hierarchy Standard, which addresses directory organization. Distributions choose kernels based on support cycles, hardware needs, and vendor policy. Claiming the standard dictates a kernel version misrepresents its purpose and is clearly wrong.

It mandates that every distribution use the ext4 filesystem for the root partition.

Why it fails: The Filesystem Hierarchy Standard governs directory structure and file placement, not the on-disk filesystem format. Distributions may use ext4, XFS, Btrfs, or others for the root filesystem while still conforming to the FHS. This statement confuses layout conventions with storage technology and is therefore incorrect.

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.

passwd

Why it fails: passwd only changes a user's own password; it cannot create, modify or delete accounts, so it fails lifecycle management. It is tempting because password expiry is part of account maintenance, and passwd would be correct for enforcing credential rotation on an existing account.

groupadd

Why it fails: groupadd creates a group entry, not a user account, so it plays no part in creating, modifying, or deleting users. It is tempting because group and user administration are both identity-management tasks, and groupadd would be correct when provisioning a supplementary group that user accounts are later assigned to.

Recommending the software to colleagues who are looking for alternatives

Why it fails: Word-of-mouth promotion can raise a project's visibility, but it is not a direct contribution to the codebase, documentation, translations, or testing. No artifact is submitted to the project's maintainers. The scenario asks for direct contributions, so advocacy, while helpful, does not meet that standard the way a patch or documentation update does.

Reading the project's release notes to learn about new features

Why it fails: Reading release notes is a learning activity for the administrator, not a contribution to the project. It produces no artifact that maintainers can incorporate. While staying informed is good practice, it does not advance the software or help other users. The scenario distinguishes between consuming information and actively giving back to the community.

Installing the software on a personal laptop and using it for daily tasks

Why it fails: Using software is consumption, not contribution. While widespread adoption benefits a project, simply running it on a laptop does not add code, documentation, translations, testing feedback, or other artifacts back to the community. The scenario asks for activities that directly contribute to the project, and personal use does not qualify as participation in development.

ROOT

Why it fails: ROOT names the superuser account, not an environment variable; the shell exposes it via $HOME, $USER or $UID instead. It is tempting because ROOT appears throughout Linux permissions and sudo discussions, and would be relevant when answering a question about account types or privilege levels rather than shell variables.

FILE

Why it fails: FILE is not a standard shell environment variable; the shell provides $0, $1 and $? for script and argument context. It is tempting because FILE resembles variables used inside shell scripts or Makefiles, and would be the right answer to a question about user-defined script variables rather than inherited shell variables.

Requiring students to reverse engineer a proprietary application and publish its source code.

Why it fails: Reverse engineering and publishing proprietary source code violates the license of that software and is not a collaborative open source practice. It teaches students to disregard licensing, which is the opposite of the respect for copyright and licensing that open source communities depend on to function legally.

Having students purchase a commercial license before reading any project documentation.

Why it fails: Most open source projects publish documentation freely and do not require a commercial license to read or contribute. Making a purchase a prerequisite misrepresents how open source participation works and would exclude students from the very communities the course is meant to introduce.

Instructing students to keep all modifications private and never share changes with the upstream project.

Why it fails: Keeping changes private defeats the purpose of collaborative development and removes the chance for peer review. While some organizations do maintain internal forks, an educational activity meant to reflect open source culture should emphasize sharing improvements back so that the wider community benefits.

It is readable by all users because the passwd command must consult it during a normal login.

Why it fails: Ordinary users do not read /etc/shadow directly; privileged processes such as the login program, which run as root or with elevated capability, perform the lookup. The passwd command for changing one's own password uses the setuid mechanism to gain the needed privilege. Making the file world-readable would defeat the purpose of separating it from /etc/passwd.

It can be read by any user who supplies the correct password through the sudo prompt.

Why it fails: sudo grants access based on policy in /etc/sudoers, not by validating the target file's password. A user permitted by sudoers could run a command as root and thereby read the file, but that is a privilege grant, not a property of the file. Users without sudo rights cannot read it at all, so the statement does not describe how /etc/shadow access works.

Its contents are encrypted with a system-wide key stored in /etc/crypttab, so permissions are largely irrelevant.

Why it fails: /etc/crypttab describes encrypted block devices to unlock at boot; it has nothing to do with password storage. The entries in /etc/shadow are one-way hashes, not reversible ciphertext, so there is no key that decrypts them. Permissions remain the primary control protecting those hashes from offline attack.

cd

Why it fails: cd changes the shell's current working directory; it never reads or prints file contents. It is tempting because it is a core file-system command used constantly alongside file viewing, and it would be correct when navigating to the directory holding the text file before displaying it with cat or less.

mkdir

Why it fails: mkdir creates a new directory entry and produces no file output. It is tempting because it is a standard file-system command often typed in the same session as viewing files, and it would be correct when creating a directory to hold text files, not when reading one.

mv

Why it fails: mv relocates or renames a file within the file system and outputs nothing to standard output. It is tempting because it operates directly on files, and it would be the correct command when reorganising or renaming a text file rather than displaying its contents.

/etc/login.defs

Why it fails: /etc/login.defs defines system-wide defaults for user creation and password policies, such as UID ranges and password aging. It does not store actual user account details; it provides configuration parameters. Thus, it is not a source of user account information, though it influences how accounts are created.

/etc/group

Why it fails: /etc/group defines group information, including group name, GID, and members. While related to user accounts, it does not store individual user details like passwords or home directories. It is used for group permissions, not for user account specifics. Thus, it is not a primary source for user account details.

/etc/gshadow

Why it fails: /etc/gshadow contains encrypted group passwords and group administrators. It is analogous to /etc/shadow but for groups. It does not hold user account information such as usernames or UIDs. Therefore, it is not a correct choice for user account details, though it is part of the authentication system.

/etc/tmp

Why it fails: /etc holds static host-specific configuration files such as passwd, fstab and hosts; temporary data belongs under /var/tmp or /tmp, which are cleared between reboots. The name tempts because /etc contains many subdirectories, yet none is designated for transient files. /etc/tmp would be correct only if a package deliberately created it.

/etc/bin

Why it fails: /etc stores configuration files, not executables; binaries live in /bin, /usr/bin or /usr/local/bin. The path tempts because /etc contains numerous subdirectories, so a bin-like name appears plausible. /etc/bin would be correct only if an administrator manually created it for site-specific configuration scripts, which is non-standard.