Deploy, configure, and maintain systems practice questions

192.168.1.10 /export/data /mnt/data nfs4 defaults 0 0

Why it fails: This line erroneously splits the remote source into two whitespace-delimited fields: the server IP (192.168.1.10) and the export path (/export/data). In /etc/fstab, an NFS mount must place the server and path together in a single fs_spec field separated by a colon, e.g., 192.168.1.10:/export/data. As written, the parser treats /export/data as the mount point and /mnt/data as an extra field, causing the mount to fail because there is no valid NFS source token.

/mnt/data 192.168.1.10:/export/data nfs4 defaults 0 0

Why it fails: This entry reverses the required column order. The first field in fstab must be the remote source (server:/export/data), and the second field must be the local mount point (/mnt/data). Here /mnt/data is placed in the fs_spec position and 192.168.1.10:/export/data in the fs_file position, which would make mount try to attach a local device named /mnt/data at a mount point named 192.168.1.10:/export/data—neither of which exists.

192.168.1.10:/export/data /mnt/data nfs defaults 0 0

Why it fails: The only deviation from the correct entry is the file system type nfs instead of nfs4. While nfs is a recognized fstab type, it permits negotiated NFS version selection, which can cause the client to fall back to NFSv3 depending on server settings or mount options. Since the task explicitly requires configuring an NFSv4 mount, nfs4 must be used to guarantee the v4 protocol; nfs is therefore incorrect because it does not pin the NFS version as required.

'systemctl enable' starts the service immediately.

Why it fails: This is incorrect because 'systemctl enable' only creates symbolic links in the appropriate target dependencies (e.g., multi-user.target.wants) so the service starts automatically at boot time. It does not transition the unit to the running state in the current session. To both enable and immediately start the service, an administrator must combine it with 'systemctl start' or use 'systemctl enable --now'.

'systemctl mask' disables a service but allows manual start.

Why it fails: This claim is false because 'systemctl mask' does far more than simply disable a service. It creates a symlink to /dev/null for the unit's configuration, which effectively tells systemd that the unit does not exist, so both automatic and explicit manual start attempts are blocked. The only way to allow the service to start again is to run 'systemctl unmask' first, which removes the /dev/null link.

'systemctl disable' stops the service immediately.

Why it fails: This is incorrect because 'systemctl disable' only removes the startup symlinks that are checked at boot time; it has no effect on a service that is currently running. The daemon or process continues to run until it is explicitly stopped with 'systemctl stop' or it exits on its own. Disabling is therefore a boot-time setting, not a runtime control, and it is often used alongside 'systemctl stop' when the administrator wants the service off both now and at the next reboot.

The Restart=on-failure directive is misconfigured.

Why it fails: The Restart=on-failure directive is not the reason for the exited state; it is a valid restart policy, but it only restarts a unit when the main process exits with a non-zero status, is terminated by a signal, or times out. If example.sh exits cleanly with status 0, systemd treats that as success and leaves the unit in the inactive/exited state. Even if a non-zero exit occurred, Restart=on-failure would trigger a new start attempt, not the 'exited' status, so the directive is not misconfigured.

The network.target dependency is not met.

Why it fails: network.target is a passive synchronization target that is reached very early in the boot process; it does not guarantee that networking is fully configured. If this dependency were unsatisfied, systemd would fail to order the unit or would not start it at all, rather than allowing it to run and exit. Because the service did run (it exited), network.target dependency was already satisfied, so this is not the cause of the status.

The administrator forgot to run systemctl daemon-reload after starting.

Why it fails: The systemctl daemon-reload command merely re-reads unit files after a change on disk; it has no effect on the runtime behavior of an already loaded unit. Forgetting to run it after starting a service is not meaningful because a freshly started unit has just loaded from disk, and no reload is needed. More importantly, daemon-reload cannot keep a process alive or change the fact that example.sh exits immediately; the observed status comes from the short-lived script, not from stale unit-file state.

Use resize2fs /dev/sdb1 to expand filesystem.

Why it fails: resize2fs is for ext2/3/4, not XFS.

Add a new disk, create a physical volume, extend volume group, and extend logical volume.

Why it fails: No LVM is used here; /dev/sdb1 is a plain partition.

Use fdisk to delete and recreate /dev/sdb1 with larger size, then mount.

Why it fails: Mounting does not grow filesystem; need xfs_growfs.

du -sh /data

Why it fails: Using `-s` on `/data` suppresses all recursion and prints a single summary line for the `/data` directory itself. This tells you the total size of the entire directory, but it hides the sizes of the individual files and subdirectories inside it. The command therefore fails to provide the per-top-level-item breakdown that the wildcard `du -sh /data/*` would produce.

du -h --max-depth=1 /data

Why it fails: The `--max-depth=1` option is a GNU extension rather than a POSIX-standard du flag, and it changes the recursion depth relative to the starting path. With `/data`, depth 1 means du prints a line for `/data` itself plus lines for each immediate child, so the output includes an extra parent entry. Additionally, if `/data` contains regular files, their sizes are folded into the parent line, not listed separately; thus the output is not a clean list of only the items inside `/data`.

Enforcing: SELinux logs all actions but does not block them.

Why it fails: This option describes Permissive mode, not Enforcing mode: Enforcing does not merely log all actions without blocking; it actively denies unauthorized operations while recording only the denial events, not every action. If SELinux merely logged and never blocked, it would have no ability to contain a compromised process or prevent an administrator error from violating policy, leaving the system as unprotected as if SELinux were off.

Permissive: SELinux enforces the policy and blocks violations.

Why it fails: This option describes Enforcing mode's behavior, not Permissive mode. Permissive never blocks; it intentionally allows every action to proceed while logging AVC denials to the audit log. The entire point of Permissive mode is to observe what would be denied, so if it also enforced the policy and blocked violations, it would defeat its role as a troubleshooting and policy-validation tool.

Disabled: SELinux warns but does not block.

Why it fails: A disabled SELinux system does not warn at all—there is no policy engine running, no access control decision is made, and thus no denial or warning can be generated. The behavior of printing warnings while allowing actions to proceed is exactly what Permissive mode does; disabled mode is the complete absence of SELinux, not a weakened warning version of it.

sec=sys,ro

Why it fails: The sec=sys option (AUTH_SYS) simply trusts the uid and gid numbers sent by the client, so a root user on the client can spoof any user identity and there is no cryptographic authentication at all. Adding ro only forces the filesystem to be read-only; it does not add Kerberos authentication, encryption, or any proof of the client user's identity. This mount cannot ensure that only authorized users can access the NFS data.

mkfile 2G /swapfile; mkswap /swapfile; swapon /swapfile

Why it fails: Incorrect. `mkfile` is not a standard Linux command for creating swap files.

touch /swapfile; truncate -s 2G /swapfile; mkswap /swapfile; swapon /swapfile

Why it fails: Incorrect. `touch` creates an empty file, and `truncate` does not allocate disk space; `mkswap` will fail on a sparse file.

blkid

Why it fails: blkid displays block device attributes (UUID, label), not disk space usage.

ls -lh

Why it fails: ls -lh lists file sizes, not filesystem disk space.

du -sh

Why it fails: du -sh shows the total size of a directory or file, not available space on mounted filesystems.

fdisk -l

Why it fails: fdisk -l displays partition tables, not filesystem usage.

The third entry (/home)

Why it fails: Local filesystem; will not fail due to NFS server.

The second entry (/boot)

Why it fails: Local filesystem; will not fail due to NFS server.

The first entry (/)

Why it fails: Local filesystem; will not fail due to NFS server.

edquota -u user

Why it fails: edquota -u user is not valid here because edquota only edits the quota limits of an already initialized quota database, which is created by quotacheck on ext3/ext4 filesystems. It does not create or initialize quotas, and it cannot interact with the XFS quota subsystem, which has no traditional quota files and requires xfs_quota for any limit modification.

quotacheck -cug /mount

Why it fails: quotacheck -cug /mount performs a scan of the filesystem and creates the aquota.user and aquota.group quota files for legacy ext-family filesystems, then writes quota accounting data into them. On XFS, quota tracking is built into the filesystem metadata itself, so quotacheck is unnecessary, unsupported, and would fail or return an error because XFS does not use those quota files; quota enabling is done via mount options.

quotaon /mount

Why it fails: quotaon /mount is inappropriate for XFS because quotaon is designed to activate quota enforcement on ext filesystems after the quota files have been set up by quotacheck. In XFS, quotas are enabled at mount time by including mount options such as uquota, gquota, or pquota, and there is no separate quota-on daemon or file to switch on; running quotaon would produce no effect or an error on an XFS filesystem.

checkmodule

Why it fails: checkmodule is a policy compilation tool that converts a policy module source file into a binary policy module. It does not query or display any runtime SELinux status, mode, or enforcement state. Its purpose is strictly to build policy modules for use with semodule, making it entirely unrelated to showing whether SELinux is currently enforcing.

seinfo

Why it fails: seinfo is a static analysis tool that displays information about the installed SELinux policy, such as the number of types, roles, users, booleans, and their relationships. It reads the policy binary, not the live runtime status, so it cannot display whether SELinux is currently enforcing, permissive, or disabled. Using seinfo for a status check would be like inspecting a map instead of checking your current GPS location.

setenforce

Why it fails: setenforce is an administrative command used to change the SELinux mode at runtime; valid arguments are 0 (permissive) or 1 (enforcing). It writes to the kernel enforcement control, so it actively alters the state instead of displaying it. While it can indirectly reveal the current mode if you read its output or behavior, it is not a status-display utility and requires root privileges to run.

Install autofs and create /etc/auto.master.d/backup.autofs with the same content

Why it fails: Installing autofs is necessary, but placing the mapping in /etc/auto.master.d/backup.autofs does not work with the same content as /etc/auto.master. Files in auto.master.d are parsed as master map fragments and must contain only top-level mount point lines (e.g., '/backup /etc/auto.backup'), not the direct map entry that belongs in /etc/auto.backup. If you put the full map line there, the autofs service will attempt to interpret 'backup -fstype=nfs4 ...' as a master map entry and fail to start properly, so the automount point will never be created. The standard, supported method is to edit /etc/auto.master directly and create a separate indirect map file as shown in the correct option.

Use systemd-mount with automount options

Why it fails: systemd-mount with automount options is a real feature, but it is not how automount is configured for NFS on Red Hat systems. The 'automount' option in systemd-mount creates a .automount unit, but you would need to write a custom systemd unit file and manage it manually; autofs is the expected and canonical solution for NFS automounting. Additionally, systemd-mount does not provide the NFS-specific syntax of autofs map files, such as the '-fstype=nfs4' option and the mount point within the map, and it cannot integrate with /etc/auto.master or auto.master.d. For the EX200 exam and typical RHEL administration, the autofs approach is the only correct way to achieve on-demand NFS mounts.

Add an entry to /etc/fstab: nfs.example.com:/exports/backup /backup nfs4 defaults 0 0

Why it fails: Adding an entry to /etc/fstab with 'defaults' forces a persistent mount that is mounted at boot time, not an automount. Automounting requires the autofs service and a map to mount only when the path is accessed; fstab entries cannot trigger on-demand mounting. Even if you use the 'noauto' option in fstab, that only prevents boot-time mounting but does not provide automount behavior—you would still need a separate mechanism to mount it. This option is fundamentally incorrect because it bypasses autofs entirely, and the exam expects you to use the autofs infrastructure for NFS automount points.

firewall-cmd --add-service=http

Why it fails: In firewalld, omitting --permanent modifies only the runtime configuration, which is stored in memory and never written to disk. As a result, the HTTP service would be allowed right now but vanish after a firewalld reload, service restart, or reboot. Since the administrator explicitly needs a permanent change, this command alone fails the requirement. To persist the change, you must either add --permanent or later run --runtime-to-permanent (which promotes all runtime changes, not just this one).

firewall-cmd --runtime-to-permanent

Why it fails: Running this command alone does not add any rule; it only takes whatever is currently in the active runtime configuration and makes that the permanent configuration. If no HTTP or port 80 rule has been previously added, the administrator has only persisted the existing state, leaving HTTP closed. Furthermore, this overwrites the permanent config with the entire runtime state, potentially removing prior permanent rules that were inactive at runtime. Thus, without a preceding --add-service or --add-port rule, this cannot accomplish the task.

The SELinux context on /webdata is incorrect for container use.

Why it fails: The statement misidentifies the problem: the SELinux type httpd_sys_content_t on /webdata is actually a valid type for web content, so the context is not inherently 'incorrect'. The real issue is that the container process runs under the svirt_t domain and cannot access a bind-mounted directory unless the directory carries a container-compatible label (container_file_t) with matching MCS categories. Manually relabeling to httpd_sys_content_t may still permit access for httpd, but the correct fix for a podman bind mount is to use :z, which automatically sets a shared container_file_t label, rather than changing the type manually.

The /webdata directory does not exist.

Why it fails: If the /webdata directory did not exist, podman would not create it and would fail with an error like 'no such file or directory' before any SELinux denial could occur. The fact that the user sees a permission denial shows that the mount path exists and is reachable; the failure is happening at the SELinux access-check layer. Since the directory is explicitly stated to exist, this option is factually wrong, and the denial is explained entirely by SELinux label mismatch, not missing paths.

The container image is incompatible with the host SELinux policy.

Why it fails: SELinux compatibility for a container image is determined by the container runtime, which launches the image under the generic svirt_t domain, not by any policy embedded in the image itself. A standard httpd image from a registry is designed to run under this domain and does not define its own host SELinux policy; if it were incompatible, you would see failures to execute, mount, or start the container, not a denial specifically on the bind-mounted data directory. The observed denial is a file-labeling issue with the bind mount, so blaming the image's SELinux compatibility is incorrect.

mkswap /dev/vdb ; swapon /dev/vdb ; systemctl enable swap.target

Why it fails: Enabling swap.target does not associate /dev/vdb with swap or make it activate at boot. The target only groups swap units; without a corresponding fstab entry or a generated swap unit, /dev/vdb remains inactive after reboot. This approach leaves the new swap space non-persistent despite appearing to enable swap services.

mkswap /dev/vdb ; mount -t swap /dev/vdb /swap ; echo '/dev/vdb /swap swap defaults 0 0' >> /etc/fstab

Why it fails: Swap space is not mounted on a directory; it is activated with swapon and appears in the virtual memory subsystem, not in the mount table. The mount command with -t swap would fail, and the fstab entry with a mount point is invalid for swap. This sequence cannot produce functional persistent swap.

mkfs.swap /dev/vdb ; swapon /dev/vdb ; echo '/dev/vdb swap defaults 0 0' >> /etc/fstab

Why it fails: There is no mkfs.swap utility on RHEL 9; swap space is initialized with mkswap. Even if the swapon command succeeded, the fstab entry is missing the filesystem type field, so it would be parsed incorrectly. This sequence would fail at the first command and never create usable persistent swap.

Add 'blacklist usb_storage' to /etc/modules-load.d/usb_storage.conf

Why it fails: The /etc/modules-load.d/ directory is handled by the systemd-modules-load.service and is intended only to specify modules to load at boot, not to block them. A 'blacklist usb_storage' line there would be misinterpreted—either as an invalid directive or as an attempt to load a module named 'blacklist'—resulting in boot-time failures. Blacklisting belongs in modprobe configuration under /etc/modprobe.d/.

Add 'install usb_storage /bin/false' to /etc/sysconfig/modules/

Why it fails: The /etc/sysconfig/ tree is a SysVinit-era location for environment variables and service configuration, and /etc/sysconfig/modules/ is not a standard directory for module blacklist rules. Even though 'install usb_storage /bin/false' is a valid modprobe directive when placed in a modprobe.d file, the udev/modprobe machinery will never read it from this path, so the module remains loadable.

Add 'blacklist usb_storage' to /etc/init.d/rc.local

Why it fails: The /etc/init.d/rc.local script is executed near the end of the boot sequence, after udev has already probed devices and automatically loaded needed modules—so usb_storage may have been loaded long before this line ever runs. Moreover, simply writing a 'blacklist' directive in a shell script has no effect on the kernel's module autoloading mechanism; it must be processed by modprobe in its configuration files. This option neither prevents the module from loading nor configures the system declaratively.

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

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

nmtui edit enp1s0 --ipv4 192.168.1.100/24

Why it fails: nmtui is an interactive text-based interface; the 'edit' subcommand opens a full-screen editor where you navigate with arrow keys and tab, so it cannot accept inline arguments like '--ipv4 192.168.1.100/24'. The correct invocation would simply be 'nmtui edit enp1s0' followed by manual entry of the address. Providing extra CLI arguments causes nmtui to ignore them or exit with an error, so this does not configure anything.

ip addr add 192.168.1.100/24 dev enp1s0

Why it fails: The 'ip addr add' command applies the address immediately at the kernel level, but the change is volatile: it vanishes on reboot or whenever NetworkManager restarts or takes over the interface, since no connection profile is updated. It also does not set a default gateway or other properties, and it can conflict with NetworkManager's management of the device. This is useful for temporary testing but not a persistent configuration.

ifconfig enp1s0 192.168.1.100 netmask 255.255.255.0

Why it fails: ifconfig is part of the deprecated net-tools package and is no longer installed by default on modern RHEL releases. Even if present, 'ifconfig enp1s0 192.168.1.100 netmask 255.255.255.0' only changes the runtime configuration and is lost after a reboot; it also fails to set additional parameters like gateway or DNS. The command is considered obsolete in favor of the ip command and NetworkManager's nmcli.

/etc/systemd/journald.conf

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