Refer to the Exhibit Practice Questions

The script lacks execute permissions

Why it fails: If the script lacked execute permissions, the shell would refuse to run it with ./script and return 'Permission denied'. Since the user was able to execute it and observe the described behavior, the execute bit must be set; therefore permission is not the cause. The question is about variable scope, not file mode.

The 'export' command is incorrectly placed after the variable assignment

Why it fails: The placement of export after the assignment is perfectly valid syntax. Both forms — `VAR=value; export VAR` and `export VAR=value` — are equivalent in bash and fully export the variable to the current shell's environment. The issue here is not the order of these commands, because in either case the script runs in a sub-shell whose exports vanish when the process ends. Thus the ordering cannot explain why the parent does not see the variable.

The variable name should be in uppercase for it to be inherited

Why it fails: Environment variable names are case-sensitive, but the shell does not require uppercase names for inheritance; `export myvar` works identically to `export MYVAR` as long as you are consistent. The conventional ALL_CAPS style is only a human-readable guideline to avoid collisions with internal shell variables. Therefore changing the variable to uppercase would not change the fact that a script's exports are confined to the child process and its descendants.

The = operator should be == for string comparison.

Why it fails: The error is not caused by using = instead of ==. In POSIX test/[ ], = is the correct string equality operator; == is a bash-ism that is also accepted but not required. The script's real problem is that an unquoted empty variable expansion removes a required argument, causing the test to misinterpret the operator token and emit the unary-operator error. Switching to == would not fix the underlying missing operand.

The string 'value' contains spaces.

Why it fails: The literal string 'value' does not contain spaces, so that is not the source of the error. Even if the string had spaces, unquoted expansion of the empty variable would still cause the same structural test failure, because the error arises from word splitting and argument count, not from the contents of the compared string. The correct diagnosis is the missing variable argument, not whitespace in the literal.

The script is missing a valid shebang.

Why it fails: The shebang is not the issue; if it were missing or invalid, the kernel would reject the file with 'No such file or directory' or an exec format error, whereas this error is produced by the test command during execution. A valid shebang is present and correct, so the script actually runs far enough to reach the [ builtin and fail on its arguments. The error message itself proves the script executed, which means the shebang fulfilled its purpose.

/data will be mounted read-only because the remount persists across reboots.

Why it fails: A remount operation only modifies the in-kernel mount flags for the current session; it writes nothing to /etc/fstab or any other persistent configuration. Mount options are re-read from fstab on every boot, so the remount cannot cause a read-only state to persist across reboots unless fstab itself had been changed to ro. Therefore, the statement is false — the remount has no durability across reboots.

/data will not be mounted because the filesystem is marked as read-only.

Why it fails: The mount -o remount command does not alter the filesystem superblock or any on-disk metadata; it only changes the in-memory VFS mount options. A filesystem is never inherently 'marked read-only' in a way that would prevent mounting; even a filesystem originally mounted ro can be remounted rw (if permitted). The command simply re-applies or updates the mount flags, and the filesystem's superblock is left untouched.

/data will be mounted read-only because the kernel remembers the last mount state.

Why it fails: The kernel does not remember or persist mount state between reboots; mount information is stored in the kernel's VFS structures only at runtime. After a reboot, the kernel starts fresh and mount options are determined solely by /etc/fstab, autofs, or manual mount commands. Thus, the last mount state is gone once the system restarts, and a remount performed before shutdown cannot influence the next boot's read-only status.

The array is in a degraded state and the recovery is waiting for the resync to start, but the event count is zero; the array may need to be forced to start recovery.

Why it fails: The array is clearly degraded, as shown by the [_U] status where only one device is active, and recovery is stuck at 0.0%. An event count of zero indicates that mdadm has not registered any state change for the re-added disk, so resync is not underway. This often happens when the array was previously marked as clean and the spare metadata does not trigger automatic recovery; you may need to force assembly with 'mdadm --assemble --force' or run 'mdadm --run' to start the resync. Without this intervention, the array remains degraded even though the disk is present.

The recovery is complete because the data is already synchronized.

Why it fails: The recovery is explicitly reported as 0.0% in the status output, meaning no synchronization has completed. Additionally, the array layout [_U] shows that only one device (the original) is active, while the re-added disk has not been integrated as a live member. If recovery were complete, the array would show a state like 'clean' or 'active' with both devices present as 'UU', and recovery progress would be absent. Therefore, the data is not synchronized and the array is still degraded.

The new disk /dev/sdb1 has a different size than the original, causing the recovery to stall.

Why it fails: A size mismatch would not cause recovery to stall silently; mdadm would normally fail to add the device if it were too small, or it would adjust the array size if the disk were larger. In the exhibit, /dev/sdb1 is 10G while the md array is only 1G, but the disk was successfully re-added as a member in the output. A size difference does not prevent resync from starting—the array uses the minimum size for recovery, and the event count of zero is the real indicator of the issue. Thus, the stall is due to recovery not being triggered, not a disk size problem.

The container is using host networking mode.

Why it fails: In host networking mode Docker would not assign a separate 10.88.0.2 IP address; the container instead shares the host's network stack and shows the host's own IP in `docker inspect`. The presence of a distinct bridge-network IP proves the container is not using host mode, because host mode bypasses the Docker bridge entirely and would have no per-container IP entry.

The container cannot be reached from other containers.

Why it fails: Other containers attached to the same default bridge network can reach this container at 10.88.0.2, since all bridge-connected containers are placed on a common, isolated Ethernet network. Even without a `PortBindings` entry, inter-container traffic over the bridge is free to use the container's IP address and port 3306. The 0.0.0.0 host binding only affects traffic arriving from outside the bridge, not communication between containers.

The container is using bridge networking with a static IP.

Why it fails: A static IP assignment would require a user-defined network with an explicit `--ip` option or the container's `ipam` configuration; the plain 10.88.0.2 shown here is a typical dynamically assigned address from the default bridge's auto-allocation pool. The default bridge network does not support static IPs unless the container is connected to a custom network, and the JSON shows no `NetworkMode` or `IPAM` fields indicating a manual configuration. Thus, the IP is necessarily dynamic.

Mount /dev/sdc directly

Why it fails: Issuing mount /dev/sdc /some/dir attempts to mount the whole raw disk, not a filesystem. While Linux can sometimes mount certain filesystems on a whole disk device, /dev/sdc currently has no partition table and no filesystem, so the mount will fail with an error like 'wrong fs type, bad option, bad superblock'. The proper workflow in most enterprise environments is to create a partition (e.g., /dev/sdc1), format it, and then mount that partition.

Add an entry to /etc/fstab

Why it fails: Adding an entry to /etc/fstab for /dev/sdc (or /dev/sdc1) is premature because the device node /dev/sdc1 does not exist and /dev/sdc has no filesystem. Even if you wrote a line specifying /dev/sdc as the device, systemd and mount commands would attempt to mount a blank device and fail at boot or during manual mount. The /etc/fstab entry should only be created after the partition and filesystem exist, and you must also test the entry with 'mount -a' to avoid boot issues.

Run mkfs.xfs /dev/sdc1

Why it fails: Running mkfs.xfs /dev/sdc1 will fail because /dev/sdc1 does not exist in the kernel's device list; the disk /dev/sdc has no partitions. Attempting to format a nonexistent block device produces an error such as 'No such file or directory' from mkfs. The partition must be created first (with fdisk or parted), and only after that can you create the filesystem on the partition.

Run mount -o remount,noexec /boot without editing /etc/fstab

Why it fails: This remount command applies the noexec flag immediately, so it works for the current session, but it does not modify /etc/fstab. Because /boot will be remounted from fstab options at the next boot, the noexec setting is lost on reboot. System administrators must edit fstab to make mount option changes permanent, otherwise the temporary remount only masks the problem until the system restarts.

Run umount /boot, edit /etc/fstab to add 'noexec', then mount /boot

Why it fails: Unmounting /boot before changing fstab is unnecessary and risky; if any process or the kernel is using files from /boot, the umount command will fail with a "target is busy" error. Even if it succeeded, a subsequent mount would apply the new options, but this approach is disruptive and can cause a boot failure if the mount does not happen cleanly. A remount is designed to switch flags on a live filesystem and avoids these problems.

Edit /etc/fstab to add 'noexec' to the /boot entry, then run mount -a

Why it fails: The mount -a command only mounts filesystems listed in /etc/fstab that are not currently mounted; it does not remount filesystems that are already active. Since /boot is already mounted before the fstab edit, mount -a will skip it and leave the old options in effect. To apply the changed noexec flag to the running system, you need an explicit remount, and mount -a would only matter after the edit for mounts that are not yet mounted.

firewall-cmd --add-service=8443/tcp --permanent

Why it fails: The --add-service option expects a named firewalld service (such as http or https), not a port/protocol string. Passing '8443/tcp' as a service name is invalid because no service with that name is defined, so the command would fail and the permanent configuration would not be updated. To open a non-standard TCP port such as 8443, the correct syntax is --add-port=8443/tcp.

firewall-cmd --add-port=8443/tcp

Why it fails: This command modifies only the runtime firewalld configuration, so the rule disappears after a reboot or firewalld restart. It also never executes --reload, but more importantly it lacks --permanent, meaning the change is not persisted to the permanent configuration. For a persistent HTTPS listener on 8443, you must include --permanent and then issue --reload to activate the saved rule.

firewall-cmd --add-port=8443/tcp --zone=public

Why it fails: This command applies the port rule to the public zone's runtime configuration only, because --permanent is missing; the default zone is indeed public, so the zone specification is redundant but harmless. After the next firewalld restart or system reboot the rule will be gone. To survive reboots, add --permanent and then run --reload.

Run mount /dev/sdb1 /mnt/data

Why it fails: Running mount /dev/sdb1 /mnt/data immediately will fail because /mnt/data does not exist; mount(8) cannot create mount points. The kernel requires a valid path to an existing directory, and returns 'mount: /mnt/data: mount point does not exist' if the path is absent. You must first create the directory with mkdir, then issue the mount command.

Run partprobe to detect the partition

Why it fails: partprobe is used to notify the kernel of changes to the partition table so it can re-read a device's partition layout. In this scenario, lsblk already shows /dev/sdb1, meaning the partition was already detected and registered in /sys/block/sdb/sdb1. Running partprobe would no-op or re-scan, but it performs no mounting operation and does not create a mount point.

Run mkfs.xfs /dev/sdb1

Why it fails: mkfs.xfs /dev/sdb1 writes a new XFS filesystem superblock and metadata to the partition, destroying any existing data and filesystem that may already be present. The administrator's immediate requirement is to mount the existing filesystem, not reinitialize it. Formatting should only be done deliberately, after checking with blkid or file -s, and is a separate step from attaching a filesystem to the directory tree.

Edit /etc/fstab and add an entry

Why it fails: Editing /etc/fstab adds an entry for automatic mounting at boot or for use with 'mount -a', but it does not perform an immediate mount. Even after a correct fstab entry is added, you still need to explicitly run 'mount /dev/sdb1 /mnt/data' or 'mount -a' to attach the filesystem now. Since the goal is simply to mount the device right away, the fstab modification is unnecessary and could introduce boot-time failures if misconfigured.

The user's home directory is missing.

Why it fails: 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 it fails: 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 it fails: /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.

/data

Why it fails: The exhibit shows /data mounted with standard options such as rw and relatime, but does not list noexec anywhere in that row, meaning binaries stored on /data can be directly executed. As a dedicated data volume, /data would need an explicit noexec flag in the mount options to block execution, and since it is absent, /data is not the mount point described in the question.

/

Why it fails: The root filesystem is mounted at / with options like rw and relatime, and noexec is absent from its mount options, so it is not the correct answer. Furthermore, applying noexec to / would prevent init, systemd, and all core binaries in /usr from being executed via execve(), making the system unbootable. The exhibit's lack of noexec on / reflects that the root filesystem must remain executable for the OS to operate.

/var

Why it fails: In the exhibit, /var is mounted with rw and relatime but not with noexec, so executable files under /var, such as package manager scripts or programs in /var/lib or /var/tmp, are still allowed to run. The /var filesystem is designed to hold variable data like logs and spool files, yet it is not hardened with noexec in this configuration. Because noexec is not shown for /var, this mount point cannot be the one the question asks about.

/boot

Why it fails: Although /boot is a separate small partition, the exhibit shows it mounted with rw and relatime but without noexec, so it is not the mount point in question. During the boot process, the firmware and bootloader read kernel images directly from /boot without invoking a filesystem exec() call, so noexec would have little practical effect there. Since noexec is absent from the /boot row, it cannot be the correct choice.

Create a new partition on /dev/sdc and format with xfs

Why it fails: Using a separate disk is possible, but the exhibit shows /dev/sdc has no filesystem on sdc1; however, sdc1 exists but no FSTYPE. Could be used, but the question asks about creating a filesystem; LVM might be more flexible. But the answer is not wrong per se. However, the exhibit shows VG vg00 has no free space, so you cannot extend vg00. You would need to use /dev/sdc or another disk.

Shrink /home to free space in vg00 and create a new LV

Why it fails: Shrinking `/home` to reclaim space from `vg00` would not address the requirement because the scenario likely involves a separate volume group or dedicated disk for `/var/log`, not shared space in `vg00`. This option is tempting because shrinking a logical volume to free space in a volume group is a standard method for reallocating storage when multiple filesystems share the same VG; it would be correct if `/var/log` were also in `vg00` and free space were needed there.

Create a new volume group using /dev/sdb

Why it fails: Creating a new volume group from /dev/sdb is incorrect because the exhibit shows /dev/sdb already contains an ext4 filesystem and is mounted at /mnt/backup. Reusing that device for a new VG would require destroying its existing filesystem with pvcreate, causing data loss and disrupting the backup mount. Even if you intended to keep it separate, the requirement is to create a new filesystem, and /dev/sdb is already allocated for backup storage, whereas /dev/sdc is free and unformatted, making it the appropriate device to integrate into vg00.

lvcreate -L 1.2T -n data myvg mkfs.ext4 /dev/myvg/data echo '/dev/myvg/data /data ext4 defaults 0 0' >> /etc/fstab mount -a

Why it fails: The `lvcreate` command incorrectly specifies the logical volume size. Using `-L 1.2T` requests 1.2 Terabytes (TB), an SI unit (10^12 bytes), whereas the requirement is for 1.2 Tebibytes (TiB), a binary unit (2^40 bytes). This difference means the created volume will be smaller than the specified TiB size. This option is tempting because `T` is a common abbreviation for large storage, and it would be correct if the question had specified 1.2 TB instead of 1.2 TiB.

lvcreate -l 100%FREE -n data myvg mkfs.xfs /dev/myvg/data echo '/dev/mapper/myvg-data /data xfs defaults 0 0' >> /etc/fstab mount -a

Why it fails: This option fails because -l 100%FREE consumes all remaining free space in volume group myvg instead of creating a precisely sized 1.2 TiB logical volume; this is typical when the administrator misinterprets the percentage flag as a way to 'use what you need'. Additionally, while /dev/mapper/myvg-data is the driver-level device name, /dev/myvg/data is the preferred, cleaner LVM2 path for use in /etc/fstab. The volume’s actual size—not the device path—is the decisive reason the answer is wrong.

lvcreate -L 1200G -n data myvg mkfs.ext4 /dev/myvg/data echo '/dev/myvg/data /data ext4 defaults 0 0' >> /etc/fstab mount -a

Why it fails: This option undersizes the logical volume: in lvcreate, the uppercase G suffix means GiB (1024^3 bytes), so 1200G equals 1200 GiB, which is only 1.171875 TiB—short of the required 1.2 TiB. While mkfs.ext4 and the fstab entry with /dev/myvg/data are technically valid and mount -a would work, the volume itself is too small to satisfy the capacity requirement. The correct approach must allocate exactly 1.2 TiB.

wheel:x:10:carol,root,alice,bob

Why it fails: Incorrect. Although 'carol' appears in this line, the order is different and the list does not match the typical output of `useradd -G`. The `-G` option appends the user to the supplementary group list, so 'carol' should appear at the end, following the existing members 'root,alice,bob'. Additionally, option A places 'carol' first, which is not the default behavior of `useradd -G` on Red Hat systems.

wheel:x:10:root,alice,bob,carol,

Why it fails: A trailing comma after the last member creates an extra, empty field in the /etc/group member list. The standard format for the group file is a comma-separated list with no empty entries, so wheel:x:10:root,alice,bob,carol, is invalid and would be rejected or misinterpreted by utilities that parse /etc/group. When useradd -G appends a user to a group, it writes the username directly after the last existing member, never with a trailing separator.

wheel:x:10:root,alice,bob carol

Why it fails: The /etc/group file uses commas as the sole delimiter between member account names; spaces are not valid separators and are treated as characters within a username. In wheel:x:10:root,alice,bob carol, the tool would attempt to interpret 'bob carol' as a single username, which cannot exist because usernames cannot contain spaces. The output generated by useradd -G always places a comma immediately before each new member, never a space, so this line could not result from the command.

The [[ ]] syntax always evaluates to true

Why it fails: The [[ ]] compound command is a conditional expression that evaluates the test inside; it returns 0 only when the test is true, and 1 when false. Its outcome is always dependent on the operands and operators (e.g., -f, -z, =~, <, >). Thus claiming it always evaluates to true is incorrect; it can just as easily evaluate to false and yield a non-zero exit status.

The $? variable is only set after external commands, not builtins

Why it fails: The shell sets $? after every command, including builtins like echo or cd, keywords like [[, and functions. It is not limited to external binaries; the shell updates it after each pipeline or simple command. Therefore, a builtin such as [[ will update $? when it runs.

The $? variable always returns 0 in a conditional

Why it fails: The value of $? is simply the exit code of the last executed command; a conditional does not force it to be 0. When a [[ ]] test is false, it returns 1 (or another non-zero code), so $? becomes non-zero. Thus $? will be 0 only if the last command happened to succeed, not because it was evaluated in a conditional context.