Refer to the Exhibit Practice Questions

The container is using host networking mode.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Format the partition with mkfs.ext4 /dev/sdb3

Why wrong: Formatting the partition /dev/sdb3 with mkfs.ext4 is incorrect because /dev/sdb3 is not a filesystem device; it is a physical volume used by LVM. Creating a filesystem directly on the PV would destroy the LVM metadata and render the volume group unusable. After creating the logical volume, the filesystem should be placed on the LV device node, such as /dev/vg01/lv01, not on the underlying partition.

Create a physical volume with pvcreate /dev/sdb3

Why wrong: Running pvcreate on /dev/sdb3 is unnecessary and potentially destructive because the exhibit clearly shows that /dev/sdb3 is already initialized as a physical volume. Reinitializing an existing PV with pvcreate would overwrite its LVM metadata, risking data loss and causing the volume group vg01 to become inconsistent. Since the PV already exists, the proper next action is to create a logical volume within the existing volume group.

Create a volume group with vgcreate vg01 /dev/sdb3

Why wrong: Creating a volume group with vgcreate vg01 /dev/sdb3 is wrong because vg01 is already present and already contains /dev/sdb3 as its physical volume, as shown in the exhibit. Running vgcreate would fail because the volume group name already exists, and attempting to reuse an already-assigned PV could corrupt LVM metadata. The volume group layer is already complete, so the administrator should proceed directly to logical volume creation.

The script is owned by root.

Why wrong: This is not the cause. On a typical RHEL system, root owns nearly all system crontab files and scripts, and cron jobs that run from root's crontab legitimately execute with root's privileges. Ownership only matters for determining the uid/gid during execution; it does not affect whether a script is executable. Since the cron job is running as root, root ownership is irrelevant to the failure.

The cron daemon is not running.

Why wrong: This is incorrect. If the cron daemon were stopped, the job would never be triggered, so no attempted execution and no error would appear in the cron log or email output. The exhibit shows the script is being launched and failing, which proves crond is alive and processing the crontab entry. Therefore, a non-running daemon cannot explain the observed permission-denied failure.

The script uses absolute paths.

Why wrong: This is wrong because using absolute paths in a cron job is a recommended practice. Cron executes jobs with a minimal PATH, so relying on relative paths or unqualified commands is a common source of 'command not found' errors. Here, the script paths are absolute, which avoids that entire class of problems and would not cause an execution permission error. Thus, the absolute-path usage is actually protecting the job, not breaking it.

xfs_repair /dev/sdc1

Why wrong: Running xfs_repair /dev/sdc1 attempts to check and repair an existing XFS filesystem by reading its superblock and metadata. If the partition has no XFS filesystem at all (or the superblock is not valid XFS), xfs_repair will abort with errors such as 'bad magic number' or 'not an XFS filesystem', so it cannot fix the mount failure. Because the mount error already suggests a missing or unrecognized filesystem, using xfs_repair presumes the very thing that needs to be verified first. You should first inspect the device with file -s to confirm whether an actual XFS filesystem exists before attempting any repair.

partprobe /dev/sdc

Why wrong: partprobe /dev/sdc forces the kernel to rescan the partition table on the disk and update the /dev/sdc1 block device representation after partition changes. This is only needed when the kernel has stale partition information, such as immediately after creating or deleting partitions, not when the partition already exists and is visible. The mount failure concerns the content of the partition (filesystem superblock), not the partition table layout. Therefore, running partprobe cannot help because it does not create a filesystem or validate the XFS superblock inside /dev/sdc1.

mkfs.xfs /dev/sdc1

Why wrong: Executing mkfs.xfs /dev/sdc1 creates a brand-new XFS filesystem, which writes a fresh superblock and metadata, irreversibly destroying any data that might be on the partition. If the partition already contains user data or a different filesystem, this action would cause catastrophic data loss, and if the mount error is due to anything other than an absent filesystem (like corrupt superblock or wrong mount options), reformatting is an unnecessarily destructive and incorrect response. The proper troubleshooting sequence is to first run file -s to determine what filesystem is actually present, then decide whether a more targeted repair like xfs_repair is appropriate, and only use mkfs.xfs as a last resort after confirming the partition is empty or data is backed up.

Root user can read, write, and execute; group and others have no access.

Why wrong: This choice misreads the permission string's execute bit. The notation 'rw' for the owner class indicates read and write permissions only; there is no execute (x) flag set, so the file is not executable via its permission bits. While root can bypass permission checks, that is not what these visible mode bits convey — they specifically deny execute to all classes.

Owner can read and write; group can read; others can read.

Why wrong: This choice incorrectly extends access beyond the owner. The three permission triads are 'rw-', '---', '---', meaning the owner may read and write, but the group and others have none of the read, write, or execute permissions. Therefore, the group cannot read the file and others cannot read it either, contrary to this answer.

Owner can read; group can read; others cannot access.

Why wrong: This choice understates the owner's permissions and wrongly grants group read access. The owner class actually has both read and write (rw-), not read-only, while the group class is entirely denied (---). Since the exhibit shows no access for group, saying group can read is incorrect.

The server's firewall is blocking the connection

Why wrong: A firewall block would prevent the TCP handshake from completing, causing the SSH client to hang until timeout or receive 'Connection refused' if the port is closed, not an SSH protocol-level error. Since the log contains sshd's own messages about the failed key exchange, the client's packets reached the sshd process on TCP port 22, proving no firewall dropped or rejected the connection.

The SSH service is not running

Why wrong: If the SSH service were not running, there would be no sshd process to write log entries, and the client would immediately get 'Connection refused' because nothing is listening on port 22. The exhibit explicitly shows sshd logging the negotiation failure, meaning the service is active and accepting TCP connections. An inactive or crashed sshd cannot generate a host key algorithm mismatch.

The client's IP is blacklisted

Why wrong: An IP blacklist implemented via /etc/hosts.deny, iptables, or fail2ban would cause the connection to be dropped or refused before SSH negotiation begins, typically logging a separate 'denied' or 'blocked' message. The log in question shows the client successfully reached sshd and exchanged KEXINIT messages, so the source IP was not blacklisted. Blacklisting would prevent any SSH banner or algorithm negotiation from appearing.

The filesystem is nearly full

Why wrong: A filesystem at 90% or even 99% capacity is irrelevant when 90G is free; write permission checks happen before any space allocation. Writing to a directory consumes space for a new directory entry, and an 'out of space' condition would typically surface as ENOSPC or a quota error, not as a permission denial. The reported 90G free clearly rules out a full filesystem as the cause.

The directory is owned by root and alice is not root

Why wrong: Unix permission evaluation first identifies the requester's relationship to the object — owner, group member, or other — but it is the mode bits that ultimately grant or deny access. Alice being a non-owner does not by itself prevent access, because group or other permissions could allow writing; for example, mode 770 would let group members write. In this case, the directory is set to 700, so 'others' (Alice) have no write permission, meaning the restrictive mode — not simple ownership — is what blocks her.

The directory has ACLs preventing access

Why wrong: The ls -l output shown in the exhibit has no '+' character after the permission string; a POSIX ACL, if present, is always indicated by a trailing plus sign, as in drwxrwx---+. Without that marker, only standard mode bits are in effect, and no ACL entries are masking or augmenting them. Therefore, the denial is fully explained by the ordinary 700 mode, not by any ACL rule.

podman attach mycontainer

Why wrong: podman attach connects your terminal to the standard input/output/error streams of a container that is already running. Because the exhibit shows the container is exited, there is no active process to attach to. You must first bring the container up with podman start before attach can be used.

podman restart mycontainer

Why wrong: podman restart is intended to cycle a running container by stopping it and then starting it again, not to launch a container that is already in the exited state. The container in this exhibit is exited, so the appropriate direct operation is simply podman start mycontainer, which changes the state from Exited to Running without a stop/start cycle.

podman run mycontainer

Why wrong: podman run creates and starts a brand-new container from an image, treating the first positional argument as an image reference, not as an existing container name. Since mycontainer already exists, a new container using that same name would cause a container-name conflict, and even without that conflict this command would not be restarting the existing container object.

The sshd service is not enabled.

Why wrong: Whether sshd is enabled (`systemctl enable sshd`) only controls whether it is automatically started at boot; it has no bearing on a runtime bind failure. If the service were merely not enabled, starting it manually would still bind successfully as long as port 22 is free, and `systemctl status sshd` would show "inactive (dead)" or "disabled" rather than a socket bind error at startup. The exhibit showing 'enabled' already rules this out.

SELinux is blocking the service.

Why wrong: SELinux enforcement causes denial messages such as 'Permission denied' on socket operations or AVC denials logged via `audit2why`; it does not produce EADDRINUSE, and sshd would fail earlier trying to create its privilege separation directory or write its PID file. A bind conflict is a TCP/IP stack-level issue, independent of SELinux policy, so the error text specifically implicates a port conflict rather than a denial.

The /etc/ssh/sshd_config file is missing.

Why wrong: If `/etc/ssh/sshd_config` were missing, sshd would abort during configuration parsing with a 'No such file or directory' or 'fatal: bad permissions' style error before even calling socket() and bind(). The bind is attempted only after startup reads its configuration and generates host keys, so reaching the 'Cannot bind any address' stage proves a valid config file was loaded and the failure is at the network binding layer.

An error because the for loop cannot iterate over files with spaces

Why wrong: The for loop itself does not error when filenames contain spaces; the shell performs glob expansion before the loop starts and yields each matching filename as a separate argument. In this particular environment there are no `.txt` files with spaces, so the loop will run normally. Even if such files existed, a robust script quoting the expansion with `"$i"` would still work correctly, so an error claim is unfounded.

Line counts for .txt files in 'backup' only

Why wrong: The glob pattern `*.txt` is expanded by the shell in the current working directory only; it does not traverse into the `backup` directory. Since the script never uses `find` or a recursive glob (`**/*.txt`), only current-directory files are processed, making the 'backup only' outcome impossible. Additionally, the files in `backup` would not be counted at all, so selecting only those cannot happen.

Line counts for all .txt files including those in 'backup'

Why wrong: This answer reflects the misconception that `*.txt` recurses into subdirectories. Shell globbing is non-recursive: `*` matches any characters within a single path component, so it expands only to filenames in the current directory, not to paths containing a slash. Because the loop iterates over the expanded list, none of the `.txt` files inside `backup/` are included in the output.