Select Two (Multi-Select) 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.

Podman volumes can only be managed by podman volume commands, not manually.

Why it fails: Although podman volume commands are the standard interface, Podman volumes are not exclusively managed by them. A volume is ultimately a directory on the host, so you can create that directory manually with mkdir and mount it into a container using the --volume or --mount option. Podman volume create mainly adds metadata and lifecycle management, but manual directories work as long as they have the correct permissions and SELinux context.

Rootless containers cannot use the overlay filesystem driver.

Why it fails: The claim that rootless containers cannot use overlay is incorrect. Rootless users can use the overlay filesystem driver when fuse-overlayfs is installed, which provides a FUSE implementation of overlayfs without requiring root privileges. Newer kernels also allow unprivileged overlay mounts in some configurations, but fuse-overlayfs is the common solution in Podman's rootless mode.

Mount point

Why it fails: A mount point is a directory in the existing filesystem hierarchy where a logical volume is attached after it has been formatted and activated. It is not part of LVM metadata and is only used during the mount operation, not during LV creation. You can create an LV and leave it unmounted indefinitely, so a mount point is not a prerequisite.

Filesystem

Why it fails: A filesystem is a data structure created on top of a logical volume using tools like mkfs.ext4 or mkfs.xfs. This formatting step must occur after the LV exists because the LV is a block device that needs to be present before any filesystem can be written to it. The lvcreate command itself does not require or create a filesystem, making it optional at creation time.

Partition

Why it fails: A partition is a section of a disk defined by a partitioning tool, but LVM can use an entire disk as a PV without creating a partition table. Running pvcreate directly on a whole device (e.g., /dev/sdb) is a valid and common practice, especially on virtual disks or SAN LUNs. Therefore, while partitions are often used for organizational convenience, they are not a strict requirement for LV creation.

e2label /dev/sda1

Why it fails: e2label /dev/sda1 is a filesystem utility specifically for ext2/ext3/ext4 volume labels; it reads or sets the label stored in the superblock, not the UUID. The UUID is a separate 128-bit identifier in the same superblock, and e2label has no option to display it.

findmnt /dev/sda1

Why it fails: findmnt /dev/sda1 prints the mount relationship and defaults to columns like SOURCE, FSTYPE, MOUNTPOINT, and OPTIONS. It does not include UUID by default; you would have to explicitly add -o UUID, and even then it is a mount-aware wrapper, not the primary tool for querying raw device identifiers.

file -s /dev/sda1

Why it fails: file -s /dev/sda1 inspects the raw data on the device and identifies the filesystem type (for example, 'Linux rev 1.0 ext4 filesystem data'), but it is not designed to extract or display a UUID. Its purpose is file type magic detection, not filesystem attribute lookup.

mkswap

Why it fails: The mkswap utility initializes a block device or regular file for use as swap space by writing a swap signature and metadata, but it does not alter the partition table. It expects an existing partition or device node as its target, and after it runs you still need to activate the swap area with swapon. Because it creates a swap filesystem rather than a new partition entry, it is incorrect here.

dd

Why it fails: dd is a low-level data duplication and conversion tool that copies raw bytes from an input to an output file or device. It can overwrite an entire disk or a portion of it, but it has no concept of partition tables and cannot add a new partition entry. In fact, using dd to write an image to a disk would replace or destroy existing partition structures rather than create new ones.

wipefs

Why it fails: wipefs is a small utility that erases filesystem, RAID, or partition-table signatures from a specified device, effectively clearing metadata that identifies a filesystem or partition. It does not create new partitions, and its typical use is to remove leftover signatures from a disk before repartitioning or to blank a device. Since its function is destructive cleanup rather than partition creation, it is wrong.

lvchange

Why it fails: lvchange is used to modify the attributes of a logical volume, such as its activation state, read-only status, persistence, or allocation policy. It does not change the size or capacity of the LV in any way; its purpose is to manage how the volume behaves, not how much space it occupies. Therefore, it cannot be used to reduce the size of a logical volume, making it incorrect for this task.

lvdisplay

Why it fails: lvdisplay is a read-only diagnostic command that displays the current properties of a logical volume, including its name, path, size, and status. It does not perform any modifications to the LV; it only queries and prints existing configuration data. Since the question asks for commands that can be used to reduce size, lvdisplay is irrelevant because it has no capability to change any aspect of the volume.

lvextend

Why it fails: lvextend is the counterpart to lvreduce, designed specifically for increasing the size of a logical volume. It can grow an LV into available free space in its volume group and optionally expand the filesystem, but it cannot shrink anything. As its name and purpose imply, it only handles growth, so it is the wrong command for reducing an LV's size.

Using 'set -e' to exit on non-zero exit codes.

Why it fails: Relying on `set -e` as a safety net is widely discouraged because it only triggers on the exit status of the entire pipeline's last command, not on every intermediate failure, and it is silently suppressed inside conditionals, negated commands, and compound predicates. A command that fails but is part of a fallback like `cmd || fallback` won't abort, while certain benign failures in unrelated functions can cause the whole script to terminate, creating brittle and confusing runtime behavior.

Using the 'source' command instead of '.' for readability.

Why it fails: Although `source` is a convenient builtin that is slightly more readable than a simple dot, it is a Bashism and not required for any POSIX-compliant shell; `.` is the standard portable command and does exactly the same job. Preferring `source` over `.` adds no functional benefit and reduces portability of your scripts to minimal dash-like environments, so it is not an objectively 'recommended practice' over the dot notation.

grep 'error' /var/log/messages.gz

Why it fails: grep does not decompress files before searching, so it will read the raw gzip binary stream instead of the plain-text log lines. When run against /var/log/messages.gz, it will complain about binary data or produce useless matches like `Binary file ... matches`, and it will never search the logical decompressed content. For compressed logs you need zgrep, or a pipeline like zcat file | grep, to carry out pattern matching on the uncompressed data.

vim /var/log/messages.gz

Why it fails: vim is an editor, and while it can read and transparently decompress a gzip file using Vim's internal autocommands, it also loads the data into an editable buffer and can write changes back as a compressed file. That makes the command a modification tool rather than a display-only utility, and merely opening vim for viewing risks accidental changes or altered compressed output. A read-only pager such as less or zless is the intended way to view logs without editing them.

less /var/log/messages.gz

Why it fails: less is a general-purpose pager, but it has no built-in decompression logic of its own; without a helper like lesspipe configured in LESSOPEN, it will dump the compressed bytes to the terminal as non-printing control codes and mojibake. On some systems less may appear to work because the distribution installs lesspipe, but that behavior is not part of less itself and cannot be assumed. The command zless, which passes through gzip, or bzless for bzip2 files, is the correct way to page a compressed log.

firewall-cmd --runtime-to-permanent

Why it fails: The firewall-cmd --runtime-to-permanent command persists the current runtime configuration to the permanent configuration files, but it does not itself add any services or rules. If the required HTTPS allow or SSH drop rules were never added to the runtime configuration, this command simply saves an incomplete firewall state. Therefore, it fails to fulfill the requirement to add the necessary firewall rules; it only copies whatever rules are already active.

firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.100 service name=ssh reject' --permanent

Why it fails: Using the reject action in a rich rule causes firewalld to send an ICMP unreachable packet or TCP RST back to 192.168.1.100, explicitly indicating the port is closed. This differs from the desired silent drop, which discards packets without any response, making the host appear nonexistent. A reject action is also more detectable during port scans and does not meet a requirement to hide or block access without feedback.

firewall-cmd --add-service=http --permanent

Why it fails: This command adds the http service, which opens TCP port 80 for unencrypted web traffic, not port 443 for HTTPS. If the web server must accept secure connections, this rule leaves HTTPS blocked and would cause the initial secure connection attempt to fail. Because the requirement specifically calls for HTTPS, adding http is the wrong service even though the syntax and persistence behavior are valid.

Mount the device to a swap directory

Why it fails: Mounting a device attaches a filesystem to the VFS via a mount point directory, but swap is not a filesystem and has no mountable content. The kernel enables swap through the swapon system call, which registers the raw block device as paging space, so there is no mount directory concept for swap.

Create a filesystem using mkfs

Why it fails: The mkfs command creates a conventional filesystem such as ext4 or XFS, which are designed for storing files and directories. Swap space contains no filesystem; instead, mkswap writes a dedicated swap signature that tells the kernel the area is raw paging space. Running mkfs on a swap device would overwrite that signature and corrupt the swap area.

A container can only be created from an image that is stored locally.

Why it fails: While container engines typically use locally cached images, they are not restricted to them. When a container is run from a named image not present locally, the engine automatically pulls it from a configured registry such as Docker Hub. This pull-on-demand behavior means the image does not need to exist on disk beforehand. Additionally, tools like Podman can run images directly from a remote reference without a pre-existing local copy.

When a container is stopped, its writable layer is automatically removed.

Why it fails: Stopping a container only sends a signal to terminate its primary process and halts CPU scheduling; it does not alter the container's storage. The writable layer, which contains all file changes made during the container's lifetime, is preserved on disk so the container can be restarted with its state intact. That layer is removed only when the container is explicitly deleted using a command like `podman rm` or `docker rm`, not when it transitions to stopped. Thus the statement conflates stopping with removal.

A container image must be built using a Dockerfile.

Why it fails: A Dockerfile is one common way to define a new image, but it is not mandatory. Images frequently originate by pulling an existing pre-built image from a registry, which requires no Dockerfile at all. They can also be created interactively by committing a modified container with `docker commit`, or by importing a filesystem archive. Consequently, building with a Dockerfile is optional and not a requirement for every container image.

Contains the user's UID.

Why it fails: User IDs (UIDs) are assigned and recorded in /etc/passwd as its third colon-separated field, not in /etc/shadow. The /etc/shadow file's fields start with the login name and then proceed directly to the password hash and aging parameters such as last change date and maximum days. While the shadow file does reference the matching passwd entry by username, it never stores the numeric UID itself, making this statement factually incorrect.

Is used to store encrypted group passwords.

Why it fails: Group password hashes, when they exist, are stored in /etc/gshadow rather than /etc/shadow. The /etc/shadow file exclusively handles local user account password data, whereas group-level security credentials and administrative information for groups are placed in the corresponding gshadow file. Encrypting group passwords is a separate feature that relies on a completely different file with its own permissions, so this option misattributes a function designed for group management.

Is readable by all users.

Why it fails: To protect password hashes from offline cracking attempts, /etc/shadow is not accessible to ordinary users; typical permissions are 0000 or 0640 owned by root:shadow. Only the root user and processes running with the shadow group (such as certain password management tools) can read it. In contrast, /etc/passwd is intentionally world-readable so that every process can look up UIDs and usernames without exposing the secret hashes that reside in the shadow file.

systemctl restart network

Why it fails: Restarting the network service via systemctl causes the system to re-read all existing interface configuration files, but it does not define or alter any IP address settings itself. If no static IP has already been configured in files such as /etc/sysconfig/network-scripts/ifcfg-eth0, the interface will simply return to its previous or DHCP-assigned address. This command is therefore not a mechanism for assigning a static address, only for applying whatever configuration already exists.

nmcli con up eth0

Why it fails: nmcli con up eth0 activates an existing NetworkManager connection profile, bringing the interface to an 'up' state with the parameters already stored in that profile. It does not change the IP configuration in any way, so if that profile currently uses DHCP or has no address, executing this command alone will not make the address static. Think of this as a light switch for the connection, not as a way to edit its addressing properties.

ip addr add 192.168.1.10/24 dev eth0

Why it fails: The ip addr add command configures an address at the kernel level on the live interface, taking effect immediately. However, it writes nothing to any persistent configuration file or NetworkManager profile, so the assignment is lost as soon as the interface is restarted, the network service restarts, or the system reboots. It is a runtime-only modification and therefore an insufficient answer when the administrator needs a static IP that lasts.

ls -l test.txt

Why it fails: ls -l is incorrect because the long format displays permission bits, link count, owner, group, file size, and modification time, but it does not include any SELinux metadata. The -l option has no effect on whether contexts appear; to see contexts with ls, the -Z option must be added (e.g., ls -Z test.txt). Thus, ls -l alone cannot reveal the SELinux label.

sestatus

Why it fails: sestatus is incorrect because it reports system-wide SELinux state, such as whether SELinux is enabled, the current enforcing or permissive mode, and the configured policy (e.g., targeted, minimum, or mls). It does not accept a filename argument and has no mechanism to inspect the label of a specific object like test.txt. It answers the question 'Is SELinux on and what mode?' not 'What is this file's context?'

getenforce

Why it fails: getenforce is incorrect because it only prints the current SELinux mode as one of Enforcing, Permissive, or Disabled. This is a system-wide runtime setting, not a per-file attribute. Because it takes no file operand and returns only the enforcement state, it cannot show the security context of an individual file such as test.txt.

blkid

Why it fails: blkid is a utility that locates and reports block device attributes such as UUID, filesystem type, and LABEL for devices listed in /dev, but it does not report how much space is allocated or available on mounted filesystems. Running blkid outputs metadata like the device's filesystem signature (e.g., ext4, xfs) and partition UUIDs, not usage statistics in bytes or percentage. Therefore it cannot answer 'current disk usage'.

fdisk

Why it fails: fdisk is an interactive command for creating, deleting, resizing, and viewing partition tables (MBR or GPT) on block devices, showing sectors, partitions, and geometry. While it shows partition boundaries and sizes from the partition table, it does not report actual disk space usage of the filesystem—it only displays the partition's nominal size. fdisk is therefore a partitioning tool, not a usage metering tool, and is not appropriate for answering how much space is currently used.

lsblk

Why it fails: lsblk lists information about all available block devices in a tree-like format derived from sysfs, showing device names, sizes, types, and mount points if available. While lsblk does show the total size of each device and which partitions exist, it does not compute how much space is used versus free on mounted filesystems. It provides topology, not utilization, and is used for identifying device names rather than gauging disk usage.

system-config-network

Why it fails: system-config-network was a graphical and text-based tool used in RHEL 6 and earlier to manage network settings and write configuration files. It was removed from RHEL 8 and is not provided in RHEL 9, so it is unavailable on current systems. Because it no longer exists in the base distribution, it cannot be used as a valid network configuration method.

ifconfig

Why it fails: The ifconfig utility is part of the deprecated net-tools package, which is considered legacy and is not maintained in current RHEL releases. It lacks support for features such as multiple IPv6 addresses per interface or detailed flag reporting, and its use is discouraged in favor of ip. Therefore it is not a valid configuration method for modern RHEL systems.

touch /mnt/newmount

Why it fails: touch /mnt/newmount is wrong because touch's purpose is to update file timestamps or create an empty regular file. After running it, /mnt/newmount would be a zero-length regular file, not a directory, so any subsequent attempt to cd into it or create files under it would fail. Thus it does not create a directory as requested.

ln -s /mnt /mnt/newmount

Why it fails: ln -s /mnt /mnt/newmount creates a symbolic link named /mnt/newmount that points to the /mnt directory. The resulting filesystem entry is a symlink (file type l), not a newly created directory; it merely references the existing /mnt directory. Because the question asks to create a new directory, and this command only creates a pointer, it is not a correct choice.

ln /mnt /mnt/newmount

Why it fails: ln /mnt /mnt/newmount attempts to create a hard link named /mnt/newmount pointing to the same inode as /mnt, but Linux forbids hard links to directories to prevent filesystem cycles. The kernel returns an error such as 'Operation not permitted', so no directory is created. Even if it were allowed, a hard link is not the same as creating a new directory — it is just an additional name for the same directory, making this command incorrect.

--expose

Why it fails: The --expose option is incorrect because it does not map any port to the host. It only tells Podman that the container listens on a particular port, and that port is communicated to other containers on the same network or via a pod. No host-side port binding is created, so the exposed port is not reachable from the host or from the outside world unless you separately publish a port with -p or -P.

--port

Why it fails: The --port option is not a valid Podman run option. Podman's CLI for publishing ports is -p or --publish, while -P publishes every exposed port; there is no single --port flag. Attempting to use it results in an 'unknown flag: --port' error from Podman. Therefore, it cannot be used to publish container ports and is the wrong choice for this question.

usermod -AG group user

Why it fails: `-A` is not a valid option for the `usermod` command on Linux; it is not recognized and will produce an error. Even if a system or a future version tried to interpret it, the absence of the lowercase `-a` means the intended 'append' behavior is lost, so the command would either fail outright or, in some permissive parsers, be treated as `-a` plus `-G` but without the proper flag combination. The correct syntax to append to supplementary groups is `usermod -aG`, with `-a` lowercase and immediately paired with `-G`.

adduser user group

Why it fails: The `adduser` utility is a friendly interactive wrapper for `useradd`, and its primary purpose is to create new user accounts, not to modify the group memberships of an existing user. Its argument syntax does not accept `user group` as a way to assign group membership; doing so would be interpreted as specifying a new username with a non-existent 'group' option, or it would simply fail with an error. To add a user to a secondary group, you must use a dedicated group management command like `usermod -aG` or `gpasswd -a`.

groupadd -a user group

Why it fails: The `groupadd` command is designed exclusively for creating new groups in /etc/group, not for adding users to existing groups. The `-a` flag is not a valid option for `groupadd`, and even if it were, the syntax `groupadd -a user group` would be misinterpreted as placing 'user' in a group-creating context, which is completely nonsensical. To add a user to a group, the correct utilities are `gpasswd -a` or `usermod -aG`, both of which explicitly operate on existing users and groups.

xfs_admin -L /mnt

Why it fails: xfs_admin is a utility for tuning and displaying parameters of an XFS filesystem, such as setting the volume label, UUID, or other metadata, but it has no functionality to alter the size of the filesystem. The -L option specifically sets the label, not the size, and the command expects a device argument rather than a mount point, so it is invalid for resizing. Attempting to use xfs_admin -L /mnt to resize an XFS filesystem would fail because it is not designed for size changes.

resize2fs /dev/sda1

Why it fails: resize2fs is the resizing utility specifically for the ext2, ext3, and ext4 filesystem families, not for XFS. It operates using EXT2_IOC_RESIZE_FS ioctl and expects ext-family superblock structures, so running it against an XFS device like /dev/sda1 will fail with an error about an unsupported filesystem type. Because it cannot understand or modify XFS metadata, this command is invalid for resizing an XFS filesystem.

xfs_repair /dev/sda1

Why it fails: xfs_repair is a filesystem repair tool used to check and rebuild XFS metadata, such as inodes, allocation group headers, and the log, but it does not have any capability to resize a filesystem. It typically requires the filesystem to be unmounted and will refuse to operate on a mounted filesystem, whereas resizing with xfs_growfs is an online operation. Thus, xfs_repair /dev/sda1 is not a resizing command and is invalid for this purpose.