Hard Difficulty Questions

Use only password authentication for simplicity.

Why it fails: Password-only authentication relies on the entropy of the password and is inherently vulnerable to online brute-force attacks, dictionary attacks, and credential stuffing, especially when users choose weak or reused passwords. SSH requires the server to verify the password over the network, but an attacker can attempt unlimited guesses unless throttled by tools like fail2ban. Additionally, passwords offer no cryptographic proof of the client's identity beyond the shared secret, making them far less resilient than asymmetric key pairs.

Change the default SSH port to a high-numbered port.

Why it fails: Changing the default SSH port to a high-numbered port only provides security through obscurity, which is not considered a real security control. Automated scanners can easily discover listening SSH daemons on any port, and the change does nothing to prevent authentication attacks or exploitation of SSH vulnerabilities. In fact, operating on a non-standard port may break firewall rules, confuse audits, and give a false sense of safety while leaving the underlying authentication mechanisms unchanged.

Allow SSH access for all users in the system.

Why it fails: Allowing SSH access for all system users unnecessarily enlarges the attack surface, as every user account becomes a potential entry point. Many accounts may have weak passwords, be unused, or belong to services that are not meant for interactive login, providing attackers with more targets for brute-force attacks. Restricting SSH access to specific users or groups via AllowUsers, AllowGroups, or a PAM policy ensures that only trusted accounts can attempt authentication.

fsck /dev/sda1

Why it fails: Running fsck against /dev/sda1 limits the check to a single partition and does not address the broader set of filesystems needed for the boot process. If the root filesystem is not on sda1, or if the boot error is actually caused by a missing or malformed entry in /etc/fstab, this command will not find the problem. It also does not honor the pass-order sequencing determined by the fifth column of /etc/fstab, which fsck -A enforces.

debugfs -R 'repair'

Why it fails: debugfs is an interactive ext2/3/4 debugger designed for manually examining and modifying inodes, block bitmaps, and superblocks, but it has no 'repair' command and is not a repair utility. The -R flag merely runs one debugfs command non-interactively, and 'repair' is not a recognized command, so the invocation will fail. Even if a valid command such as 'check' were used, debugfs lacks the automated scanning and recovery logic of e2fsck and is far too low-level and risky for ordinary boot recovery.

e2fsck -p

Why it fails: e2fsck -p invokes the ext-family checker in preen mode, which automatically fixes only the set of cleanly repairable problems and requires you to specify a device or filesystem explicitly. It does not scan /etc/fstab, so it cannot discover every filesystem that the boot sequence depends on; if another ext4 filesystem is also corrupted, it will remain unchecked. Moreover, preen mode is intentionally conservative and will stop and require a manual answer or -y for more severe corruption, making it less robust than fsck -A -y.

lvextend -r -L +2G /dev/mapper/vg01-lv01

Why it fails: lvextend -r resizes the filesystem automatically, but it should be run before the manual resize step; however, the question says after extending without -r, so we need a separate command. Actually D would have worked if used initially, but now we need resize2fs. So D is not correct as a follow-up.

xfs_growfs /data

Why it fails: xfs_growfs /data is incorrect because xfs_growfs is specifically designed for XFS filesystems, not ext4. The filesystem on the logical volume is ext4, so invoking xfs_growfs would fail (and even if it didn't, xfs_growfs expects a mounted XFS filesystem as the argument, typically using a mount point like /data, but /data is irrelevant here). The only valid way to expand an ext4 filesystem after its underlying LV has been enlarged is with resize2fs, not with XFS's grow tool.

fsck -f /dev/mapper/vg01-lv01

Why it fails: fsck -f /dev/mapper/vg01-lv01 is incorrect because fsck is a filesystem consistency checker and repair utility, not a resizing tool. It scans and fixes structural problems such as bad inodes, incorrect block counts, or corrupted metadata, but it never alters the size of the filesystem to match the enlarged logical volume. Furthermore, running fsck -f on a mounted ext4 filesystem is dangerous and can cause corruption; even if run unmounted, it would leave the filesystem at its old size, so the new storage space in the LV would remain unused.

lvextend -L 50G /dev/mapper/vg01-data && xfs_growfs /dev/mapper/vg01-data

Why it fails: The command uses `-L 50G` without the `+` prefix, which sets the logical volume to exactly 50G rather than increasing it by 50G. If the current LV is larger than 50G, lvextend will attempt to shrink it, which lvextend does not support and will likely fail. Additionally, `xfs_growfs` expects the mount point (e.g., `/data`) as its argument; passing the device mapper path (`/dev/mapper/vg01-data`) is not the standard usage and may fail to locate the correct mount.

lvextend -L +50G /dev/mapper/vg01-data && resize2fs /dev/mapper/vg01-data

Why it fails: Although `lvextend -L +50G` correctly extends the logical volume by 50G, the following command `resize2fs` is the wrong tool for an XFS filesystem. `resize2fs` is designed for ext2, ext3, and ext4 filesystems; it will fail with an error such as 'superblock magic number mismatch' when run against XFS. For XFS, the correct utility is `xfs_growfs`, and it must be pointed at the mount point, not the volume device.

xfs_growfs /dev/mapper/vg01-data && lvextend -L +50G /dev/mapper/vg01-data

Why it fails: This option inverts the required sequence: the filesystem cannot be grown before the underlying logical volume has been extended. When `xfs_growfs /dev/mapper/vg01-data` runs first, the LV has not yet changed size, so the filesystem still sees the old capacity and has no new space to expand into—it may report that the filesystem is already at its maximum size. Only after `lvextend -L +50G` has successfully increased the LV should you run `xfs_growfs` to extend the filesystem to utilize the newly added space.

firewall-cmd --zone=external --add-service=ssh --permanent

Why it fails: This command opens the predefined ssh service (TCP port 22) to every source address in the external zone because no source restriction is specified. That would expose the SSH daemon to the entire external network, whereas the requirement is to limit SSH access from the Internet to only the 10.0.1.0/24 subnet and to the non-standard port 2222. Therefore it is both over-permissive and uses the wrong port.

firewall-cmd --zone=external --add-port=2222/tcp --permanent

Why it fails: Adding --add-port=2222/tcp to the external zone without a rich rule or source address allows any IP address on the Internet to reach port 2222/tcp. This satisfies the port requirement but completely ignores the restriction to the 10.0.1.0/24 source subnet, making it too broad. A port-only rule applies to all sources, so it fails the stated access-control requirement.

firewall-cmd --zone=external --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" service name="ssh" accept' --permanent

Why it fails: This rich rule correctly confines SSH access to the 10.0.1.0/24 source subnet, but it references the service name ssh, which firewalld maps to port 22/tcp. Since the company runs SSH on port 2222, this rule would not permit the actual SSH service; it would open the wrong port. The rule must specify the custom port explicitly, as in the correct answer.

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.

Add 'usrquota' to /etc/fstab, remount, then run quotacheck and edquota

Why it fails: The usrquota mount option and the quotacheck/edquota workflow apply to ext4 and other classic filesystems, not XFS. XFS treats quota information as part of its own metadata, so quotacheck is unnecessary and unsupported; running it on XFS produces an error or is a no-op. Similarly, edquota is not the correct interface for XFS limits—you must use the xfs_quota utility with the 'limit' command instead.

Quotas are not supported on XFS filesystems

Why it fails: This is a well-known misconception. XFS has included full user, group, and project quota support since its origins on IRIX, and Linux XFS implements quotas robustly with journaled accounting. In fact, XFS avoids quotacheck entirely because quota data is maintained on-disk in a way that is always consistent. The actual challenge is using the correct mount option (uquota) and the xfs_quota command, not whether support exists.

Use mount -o uquota /home, then setquota -u user1 500M 1G /home

Why it fails: The uquota mount option is indeed correct for XFS, but this answer is flawed in its execution. A plain mount -o uquota without updating /etc/fstab will work only until the next reboot, and the setquota command is a util-linux tool designed for ext4 and other non-XFS filesystems. XFS requires the xfs_quota utility with expert mode (-x) and the 'limit' command, using syntax like bsoft=500m bhard=1g, to set and enforce per-user limits.

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.

by-path

Why it fails: The /dev/disk/by-path symlink is generated by udev to reflect the physical hardware topology of the device, such as PCI bus, SCSI host, and target ID. Although it is persistent as long as the hardware layout is unchanged, the systemd mount unit or the mount command reading /etc/fstab does not resolve by-path symlinks by default, so it is not a recognized keyword for the file's device field. Consequently, specifying an entry as /dev/disk/by-path/... will not be parsed correctly and is therefore invalid for identifying a filesystem in fstab.

/dev/sda1

Why it fails: Using a raw device name like /dev/sda1 in /etc/fstab is not a valid persistent identification method because kernel-assigned names are allocated at boot time based on detection order, which can change when disks are added, removed, or enumerated differently. This makes the mapping non-deterministic and can cause the system to mount the wrong partition or fail to boot. Static device nodes are also not guaranteed to remain stable across reboots, so they are avoided for critical configuration.

podman ps -a

Why it fails: `podman ps -a` lists all containers on the system, both running and stopped, along with their container IDs, names, status, and ports. It does not provide any information about container images themselves, such as their layers, configuration, or metadata, so it is irrelevant to the task of inspecting image details.

podman images <image>

Why it fails: `podman images <image>` displays a table of local images that match the given name, showing only the repository, tag, image ID, and size. This is a high-level summary; it lacks the detailed JSON configuration, layer information, and metadata that the question asks for.

podman history <image>

Why it fails: `podman history <image>` outputs the layer history of the image, listing each layer's creation time, size, and command that generated it. While useful for understanding how an image was built, it does not expose the full container configuration, environment variables, entrypoint, or other detailed metadata that `podman inspect` provides.

Filesystem type

Why it fails: Correct. The filesystem type (e.g., ext4, xfs) tells the system how to interpret the device and is required.

UUID

Why it fails: Incorrect. UUID is not a separate field; it is a valid way to specify the device, but the required field is the device identifier itself.

find /var -type f -size +100M -mtime -7 -ls | sort -k7 -n

Why it fails: -ls output has size in bytes, not human-readable, and sort -n may not order correctly with different units.

find /var -type f -size +100M -mtime -7 -exec ls -lh {} \; | sort -k5 -h

Why it fails: -exec option spawns ls for each file, but sorting may not work as expected because the output is interleaved and sort -k5 may not match the size column reliably.

find /var -type f -size +100M -mtime -7 -printf '%s %p\n' | sort -n -r | head -20

Why it fails: Output is numeric bytes, not human-readable.

Use 'podman network create' and connect both containers to that network.

Why it fails: Running `podman network create` and attaching both containers to that user-defined network would technically allow communication, but it is unnecessary and adds configuration overhead. Since the two containers are already in the same pod, they share the same network namespace and can communicate via localhost or container-name DNS without any extra network setup. Moreover, this approach would bypass the pod's automatic name resolution and instead rely on the separate network's DNS, which is redundant for pods.

Set environment variable LOGGER_HOST in nginx container.

Why it fails: Setting an environment variable like LOGGER_HOST in the nginx container is a manual, brittle approach that requires knowing the exact container name or IP address ahead of time. It also fails to leverage the pod's built-in DNS service, which dynamically resolves container names to their current IPs. If the container is recreated, the environment variable would become stale, whereas the pod-managed DNS entry updates automatically.

Create a network with --internal and --ip-range.

Why it fails: Creating a network with `--internal` and `--ip-range` is completely over-engineered and actually counterproductive for this scenario. An internal network prohibits external connectivity, and setting an ip-range restricts the IP allocation pool, both of which are irrelevant to pod-internal communication. Since containers inside the same pod already share a network namespace and can reach each other via container names, no additional network configuration—let alone a restricted one—is required.

Bob will not be able to read the file because the group bob has no members.

Why it fails: This is incorrect. Even though the group 'bob' has no members listed in /etc/group, Bob's primary group (from /etc/passwd) is 'bob' with GID 1002, which matches the file's group owner. Therefore, he inherits the group read permission (r--) from the file's 640 permissions and can read the file.

Bob will be able to read the file only if he is explicitly listed in /etc/group.

Why it fails: This is incorrect because explicit listing in /etc/group is not a prerequisite for group access. Bob's primary group is defined by the GID field (1002) in /etc/passwd, and that GID matches the file's group owner. The kernel compares the file's GID to Bob's effective GID, which includes his primary group automatically, regardless of whether he appears as a supplementary member in /etc/group.

usermod -e 2024-12-31 bob; passwd -S bob

Why it fails: usermod -e 2024-12-31 bob assigns a fixed calendar date rather than a date relative to the current day, so it does not guarantee the required 30-day window; if today's date is past that date, the account is immediately expired. passwd -S bob merely reports the password status (for example, PS, LK, NP) and does not change any field in /etc/shadow, so it cannot unlock the account or reset its expiration. The password status may still show locked even after the first command.

chage -d 0 bob; usermod -L bob

Why it fails: chage -d 0 bob forces Bob to change his password at the next login by setting the last password change date to epoch, but this does not touch the account expiration or inactivity lock that caused the account to be disabled. usermod -L bob then explicitly locks the account by prepending '!' to the encrypted password hash in /etc/shadow, which is the opposite of reactivating it. The two commands together make the account more inaccessible, not less.

usermod -e $(date -d +30days +%Y-%m-%d) bob; passwd -u bob

Why it fails: While usermod -e $(date -d +30days +%Y-%m-%d) bob does correctly extend the account expiration to 30 days from now using shell command substitution, the second command fails to address the inactivity lock: passwd -u bob only removes the '!' or '!!' prefix from the password hash in /etc/shadow, essentially unlocking the password, but it does not reset the number of inactive days tracked by chage -I. As a result, the account still remains disabled under the inactivity policy, and Bob still cannot log in. This answer is incomplete because it only handles password locking, not expiration/inactivity.

Modify the umask of all users to 002, use chage -M 90 for all users, and set the setgid bit.

Why it fails: Umask 002 only changes default permission bits (giving group write access) but does not cause new files to inherit a specific group; group inheritance requires the setgid bit. While chage -M 90 sets maximum password age, omitting -W 7 means users receive no advance warning before their password expires, which is a required part of the password aging policy. The sticky bit is missing entirely, so there is no protection against one user deleting another user's files in the shared directory. The combination of a missing sticky bit and incomplete chage arguments makes this solution technically insufficient.

Use ACLs to set default group permissions, enable password aging by editing /etc/shadow directly, and set the sticky bit on the directory.

Why it fails: Using ACLs to set default group permissions fails because ACLs define default *permissions* for new files, not their *owning group*. To ensure new files belong to the 'developers' group, the directory's setgid bit must be enabled, which ACLs do not achieve. While `/etc/shadow` contains password aging data, directly editing it is not the correct or recommended method; `chage` should be used. This option is tempting because ACLs are used for granular default permissions, and `/etc/shadow` does control aging, but the specified actions are technically incorrect or poor practice for the given requirements.

Set the setgid bit, create a cron job to change group ownership, and enforce password policy through pam_tally2.

Why it fails: This option is technically incorrect because although the setgid bit is correctly included, a cron job to periodically change group ownership is an unnecessary and fragile substitute for proper group inheritance—once setgid is in place, new files already inherit the group, and a cron job cannot retroactively fix files created with wrong groups without additional logic. More critically, pam_tally2 is designed to lock accounts after repeated authentication failures (a brute-force protection mechanism), not to enforce password aging policies like maximum days or warning periods. Password aging must be implemented with chage or by configuring /etc/login.defs and /etc/shadow, not through PAM tally modules. This option conflates account lockout with password expiry and relies on an avoidable administrative hack.

yum repoinfo

Why it fails: The yum repoinfo command lists metadata such as repository IDs, names, and base URLs for currently enabled repositories, but it does not read the raw contents of a .repo file. If /etc/yum.repos.d/custom.repo exists but its repository is disabled or syntactically invalid, yum repoinfo will not display it, so it cannot prove the file is present at the expected path. The correct way to confirm the file itself is to use a plain file-read command.

yum check-repo

Why it fails: There is no yum subcommand named check-repo in Red Hat Enterprise Linux; the valid yum commands include repolist, repoinfo, check-update, and clean, among others. Running it will produce a 'no such command' usage error from yum, so it cannot perform any verification of the repository file. This option is invalid and does nothing useful.

yum-config-manager --dump

Why it fails: The yum-config-manager utility, provided by the yum-utils package, is not guaranteed to be installed on a minimal RHEL server, and its --dump option prints the repository configuration as parsed by yum, not the literal file contents. This output may merge values from multiple files or omit comments and blank lines, so it cannot confirm the exact existence and content of /etc/yum.repos.d/custom.repo. A direct cat command is the standard file-integrity check that does not depend on extra packages or yum's interpretation.

podman run --label selinux_context=container_t -v /host/data:/data myimage

Why it fails: The `--label` flag is intended for attaching key-value metadata to the container, such as version or description, which is stored in the container's configuration and exposed via `podman inspect`. It does not interact with SELinux labeling at all; `selinux_context` is not a recognized label key for security purposes. SELinux contexts are controlled through the `--security-opt label=` options, not via metadata labels.

podman run --privileged -v /host/data:/data myimage

Why it fails: The `--privileged` flag disables SELinux separation entirely for the container, turning off the `container_t` type enforcement and other isolation mechanisms, which is a significant security risk. It also grants all capabilities and access to host devices, effectively bypassing the very SELinux controls you might want to enforce. For a task where the goal is to ensure the container runs with a specific SELinux context, this option is the opposite of a targeted security setting.

podman run --selinux-context container_t -v /host/data:/data myimage

Why it fails: `--selinux-context` is not a valid `podman run` command-line option, so the command would immediately fail with an unknown flag error. Even if the flag were accepted, specifying a bare type like `container_t` without the `label=` prefix structure would not be how SELinux policy is applied. The correct syntax requires the `--security-opt` option with `label=type:` as a prefix to the SELinux type.

The replacement disk was not initialized with an mdadm superblock before adding.

Why it fails: The --add operation automatically writes a fresh mdadm superblock to the device when it is incorporated into the array, so pre-initializing the disk with a superblock is unnecessary. In fact, trying to create a superblock beforehand could leave stale metadata that confuses the array. The real failure here is that the kernel has not been told about the new partition on the replacement disk.

The /dev/md0 array is still in a clean state and does not need the disk yet.

Why it fails: When a disk in a RAID1 array fails, the array automatically switches to a degraded but still operational state, and /proc/mdstat will indicate the missing device. The array is not 'clean' in the sense of having no need for the replacement; rather, it is missing one of its mirrors and is waiting to be rebuilt. Until the new disk is added, the array lacks the expected redundancy and is vulnerable to a second failure.

The /dev/sdb1 partition is already part of another md array.

Why it fails: A brand-new replacement disk would not normally contain a valid mdadm superblock unless it had been reused from a previous array. You can confirm this by running `mdadm --examine /dev/sdb1`, which would show an array membership; if that were the case you could wipe it with `mdadm --zero-superblock`. However, the more plausible cause of the 'device not found' error is the kernel's stale partition table, not pre-existing RAID membership.