EX200 Exam Questions and Answers

Another process is already bound to port 22.

The log message 'Cannot bind any address' is what OpenSSH emits when bind(2) returns EADDRINUSE, meaning another process already holds a listening socket on 0.0.0.0:22 or the specific address configured in sshd_config. This can happen after a failed shutdown leaves an old sshd running, or if another daemon (e.g., a second sshd, a proxy) grabbed port 22. Confirm by checking `ss -tlnp` or `sudo lsof -i :22` to identify the PID holding the port.

The ONBOOT directive is set to no in the ifcfg file.

The ONBOOT directive in the interface's ifcfg file (e.g., /etc/sysconfig/network-scripts/ifcfg-eth0) explicitly controls whether the interface is activated when the system boots. When ONBOOT=no, the interface is fully configured but is deliberately skipped by the boot-time startup sequence, so it stays down until an administrator runs ifup or uses NetworkManager to connect manually. Manual activation succeeds because the rest of the configuration (e.g., IP address, netmask, gateway) is valid, and the service that performs ifup is already running. This exactly matches the symptom of an interface that is correctly configured but not active after a reboot.

Set OOMScoreAdjust=-1000 in the service unit file.

Setting OOMScoreAdjust=-1000 in the service unit file writes -1000 to /proc/<pid>/oom_score_adj, making the process's OOM score effectively zero and marking it as the kernel's last choice for OOM victim selection. This is a direct, unit-level mitigation that applies only to the custom service, so it doesn't weaken system-wide OOM behavior. It is the recommended way to protect a critical service from being killed.

/etc/fstab: /dev/vg/lv /mnt ext4 defaults,noexec 0 0

Correct fstab entry.

mdadm --fail /dev/md0 /dev/sdb

This is the correct command: mdadm --manage --fail /dev/md0 /dev/sdb (the --manage action is implicit when using --fail) marks /dev/sdb as faulty in the RAID 5 array /dev/md0. Once marked, mdadm removes the device from the active array, and the array continues operating in a degraded state because RAID 5 tolerates a single disk failure. You can then remove the failed disk (mdadm --remove) and replace it (mdadm --add) to rebuild redundancy, which is the proper workflow for handling a failing disk.

pvcreate /dev/sdc /dev/sdd; vgextend vg /dev/sdc /dev/sdd; lvextend -L +2G /dev/vg/lv_data; xfs_growfs /data

This command chain is fully correct. pvcreate initializes both /dev/sdc and /dev/sdd as physical volumes, then vgextend adds both to volume group vg in a single command. lvextend -L +2G grows lv_data by exactly 2 GiB (the plus sign means 'add' rather than 'set to'), and xfs_growfs /data expands the XFS filesystem that is mounted at /data to consume the additional space. This is the proper order: create PVs, extend the VG, extend the LV, and finally grow the filesystem online without needing to unmount.

The /logs entry is missing from /etc/fstab.

The /etc/fstab file is the persistent mount table that systemd reads at boot via fstab-generator to create mount units. Without an entry for /dev/vg_app/lv_logs (or its UUID) pointing to /logs, the filesystem will not be mounted automatically after a reboot. The storage device exists and is formatted, but the mount point is empty because no fstab line tells the system to mount it. This is the classic cause of a filesystem that is reachable manually but unavailable after the server restarts.

lvcreate -l 100%FREE -n lvdata vgdata

The -l flag accepts percentage-based allocation, and 100%FREE specifically targets only the unallocated physical extents in the volume group, so the resulting LV consumes all remaining free space. In contrast to a fixed-size command, this scales automatically as the VG's free space changes. It is the canonical way to create an LV spanning the full free capacity without requiring the administrator to calculate extent counts.

mkswap /dev/sdb1; swapon /dev/sdb1; echo '/dev/sdb1 swap swap defaults 0 0' >> /etc/fstab

This is the correct sequence: `mkswap` initializes the partition with a swap signature, `swapon` activates it immediately for use by the kernel, and appending the line to `/etc/fstab` ensures the swap partition is automatically enabled at boot. The fstab entry uses the correct fields: device, mount point specified as `swap`, filesystem type `swap`, and `defaults` as the mount options. This covers both immediate activation and persistence across reboots, satisfying the administrator's requirement.

fdisk /dev/sdd, create partition, then mkswap /dev/sdd1, swapon /dev/sdd1, and add to /etc/fstab.

This is the complete and correct procedure: fdisk creates a 1 GB partition on /dev/sdd (assigned as /dev/sdd1), mkswap writes the swap signature to that partition, swapon activates the swap for immediate use, and adding the line to /etc/fstab ensures automatic activation at boot. The fstab entry alone or the swapon alone would be incomplete, but combining them covers both current-session and persistent swap. The fdisk step also ensures the partition actually exists with the desired size, unlike the other options that assume a preexisting /dev/sdd1.

The filesystem is XFS, and fsck does not repair XFS.

This is correct. XFS is not repairable by fsck; fsck only inspects the XFS log to see whether the filesystem was cleanly unmounted and reports a 'clean' status based on that flag alone, without traversing metadata structures. To actually verify and repair an XFS filesystem you must use the dedicated xfs_repair utility, so a read-only XFS filesystem after a crash would still be reported as 'clean' by fsck while remaining unusable for writes.

xfs_growfs /mnt

xfs_growfs is the standard tool for resizing an XFS filesystem, and running it with a mount point grows the filesystem to occupy all available space in the underlying device or logical volume. This command works online—meaning the filesystem can remain mounted and in use during the operation—which is a key advantage in production environments. Therefore, xfs_growfs /mnt is a valid and correct answer for resizing an XFS filesystem.

xfs_growfs -D 10g /mnt

xfs_growfs -D 10g /mnt is a valid resizing command because the -D option explicitly sets the new filesystem size to 10 gigabytes, overriding the default behavior of expanding to the full device capacity. It can be used as an alternative to the plain xfs_growfs /mnt when you want to control the exact final size, and the command still requires the target to be larger than the current filesystem since XFS only supports growing. This option is useful when extending a logical volume to a specific size rather than filling all available space.

xfs

XFS is the correct choice because it is the default filesystem on RHEL 9, and Red Hat fully supports it for production workloads. While XFS itself does not have native snapshot capabilities, it works seamlessly with LVM, which provides snapshot functionality for consistent backups and recovery. Its allocation groups, scalable inode handling, and high concurrency support make it ideal for large database files, exactly what the administrator needs.

The partition size is less than 1GB, so mkfs.xfs automatically used a 1024-byte block size.

When the partition on /dev/sdb1 is smaller than 1 GiB, mkfs.xfs automatically uses 1024-byte blocks instead of the usual 4096-byte blocks. This tuning improves space efficiency on small volumes by reducing the overhead associated with larger blocks, such as internal fragmentation and per-block metadata structures. The administrator did not need to specify any option; this is the default behavior for sub-1 GiB XFS filesystems.

blkid

blkid is the dedicated utility that enumerates all block devices visible to the system and prints each file system's UUID, TYPE, LABEL, PARTUUID, and other attributes by default. Since it scans every block device under /dev via libblkid, a bare `blkid` command displays the UUIDs of all file systems without needing a device argument or a filesystem-specific tool.

mkfs.xfs /dev/sdb1

mkfs.xfs is the correct command because it explicitly initializes an XFS filesystem on the target partition. XFS is the default filesystem in RHEL 9 for root and many standard partitions, and this invocation creates the required on-disk structure, including the superblock, allocation groups, and B+tree metadata. After running this command, the partition can be mounted and used as an XFS volume.

Use fdisk to delete and recreate /dev/sdb1 with larger size, run partprobe, then xfs_growfs /mnt/data.

Correct steps for XFS on a partition.

systemctl enable httpd

Enables the service to start at boot.

systemctl enable --now httpd.service

systemctl enable --now httpd.service combines boot-persistent enablement with immediate activation in a single atomic operation. The --now flag instructs systemd to both create the boot-enabling symlinks and start the unit right away, eliminating the risk of forgetting either step. This is the correct choice when the requirement explicitly states that the service must start automatically after reboot; it satisfies both the immediate runtime need and the persistent boot-time need simultaneously.

journalctl -xb -p err

Running journalctl -xb -p err reads the persistent journal from the current boot (-b), applies extended explanatory hints (-x) that describe what each message means, and filters to error priority and above (-p err). This will surface kernel driver errors, systemd mount failures, and device not found messages that directly explain why local-fs.target failed. Because the emergency shell runs early in the boot process, the journal still contains the relevant log entries, making this the most reliable diagnostic command.

The user is not the owner of the directory

If the user is not the owner of their home directory, the owner permission set (typically rwx) does not apply to them. Depending on whether they belong to the directory's group, they fall under the group or other permissions, which in this case are r-x, lacking write permission. Write access to the directory is a prerequisite for creating a new entry, so without 'w' in the effective permission bits, the create operation fails with 'Permission denied'. The ownership mismatch is therefore the direct cause.

The directory has incorrect SELinux context

Even when the directory's mode and ownership (2775, root:developers) grant Bob write access, SELinux performs a separate mandatory access control check. If /data carries a context type that Bob's domain is not allowed to write to (for example, default_t instead of a type like public_content_rw_t or a domain-specific type), the kernel denies the operation with EACCES. This appears as a permission problem though standard permissions are correct. To fix, restore or apply the correct context, e.g., restorecon -Rv /data or a custom semanage fcontext rule.

usermod -aG wheel,docker jane

The -aG form is a compact combined option where -a enables append mode and -G specifies the supplementary group list, so the effect is exactly the same as usermod -a -G. It adds jane to wheel and docker while retaining any other supplementary groups she already has. Although it is less readable than the separated form, it is a fully valid and correct way to accomplish the task.

usermod -a -G wheel,docker jane

Using -a alongside -G directs usermod to append the listed groups to the user's current supplementary groups instead of replacing them. This command explicitly adds jane to both wheel and docker, and because -a is present, all her existing supplementary memberships are left intact. It is the canonical, unambiguous way to satisfy the requirement, and the space between -a and -G is optional but harmless.

Write a script to run 'chage -M 90' for each user in the finance group

A script that calls chage -M 90 for each user in the finance group is the correct approach because chage directly updates the maximum password age field in /etc/shadow for existing user accounts. For example, you can iterate over `getent group finance | cut -d: -f4`, and run chage for each member, which precisely targets the intended accounts and leaves all other users untouched.

usermod -aG

`usermod -aG` adds the user to a supplementary group, not the primary group.

gpasswd -a

`gpasswd -a` adds the user to a supplementary group, not the primary group.

useradd -e $(date -d '+90 days' +%Y-%m-%d) contractor

Correct. The -e option specifies an account expiration date in YYYY-MM-DD format. Using $(date -d '+90 days' +%Y-%m-%d) dynamically calculates the date 90 days from today, ensuring the account is disabled after exactly 90 days.

The directory containing the file lacks execute permission for the group or others.

The directory containing the file lacks execute permission for the group or others. This is the most likely cause because to access a file inside a directory, the user needs execute (x) permission on the directory. Without it, even with correct file permissions, the user will get 'Permission denied'.

The rule was added with --permanent but firewall-cmd --reload was not run.

Permanent rules do not affect runtime until reload.

The file permissions are too permissive (0640 instead of 0440).

Sudo requires /etc/sudoers to be owned by root:root and have mode 0440 (read-only for owner and group). A mode of 0640 grants write permission to root, which sudo considers unsafe because it suggests the file was modified manually outside visudo's validation; sudo then refuses to open it for policy parsing and reports an error. Changing the mode back to 0440 with `chmod 0440 /etc/sudoers` resolves the issue. The message may explicitly say 'sudo: /etc/sudoers is mode 0640, should be 0440'.

The network interface is not assigned to the 'internal' zone.

This is the root cause. firewalld applies zones to traffic based on the ingress interface or source address; if the interface is not permanently assigned to the `internal` zone, it remains in the default zone, which here is `drop` and thus silently discards all incoming packets. The rich rule lives in `internal`, but without the interface assigned there, the rule never sees the SSH traffic. You must run `firewall-cmd --permanent --zone=internal --change-interface=eth0` (then `--reload`) to make the assignment persistent across reboots.

chage -M 30 bob

chage -M 30 bob is the standard command for configuring password aging in RHCSA environments, setting the maximum password age to exactly 30 days. This writes to the fifth field of bob's /etc/shadow entry, after which the password will expire and require change. It is the direct equivalent of passwd -x, but is more commonly seen in scripts and documentation.

passwd -x 30 bob

passwd -x 30 bob is a valid, albeit less commonly used, way to set the password's maximum age on Red Hat systems. The -x option directly controls the maximum number of days a password may be used before the user is forced to change it, and it writes the same shadow field as chage -M. Running it as root is required, and the change takes effect immediately for bob.

restorecon

restorecon resets a file's SELinux context to the policy-defined default by consulting the file_contexts rules, typically with `restorecon -v /path/to/file`. It is the correct tool when a file's context has become incorrect because it determines the intended context from the policy rather than relying on a manually specified value, and it only changes files whose current context does not match the default.

firewall-cmd --list-all-zones

Correct. This command displays the full configuration for all zones, including rules for each zone.

Run the container with 'podman run --restart=always -v /var/log/app:/var/log -p 443:443 myapp' and rely on the container's restart policy.

The '--restart=always' policy only works if the Podman process is running; it does not survive a system reboot without systemd.

podman start web1 && podman attach web1

This combination first uses podman start web1 to take the existing stopped container and transition it to the running state, preserving its filesystem and configuration. Then podman attach web1 connects your terminal to the container's primary process' STDIN and STDOUT, giving you the same interactive console session that existed when it was originally run. This is the correct lifecycle sequence for resuming an existing interactive container without recreating it.

--restart=unless-stopped

--restart=unless-stopped is correct because it ensures the container is automatically restarted whenever it exits, for any reason, with one crucial exception: if an administrator explicitly issues 'docker stop', the container will not be restarted by the policy until it is manually started again. Docker distinguishes between a container that stopped on its own and one that was intentionally stopped, so this matches the requirement exactly. It also survives daemon restarts and host reboots, making it a robust production choice.

USER

The USER instruction is the standard Containerfile directive that sets the active user for subsequent instructions, including the final CMD/ENTRYPOINT runtime process. By specifying a non-root user or numeric UID (e.g., USER 1000), the container runs with least privilege. This is the only option here that directly changes the identity of the running container process.

podman start mycontainer

podman start is correct because it changes an existing, stopped container from the Exited state to the Running state without creating a new container or pulling an image. It resumes the container's configured entrypoint, command, and environment, making it the exact tool needed for the situation shown in the exhibit.

Use 'podman generate systemd --new --name mycontainer' and enable the generated service.

podman generate systemd --new --name mycontainer generates a complete systemd service unit that records the exact podman command, container ID, and environment required to create and start the container fresh on every invocation of the service. Placing this unit in /etc/systemd/system and enabling it with systemctl enable --now makes systemd the supervisor: it sets up dependencies such as After=network-online.target, can apply Restart=on-failure, and will tear down the container cleanly on service stop. This is the intended way to manage a container's lifecycle as a systemd service.

if id 'jdoe' &>/dev/null; then echo 'Exists'; else useradd -m 'jdoe' && echo 'Created' || echo 'Failed'; fi

Correctly checks existence, creates with home dir, and verifies.

No .log files exist in /var/log/myapp at the time of script execution, causing the glob to match nothing.

In a non-interactive shell, an unmatched glob like /var/log/myapp/*.log is not expanded and is passed literally to cp. cp then attempts to copy a file named `*.log`, which does not exist, producing a 'No such file or directory' error and creating no backup. Unless the script checks the glob result or has error handling, this failure can be silent, especially if cron's stderr output is not inspected.

It exits the script immediately if a command fails

This is the exact purpose of `set -e`, also known as `errexit`. When enabled, the shell immediately exits if any simple command, pipeline, or compound command (outside of contexts like `if`, `while`, `until`, `!`, or `&&`/`||` left operands) returns a non-zero status. This halts the script at the first error rather than continuing with unchecked failures.

while read host; do ... done < hosts

The `while read host; do ... done < hosts` construct is the correct approach because it reads the file line by line. On each iteration, `read` assigns the entire line (minus trailing newline) to the variable `host`, so the content is not subjected to word splitting or pathname expansion. This makes it robust for hostnames that might contain unusual characters, though for exact preservation one should add `IFS=` and `-r` to `read`. Additionally, the redirection `< hosts` attaches the file to the loop's standard input, and the loop runs in the current shell, so any variable updates inside the loop remain available afterward.

dir=${1:-.}

The parameter expansion `${1:-.}` explicitly targets the first positional parameter (`$1`) and applies the `:-` operator: if `$1` is unset or null, the expansion substitutes the literal `.` (the current directory). This precisely fulfills the requirement to accept a directory argument with a sensible default when no argument is supplied, because `$1` is the first argument passed to the script, and the default value is only used when that argument is missing or empty.

Use 'df / | awk 'NR==2 {print $5}' | tr -d '%'

This option uses `df /` without `-h`, which produces a stable, machine-parseable output. The `awk` command extracts the fifth field (the percentage used) and `tr` removes the percent sign. This is portable across different Unix/Linux systems.

grep -r --exclude='*.gz' 'ERROR' /var/log

The -r flag makes grep recursively descend into /var/log and all of its subdirectories, while --exclude='*.gz' instructs grep to skip any file whose basename matches that glob, thereby avoiding compressed log files. This precisely implements the requested search: only uncompressed files under /var/log are examined for the string 'ERROR'. Using -r rather than the similar -R is also safer because -r does not dereference symbolic links, keeping the search confined to the named directory tree.

date '+%Y-%m-%d %H:%M:%S'

Formats date as required.

Check the status of remote-fs.target with 'systemctl status remote-fs.target'

Checking 'systemctl status remote-fs.target' is the correct first step because systemd uses this target to synchronize the activation of all remote filesystem mounts, including NFS, during the boot sequence. If the target is in a 'failed' or 'degraded' state, the status output will directly show which mount unit failed and why, allowing you to then inspect that specific unit's logs or configuration rather than guessing. This target is explicitly ordered after network-online.target and pulls in the mount units, so its state is the authoritative indicator of whether boot-time NFS mounting was attempted and completed.

Create a systemd user unit in ~/.config/systemd/user/

A systemd user unit placed in ~/.config/systemd/user/ is managed by the per-user systemd manager and runs in the user's own runtime context, with access to the user's environment, PATH, and systemd user D-Bus. To have it launch at boot rather than only after login, the user must be enabled for lingering (loginctl enable-linger username), after which the user manager starts automatically at boot. This makes it the correct choice for boot-time per-user scripts.

Only root user can read and write; others have no access.

The permission string begins with a hyphen indicating a regular file, followed by 'rw-' for the owner, which is root (or the file's owning user). The subsequent '---' for group and '---' for others show those classes have zero access, so only the owner can read and write (and not execute). This matches typical root-owned file permissions.

The script is not executable.

This is the cause. The exhibit shows the script has permissions 644, meaning there is no execute bit set for the owner, group, or others. When cron encounters a script path in a crontab, it invokes that file directly via execve(), which requires at least one execute bit; otherwise the kernel returns EACCES and the job logs 'Permission denied' or sends a non-zero exit status. The file must be made executable, for example with 'chmod +x', for cron to run it successfully.