527 questions total · 8pages · All types, answers revealed
Which command checks if a user's password has expired and forces a password change at next login?
Sets last password change to 0, forcing change on next login.
Why this answer
chage -d 0 sets the last password change to epoch, forcing password change on next login. Option A locks the account. Option C locks the account.
Option D does not exist.
An administrator needs to create a network bond interface 'bond0' with two slave interfaces 'eth0' and 'eth1' using active-backup mode. Which set of commands is correct?
Correct use of nmcli to create bond and attach ethernet slaves.
Why this answer
Option A is correct because it uses `nmcli` to first create a bond interface named 'bond0' with the default active-backup mode, then adds an Ethernet connection for 'eth0' as a slave to 'bond0' using the `master bond0 slave-type bond` parameters. This is the standard NetworkManager approach for bonding in RHEL 8/9, ensuring the bond is managed by NetworkManager and the slave is properly attached.
Exam trap
The trap here is that candidates confuse bonding with teaming (Option C) or use deprecated manual file editing (Option B), while the correct `nmcli` syntax for adding a slave requires `type ethernet` with `master` and `slave-type`, not a non-existent `type bond-slave` (Option D).
How to eliminate wrong answers
Option B is wrong because manually editing configuration files under `/etc/sysconfig/network-scripts/` is deprecated in RHEL 8/9 in favor of `nmcli`; it also does not include the second slave 'eth1' and lacks the active-backup mode specification. Option C is wrong because `teamd` is used for teaming (a different technology), not bonding; the command uses a teamd JSON configuration with 'activebackup' runner, but the question explicitly asks for a bond interface, not a team interface. Option D is wrong because `nmcli con add type bond-slave` is not a valid connection type in `nmcli`; the correct syntax is `type ethernet` with the `master` and `slave-type` options.
Refer to the exhibit. An administrator runs 'mount -o remount,ro /data' and then 'mount' shows /data as read-only. Later, the system is rebooted. What is the state of /data after reboot?
The remount only affects the current session; after reboot, fstab is used, which has defaults (rw).
A system administrator needs to create a new ext4 filesystem on /dev/sdb1 and mount it persistently at /data. Which set of commands should be used?
Complete sequence.
Why this answer
Option A is correct because it creates the ext4 filesystem with `mkfs -t ext4 /dev/sdb1`, creates the mount point directory with `mkdir /data`, mounts the filesystem immediately with `mount /dev/sdb1 /data`, and then adds an entry to `/etc/fstab` using the correct format (device, mount point, filesystem type, options, dump, pass) to ensure the mount persists across reboots. The `&&` operator ensures each command only runs if the previous one succeeds, which is a safe practice for scripting this task.
Exam trap
The trap here is that candidates often forget to create the mount point directory or attempt to use `blkid` output directly in fstab, assuming it will work, when in fact the fstab file requires a specific columnar format with the device, mount point, filesystem type, options, dump, and pass fields.
How to eliminate wrong answers
Option B is wrong because it does not create the mount point directory (`/data`) before mounting, which will cause the mount command to fail if `/data` does not already exist, and it does not add an entry to `/etc/fstab`, so the mount is not persistent. Option C is wrong because it attempts to mount using `mount /data` without specifying the device, which is invalid syntax; the mount command requires either a device or an existing fstab entry to reference, and the fstab entry is added after the mount command in this sequence, so the mount would fail. Option D is wrong because it uses `blkid /dev/sdb1 >> /etc/fstab` to append the output of blkid (which includes the UUID and filesystem type in a non-fstab format) instead of a properly formatted fstab line; this would corrupt /etc/fstab and not result in a persistent mount.
An administrator wants to run a container with --user 1001:1001 to avoid running as root. After starting, the container cannot write to a bind-mounted directory owned by root. What is the best practice to allow write access?
This changes UID/GID on the host to match the container user, allowing write.
Why this answer
Option C is correct because `podman unshare chown 1001:1001 /host/dir` changes the ownership of the host directory to UID/GID 1001, matching the container's user. This is the best practice in rootless Podman environments, as it avoids running the container with elevated privileges while ensuring the container user can write to the bind-mounted directory.
Exam trap
The trap here is that candidates often choose `--privileged` or setuid as a quick fix, not realizing that rootless Podman requires explicit ownership changes via `podman unshare` to maintain security and proper UID mapping.
How to eliminate wrong answers
Option A is wrong because `--privileged` grants the container all capabilities and access to host devices, which defeats the purpose of running as a non-root user and introduces unnecessary security risks. Option B is wrong because adding user 1001 to the root group on the host does not grant write access to a directory owned by root unless the directory's group permissions allow it (e.g., 775), and it violates the principle of least privilege. Option D is wrong because setting the setuid bit on the host directory does not affect write permissions for a non-root container user; setuid is for executable files, not directories, and does not change ownership for file creation.
Which TWO options correctly describe the use of 'podman exec'? (Choose TWO.)
Correct: runs command in existing container.
Why this answer
Option A is correct because `podman exec <container> ls /` executes the `ls /` command directly inside the specified running container, using the container's filesystem and environment. This is the primary purpose of `podman exec`: to run a new process in an already running container without creating a new container.
Exam trap
The trap here is confusing `podman exec` (which runs a new process in an existing running container) with `podman attach` (which connects to an existing process) or `podman run` (which creates a new container), leading candidates to incorrectly select options about attaching to existing shells or starting stopped containers.
Match each systemd unit type to its purpose.
Drag a concept onto its matching description — or click a concept then click the description.
Manages a daemon or service process
Groups units to define system states (runlevels)
Enables socket-based activation for services
Triggers activation of other units on a schedule
Why these pairings
Systemd uses different unit types to manage system resources.
During an audit, it is discovered that a critical file /etc/shadow has permissions 644 and is owned by root:shadow. The administrator needs to secure it. What is the correct action?
Restricts access to root only, which is the standard requirement.
Why this answer
Option A is correct: permissions 600 (owner read/write only) is the standard. Option B would also work but changes group to root unnecessarily. Option C (000) is too restrictive and may break PAM.
Option D (640) allows shadow group read access, which is less secure.
A production server running Red Hat Enterprise Linux 9 hosts multiple Podman containers. The system administrator wants to ensure that a critical container named 'payments' automatically starts when the host boots, even if no user is logged in. The administrator has already created a systemd service file at /etc/systemd/system/container-payments.service. The service file contains: [Unit] Description=Payments container [Service] ExecStart=/usr/bin/podman start -a payments ExecStop=/usr/bin/podman stop payments Type=forking Restart=always [Install] WantedBy=multi-user.target. After enabling the service with 'systemctl enable container-payments.service' and rebooting, the container does not start. The administrator checks 'systemctl status container-payments.service' and sees that the service is inactive (dead). What is the most likely reason and the correct fix?
The podman generate systemd --new command creates a service unit that automatically creates and starts the container, ensuring it exists and is managed correctly by systemd. The manual unit fails because the container may not exist or the start command is not appropriate for boot-time startup.
Why this answer
Option D is correct because the existing systemd unit file uses `ExecStart=/usr/bin/podman start -a payments`, which assumes the container already exists. On a fresh boot, Podman containers are not automatically recreated unless the systemd unit includes container creation. Using `podman generate systemd --new` produces a unit that includes `ExecStartPre` directives to create the container from the image before starting it, ensuring the container exists and starts on boot.
Exam trap
The trap here is that candidates assume a manually written systemd unit with `ExecStart=/usr/bin/podman start` will work, but they overlook that Podman containers do not survive a reboot unless the unit also creates the container, which is exactly what `podman generate systemd --new` does.
How to eliminate wrong answers
Option A is wrong because `podman auto-update` is used to update containers to newer images, not to start containers on boot. Option B is wrong because adding `--restart=always` to the ExecStart line is not a valid Podman flag; Podman's restart policy is set via `--restart` when running the container, not in the systemd ExecStart command. Option C is wrong because `RestartSec=0` controls the delay between restart attempts by systemd, but the core issue is that the container does not exist after reboot, so no amount of restart timing will fix a missing container.
Which two commands can be used to display the contents of a compressed .tar.gz archive without extracting it? (Choose two)
The -z option tells tar to use gzip decompression; -t lists contents; -f specifies the file.
Why this answer
Option C is correct because `tar -tzf` lists the contents of a gzip-compressed tar archive without extracting it. The `-t` flag tells tar to list the table of contents, `-z` handles the gzip decompression on the fly, and `-f` specifies the archive file. This is the standard way to inspect a .tar.gz file's contents without extraction.
Exam trap
Red Hat often tests the distinction between `-t` (list) and `-x` (extract), and candidates mistakenly choose `tar -xf` thinking it only displays contents, or they confuse `gzcat` with a listing tool.
Which THREE commands are required to create a logical volume named lv_data of size 10G in volume group vg_data, format it as XFS, and mount it at /mnt/data?
Correct: Creates the logical volume.
Why this answer
Option B is correct because the `lvcreate -L 10G -n lv_data vg_data` command creates a logical volume named lv_data with a size of 10 GB within the volume group vg_data. This is the standard LVM command for creating logical volumes, where `-L` specifies the size and `-n` specifies the name.
Exam trap
The trap here is that candidates often include `pvcreate` and `vgcreate` as required steps, but the question specifies that the volume group vg_data already exists, so only the LV creation, formatting, and mounting commands are needed.
A user reports that they cannot create files in their home directory. The administrator checks permissions and sees drwxr-xr-x. What is the likely cause?
If the user is not the owner, they only have read and execute permissions, preventing file creation.
Why this answer
The permissions `drwxr-xr-x` mean the owner has read, write, and execute (rwx) access, while group and others have only read and execute (r-x). Since the user cannot create files (which requires write permission), the user must not be the owner of the directory. Only the owner (or root) can write to it, so the likely cause is that the user is not the owner.
Exam trap
Red Hat often tests the misconception that group membership alone grants write access, but here the group lacks write permission (`r-x`), so even being in the group does not allow file creation; the trap is focusing on group membership rather than the actual permission bits.
How to eliminate wrong answers
Option A is wrong because the sticky bit (indicated by a 't' in the execute position for others, e.g., `drwxr-xr-t`) is not set here; the permissions show a regular 'x' for others, and the sticky bit does not prevent file creation by the owner or those with write permission. Option B is wrong because a read-only filesystem would prevent all write operations system-wide, not just for this user, and the user can still read and execute files in the directory, which would be impossible if the filesystem were read-only. Option D is wrong because group permissions are `r-x`, which do not include write access, so even if the user were in the group, they still could not create files; the issue is the lack of write permission, not group membership.
The administrator wants to create a new ext4 file system on /dev/sdb1 with a block size of 1024 bytes. Which command should be used?
The -b option sets the block size to 1024 bytes.
Why this answer
Option A is correct because the `-b` flag in `mkfs.ext4` specifies the block size in bytes. To create an ext4 filesystem with 1024-byte blocks on /dev/sdb1, the command `mkfs.ext4 -b 1024 /dev/sdb1` is used. This is the standard syntax for setting the logical block size when formatting an ext4 filesystem.
Exam trap
The trap here is that candidates confuse the `-b` flag with other common flags like `-B` (used by XFS) or `-s` (used for stride), or assume GNU-style long options like `--block-size` are supported by `mkfs.ext4` when they are not.
How to eliminate wrong answers
Option B is wrong because `-B` is not a valid flag for `mkfs.ext4`; it is used by `mkfs.xfs` to specify block size, but for ext4 the correct flag is lowercase `-b`. Option C is wrong because `-s` in `mkfs.ext4` is used to specify the number of bytes per inode (stride), not the block size. Option D is wrong because `--block-size` is not a recognized long option for `mkfs.ext4`; the utility does not support GNU-style long options for block size, only the short `-b` flag.
A logical volume 'lv_share' in volume group 'vg_share' has no free extents. The administrator needs to increase the size of '/dev/vg_share/lv_share' by 5 GB. There is another logical volume 'lv_archive' in the same volume group that has 10 GB free space within its filesystem. What must the administrator do to allocate space from 'lv_archive' to 'lv_share'?
Correct: shrinks filesystem and LV, then extends target LV.
Why this answer
Option A is correct because you must first shrink the filesystem on 'lv_archive' using resize2fs (or e2fsck -f / resize2fs) to free space within the filesystem, then reduce the logical volume with lvreduce to release the underlying physical extents back to the volume group. Only after those steps can you extend 'lv_share' with lvextend and then resize its filesystem. This sequence ensures data integrity and avoids filesystem corruption.
Exam trap
Red Hat often tests the misconception that you can reduce a logical volume without first shrinking the filesystem, leading candidates to choose option C, but the correct sequence always requires filesystem resizing before LV reduction to prevent corruption.
How to eliminate wrong answers
Option B is wrong because vgsplit is used to move entire physical volumes between volume groups, not to reallocate free space within the same volume group; it would break the volume group structure. Option C is wrong because using lvreduce directly on 'lv_archive' without first shrinking the filesystem will corrupt the filesystem, as the logical volume shrink truncates the block device before the filesystem is aware. Option D is wrong because lvresize cannot simultaneously reduce one LV and extend another in a single command; it operates on one logical volume at a time.
Option E is wrong because adding a new physical volume does not utilize the existing free space within 'lv_archive' and is unnecessary when space can be reclaimed from the same volume group.
An administrator needs to ensure that a container always runs with a specific SELinux context for security reasons. The container uses a volume mount from the host. Which command should be used to start the container?
'--security-opt label=type:container_t' correctly sets the SELinux context for the container.
Why this answer
Option D is correct because `--security-opt label=type:container_t` explicitly sets the SELinux type for the container process to `container_t`, ensuring the container runs with the required SELinux context. This is the proper way to assign a specific SELinux type when using `podman run`, especially when volume mounts are involved, as it avoids permission conflicts with the host's SELinux policy.
Exam trap
The trap here is that candidates often confuse `--label` (for metadata) with SELinux labeling, or assume `--privileged` is a quick fix for SELinux issues, but the exam specifically tests the correct `--security-opt label=type:` syntax for setting SELinux contexts in Podman.
How to eliminate wrong answers
Option A is wrong because `--label` is used to add metadata labels to the container (e.g., for Podman or Docker), not to set SELinux contexts; `selinux_context` is not a valid option for `--label`. Option B is wrong because `--privileged` grants the container full access to the host, including disabling SELinux enforcement, which bypasses the requirement to run with a specific SELinux context and is insecure. Option C is wrong because `--selinux-context` is not a valid flag in Podman; the correct syntax uses `--security-opt label=type:` to specify the SELinux type.
A system administrator is troubleshooting a custom service called 'database.service' that fails intermittently. The service is a proprietary database that requires large amounts of memory. The administrator runs systemctl status database and sees 'Active: failed (Result: core-dump)' and the journal shows 'Out of memory: Killed process (database) total-vm:...' The server has 8GB RAM and 2 CPU cores. The service unit file does not contain any memory limits. The application is configured to use up to 4GB. The administrator suspects the systemd service is being killed by the OOM killer. Which action should the administrator take to prevent this issue?
Correct: This makes the process less likely to be selected by the OOM killer.
Why this answer
Option B is correct because setting OOMScoreAdjust=-1000 makes the systemd service less likely to be targeted by the OOM killer. The OOM killer selects processes based on a badness score; a lower score (down to -1000) reduces the likelihood of being killed. Since the service is already configured to use up to 4GB and the server has 8GB RAM, adjusting the OOM score is the targeted fix without disabling kernel protections or over-allocating resources.
Exam trap
The trap here is that candidates confuse systemd's cgroup memory limits (MemoryMax) with the kernel OOM killer's scoring mechanism, or they think disabling the OOM killer or adding swap is a safe solution, when the correct approach is to adjust the OOM score to protect the specific service.
How to eliminate wrong answers
Option A is wrong because MemoryMax=6G would set a cgroup memory limit that could cause the service to be killed by systemd's own OOM logic before the kernel OOM killer acts, and it does not address the kernel OOM killer's scoring; the service already uses up to 4GB, so a 6GB limit may still trigger OOM kills if other processes consume memory. Option C is wrong because disabling the OOM killer entirely (e.g., via vm.oom_kill_allocating_task=0 or panic_on_oom=0) is dangerous and not recommended; it can lead to system hangs or unresponsive states, and it is not a targeted fix for a single service. Option D is wrong because increasing swap space to 16GB only delays OOM conditions and can cause severe performance degradation (thrashing); the OOM killer may still kill the process if memory pressure persists, and it does not address the root cause of the service being scored high by the OOM killer.
Which TWO of the following are valid examples of using redirection and pipes in bash to append the output of a command to a file while also displaying it on the terminal? (Choose exactly two.)
tee -a appends to file and writes to stdout.
Why this answer
Option B is correct because `tee -a file` reads from stdin and writes both to stdout and appends to the named file. The pipe `|` sends the stdout of `command` to `tee`, so the output is displayed on the terminal and appended to `file`. The `-a` flag ensures append mode, not overwrite.
Exam trap
Red Hat often tests the distinction between `|` (stdout only) and `|&` (stdout and stderr), and the requirement for `-a` to append rather than overwrite, causing candidates to miss that option A lacks `-a` and option D correctly uses `|&` with `-a`.
An administrator needs to create a 10GB logical volume named 'mylv' in an existing volume group 'vg1', format it with XFS, and mount it at /mnt/data. Which set of commands achieves this correctly?
Correct: Uses proper device path and appends fstab entry.
Why this answer
Option A is correct because it uses the proper `lvcreate` syntax with `-n` for name and `-L` for size, creates the logical volume `/dev/vg1/mylv`, formats it with XFS, mounts it, and appends the correct fstab entry using `>>` to avoid overwriting existing entries. The device path `/dev/vg1/mylv` is the standard LVM device mapper path for a logical volume named 'mylv' in volume group 'vg1'.
Exam trap
Red Hat often tests the distinction between `>` (overwrite) and `>>` (append) in fstab manipulation, and the correct LVM device path format (`/dev/vg1/mylv` vs. `/dev/mylv`), to catch candidates who confuse volume group names with logical volume paths or misuse shell redirection.
How to eliminate wrong answers
Option B is wrong because `blkid` outputs a line with the UUID and filesystem type, but the format is not a valid fstab entry (it lacks mount point, options, dump, and pass fields), and appending it directly to `/etc/fstab` would cause mount failures. Option C is wrong because it uses `>` (single redirect) instead of `>>`, which overwrites the entire `/etc/fstab` file, destroying all existing mount entries. Option D is wrong because it uses the incorrect device path `/dev/mylv` (which would be a volume group name, not a logical volume path) and also uses `--size` instead of `-L` (though `--size` works, the path error is fatal); the correct path should be `/dev/vg1/mylv`.
Correct for HTTPS.
Why this answer
Option C is correct because `firewall-cmd --add-service=https --permanent` adds the HTTPS service (TCP port 443) to the permanent firewall configuration, which is required to allow incoming HTTPS traffic persistently across reboots. The `--permanent` flag ensures the rule survives a reload or restart, and the `--add-service` option uses predefined service definitions from firewalld to simplify rule creation.
Exam trap
The trap here is that candidates often confuse `reject` with `drop` in rich rules, or they mistakenly add the HTTP service instead of HTTPS, failing to distinguish between the two services and their respective ports.
An administrator wants to ensure that a file system is automatically mounted at boot. Which file should be edited?
/etc/fstab is the file system table that defines how and where file systems are mounted at boot.
Why this answer
The /etc/fstab file is the standard configuration file that defines how disk partitions, block devices, and remote filesystems should be mounted into the filesystem tree, including options for automatic mounting at boot time. The system reads this file during the boot process (via systemd or the traditional mount -a command) to mount all filesystems listed with the 'auto' or nofail option.
Exam trap
Red Hat often tests the distinction between configuration files (/etc/fstab) and runtime or bootloader files, leading candidates to mistakenly choose /etc/rc.local or /boot/grub2/grub.cfg because they associate 'boot' with bootloader or startup scripts.
How to eliminate wrong answers
Option A is wrong because /etc/rc.local is a legacy script executed at the end of the boot process, not a configuration file for automatic filesystem mounting; it is not designed for managing mount points and is often empty or disabled on modern Red Hat systems. Option C is wrong because /boot/grub2/grub.cfg is the GRUB2 bootloader configuration file that controls the kernel and initramfs selection, not filesystem mounting; editing it would not affect mount behavior. Option D is wrong because /etc/mtab is a dynamically updated file that lists currently mounted filesystems, maintained by the kernel or mount command; it is not a configuration file and changes to it are not persistent across reboots.
You are managing a Red Hat Enterprise Linux 8 server that hosts a shared development environment. The server has a directory /projects owned by root:developers with permissions 2770. There are three users: dev1, dev2, and dev3, all members of the 'developers' group. Developers need to create and edit files in /projects, and any new file should be writable by all members of the developers group. However, you notice that when dev1 creates a file, the permissions are 644 instead of 664, and the group is set to dev1's primary group (dev1) instead of 'developers'. After investigating, you find that the setgid bit is set on /projects, but the directory's ACLs are not configured. What is the most efficient way to ensure that new files in /projects inherit the group 'developers' and have group-writable permissions by default?
Default ACLs ensure that new files inherit the specified permissions, overriding umask for group.
Why this answer
Option A is correct because setting a default ACL on the /projects directory with `setfacl -d -m g:developers:rwx /projects` ensures that any new file or subdirectory created inside /projects automatically inherits the 'developers' group with rwx permissions. This overrides the creating user's umask and primary group, guaranteeing group-writable files (664) and the correct group ownership, which the setgid bit alone cannot achieve for group permissions when the user's umask is restrictive.
Exam trap
The trap here is that candidates assume the setgid bit alone is sufficient to enforce group-writable permissions, but they overlook that the umask of the creating user still restricts the file's group permissions, making default ACLs necessary to guarantee group-write access.
How to eliminate wrong answers
Option B is wrong because the setgid bit (chmod g+s) is already set on /projects and only ensures new files inherit the directory's group ('developers'), but it does not override the user's umask to make files group-writable; files created with umask 022 will still have 644 permissions. Option C is wrong because changing dev1's umask to 0002 in /etc/bashrc would affect all processes for dev1 system-wide, not just files in /projects, and it does not address the group ownership issue (files would still be owned by dev1's primary group, not 'developers'). Option D is wrong because the sticky bit (chmod o+t) only prevents users from deleting files they do not own in a shared directory; it has no effect on file permissions or group inheritance.
Refer to the exhibit. An administrator extends an XFS filesystem on /data. Which prerequisite step is missing from the output?
Correct. xfs_growfs requires the filesystem to be mounted (or at least the device to be accessible, but typically mounted).
Why this answer
The output shows vgextend and lvextend, then xfs_growfs. However, after lvextend, the filesystem must be notified. For XFS, xfs_growfs is the correct tool, but the output does not show that the underlying block device (the LV) was resized first (which it was via lvextend).
Actually, lvextend resizes the LV, and xfs_growfs resizes the filesystem. The missing step is resizing the filesystem? No, xfs_growfs is present. The question likely expects that the filesystem must be mounted for xfs_growfs to work.
But the output shows it worked. Alternatively, the prerequisite is that the LV must be extended before xfs_growfs, which is shown. Perhaps the missing step is that the filesystem should be unmounted? No, xfs_growfs can be run on a mounted filesystem.
Actually, the exhibit is complete; maybe the missing step is that the partition (sdb3) must be added to the VG, which is done via vgextend. The question might be misaligned. Let me adjust: The exhibit shows extending the LV and then growing the filesystem.
The missing step is that the filesystem must be mounted? But it is mounted at /data. The output shows xfs_growfs /data, which works on mounted. So perhaps the missing step is that the partition (sdb3) must be created first? The exhibit shows vgextend /dev/sdb3, implying sdb3 already exists.
Actually, the question should be about resizing an XFS filesystem after extending the LV. The prerequisite is that the filesystem must be mounted (or at least the device must be accessible). But the output shows it's mounted.
Let me rephrase the stem to be more specific.
After adding a new disk /dev/sdc, a system administrator wants to mount it persistently at /mnt/backup. Which entry in /etc/fstab is most reliable?
Correct: UUID uniquely identifies the filesystem.
Why this answer
Option D is correct because using the UUID (Universally Unique Identifier) ensures the filesystem is mounted persistently regardless of device name changes (e.g., /dev/sdc could become /dev/sdd after a reboot or disk addition). The UUID is generated when the filesystem is created and remains constant, making it the most reliable method for persistent mounts in /etc/fstab.
Exam trap
Red Hat often tests the misconception that device names like /dev/sdc are stable, but the trap here is that device names can change after reboots or hardware changes, while UUIDs remain constant and are the recommended method for persistent mounts in /etc/fstab.
How to eliminate wrong answers
Option A is wrong because it uses a LABEL, which is not set by default on a new disk; if the label 'data' does not exist on /dev/sdc, the mount will fail, and labels can be accidentally duplicated or changed. Option B is wrong because PARTUUID identifies the partition table entry, not the filesystem itself; it is used for partition identification (e.g., with GPT) and does not guarantee the filesystem is present or consistent. Option C is wrong because /dev/sdc is a device name that can change dynamically (e.g., after a reboot or adding other disks), leading to mount failures or mounting the wrong device.
Match each firewall zone to its default trust level.
Drag a concept onto its matching description — or click a concept then click the description.
Low trust; only allow selected incoming connections
Moderate trust; for private networks
High trust; accept all connections
For publicly accessible systems isolated from internal network
Why these pairings
Firewalld zones define trust levels for network interfaces.
Put the steps to configure a cron job that runs a script every day at 2:30 AM in the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Cron jobs are added by editing crontab and specifying the schedule and command.
A server uses firewalld with the default zone set to 'drop'. SSH is allowed only for the 192.168.1.0/24 subnet via a rich rule in the 'internal' zone. After a reboot, SSH connections from that subnet are refused. What is the most likely cause?
Without a permanent zone assignment, the interface reverts to the default zone on reboot.
Why this answer
After a reboot, firewalld applies the default zone to all interfaces not explicitly assigned to another zone. Since the rich rule allowing SSH from 192.168.1.0/24 is defined in the 'internal' zone, the network interface must be assigned to that zone for the rule to take effect. If the interface is not assigned (e.g., it remains in the default 'drop' zone), all incoming traffic, including SSH from the allowed subnet, is dropped by default.
Exam trap
The trap here is that candidates assume rich rules are globally evaluated regardless of zone assignment, but firewalld enforces rules only within the zone bound to the interface, so a rule in the wrong zone is effectively invisible to traffic on that interface.
How to eliminate wrong answers
Option A is wrong because 192.168.1.0/24 is a valid source address in firewalld rich rules; rich rules support CIDR notation for source filtering. Option C is wrong because if the rich rule were not made permanent, it would be lost after reboot, but the question states the rule exists (it was configured), and the issue is that it is not being applied—the interface assignment is the missing link. Option D is wrong because the default zone is 'drop', which by design does not allow any services; the SSH service is intentionally allowed only via a rich rule in the 'internal' zone, not in the default zone, so this is expected behavior and not the cause of the refusal.
What is the most likely cause of the mount error?
Most common cause of mount failure.
Why this answer
The mount error is most likely caused by the NFS server being unreachable or the nfs-utils package not being installed. Without the nfs-utils package, the system lacks the necessary NFS client tools (e.g., mount.nfs, rpcbind) to mount NFS shares. If the server IP is unreachable, the mount command will fail with a timeout or 'No route to host' error, which is a common issue when network connectivity or NFS services are not properly configured.
Exam trap
Red Hat often tests the misconception that a mount error is always due to a syntax error in /etc/fstab or a missing mount point, when in fact the root cause is often a missing client package or network connectivity issue.
How to eliminate wrong answers
Option A is wrong because a malformed /etc/fstab entry would typically cause a mount failure at boot or with 'mount -a', but the question describes a mount error that is most likely due to a missing package or network issue, not a syntax problem in fstab. Option C is wrong because 'nfs4' is a valid filesystem type for NFSv4 mounts; using 'nfs' instead would default to NFSv3, but both are acceptable and would not cause a mount error by themselves. Option D is wrong because if the mount point /mnt/data did not exist, the error message would explicitly state 'mount point does not exist', which is a different and less likely scenario than the one described.
An administrator wants to enable disk quotas for users on an XFS filesystem. Which command initializes the quota database?
After editing /etc/fstab and remounting, 'quotaon' enables quotas on the filesystem.
Why this answer
Option D is correct because `quotaon` activates disk quotas on a filesystem after the quota database has been initialized. However, for XFS filesystems, the quota database is not a separate file; XFS uses internal metadata. The command to initialize quota accounting on XFS is `xfs_quota -x -c 'limit'`, but the question asks for initializing the quota database, which for non-XFS filesystems is done with `quotacheck`.
For XFS, the equivalent is enabling quota via `xfs_quota` or mounting with `uquota`/`gquota` options. The correct answer here is D because `quotaon` is the command that turns on quota enforcement after the database is ready, but the question's phrasing is ambiguous; in the context of EX200, `quotaon` is the final step to activate quotas, not to initialize the database. The trap is that candidates confuse 'initializing the database' with 'enabling quotas'.
For XFS, the database is initialized automatically when quotas are enabled via mount options or `xfs_quota`.
Exam trap
Red Hat often tests the distinction between initializing quota databases (which for XFS is done at mount time) and enabling quota enforcement (quotaon), leading candidates to incorrectly choose quotacheck or edquota.
How to eliminate wrong answers
Option A is wrong because `edquota -u user` edits quotas for a specific user, not initializes the quota database. Option B is wrong because `quotacheck -cug /mount` is used for ext3/ext4 filesystems to create quota files (aquota.user/aquota.group), but XFS does not use separate quota files; it stores quota information in its internal metadata, so `quotacheck` is not applicable. Option C is wrong because `xfs_quota -x -c 'limit -u bsoft=...' /mount` sets a quota limit for a user, but it does not initialize the quota database; it assumes quotas are already enabled on the filesystem.
Which three of the following actions are required when adding a new swap device to the system? (Choose three.)
mkswap initializes the device for use as swap.
Why this answer
Option C is correct because `mkswap` writes a swap signature (UUID and label) to the device, which is required before the kernel can use it as swap space. Without this signature, the device is not recognized as a swap area.
Exam trap
Red Hat often tests the misconception that swap devices must be mounted or formatted with a filesystem, leading candidates to incorrectly select options A or B.
A system is experiencing high CPU usage. The administrator suspects a process is stuck in an infinite loop. Which command can be used to identify the most CPU-intensive process in real-time?
top displays real-time process activity and can sort by CPU usage.
Why this answer
The `top` command provides a real-time, dynamic view of system processes, sorted by CPU usage by default. It continuously refreshes, making it ideal for identifying the most CPU-intensive process as it runs, which directly addresses the scenario of a suspected infinite loop causing high CPU usage.
Exam trap
Red Hat often tests the distinction between real-time monitoring (`top`) and static snapshots (`ps`), where candidates mistakenly choose `ps aux` because they see CPU columns, but fail to recognize that `ps` does not refresh dynamically to catch a looping process.
How to eliminate wrong answers
Option B is wrong because `lsof` lists open files and the processes using them, but it does not show CPU usage or sort processes by CPU consumption in real-time. Option C is wrong because `ps aux` provides a static snapshot of all processes with CPU usage at the moment of execution, but it does not update in real-time to track a rapidly changing CPU-intensive process. Option D is wrong because `strace` traces system calls and signals for a specific process, but it is not designed to identify the most CPU-intensive process; it is a debugging tool for analyzing a process's behavior, not for monitoring overall system CPU usage.
An administrator creates a pod named 'webpod' containing two containers: 'nginx' and 'logger'. The goal is for the nginx container to access the logger container via hostname 'logger'. Which network configuration is required?
Podman pods provide shared network namespace; containers can resolve each other.
Why this answer
In Kubernetes (and by extension, OpenShift, which is the focus of EX200), containers within the same Pod share the same network namespace. This means they can communicate with each other using localhost or, more commonly, the container name as a hostname, which is resolved via the Pod's internal DNS or /etc/hosts. No additional network configuration is required for inter-container communication within a Pod.
Exam trap
The trap here is that candidates confuse standalone container networking (e.g., Podman or Docker) with Kubernetes Pod networking, assuming they need to create a custom network or use environment variables for inter-container communication, when in fact the shared network namespace handles it automatically.
How to eliminate wrong answers
Option B is wrong because 'podman network create' is used for Podman standalone containers, not for containers within a Kubernetes Pod; Pods have an implicit shared network namespace. Option C is wrong because setting an environment variable like LOGGER_HOST is not a network configuration and does not enable hostname resolution; the nginx container can already reach the logger container via the hostname 'logger' without any environment variables. Option D is wrong because creating a network with --internal and --ip-range is unnecessary and would isolate the Pod from external networks, which is not the goal; the default Pod network already supports inter-container communication.
A user is unable to log in via SSH. The administrator checks /var/log/secure and sees 'Authentication refused: bad ownership or modes' for the user's home directory. What is the most likely cause?
The error directly refers to bad ownership or modes; typically the authorized_keys file permissions are too permissive.
Why this answer
Option C is correct because the error 'Authentication refused: bad ownership or modes' in /var/log/secure specifically indicates that the SSH daemon (sshd) has rejected authentication due to overly permissive permissions on the user's ~/.ssh/authorized_keys file. SSH requires that this file be owned by the user and not writable by group or others (typically mode 600 or 644), and the directory ~/.ssh must be mode 700. This is a security check enforced by sshd to prevent unauthorized key injection.
Exam trap
Red Hat often tests the distinction between home directory ownership issues and the specific permissions of ~/.ssh/authorized_keys, leading candidates to incorrectly select 'home directory owned by root' when the log message explicitly mentions 'bad ownership or modes' for the key file.
How to eliminate wrong answers
Option A is wrong because if the sshd service were not running, the user would not even reach the authentication stage; the error would be a connection timeout or 'Connection refused', not a permission-related log entry. Option B is wrong because SELinux context issues typically produce AVC denial messages in /var/log/audit/audit.log, not the specific 'bad ownership or modes' error in /var/log/secure. Option D is wrong because while a home directory owned by root could cause other issues (e.g., inability to write files), the specific error about 'bad ownership or modes' for SSH authentication is triggered by the permissions of ~/.ssh/authorized_keys, not the home directory itself.
An administrator wants to create a swap partition on /dev/sdb1. After creating the partition with fdisk, which command sets up the swap area?
Correct: mkswap initializes swap.
Why this answer
The correct command to set up a swap area on a partition is `mkswap /dev/sdb1`. This command initializes the partition with a swap signature, writing the necessary metadata (such as the swap superblock and version information) so the kernel can later use it as swap space. Without running `mkswap`, the partition is not recognized as a valid swap device.
Exam trap
Red Hat often tests the distinction between preparing a swap area (`mkswap`) and activating it (`swapon`), so candidates mistakenly choose `swapon` thinking it both creates and enables the swap.
How to eliminate wrong answers
Option B is wrong because `mkfs.swap` is not a valid command; the proper tool for creating a swap filesystem is `mkswap`, not a `mkfs.*` variant. Option C is wrong because `swapon` activates an already-prepared swap area; it does not set up or initialize the swap signature on the partition. Option D is wrong because `swapoff` deactivates an active swap device, which is the opposite of what is needed to prepare a new swap area.
An administrator suspects a disk failure in /dev/md0. Which command would be used to simulate a failure on /dev/sdb and then remove it from the array?
Correct: -f for fail, -r for remove.
Why this answer
Option C is correct because the `mdadm` command with the `-f` (fail) and `-r` (remove) flags in a single command line first marks /dev/sdb as faulty in the /dev/md0 array, then immediately removes it. This is the standard syntax for simulating a failure and removing the disk in one step, as tested in the EX200 exam.
Exam trap
The trap here is that candidates often confuse the `--fail` and `--remove` options with similar-sounding but incorrect terms like `--fault`, or they mistakenly specify the wrong disk device in the remove operation, testing attention to exact syntax and device naming.
How to eliminate wrong answers
Option A is wrong because it specifies `--remove /dev/sdc` instead of `/dev/sdb`, attempting to remove a different disk than the one failed, which would fail or cause unintended behavior. Option B is wrong because the `--remove` operation targets `/dev/sda` instead of `/dev/sdb`, and the semicolon separates two commands that are not combined into a single mdadm invocation, which is less efficient and could lead to race conditions. Option D is wrong because it uses the invalid option `--fault` instead of the correct `--fail`; the mdadm command does not recognize `--fault` and would return an error.
A user was recently added to the 'testgrp' group using `usermod -aG testgrp user1`. However, when they try to access a file owned by testgrp with permissions 660, they get permission denied. What is the most likely reason?
The new group membership is not active until the user re-authenticates.
Why this answer
When a user is added to a supplementary group with `usermod -aG`, the group membership change does not take effect in the user's current login session. The user must log out and log back in (or start a new login shell) for the new group to be recognized by the kernel's process credential system. Without this, the user's process lacks the group ID in its supplementary group list, so access to a file with group permissions (660) is denied.
Exam trap
The trap here is that candidates assume `usermod -aG` immediately grants access, overlooking that group membership changes require a new login session to take effect in the process's credential cache.
How to eliminate wrong answers
Option A is wrong because the primary group is irrelevant for accessing a file owned by a supplementary group; the file's group permissions are checked against all groups the user belongs to, including supplementary groups. Option C is wrong because the question states the file is owned by testgrp, so the group owner is correct; if it were not, the user would not get group permissions but could still get 'other' permissions (which are 0 in 660). Option D is wrong because there is no mention of ACLs in the scenario, and standard POSIX permissions (660) are in effect; ACLs would only override if explicitly set, and the question does not indicate that.
You are tasked with creating a script that reads a list of usernames from /tmp/users.txt, one per line, and creates a home directory for each user using `mkdir /home/$username`. The script is: #!/bin/bash while read username; do mkdir /home/$username done < /tmp/users.txt However, the script fails for usernames that contain spaces (e.g., 'john smith'). The error is 'mkdir: cannot create directory '/home/john': File exists' and then a separate directory for 'smith'. What is the best fix?
IFS= and -r prevent field splitting and backslash processing.
Why this answer
Option B is correct because setting IFS= and using -r prevents the read command from splitting on spaces and disables backslash escapes. Option A quoting $username is necessary but not sufficient because read still splits. Option C would also split on spaces.
Option D disables globbing but does not fix word splitting.
A script needs to be run at system boot for a specific user. Which method ensures the script runs with that user's environment?
User units run with the user's environment and can start at login.
Why this answer
Option C is correct because systemd user units, placed in ~/.config/systemd/user/, are executed in the user's own session context, inheriting the user's environment variables, PATH, and D-Bus session. This ensures the script runs with the specific user's environment at boot, as systemd starts the user manager (systemd --user) early in the boot process for each enabled user.
Exam trap
The trap here is that candidates often assume @reboot in crontab runs with the full user environment, but in reality cron provides a stripped-down environment (e.g., no D-Bus, no systemd user session), making it unsuitable for scripts that depend on user-specific services or graphical session variables.
How to eliminate wrong answers
Option A is wrong because /etc/rc.d/rc.local runs as root during system boot, not as a specific user, so it does not load the target user's environment (e.g., $HOME, $USER, or desktop session variables). Option B is wrong because ~/.xprofile is sourced only when the X display server starts (e.g., via a display manager), not at system boot, and it depends on a graphical session being available. Option D is wrong because @reboot in a user's crontab runs the script under the cron daemon's minimal environment, which lacks the full user session context (e.g., D-Bus, systemd user services, or graphical session variables), and cron may not start until after the user logs in.
A script needs to read every line from a file and execute a command on each line. Which code block is correct and handles whitespace correctly?
IFS= preserves leading/trailing whitespace; -r prevents backslash escapes; quoting prevents word splitting.
Why this answer
Option C is correct because using IFS= and -r preserves whitespace and backslashes. Option A does not use -r, breaking backslashes. Option B splits on spaces and globs.
Option D uses an invalid here-string redirection for a file.
A Red Hat Enterprise Linux 8 system was recently updated via 'yum update'. After reboot, the systemd-logind service fails to start with the error 'Failed to start Login Service' and 'Permission denied' messages in the journal. The administrator checks the SELinux status with 'getenforce' and it returns 'Enforcing'. The administrator also notices that the '/var/run' directory is now a symlink to '/run'. There are no firewall issues. The service works if SELinux is set to permissive. Which single action should the administrator take to resolve this issue permanently?
Restoring contexts on /run will fix permission problems caused by mislabeled files.
Why this answer
After a yum update, SELinux contexts on /run may be incorrect because /var/run is a symlink to /run. When SELinux is enforcing, systemd-logind requires the correct context (typically system_u:object_r:var_run_t:s0) on /run to access its runtime files. Running 'restorecon -Rv /run' restores the default SELinux contexts for all files under /run, resolving the 'Permission denied' errors permanently without disabling SELinux.
Exam trap
The trap here is that candidates may focus on the symlink (/var/run -> /run) and assume a package reinstall or disabling SELinux is needed, rather than recognizing that SELinux contexts on the target directory (/run) are the root cause, which is fixed by a simple restorecon.
How to eliminate wrong answers
Option B is wrong because adding 'selinux=0' disables SELinux entirely, which is not a permanent fix and violates security best practices; the service works in permissive mode, indicating SELinux is the issue but should remain enforcing. Option C is wrong because systemd-logind service units do not have a 'Permissions=yes' directive; this is a fictional option that misleads candidates into thinking a service-level permission setting exists. Option D is wrong because reinstalling the systemd-logind package does not fix SELinux context mismatches; the package files are correct, but the runtime contexts on /run are wrong due to the symlink change.
Which command shows the amount of disk space used and available on each mounted filesystem?
df -h shows disk space usage for mounted filesystems.
Why this answer
The `df -h` command displays disk space usage for all mounted filesystems, showing total, used, and available space in human-readable format (e.g., GB, MB). This directly answers the question about disk space on each mounted filesystem.
Exam trap
The trap here is that candidates confuse `df` (filesystem-level space) with `du` (directory-level usage) or `fdisk` (partition table), leading them to pick a command that does not report available space on mounted filesystems.
How to eliminate wrong answers
Option A is wrong because `fdisk -l` lists partition tables on block devices, not disk space usage on mounted filesystems; it shows partition geometry and types, not available space. Option C is wrong because `du -sh` summarizes disk usage of files and directories, not filesystem-level available space; it reports space consumed by specific paths, not mounted filesystems. Option D is wrong because `lsblk` lists block devices and their attributes (e.g., size, type, mount point) but does not show used or available disk space on mounted filesystems; it omits usage percentages and available space.
On a default Red Hat Enterprise Linux 8 installation, which THREE tools or files can be used to configure time synchronization?
Command-line tool for managing chrony.
Why this answer
On a default Red Hat Enterprise Linux 8 installation, `chronyd` is the default NTP daemon, and its configuration file is `/etc/chrony.conf`. The `chronyc` command is the command-line interface for interacting with the `chronyd` daemon, allowing you to monitor and adjust time synchronization. `timedatectl` is the systemd-based tool for managing system time and date settings, including enabling NTP synchronization via `chronyd`.
Exam trap
The trap here is that candidates familiar with older RHEL versions (6/7) may assume `ntpq` and `/etc/ntp.conf` are still the default tools, but RHEL 8 has replaced `ntpd` with `chronyd` as the default NTP implementation.
Which TWO of the following are valid mount options for enabling quotas on an ext4 file system?
grpquota enables per-group quotas on ext4.
Why this answer
Option A is correct because `grpquota` is a valid mount option for enabling group quotas on an ext4 file system. Option E is correct because `usrquota` is the valid mount option for enabling user quotas. Both options are recognized by the `mount` command and the ext4 driver to activate quota tracking at mount time.
Exam trap
The trap here is that candidates confuse the generic `quota` command with a mount option, or misremember the exact option names (e.g., `userquota` instead of `usrquota`), leading them to select incorrect options like `quota` or `userquota`.
Which TWO commands can be used to display available disk space on mounted filesystems in a human-readable format?
Disks space usage for filesystems.
Why this answer
The `df -h` command displays disk space usage for mounted filesystems, with the `-h` flag converting sizes into human-readable units (e.g., KB, MB, GB). This directly answers the requirement to show available disk space on mounted filesystems in a human-readable format.
Exam trap
The trap here is that candidates often confuse `du -sh` (which shows used space for a specific directory) with `df -h` (which shows available space on filesystems), but both are correct in this question because `du -sh` can be used to display disk usage in human-readable format, though it does not show available space directly.
A user reports that SSH key-based authentication fails, but password authentication works. The admin checks /etc/ssh/sshd_config: PubkeyAuthentication yes, PasswordAuthentication no (contrary to the report). Which is the most likely reason key-based auth fails?
sshd requires .ssh to be 700; 755 is too permissive.
Why this answer
Option D is correct because SSH key-based authentication requires that the ~/.ssh directory and its contents have restrictive permissions. If the .ssh directory has permissions 755, it is world-readable, which violates SSH's security model. SSH daemon (sshd) will refuse to use the authorized_keys file if the directory permissions are too permissive, causing key-based authentication to fail even though PubkeyAuthentication is enabled.
Exam trap
The trap here is that candidates assume key-based authentication fails only due to missing keys or disabled PubkeyAuthentication, overlooking the strict permission requirements that SSH enforces for security.
How to eliminate wrong answers
Option A is wrong because SELinux, by default, does not block SSH from reading user keys; SELinux contexts for SSH are typically set correctly, and a denial would require specific policy violations or misconfigurations. Option B is wrong because if the public key were missing from ~/.ssh/authorized_keys, password authentication would still work only if PasswordAuthentication were set to yes, but the config shows PasswordAuthentication no, so the user's report of password working contradicts this scenario. Option C is wrong because SSH being configured to use a different port would affect both key-based and password authentication equally, not selectively break key-based auth while leaving password auth functional.
An administrator needs to mount the backup filesystem with the ‘exec’ option temporarily for a one-time script. Which command will remount the filesystem with exec without unmounting?
This remounts the already mounted filesystem with the exec option added.
Why this answer
Option C is correct because the `mount -o remount,exec /mnt/backup` command changes the mount options of an already-mounted filesystem without unmounting it. The `remount` option applies the specified mount options (in this case, `exec`) to the existing mount point, and the filesystem path (device or mount point) is sufficient for the kernel to identify and modify the mount. This is the standard method for altering mount options on a live filesystem in Linux.
Exam trap
The trap here is that candidates often think they must specify both the device and mount point (as in Option B) for a remount, but the `remount` option only requires one identifier (the mount point or device) to locate the mount, and including both can cause a syntax error or be ignored.
How to eliminate wrong answers
Option A is wrong because `umount && mount` performs an unmount followed by a mount, which is not a remount operation and requires the filesystem to be unmounted first, potentially causing disruption if the filesystem is in use. Option B is wrong because `mount -o exec,remount /dev/sdc1 /mnt/backup` specifies both the device and mount point, which is redundant and can cause a syntax error or unexpected behavior; the `remount` option expects only one of them (typically the mount point or device) to identify the mount. Option D is wrong because `mount -a -o exec` attempts to remount all filesystems listed in `/etc/fstab` with the `exec` option, which is not a targeted remount of the backup filesystem and may fail or apply the option to unintended mounts.
Refer to the exhibit. A container named 'db' is running on the host. An administrator runs `podman inspect db` and sees the above output snippet. What can be concluded about the container's network configuration?
The HostIp 0.0.0.0 means the port is exposed on every network interface of the host.
Why this answer
The output snippet from `podman inspect db` shows `"Ports": {"3306/tcp": [{"HostIp": "0.0.0.0", "HostPort": "3306"}]}`. This indicates that the container's port 3306 is mapped to port 3306 on all host interfaces (0.0.0.0), which is the default bridge networking port binding behavior. Therefore, option C is correct.
Exam trap
Red Hat often tests the distinction between host networking mode and bridge networking with port mapping, where candidates mistakenly think that any port binding to 0.0.0.0 implies host networking, but it actually indicates bridge mode with a published port.
How to eliminate wrong answers
Option A is wrong because host networking mode would show `"NetworkMode": "host"` in the inspect output, and the port mapping would not appear as a bind to 0.0.0.0; instead, the container would share the host's network stack directly. Option B is wrong because the container can be reached from other containers on the same bridge network via its IP address or container name, and the port mapping shown does not prevent inter-container communication. Option D is wrong because the inspect output does not show a static IP assignment; bridge networking with a static IP would require a custom network configuration with an explicit IP address, which is not indicated in the provided snippet.
A system administrator needs to verify that the filesystem on /dev/sdb1 is ext4 before adding it to /etc/fstab. Which command provides this information?
lsblk -f displays filesystem type, UUID, and mount point.
Why this answer
The `lsblk -f /dev/sdb1` command displays the filesystem type (FSTYPE) for the specified block device, such as ext4. This is the most direct and reliable way to verify the filesystem on a specific partition before adding it to /etc/fstab.
Exam trap
The trap here is that candidates often choose `df -Th` because it shows filesystem type, but they forget that it only works on mounted filesystems, whereas `lsblk -f` works on unmounted devices as well.
How to eliminate wrong answers
Option A is wrong because `mount -a` mounts all filesystems listed in /etc/fstab that are not already mounted; it does not display filesystem type information. Option B is wrong because `df -Th /dev/sdb1` shows the filesystem type of mounted filesystems, but if /dev/sdb1 is not mounted, it will not show the type or may produce an error. Option C is wrong because `fdisk -l /dev/sdb1` displays partition table information (size, type, start/end sectors) but does not show the filesystem type (e.g., ext4) — it only shows the partition type ID (e.g., 83 for Linux).
A user reports that they cannot use the 'systemctl' command to manage services. The user is part of the 'wheel' group. Which configuration change is required to allow this?
polkit rules grant systemctl permissions to members of wheel.
Why this answer
The 'systemctl' command requires PolicyKit authorization for non-root users to manage systemd services. The correct configuration is to add a PolicyKit rule in /etc/polkit-1/rules.d/10-admin.rules that grants the 'wheel' group administrative privileges, allowing them to invoke systemctl without a password or with appropriate authentication.
Exam trap
The trap here is that candidates often confuse group membership (like 'wheel' for sudo) with direct authorization via PolicyKit, assuming being in the 'wheel' group automatically grants all administrative privileges, when in fact systemctl relies on polkit rules for non-root users.
How to eliminate wrong answers
Option A is wrong because there is no 'systemd.conf' file; systemd uses 'system.conf' and 'user.conf' for daemon configuration, and 'permissive' mode is a SELinux concept, not a systemd setting. Option B is wrong because the 'systemd-journal' group only grants access to read systemd journal logs, not to manage services with systemctl. Option C is wrong because adding the user to /etc/sudoers with 'ALL ALL=(ALL) ALL' would allow them to run any command as root via sudo, but the question specifies using 'systemctl' directly, not via sudo, and the user is already in the 'wheel' group which typically has sudo access; the issue is about direct PolicyKit authorization for systemctl.
An administrator needs to pull a container image from a private registry at registry.example.com:5000. The registry requires authentication. Which command should be used first?
Authenticates to the registry, then pull can succeed.
Why this answer
Option A is correct because `podman login` authenticates the user to the specified private registry (registry.example.com:5000) before any pull or push operation. Without prior authentication, Podman cannot access the registry's content, and the pull command will fail with an authentication error.
Exam trap
Red Hat often tests the prerequisite step of authentication before interacting with a private registry, and the trap here is that candidates may jump directly to `podman pull` (option D) thinking it will prompt for credentials, but Podman does not prompt interactively in non-TTY environments and requires explicit prior login.
How to eliminate wrong answers
Option B is wrong because `podman tag` is used to assign a new name or alias to an existing local image, not to authenticate or pull from a registry; it requires a source image and a target tag. Option C is wrong because `podman images` lists only locally stored images and does not interact with remote registries or handle authentication. Option D is wrong because `podman pull registry.example.com:5000/myimage` attempts to download the image directly, but without prior authentication (via `podman login`), the pull will fail if the registry requires credentials.
An administrator needs to configure system tuning profiles for a database server. Which command is used to set the 'throughput-performance' profile?
tuned-adm is the correct tool for applying tuning profiles.
Why this answer
The `tuned-adm profile throughput-performance` command is correct because Tuned is the system tuning service on Red Hat Enterprise Linux, and `tuned-adm` is the command-line tool used to activate predefined tuning profiles. The 'throughput-performance' profile optimizes the system for maximum network and disk throughput by disabling power-saving features and tuning kernel parameters.
Exam trap
The trap here is that candidates confuse `systemctl` (which manages systemd services) with `tuned-adm` (which manages Tuned profiles), or they assume a generic sysctl parameter exists for setting a complete tuning profile.
How to eliminate wrong answers
Option A is wrong because `powertop` is a power management diagnostic tool, not a profile manager; it does not have a `--set-profile` option for setting Tuned profiles. Option B is wrong because `sysctl` is used to modify kernel parameters at runtime, but there is no `kernel.throughput` parameter; setting a Tuned profile involves multiple kernel and system settings, not a single sysctl variable. Option C is wrong because `systemctl` manages systemd services, not Tuned profiles; the correct command to set a Tuned profile is `tuned-adm profile`, not `systemctl set-profile`.
Which TWO commands can be used to display the current SELinux mode?
sestatus provides detailed SELinux status including current mode.
Why this answer
The `sestatus` command displays the current SELinux mode (enforcing, permissive, or disabled) along with other SELinux status information. The `getenforce` command specifically returns only the current SELinux mode as a string (Enforcing, Permissive, or Disabled). Both are standard tools for checking the SELinux operational state.
Exam trap
The trap here is that candidates confuse `setenforce` (which changes the mode) with `getenforce` (which displays the mode), or assume `seinfo` or `checkmodule` are status-checking tools when they are actually policy analysis and compilation utilities.
An administrator attempts to start a container with `podman run -d --name web -p 80:80 nginx`. The container fails to start and the logs show 'Error: cannot listen on port 80'. Which of the following is the most likely cause?
The error 'cannot listen on port 80' directly indicates the port is occupied by another process or container.
Why this answer
Option D is correct because the error message 'cannot listen on port 80' indicates that the host's port 80 is already bound by another process. The `-p 80:80` flag maps host port 80 to container port 80, and if another service (e.g., another container or a system daemon like httpd) is already using that port, `podman run` will fail immediately. This is a common port conflict scenario in container management.
Exam trap
The trap here is that candidates may assume SELinux is the cause of all port-related failures in Red Hat environments, but the specific error message 'cannot listen on port 80' directly points to a port conflict, not a MAC policy denial.
How to eliminate wrong answers
Option A is wrong because SELinux blocking the port would typically produce an AVC denial message in the audit log (e.g., 'Permission denied' or 'Operation not permitted'), not a 'cannot listen on port 80' error; SELinux does not prevent binding to a port that is already in use. Option B is wrong because a corrupt container image would cause errors during image pull or extraction (e.g., 'layer not found' or 'checksum mismatch'), not a port binding failure at container start. Option C is wrong because out-of-memory (OOM) conditions result in the container being killed by the kernel OOM killer, producing a '137' exit code or 'container process exited' message, not a specific 'cannot listen on port 80' error.
After restoring files from backup, an SELinux context of a directory is not correct. Which command will restore the file contexts to the system defaults?
Restores the default SELinux contexts based on policy.
Why this answer
Option B (restorecon -R) is the correct command to restore default SELinux contexts. Option A (chcon) sets contexts manually, not to defaults. Option C (setfiles) is used for initial labeling.
Option D (semanage fcontext) adds default context rules.
Which THREE options to podman run can be used to publish container ports to the host? (Select exactly three.)
Maps a container port to a host port.
Why this answer
Option A (-p) is correct because it is the short form of --publish, which maps a container port to a host port. Option B (--publish) is the long form of -p and explicitly publishes container ports to the host. Option D (-P) is correct because it publishes all exposed container ports to random high-numbered ports on the host (typically in the range 32768-60999).
Exam trap
Red Hat often tests the distinction between --expose (which does not publish ports) and -p/--publish (which does), and the fact that --port is not a valid podman option, causing candidates to confuse it with the correct --publish flag.
An administrator is configuring a RAID 1 (mirror) using two 100GB disks /dev/sda and /dev/sdb. After creating the array, which command(s) will verify the array status? (Choose the best answer.)
Correct. Both mdadm --detail and cat /proc/mdstat display RAID array status.
Why this answer
Option E is correct because both `mdadm --detail /dev/md0` and `mdadm --examine /dev/sda` are valid commands to verify the status of a RAID 1 array. `mdadm --detail /dev/md0` shows the current state, sync status, and member disks of the assembled array, while `mdadm --examine /dev/sda` displays the superblock metadata on a component disk, confirming its role in the array and its health. Together, they provide a complete verification from both the array and disk perspectives.
Exam trap
The trap here is that candidates often think only one command is needed, but the EX200 exam tests that `--detail` verifies the assembled array and `--examine` verifies the component disks, requiring both for complete status verification.
How to eliminate wrong answers
Option A is wrong because it alone is insufficient; `mdadm --detail /dev/md0` only checks the array after assembly, not the metadata on individual disks. Option B is wrong because it alone is insufficient; `mdadm --examine /dev/sda` only checks the superblock on one disk, not the array status. Option C is wrong because `cat /proc/mdstat` shows a real-time summary of all MD devices but is not as detailed as `mdadm --detail` or `--examine` for verifying specific array metadata or disk health.
Option D is wrong because `mdadm --query /dev/md0` provides only a brief status (e.g., active/inactive) without the detailed information needed for thorough verification.
Refer to the exhibit. What is the primary security concern with this sudo configuration?
This is a well-known sudo escape vector.
Why this answer
The less command has the ability to execute other commands by typing '! command' within the pager. This allows jane to execute any command as root, effectively bypassing the restriction.
You are a Linux administrator. A user reports that when they log in via SSH, they see the message 'Could not chdir to home directory /home/john: No such file or directory' and are dropped into the root directory. The user's home directory does exist at /home/john but is empty. The user's entry in /etc/passwd is: 'john:x:1001:1001::/home/john:/bin/bash'. What is the most likely cause and the correct fix?
Correct ownership solves permission issue.
Why this answer
The error 'Could not chdir to home directory /home/john: No such file or directory' occurs even though the directory exists, because the SSH daemon (or login process) cannot access it. The most likely cause is that the home directory is not owned by the user john, so the system denies permission to change into it. Running 'chown john:john /home/john' corrects the ownership, allowing the user to enter their home directory.
Exam trap
The trap here is that candidates focus on the literal 'No such file or directory' message and assume the directory is missing or misconfigured, rather than recognizing that permission errors (due to incorrect ownership) can produce the same misleading message.
How to eliminate wrong answers
Option A is wrong because the /etc/passwd entry shows the correct path '/home/john', so there is no typo; changing it would not fix the issue. Option C is wrong because missing .bashrc or skeleton files would not cause a 'No such file or directory' error; that error is about the directory itself, not its contents. Option D is wrong because the shell '/bin/bash' is valid and present; an invalid shell would produce a different error (e.g., 'shell not found').
A file server is experiencing slow write performance. The admin suspects the filesystem is nearly full. Which command should be used to check disk usage per partition?
Shows filesystem disk space usage.
Why this answer
The `df -h` command displays disk space usage for all mounted filesystems in human-readable format (e.g., GB, MB). This directly answers the admin's need to check per-partition usage and identify if a filesystem is nearly full, which can cause slow write performance due to lack of free space.
Exam trap
The trap here is that candidates confuse `df` (disk free, per-partition) with `du` (disk usage, per-directory), or they mistake inode usage (`df -i`) for space usage, leading them to pick a command that does not show partition-level free space.
How to eliminate wrong answers
Option B is wrong because `df -i` shows inode usage, not disk space usage; a filesystem can have free space but run out of inodes, which is a different issue. Option C is wrong because `du -h --max-depth=1 /` shows disk usage of directories under the root, not per-partition usage, and it does not report free space or partition boundaries. Option D is wrong because `du -sh /` shows the total disk usage of the root directory only, not per-partition breakdown, and it cannot identify which partition is nearly full.
A system administrator is troubleshooting a container that fails to start with the error: 'Error: cannot start container: listen tcp4 :80: bind: address already in use'. The container is intended to serve HTTP traffic on port 80. What is the most appropriate first step to resolve this issue?
The correct approach is to identify the conflicting process, stop it if possible, or map the container to an unused host port (e.g., -p 8080:80).
Why this answer
The error 'address already in use' indicates that port 80 on the host is already occupied by another process. The correct first step is to identify that process using commands like `ss -tlnp` or `lsof -i :80` and either stop it or map the container to a different host port (e.g., `-p 8080:80`). This directly resolves the binding conflict without risking data loss or unintended behavior.
Exam trap
The trap here is that candidates may confuse container-level options like `--replace` or `--force` with host-level port management, or assume `--net=host` bypasses port conflicts, when in fact it still requires the port to be available on the host.
How to eliminate wrong answers
Option A is wrong because `--force` is not a valid flag for `podman run`; it is used with `podman rm` or `podman stop` to forcefully remove or stop a container, not to bypass port conflicts. Option C is wrong because `--replace` is used with `podman run` to stop and remove an existing container with the same name before starting a new one, but it does not address the underlying port binding conflict on the host. Option D is wrong because `--net=host` makes the container share the host's network stack, which would still require port 80 to be free on the host and does not resolve the conflict; it also reduces network isolation.
Refer to the exhibit. An administrator wants to add the HTTP service (port 80) to the internal zone permanently. Which sequence of commands should be used?
This adds the service permanently and reloads to apply.
To ensure that a filesystem is mounted automatically at boot and that only root can write to it, which mount options should be used in /etc/fstab? (Assume the filesystem permissions are appropriately set.)
Correct. 'defaults' includes 'nouser' (only root can mount) and 'rw' (read-write). Actual write access is then controlled by filesystem permissions.
Why this answer
Option C is correct because the 'defaults' mount option in /etc/fstab implies rw, suid, dev, exec, auto, nouser, and async. This ensures the filesystem is mounted automatically at boot (via the 'auto' sub-option) and, critically, only root can write to it (because 'nouser' prevents non-root users from mounting or writing, and the default permissions allow root write access). The question states that filesystem permissions are appropriately set, so 'defaults' satisfies both requirements without additional options.
Exam trap
The trap here is that candidates often think 'defaults' is too generic or insufficient, and they overcomplicate by adding explicit options like 'rw' or 'auto', not realizing that 'defaults' already includes both 'auto' (for boot mounting) and 'nouser' (to restrict write access to root), making it the correct single-option answer.
How to eliminate wrong answers
Option A is wrong because 'ro' mounts the filesystem read-only, preventing root from writing, and 'noauto' prevents automatic mounting at boot, directly contradicting the requirement. Option B is wrong because 'noexec,nodev,nosuid' only restricts execution, device files, and setuid/setgid bits; it does not control automatic mounting at boot (missing 'auto') and does not restrict write access to root (it allows any user with write permissions to write). Option D is wrong because 'rw,suid,dev,exec' explicitly allows writing by any user with appropriate permissions, not just root, and does not include 'auto' to ensure boot-time mounting.
Option E is wrong because 'auto' is a valid mount option for boot-time mounting, but 'root' is not a valid mount option in /etc/fstab; the correct option to restrict write access to root is 'nouser' (implied by 'defaults'), not 'root'.
After a system crash, an administrator needs to review logs from the previous boot. Which command shows only logs from the boot before the current one?
Displays journal entries from the previous boot.
Why this answer
Option A (journalctl -b -1) shows logs from the previous boot. Option B shows current boot. Option C uses dmesg incorrectly.
Option D shows only the current boot log.
An administrator needs to run a container with a bind mount of the host directory /data to /var/lib/data inside the container. The container image is web:latest. Which command correctly achieves this?
Correct syntax: host directory /data mounted to container path /var/lib/data.
Why this answer
Option B is correct because the `-v` flag in Podman creates a bind mount from the host directory `/data` to the container directory `/var/lib/data`. The syntax `-v /host/path:/container/path` is the standard way to specify a bind mount, and this command correctly maps the host directory to the intended container path.
Exam trap
The trap here is that candidates often confuse the order of paths in the bind mount syntax, incorrectly placing the container path before the host path, or they mistakenly use an invalid flag like `-V` instead of the correct `-v`.
How to eliminate wrong answers
Option A is wrong because it uses the uppercase `-V` flag, which is not a valid Podman option; Podman uses lowercase `-v` for volume or bind mount operations. Option C is wrong because it reverses the bind mount syntax, mapping the host directory `/var/lib/data` to the container directory `/data`, which does not match the requirement of mounting `/data` to `/var/lib/data`. Option D is wrong because it contains an extra colon (`::`) in the mount specification, which is syntactically incorrect and would cause Podman to fail with an invalid argument error.
An administrator needs to monitor network traffic on a specific interface in real time. Which tool is most appropriate for this task?
Captures and displays packets on eth0 in real time.
Why this answer
tcpdump -i eth0 captures and displays packet headers in real time on the specified interface (eth0). It uses libpcap to intercept raw network frames at the data link layer, making it the standard tool for live traffic monitoring and analysis.
Exam trap
Red Hat often tests the distinction between tools that show aggregate statistics (ip -s link, nload) versus tools that capture individual packets (tcpdump), leading candidates to choose nload because it shows real-time data, but it does not show packet contents.
How to eliminate wrong answers
Option B is wrong because 'ip -s link' shows cumulative statistics (bytes, packets, errors) for interfaces, not real-time packet-by-packet traffic. Option C is wrong because 'ss -tulpn' lists current TCP/UDP sockets and listening services, not live network traffic on an interface. Option D is wrong because 'nload eth0' displays real-time bandwidth usage (in/out rates) but does not show individual packets or their contents; it is a traffic meter, not a packet capture tool.
Arrange the steps to configure a network bond (mode 1) using two interfaces (eth0, eth1) in RHEL.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Network bonding requires creating a bond interface and configuring slaves, then restarting network.
A system administrator notices that a RHEL 9 server's /var/log/messages is filling up the /var partition. The administrator wants to ensure log rotation runs daily and keeps 4 weeks of logs. Which configuration file should be modified?
This is the logrotate config for syslog files.
Why this answer
Option B is correct because /etc/logrotate.d/syslog is the configuration file that controls log rotation for system log files such as /var/log/messages. By modifying this file, the administrator can set the rotation frequency to daily and specify the number of weeks (e.g., rotate 28 for 4 weeks) to retain logs, directly addressing the requirement.
Exam trap
The trap here is that candidates confuse the log rotation configuration file (/etc/logrotate.d/syslog) with the cron job that triggers it (/etc/cron.daily/logrotate) or with the logging daemon configuration files (journald.conf or rsyslog.conf), assuming those control rotation parameters.
How to eliminate wrong answers
Option A is wrong because /etc/systemd/journald.conf configures the systemd journal daemon (journald), which manages binary journal logs, not the rotation of text-based log files like /var/log/messages; log rotation for syslog files is handled by logrotate. Option C is wrong because /etc/rsyslog.conf configures the rsyslog daemon's logging rules and destinations, not log rotation parameters; rotation is a separate function managed by logrotate. Option D is wrong because /etc/cron.daily/logrotate is the cron job script that triggers logrotate execution daily, not a configuration file where rotation parameters (frequency, retention) are defined; modifying this script would not set the rotation schedule or retention count.
An administrator wants to modify the default expiration settings for new user passwords. Which file should be modified?
Contains default settings for password aging and other account parameters.
Why this answer
Option B is correct: /etc/login.defs contains the default password aging parameters like PASS_MAX_DAYS and PASS_WARN_AGE. Option A (/etc/shadow) stores per-user values, not defaults. Option C is for password quality.
Option D is for PAM configuration.
Which TWO commands can be used to create a physical volume for LVM? (Choose exactly two.)
Creates a PV on a partition.
Why this answer
The `pvcreate` command initializes a block device (such as a partition or an entire disk) for use as a physical volume in LVM. Option B targets a partition `/dev/sdb1`, and option C targets the whole disk `/dev/sdb` — both are valid devices that can be initialized as physical volumes, as LVM can operate on either.
Exam trap
Red Hat often tests the distinction between initializing a partition (`/dev/sdb1`) versus a whole disk (`/dev/sdb`) — both are valid with `pvcreate`, but candidates may incorrectly think only partitions can be used, or that `mkfs.ext4` can somehow create an LVM physical volume.
A system administrator receives reports that a web server service (httpd) fails to start after a reboot. The administrator checks the service status and sees it is disabled. Which of the following is the most appropriate command to ensure the service starts automatically on future reboots?
Enables the service to start automatically at boot by creating symlinks.
Why this answer
Option B is correct because systemctl enable creates symlinks to start the service at boot. Option A (restart) only runs the service now, not persistently. Option C (start) also only runs now.
Option D (daemon-reload) reloads unit files but does not enable the service.
Refer to the exhibit. What does the file permission -rw------- indicate about /etc/shadow?
The permissions are rw for owner only, no access for group or others.
Why this answer
The permission string `-rw-------` breaks down as: owner (root) has read (4) and write (2) permissions, and no execute (0); group has no permissions (---); others have no permissions (---). Since `/etc/shadow` is owned by root, only the root user can read and write the file, while all other users (including group members and others) have zero access. Option D correctly states this.
Exam trap
Red Hat often tests the misconception that `-rw-------` means the owner can execute, or that the hyphen in the execute position is easily overlooked, causing candidates to incorrectly assume execute permission is present.
How to eliminate wrong answers
Option A is wrong because the permission string shows no execute bit for the owner (the third character is `-`, not `x`), so the root user cannot execute the file; also, group and others have no access, but the statement incorrectly includes execute. Option B is wrong because it claims group and others can read, but the permission string shows `---` for both group and others, meaning no read access. Option C is wrong because it says the owner can only read, but the owner actually has both read and write permissions (the second character is `w`).
Which two commands correctly set the system to boot into a multi-user target (runlevel 3)?
Correctly sets the default target to multi-user.
Why this answer
Option C is correct because `systemctl set-default multi-user.target` sets the default systemd target to multi-user.target, which corresponds to runlevel 3. This command changes the symlink at /etc/systemd/system/default.target to point to the specified target, ensuring the system boots into that target by default.
Exam trap
The trap here is that candidates may confuse `systemctl set-default` with `systemctl enable` or use incorrect target names like `runlevel3.target`, which does not exist in systemd; the correct target is `multi-user.target`.
A developer wrote a shell script that is intended to back up log files by copying all .log files from /var/log/myapp to /backup/logs. The script runs daily via cron but the backup folder is empty. The script contains the following line: `cp /var/log/myapp/*.log /backup/logs/`. What is the most likely reason the backup fails?
If no files match, cp receives the literal '*' and fails silently if no error handling.
Why this answer
Option C is correct because the glob pattern `*.log` in the `cp` command is expanded by the shell at the time the script runs. If no `.log` files exist in `/var/log/myapp` when the cron job executes, the shell passes the literal string `*.log` to `cp`, which then fails with a 'No such file or directory' error (or, depending on shell settings, may silently do nothing). This is a common issue when log rotation or cleanup removes files before the backup runs.
Exam trap
Red Hat often tests the misconception that cron PATH or permissions are the root cause, but the real trap is that glob expansion happens at script execution time and an empty glob silently fails, leading to an empty backup destination.
How to eliminate wrong answers
Option A is wrong because `cp` is a built-in shell command or located in standard paths like `/bin/cp` or `/usr/bin/cp`, and cron typically sets a minimal PATH that includes `/usr/bin` and `/bin`, so `cp` is almost always found. Option B is wrong because the script itself does not need execute permission if it is invoked via `sh script.sh` or if the cron job line directly calls `sh`; the issue is about file existence, not permissions. Option D is wrong because the question states the script runs daily via cron, implying the crontab syntax is correct and the job is enabled; the backup folder is empty, not that the job fails to run.
A backup script uses tar to create an archive, but the administrator wants to exclude the /tmp directory from the backup. Which tar option should be added?
Excludes the /tmp directory.
Why this answer
Option A is correct because the `--exclude=PATTERN` option in tar tells the command to skip files or directories matching the given pattern. By specifying `--exclude=/tmp`, the tar archive will omit the /tmp directory and all its contents, which is exactly what the administrator needs for the backup script.
Exam trap
The trap here is that candidates confuse `--exclude` (which excludes a pattern) with `--exclude-from` (which reads patterns from a file), leading them to pick option C or D, thinking they can pass a directory path directly to exclude it.
How to eliminate wrong answers
Option B is wrong because `--ignore-failed-read` tells tar to continue archiving even if it cannot read a file (e.g., due to permissions), but it does not exclude any directory. Option C is wrong because `--exclude-from=FILE` reads exclusion patterns from a file, not from a directory path; using `--exclude-from=/tmp` would try to read patterns from the /tmp directory itself, which is not a valid pattern file and would cause an error. Option D is wrong because `-X /tmp` is the short form of `--exclude-from`, which again expects a file containing patterns, not a directory to exclude; it would attempt to read exclusion patterns from /tmp, not exclude the /tmp directory.
Which TWO statements about Logical Volume Manager (LVM) metadata are correct?
Correct: 'pvck' checks physical volume metadata.
Why this answer
Option A is correct because the 'pvck' command is specifically designed to check the metadata of physical volumes in LVM. It verifies the consistency and integrity of the PV metadata, including the volume group descriptor area (VGDA), without making changes. This is a diagnostic tool used before attempting repairs.
Exam trap
The trap here is that candidates confuse the role of 'pvs' (a display tool) with a repair tool, or mistakenly think LVM metadata is stored in a configuration directory like /etc/lvm, when it is actually stored on the physical volumes themselves.
A company policy requires that all new logical volumes be created with a physical extent size of 16 MiB to optimize performance for large sequential I/O. During the creation of a new volume group, what parameter should be used?
Correct: -s sets extent size.
Why this answer
Option E is correct because the `-s` parameter in `vgcreate` sets the physical extent (PE) size for the volume group. A PE size of 16 MiB is specified with `-s 16M`, which ensures all subsequent logical volumes in that VG use 16 MiB extents, optimizing performance for large sequential I/O by reducing metadata overhead.
Exam trap
The trap here is confusing the `-s` (extent size) option with other common LVM parameters like `-L` (size) or `-p` (max PVs), leading candidates to select a wrong option that sets a different attribute entirely.
How to eliminate wrong answers
Option A is wrong because `-p` sets the maximum number of physical volumes allowed in the volume group, not the extent size. Option B is wrong because `-L` sets the maximum logical volume size, not the extent size. Option C is wrong because `-e` is not a valid parameter for `vgcreate`; it is used with `pvcreate` to set the PE start offset.
Option D is wrong because `-c` sets the cluster mode for the volume group, not the extent size.
Practice EX200 by domain
Target a specific domain to shore up weak areas.