Hard Difficulty Questions

Use only password authentication for simplicity.

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

The lvextend command failed silently.

Why wrong: The lvextend output in the exhibit explicitly reports a successful resizing of the logical volume, and the command typically returns an exit code of 0 on success; a genuine failure would produce an error message and a non-zero exit code. Therefore, the logical volume itself has already been extended. The symptom the user observes—no change in available space on /data—stems not from a silent failure, but from the fact that the filesystem has not yet been expanded to match the larger block device.

The filesystem type is ext4 and requires resize2fs.

Why wrong: The exhibit clearly identifies the filesystem as XFS, not ext4, based on the output of df or blkid. For an XFS filesystem, the proper resize utility is xfs_growfs, while resize2fs is the tool for ext2/ext3/ext4 filesystems. Even if the filesystem were ext4, you would still need to run resize2fs after lvextend to grow the filesystem; however, stating that it is ext4 contradicts the evidence. The core requirement for this scenario is to use the XFS-specific command.

The mount point /data is not accessible.

Why wrong: The df output shown in the exhibit lists /data as a mounted filesystem, proving that the mount point is present and accessible; an inaccessible mount would produce errors like 'No such file or directory' or would not appear in df. The issue is not that operations on /data fail, but that the filesystem capacity remains at its old size even though the underlying logical volume has grown. Thus, accessibility is not the problem; the lack of filesystem resizing is.

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

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

Configure podman auto-update to automatically start the container on boot

Why wrong: Podman auto-update is a mechanism that periodically checks for newer versions of container images and applies updates to running containers by redeploying them via the existing systemd unit; it has no role in launching or creating a container at boot. Auto-update requires the container to already exist and be managed by a systemd unit, so relying on it to start the container is conceptually wrong. A separate systemd unit with a proper ExecStart command (or one generated by 'podman generate systemd --new') is mandatory for boot-time startup.

Add --restart=always to the ExecStart line in the existing unit file

Why wrong: The unit file already contains Restart=always, so adding the container's own --restart=always flag to the ExecStart line is redundant and does not alter how systemd supervises the service. Furthermore, --restart=always is a podman container restart policy that only applies once the container has been created and started; it cannot resurrect a nonexistent container during boot. A service that executes 'podman start payments' will fail if the container does not yet exist in the container store, regardless of any restart policy attached to the command line.

Set RestartSec=0 in the [Service] section to eliminate any delay

Why wrong: RestartSec is the delay systemd waits before retrying a service after a failed restart attempt, but if the underlying 'podman start payments' command fails because the container is missing, setting RestartSec=0 simply causes immediate, repeated retries that still hit the same missing-container error. It only changes the timing of the failure loop, not the root cause. The correct solution is to ensure the unit first creates the container—as 'podman generate systemd --new' does—so that the start command has a valid container to launch.

podman ps -a

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

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

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

Compile and install with default paths, then use 'make uninstall' to remove

Why wrong: Running ./configure without --prefix defaults to /usr/local, placing binaries and libraries alongside system-managed paths, which can shadow package files and create conflicts. Moreover, 'make uninstall' is often an incomplete or missing target in the Makefile, so it may leave many installed files behind. Thus this approach does not guarantee a clean or reversible installation.

Compile with './configure --prefix=/opt/custom' and use 'checkinstall' to create an RPM

Why wrong: Using 'checkinstall' to build an RPM from a custom-built source adds unnecessary complexity and a third-party tool dependency. The tool may not reliably capture every installed file or dependency, leading to an incomplete package. Since the goal is simply to compile and install, performing 'make install' into a dedicated prefix like /opt/custom is straightforward and sufficient.

Compile with './configure --prefix=/usr' and then install

Why wrong: Specifying '--prefix=/usr' causes the software to be installed directly into the distribution's system directories, which are managed by the package manager. This can overwrite files that belong to RPM packages, break package integrity, and hinder future updates or removals. Manual installation into /usr is strongly discouraged for exactly these reasons.

Setting the partition's UUID

Why wrong: Setting the partition's UUID is not a valid action during partition creation because UUIDs are metadata generated by filesystem utilities such as mkfs or tune2fs, not by partition table tools like parted. On MBR disks, partitions have no UUID concept at all; even on GPT disks, the partition unique GUID is automatically assigned and not typically user-specified at creation time. Moreover, most Linux UUIDs (for mounting via fstab) refer to the filesystem UUID, which exists only after formatting, not partitioning.

Mounting the partition to a directory

Why wrong: Mounting the partition to a directory is not a partition creation step because mounting requires an existing block device with a valid filesystem on it. Partition tools like parted only define the partition table entries and disk layout; they do not and cannot mount devices. The correct workflow is to create the partition, format it with mkfs to create a filesystem, and then mount it separately using mount(8) or an /etc/fstab entry.

LABEL=1234 /mnt xfs defaults 0 0

Why wrong: LABEL=1234 is invalid for this requirement because the tokens after the equals sign are filesystem labels, not filesystem UUIDs. The intended device is identified by UUID 1234, but this entry would tell the system to search for a volume whose human-readable label is literally '1234', which does not exist. Labels are also not guaranteed to be unique across a system, so relying on LABEL= for persistent mounts is less robust than using the filesystem UUID.

/dev/disk/by-uuid/1234 /mnt xfs defaults 0 0

Why wrong: Although /dev/disk/by-uuid/1234 is a valid udev-managed symlink that points to the block device, it is not the UUID keyword syntax that fstab recognizes as a stable identifier. Using this path as the first field makes the mount dependent on the presence of the /dev filesystem and udev database during early boot, which can be problematic for root filesystems. The standard and more reliable method is to place UUID=1234 in the first field, rather than a symlink path that resolves to the device node.

PARTUUID=1234 /mnt xfs defaults 0 0

Why wrong: PARTUUID= refers to a partition entry's unique identifier in the GUID Partition Table (GPT), not to the filesystem UUID assigned by tools like mkfs.xfs. The given value 1234 is stated as the filesystem UUID, which is what UUID= matches; using PARTUUID= instead would look for a partition-table identifier, a completely different namespace. Since an XFS filesystem's UUID lives in the superblock and not in the partition table, this entry would fail to mount the intended filesystem.

user.* /var/log/usercron.log

Why wrong: The 'user' facility in syslog is reserved for user-level application messages, not for system daemons like cron. Cron uses its own dedicated facility, traditionally 'cron' (and on most Linux systems the rsyslog selector is simply 'cron'). Therefore, a 'user.*' rule would capture arbitrary user-process logs and completely miss crond's execution records, failing the policy's requirement. In practice, nothing from cron is ever filed under 'user', so this directive would produce an empty or irrelevant usercron.log.

*.* /var/log/usercron.log

Why wrong: The '*.*' selector matches every possible facility (auth, daemon, kern, cron, mail, etc.) and every possible priority, so it would redirect the entire system's syslog stream into /var/log/usercron.log. This is wildly over-inclusive: kernel, boot, security, and application messages would all be merged with cron data, making the log file noisy and difficult to audit. It violates the principle of least privilege in logging, because the policy specifically asks for cron job records, not a full system log dump.

authpriv.* /var/log/usercron.log

Why wrong: The 'authpriv' facility is used exclusively for authentication and security events, such as login attempts, sudo invocations, and su usage. Cron job execution is not considered an authentication event, so an 'authpriv.*' rule would write login/sudo records to usercron.log while completely ignoring crond's activity. This would not satisfy the monitoring requirement because no cron job output would ever appear in the targeted file.

ps aux

Why wrong: ps aux is a snapshot command: it reads the current process table, prints the complete list once, and then exits, with no built-in repeat or refresh mechanism. As a standalone command, it shows only the processes that existed at the exact moment it ran, so it cannot reveal changes over time. Therefore, ps aux alone is not real-time monitoring; it only produces a static picture, although it can be turned into a recurring display by an external wrapper like watch.

at 2

Why wrong: at 2 is a job scheduler, not a monitoring tool: the at command reads a command or script from standard input and executes it once at a specified time, such as 2 o'clock or a relative time like 'now + 2 minutes'. It does not loop, does not refresh output, and is designed for deferred one-shot execution, not for observing processes over time. Therefore, at 2 is entirely unrelated to real-time process monitoring and cannot be used to watch ongoing process activity.

resize2fs /dev/vg_data/lv_data; lvextend -L 15G /dev/vg_data/lv_data

Why wrong: resize2fs /dev/vg_data/lv_data; lvextend -L 15G /dev/vg_data/lv_data — Running resize2fs before lvextend attempts to grow the filesystem while the underlying logical volume still has its original size. The kernel block device size has not changed, so resize2fs will either report there is no space at the end of the device or fail to expand to the requested size. The filesystem must always be resized after the device layer is enlarged, not before.

lvextend -L 15G /dev/vg_data/lv_data; xfs_growfs /dev/vg_data/lv_data

Why wrong: lvextend -L 15G /dev/vg_data/lv_data; xfs_growfs /dev/vg_data/lv_data — Although the lvextend step is correct for growing the LV, xfs_growfs is the wrong tool because it is designed for XFS filesystems, not ext4. On RHEL 9, ext4 requires resize2fs to update its block group descriptors and superblock, whereas xfs_growfs manages XFS-specific allocation group structures and normally takes a mount point argument. Pointing xfs_growfs at an ext4 device will simply fail or have no effect.

lvreduce -L 15G /dev/vg_data/lv_data; resize2fs /dev/vg_data/lv_data

Why wrong: lvreduce -L 15G /dev/vg_data/lv_data; resize2fs /dev/vg_data/lv_data — This does the opposite of what is requested: lvreduce shrinks the logical volume to 15G instead of extending it to 15G. Shrinking an ext4 LV without first reducing the filesystem is dangerous and likely to corrupt data, though in this scenario the desired action is growth. The correct direction is to expand the LV first, then grow the filesystem to match.

Change webuser's shell to /bin/bash to allow SFTP login

Why wrong: Changing webuser's shell to /bin/bash does not affect file permissions; SFTP login is independent of shell and already possible with a restricted shell like /sbin/nologin.

Change the SELinux context of /var/www/html to httpd_sys_rw_content_t

Why wrong: Changing SELinux context to httpd_sys_rw_content_t is relevant for Apache write access, but the question specifically requires SFTP uploads, which operate under different SELinux policies; not a necessary step.

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

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

/etc/systemd/journald.conf

Why wrong: This file contains settings for systemd-journald, a separate logging daemon that manages its own binary journal. It does not control rotation of text-based syslog files like /var/log/messages. Although journald has size and retention limits (e.g., SystemMaxUse), those are not logrotate directives, and this path is not read by logrotate.

/etc/rsyslog.conf

Why wrong: This is the main configuration file for the rsyslog daemon. It defines input modules, rule sets, and output destinations, such as writing to /var/log/messages. It does not contain rotate, daily, weekly, size, or count directives, and logrotate does not parse this file; therefore changing it will not alter log rotation behavior.

/etc/cron.daily/logrotate

Why wrong: This path is a cron script maintained in the /etc/cron.daily directory that runs the logrotate utility each day. It is the scheduler or trigger that invokes /usr/sbin/logrotate with /etc/logrotate.conf, not a configuration file for individual log files. Any rotation settings for /var/log/messages belong in /etc/logrotate.d, so editing or replacing this script would be the wrong layer.

Run 'mount -a' after boot

Why wrong: Running 'mount -a' after boot only processes the entries already listed in /etc/fstab at that moment; it does not create or modify any persistent configuration. It is a manual command used to test or apply fstab changes, not a configuration step that makes NFS mounts happen automatically at boot. Therefore, while useful for validation, it is incorrect as a common configuration step.

Configure /etc/exports

Why wrong: The /etc/exports file is read by the NFS server's exportfs process (via nfs-server) to define which local directories are made available to remote clients and with what access restrictions. A client never reads or writes this file; it is purely server-side configuration. For mounting NFS shares at boot on a client, you would add entries to /etc/fstab or configure autofs, not edit /etc/exports.