Refer to the Exhibit Practice Questions

Use parted to resize the root partition and then mount it

Why it fails: Resizing the partition with parted does not grow the filesystem itself, and remounting does not resize it; resize2fs must run afterwards. It is tempting because parted is the correct tool for manipulating the partition table when extending a partition into adjacent unallocated space.

Use fdisk to increase the size of /dev/sda1 and then run resize2fs

Why it fails: fdisk writes the partition table but does not inform the running kernel of the new size, so resize2fs would still see the old block device size; partprobe or a reboot is required first. It is tempting because fdisk plus resize2fs is the correct sequence for growing a partition on a disk with free space.

Create a new filesystem on /dev/sda2 and mount it to /

Why it fails: Creating a fresh filesystem on /dev/sda2 and mounting it at / would discard the existing root data and cannot extend the current filesystem in place. It is tempting because adding a separate partition is the correct approach when you need extra storage mounted at a new mount point, such as /data.

The swap partition

Why it fails: Swap partitions carry no filesystem for fsck to check and are given a pass number of 0 in /etc/fstab, so fsck skips them entirely. It is tempting because swap is configured in /etc/fstab alongside real filesystems, and it would be relevant only to swapon, not to boot-time filesystem checking.

The CD-ROM device

Why it fails: The CD-ROM device is mounted read-only with a pass number of 0 in /etc/fstab, so fsck never checks it. It is tempting because it appears as an fstab entry like any other mount, and it would be the correct answer only if the question asked which device is excluded from boot-time checking.

The /boot filesystem

Why it fails: fsck processes filesystems in the order listed in /etc/fstab, skipping entries whose sixth field is 0; /boot typically carries a pass number of 2, so it is checked after any pass-1 filesystem. It is tempting because /boot holds the kernel, and it would be correct if its pass field were 1.

The NTP service is not running.

Why it fails: If ntpd were stopped, ntpq would fail to query the daemon and report no peers at all, rather than listing a peer at stratum 16. The stratum 16 entry shows the daemon is running but the peer is unreachable or unsynchronised, so this misreads the exhibit.

The firewall is blocking UDP port 123.

Why it fails: A blocked UDP port 123 would leave the peer unreachable, yet ntpq would still display the configured peer with stratum 16 and zero values, so this is superficially consistent. However, the exhibit's specific pattern points to the peer being rejected as unsynchronised rather than silently filtered.

The restrict lines are blocking all NTP queries.

Why it fails: Restrict lines govern which hosts may query or modify the local daemon; they do not set a remote peer's stratum to 16. Blocking queries would prevent ntpq itself from returning data, so this misattributes a peer synchronisation failure to local access-control configuration.

python --version2

Why it fails: python --version2 passes --version2 as an argument to the Python 3 interpreter, which rejects it as an unrecognised option; no version selector exists in that form. It is tempting because appending a version number to a command looks like a selector, and versioned binary names such as python2 are the real mechanism.

python3

Why it fails: python3 explicitly invokes the Python 3 interpreter, so it runs the same major version already reported, not Python 2. It is tempting because versioned interpreter names are the usual way to select a major version, and python3 would be correct when Python 2 is the default and Python 3 is required.

python2 --version

Why it fails: python2 --version only prints the installed Python 2 version string and exits; it never launches an interactive interpreter or executes a script. It is tempting because python2 is the genuine Python 2 binary, and invoking it with a script argument would correctly run code under Python 2.

Only messages with facility *.info are forwarded.

Why it fails: The facility is a wildcard, so every facility is matched; the priority after the dot sets the minimum severity, not a facility named info. It is tempting because the syntax places the priority after the dot, which reads like a facility filter if you misremember which side of the dot carries which field.

All syslog messages are forwarded via TCP to the server.

Why it fails: A single '@' forwards over UDP; TCP requires '@@'. The line therefore does not use TCP. It is tempting because forwarding to a remote syslog server is exactly what the line does, and TCP is often assumed for reliable delivery, but the transport is chosen solely by the '@' or '@@' prefix.

Only authentication-related messages are forwarded.

Why it fails: The selector's facility and priority determine which messages match; nothing in the line restricts forwarding to authentication services such as authpriv. It is tempting because authpriv logging is a common rsyslog use case, and a line naming a specific facility would indeed forward only those messages.

The package is unpacked but not configured.

Why it fails: The 'rc' status means the package was removed but its configuration files remain, not that it is unpacked and unconfigured. Unpacked-but-unconfigured is shown by 'iU'. This option tempts because dpkg does track unpacked and half-configured states, but those apply during installation, not after removal.

The package is installed and configured.

Why it fails: The 'rc' state means the package was removed but its configuration files remain, so it is neither installed nor configured. It tempts because 'c' suggests configuration present, and 'ii' is the status that actually denotes installed and configured.

The package is completely purged.

Why it fails: The 'rc' status means the package was removed but its configuration files remain, so it is not fully purged. Purging, which deletes those residual configuration files too, is what 'dpkg --purge' or the 'p' status would show.

The local mount point /mnt/nfs does not exist.

Why it fails: A missing local mount point produces a distinct error, yet the exhibit typically shows the NFS-specific failure rather than a directory-not-found message. This option tempts because absent mount points genuinely break 'mount -a', but that occurs when /etc/fstab references a path never created, not in the exhibited NFS timeout or server-unreachable case.

The filesystem type 'nfs' is not supported by the kernel.

Why it fails: The kernel almost certainly includes NFS client support; the exhibit would show a different error if the module were absent. This option is tempting because missing kernel modules do break mounts, but that scenario arises with custom-compiled kernels, not standard distributions where nfs.ko ships by default.

The 'defaults' option is missing for the NFS entry.

Why it fails: Omitting 'defaults' does not prevent mounting; mount applies implicit defaults when no options are listed. This option tempts because 'defaults' appears in most fstab entries, but its absence only matters when specific flags like 'noauto' or 'ro' are required, not for a basic NFS mount failure.

The minute field

Why it fails: The minute field controls only which minute within the hour the job fires; it cannot suppress a whole weekday. It is tempting because a stray value there changes timing, but Sunday exclusion comes from the day-of-week field, not minutes.

The hour field

Why it fails: The hour field sets which hours the job triggers, so a restricted value would skip hours on every day, not only Sundays. It is tempting since the job is hourly, but weekday-specific suppression is governed by the day-of-week field.

The month field

Why it fails: The month field governs which months a job runs, so a Sunday-only failure cannot stem from it. It is tempting because month and day-of-week fields look similar, but restricting months is the correct choice only when a job must skip entire calendar months, not one weekday.

The filesystem is mounted read-only

Why it fails: A read-only mount yields 'Read-only file system' (EROFS), not 'Permission denied' (EACCES). Read-only mounting is tempting because it does block writes, but it would be correct if the error message named the filesystem as read-only rather than citing permission.

The filesystem is mounted with the 'noexec' option, preventing write

Why it fails: 'noexec' blocks execution of binaries on the mount; it does not prevent creating or writing files. It is tempting because it is a restrictive mount option, but it would be correct when a user can write a script yet cannot execute it, producing a permission error on execution.

The file's permissions are 644, so the user does not have write access

Why it fails: Mode 644 grants the owner write access, so an owner writing would succeed; the exhibit shows the user is not the owner. File permissions are tempting because they commonly cause EACCES, but this would be correct when the user lacks write permission on the file itself.

Every minute of every hour, but only weekdays.

Why it fails: A weekday-only schedule requires a day-of-week field restricting execution to Monday–Friday, so this omits that constraint and would also run at weekends. It is tempting because cron's five fields can express per-minute and per-hour timing, which is the correct approach when the requirement genuinely is every minute of every hour.

Every day at midnight.

Why it fails: Midnight corresponds to the 0 0 field values, which the exhibit's schedule does not specify; the minute and hour fields indicate a different cadence. It is tempting because daily midnight execution is a common cron pattern, but the actual field values determine the real timing.

Every hour.

Why it fails: Hourly execution requires the minute field to hold a fixed value with the hour field as an asterisk, which the exhibit does not show. It is tempting because asterisks suggest repetition, but the specific minute and hour values define the true schedule.

grub-editenv

Why it fails: grub-editenv edits the small saved-environment block storing variables such as boot entry and next_entry; it does not rebuild grub.cfg from /etc/default/grub. It is tempting as a GRUB configuration tool, and would be correct for changing the default boot entry at runtime.

grub-install

Why it fails: grub-install writes bootloader files to a disk's boot sector or EFI partition; it does not regenerate grub.cfg from /etc/default/grub. It is tempting because both concern GRUB, and would be correct when reinstalling the bootloader after disk or firmware changes.

grub-set-default

Why it fails: grub-set-default only sets the default boot entry; it does not regenerate grub.cfg, so the serial console edits never reach the bootloader. It is tempting because it does write GRUB state, and it would be correct for changing which menu entry boots by default.

Increase the size of the /var/log partition using lvextend.

Why it fails: Growing the logical volume does not free space immediately and assumes unallocated space exists in the volume group; the stem asks for an immediate action. lvextend is the right choice when a filesystem genuinely needs more capacity and free physical extents are available.

Delete /var/log/syslog and restart the syslog daemon.

Why it fails: Deleting syslog destroys the log data the scenario requires preserving, and restarting the daemon does not recover it. Removal is tempting for reclaiming space quickly, and would be correct only when the logs are expendable or already archived elsewhere.

Move /var/log/syslog to /tmp and create a symbolic link.

Why it fails: Moving syslog to /tmp relocates the data onto another filesystem, so /var/log frees space only until the daemon reopens the path, and /tmp may be cleared on reboot. Relocation suits separating volatile data from persistent storage, not reclaiming space safely.

It is stopped.

Why it fails: A stopped unit reports inactive (dead) with no active process, while the exhibit shows the daemon active and running. It is tempting because an enabled-but-idle service can look dormant; the displayed active state confirms the daemon is currently executing, so stopped is contradicted.

It is enabled but not currently running.

Why it fails: Enabled describes start-at-boot configuration, not current runtime state, and the exhibit shows the unit active rather than merely enabled. It is tempting because enabled units often sit idle until triggered; here the daemon is actively running, so the enabled-but-not-running conclusion is wrong.

It has failed recently.

Why it fails: A failed unit shows an active failed state with a non-zero exit result, whereas the exhibit shows the daemon loaded and active. It is tempting because a service that exited unexpectedly can appear inactive; here the state reflects normal running, so no recent failure can be concluded.

Move some files from /var to / and create a symbolic link.

Why it fails: Moving files to / and symlinking them back leaves the data on the same physical volume, so no space is freed; it merely relocates paths. It is tempting because symlinks do consolidate scattered data, and this works when / resides on a separate disk, but here the first step is finding and deleting or archiving unneeded files.

Increase the size of /dev/sdb2 using resize2fs.

Why it fails: resize2fs grows the filesystem, but it cannot enlarge the underlying /dev/sdb2 partition, so the operation fails or leaves the partition unchanged. It is tempting because resize2fs is the standard ext4 growth tool, and it is correct once the partition itself has been expanded with parted or fdisk.

Add a new disk and mount it to /var.

Why it fails: Adding a new disk mounted to `/var` does not free space on the existing `/var` partition; it merely provides additional storage capacity, leaving the original partition still full. This option is tempting because mounting a new volume is a standard method to expand storage when a filesystem runs out of inodes or blocks, and it would be correct if the goal were to increase total available space rather than reclaim space from the current partition.

The command is an alias that conflicts.

Why it fails: Aliases are defined in shell configuration files and expand to existing commands; they are not files installed into /opt/bin/. The symptom arises because /opt/bin/ is missing from PATH, so the shell cannot locate the executable by name. Aliases matter when shortening frequently typed commands interactively.

The command has no execute permission.

Why it fails: A missing execute bit yields 'Permission denied', not a command-not-found failure requiring the full path. The actual cause is that /opt/bin is absent from the user's PATH, so the shell cannot locate the binary. Execute permission would be the issue if invocation failed with an access error.

The command is a function that overrides.

Why it fails: Shell functions live in the current shell's memory, not in /opt/bin/, and would be invoked by name without a path anyway. The failure stems from /opt/bin/ being absent from the PATH variable, so the shell searches only listed directories. Functions are relevant when overriding an existing command's behaviour within a session.