Scenario practice questions

A security team wants to implement mandatory access control (MAC) on a Linux server to confine a potentially vulnerable daemon. Which TWO of the following technologies can be used for this purpose?

Trap 1: sudo

sudo grants per-user privilege escalation via the sudoers file; it is discretionary, not mandatory, since administrators define who may run what. MAC confines processes through kernel-enforced, centrally compiled policy independent of user identity. sudo would suit delegating specific administrative commands to named operators, not containing a daemon's syscall and file access.

Trap 2: TCP wrappers

TCP wrappers filter inbound connections by source address and service name through hosts.allow and hosts.deny; they enforce no per-process, label-based confinement, so a compromised daemon retains full access to files and sockets. They are correct for host-level network access control, not mandatory access control.

Trap 3: iptables

iptables filters network packets by address, port and protocol; it cannot constrain a daemon's filesystem, capability or syscall access, which is what MAC confinement requires. It would be the right choice for restricting inbound or outbound traffic to specific hosts and services, not for sandboxing a vulnerable local process.

A
sudo
Why it fails: sudo grants per-user privilege escalation via the sudoers file; it is discretionary, not mandatory, since administrators define who may run what. MAC confines processes through kernel-enforced, centrally compiled policy independent of user identity. sudo would suit delegating specific administrative commands to named operators, not containing a daemon's syscall and file access.
B
AppArmor
AppArmor enforces mandatory access control by applying per-program path-based profiles that confine a daemon's file, network and capability usage, independently of discretionary permissions. This satisfies the requirement to confine a potentially vulnerable daemon on Linux.
C
SELinux
SELinux implements mandatory access control through type enforcement, assigning labels to processes and objects so a confined daemon can only access permitted types. This satisfies the requirement to confine a potentially vulnerable daemon independently of standard Unix permissions.
D
TCP wrappers
Why it fails: TCP wrappers filter inbound connections by source address and service name through hosts.allow and hosts.deny; they enforce no per-process, label-based confinement, so a compromised daemon retains full access to files and sockets. They are correct for host-level network access control, not mandatory access control.
E
iptables
Why it fails: iptables filters network packets by address, port and protocol; it cannot constrain a daemon's filesystem, capability or syscall access, which is what MAC confinement requires. It would be the right choice for restricting inbound or outbound traffic to specific hosts and services, not for sandboxing a vulnerable local process.

Question 2mediummulti select

A system administrator needs to monitor system performance over time. Which THREE tools can be used to collect and display CPU, memory, and I/O statistics? (Choose three.)

Trap 1: top

top displays a live, refreshing snapshot of CPU, memory and process activity but retains no history, so it cannot collect statistics over time. It is tempting because it shows all three metric classes. top is the right choice for real-time interactive troubleshooting, not longitudinal monitoring.

Trap 2: htop

htop is an interactive process viewer showing current CPU and memory usage, but it stores no historical data, so it cannot collect statistics over time. It is tempting because its colour display covers the same metrics. htop suits live interactive inspection rather than recording trends.

A
iostat
iostat reads per-device and per-partition I/O statistics from the kernel, reporting transfer rates, request queue lengths and CPU utilisation. It satisfies the requirement to collect and display I/O statistics over time, complementing CPU and memory tools such as vmstat, sar and top.
B
top
Why it fails: top displays a live, refreshing snapshot of CPU, memory and process activity but retains no history, so it cannot collect statistics over time. It is tempting because it shows all three metric classes. top is the right choice for real-time interactive troubleshooting, not longitudinal monitoring.
C
sar
sar reads historical data collected by sadc, reporting CPU, memory and I/O statistics over time. This satisfies the stem's requirement for tools that collect and display performance statistics, unlike instantaneous tools such as top or vmstat.
D
vmstat
vmstat samples kernel counters for CPU utilisation, run-queue and swap activity, memory usage, and block I/O, printing periodic rows to the terminal. This satisfies the stem's requirement to collect and display CPU, memory, and I/O statistics over time on Linux systems.
E
htop
Why it fails: htop is an interactive process viewer showing current CPU and memory usage, but it stores no historical data, so it cannot collect statistics over time. It is tempting because its colour display covers the same metrics. htop suits live interactive inspection rather than recording trends.

Question 3mediummultiple choice

Scenario: A cloud hosting company uses SELinux in enforcing mode on all Linux servers. A developer reports that a custom web application running under Apache (httpd) is unable to write log files to /var/log/myapp/. The directory /var/log/myapp/ has permissions 755 and is owned by root:root. The httpd process runs as the 'apache' user. The administrator checks SELinux context: /var/log/myapp is labeled with default_t type. The administrator wants to allow httpd to write to this directory while maintaining security. Which command should the administrator run?

Trap 1: Change ownership with 'chown apache:apache /var/log/myapp'

Ownership is irrelevant here: the directory is already 755, and SELinux type enforcement, not Unix permissions, is blocking httpd from writing to a default_t directory. chown is tempting because permission-denied errors often stem from ownership, and it would be correct if standard DAC permissions were the actual cause.

Trap 2: Run 'setenforce 0' to disable SELinux

Disabling enforcement removes all SELinux confinement system-wide, abandoning the security posture the scenario requires rather than granting httpd write access to this one directory. It is tempting as a quick diagnostic, and setenforce 0 is legitimate for temporarily testing whether SELinux is the cause of a failure.

Trap 3: Run 'chcon -t httpd_log_t /var/log/myapp'

chcon applies only a temporary label change that restorecon or a relabel will revert, and httpd_log_t is the type for httpd's own log files, not for a custom directory under /var/log. It is tempting because chcon does set an SELinux type on a path, which is the right approach when the label merely needs correcting.

A
Change ownership with 'chown apache:apache /var/log/myapp'
Why it fails: Ownership is irrelevant here: the directory is already 755, and SELinux type enforcement, not Unix permissions, is blocking httpd from writing to a default_t directory. chown is tempting because permission-denied errors often stem from ownership, and it would be correct if standard DAC permissions were the actual cause.
B
Run 'setenforce 0' to disable SELinux
Why it fails: Disabling enforcement removes all SELinux confinement system-wide, abandoning the security posture the scenario requires rather than granting httpd write access to this one directory. It is tempting as a quick diagnostic, and setenforce 0 is legitimate for temporarily testing whether SELinux is the cause of a failure.
C
Run 'chcon -t httpd_log_t /var/log/myapp'
Why it fails: chcon applies only a temporary label change that restorecon or a relabel will revert, and httpd_log_t is the type for httpd's own log files, not for a custom directory under /var/log. It is tempting because chcon does set an SELinux type on a path, which is the right approach when the label merely needs correcting.
D
Run 'semanage fcontext -a -t httpd_log_t "/var/log/myapp(/.*)?"' and then 'restorecon -Rv /var/log/myapp'
Labeling the directory with the httpd_log_t type grants httpd write access under SELinux, satisfying the enforcing-mode constraint that default_t denies. The semanage fcontext command adds the persistent file-context rule, and restorecon applies it to the existing files.

Read the full Ansible explanation →

Question 4hardmultiple choice

An administrator wants to run a script on multiple remote servers using Ansible. The script requires a variable that differs per host. Where should the administrator define this variable to follow best practices?

Trap 1: In the playbook under vars:

Playbook-level vars: apply one value to every host in the play, so the per-host variation cannot be represented. It is tempting because declaring variables beside tasks keeps a playbook self-contained, and it would be correct when the value is constant for all hosts in that play.

Trap 2: In the inventory file as a variable

An inventory variable attached to a host entry defines the value for that host, but the stem asks for best practice, which places host-specific data in host_vars. It is tempting because inventory variables are quick to add, and it would be correct for connection settings such as ansible_host or ansible_user.

Trap 3: In group_vars/all.yml

group_vars/all.yml applies one identical value to every host, so per-host differences cannot be expressed. It is tempting because group_vars is the standard location for shared settings, and it would be correct when a variable genuinely holds the same value across all managed hosts.

A
In the playbook under vars:
Why it fails: Playbook-level vars: apply one value to every host in the play, so the per-host variation cannot be represented. It is tempting because declaring variables beside tasks keeps a playbook self-contained, and it would be correct when the value is constant for all hosts in that play.
B
In host_vars/<hostname>.yml
Host-specific variables belong in host_vars/<hostname>.yml, which Ansible loads automatically for that inventory host. This keeps per-host values isolated from group and playbook scope, so the differing variable is applied only to the intended server without overriding other hosts' configuration.
C
In the inventory file as a variable
Why it fails: An inventory variable attached to a host entry defines the value for that host, but the stem asks for best practice, which places host-specific data in host_vars. It is tempting because inventory variables are quick to add, and it would be correct for connection settings such as ansible_host or ansible_user.
D
In group_vars/all.yml
Why it fails: group_vars/all.yml applies one identical value to every host, so per-host differences cannot be expressed. It is tempting because group_vars is the standard location for shared settings, and it would be correct when a variable genuinely holds the same value across all managed hosts.

Question 5mediummulti select

A bash script uses a loop to iterate over files in a directory. Which TWO of the following loop constructs will correctly iterate over each .txt file in the current directory? (Select TWO).

Trap 1: for file in '*.txt'; do

Single quotes suppress glob expansion, so the loop iterates once over the literal string '*.txt' rather than matching files. It is tempting because the syntax resembles a working glob loop, but unquoted *.txt is required for pathname expansion; quoting suits literal strings, not filename matching.

Trap 2: for file in $(ls *.txt); do

Command substitution splits ls output on whitespace, so filenames containing spaces break into separate iterations. It is tempting because it lists matching files and works for simple names, but unquoted expansion causes word splitting; a glob loop handles spaces and newlines correctly.

Trap 3: for ((i=0; i<${#files[@]}; i++)); do

This C-style loop indexes a files array that the stem never populates, so it iterates nothing. It is tempting because indexed iteration is valid bash and useful when an array already holds filenames, but here no array assignment exists; a glob-based for loop is needed instead.

A
for file in '*.txt'; do
Why it fails: Single quotes suppress glob expansion, so the loop iterates once over the literal string '*.txt' rather than matching files. It is tempting because the syntax resembles a working glob loop, but unquoted *.txt is required for pathname expansion; quoting suits literal strings, not filename matching.
B
for file in $(ls *.txt); do
Why it fails: Command substitution splits ls output on whitespace, so filenames containing spaces break into separate iterations. It is tempting because it lists matching files and works for simple names, but unquoted expansion causes word splitting; a glob loop handles spaces and newlines correctly.
C
for file in *.txt; do
Glob expansion by the shell resolves `*.txt` into a list of matching filenames before the loop runs, so each iteration assigns one filename to `file`. This satisfies the requirement to iterate over every .txt file in the current directory, provided matches exist.
D
for ((i=0; i<${#files[@]}; i++)); do
Why it fails: This C-style loop indexes a files array that the stem never populates, so it iterates nothing. It is tempting because indexed iteration is valid bash and useful when an array already holds filenames, but here no array assignment exists; a glob-based for loop is needed instead.
E
while IFS= read -r file; do done < <(find . -maxdepth 1 -name '*.txt')
Using process substitution, `find . -maxdepth 1 -name '*.txt'` feeds matching filenames into the `while` loop, with `IFS=` and `read -r` preserving whitespace and backslashes. This satisfies the requirement to iterate over each .txt file in the current directory, including names containing spaces.

Question 6hardmulti select

An administrator is configuring iptables on a server. The requirements are: allow incoming SSH (port 22) from the 192.168.1.0/24 network, drop all other incoming traffic, and allow all outgoing traffic. Which three iptables rules achieve this? (Choose THREE.)

Trap 1: iptables -P FORWARD ACCEPT

The FORWARD chain governs traffic routed through the host, not traffic destined for it, so this policy leaves inbound INPUT filtering undefined. It is tempting because ACCEPT policies are commonly set on FORWARD for routers and NAT gateways, where transit traffic genuinely needs permitting.

Trap 2: iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Allowing port 22 without a source restriction accepts SSH from any address, not just 192.168.1.0/24, so it fails the stated requirement. It is tempting because a bare port-22 ACCEPT rule is exactly what you would write when SSH must be reachable from every host, such as an internet-facing bastion.

A
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
This rule appends to the INPUT chain, matching TCP destination port 22 with source 192.168.1.0/24 and accepting it. It satisfies the requirement to permit SSH only from that subnet, and must precede the blanket INPUT drop so legitimate SSH is not discarded.
B
iptables -P OUTPUT ACCEPT
Setting the OUTPUT chain's default policy to ACCEPT permits all outbound traffic without per-rule matching, satisfying the requirement to allow all outgoing traffic. As a policy rather than an appended rule, it applies to any packet leaving the host that no specific rule handles.
C
iptables -P FORWARD ACCEPT
Why it fails: The FORWARD chain governs traffic routed through the host, not traffic destined for it, so this policy leaves inbound INPUT filtering undefined. It is tempting because ACCEPT policies are commonly set on FORWARD for routers and NAT gateways, where transit traffic genuinely needs permitting.
D
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
Why it fails: Allowing port 22 without a source restriction accepts SSH from any address, not just 192.168.1.0/24, so it fails the stated requirement. It is tempting because a bare port-22 ACCEPT rule is exactly what you would write when SSH must be reachable from every host, such as an internet-facing bastion.
E
iptables -P INPUT DROP
Setting the INPUT chain's default policy to DROP discards every inbound packet lacking an explicit ACCEPT rule, satisfying the requirement to drop all other incoming traffic. The earlier SSH rule must precede it logically, since policy applies only after rules are evaluated.

Question 7mediummultiple choice

A Linux server has SELinux enabled. An administrator wants to temporarily set the SELinux mode to permissive without rebooting, then confirm the change. Which command should be used?

Trap 1: setsebool -P httpd_can_network_connect on

setsebool toggles a specific SELinux boolean and the -P flag makes it persistent across reboots. This changes policy behavior for one feature, not the global SELinux mode. It does not set the system to permissive, so it cannot fulfill the administrator's goal of temporarily disabling enforcement for all domains.

Trap 2: semanage permissive -a httpd_t

semanage permissive -a adds a domain to the permissive domains list, causing only that domain to run without enforcement while the rest of the system remains enforcing. This is a targeted change, not a global mode switch. The administrator asked to set the SELinux mode to permissive, which affects all domains, so this command is too narrow.

Trap 3: restorecon -R /

restorecon relabels files to match the SELinux policy context and does not change the SELinux mode. Running it recursively on the root filesystem could be disruptive and would not make the system permissive. It addresses file context mismatches, not global enforcement behavior, so it fails the stated objective.

A
setenforce 0
setenforce 0 switches SELinux from enforcing to permissive mode immediately in the running kernel. In permissive mode, policy violations are logged but not blocked, which is exactly the temporary change requested. The command takes effect without a reboot and does not alter the persistent configuration in /etc/selinux/config.
B
setsebool -P httpd_can_network_connect on
Why it fails: setsebool toggles a specific SELinux boolean and the -P flag makes it persistent across reboots. This changes policy behavior for one feature, not the global SELinux mode. It does not set the system to permissive, so it cannot fulfill the administrator's goal of temporarily disabling enforcement for all domains.
C
semanage permissive -a httpd_t
Why it fails: semanage permissive -a adds a domain to the permissive domains list, causing only that domain to run without enforcement while the rest of the system remains enforcing. This is a targeted change, not a global mode switch. The administrator asked to set the SELinux mode to permissive, which affects all domains, so this command is too narrow.
D
restorecon -R /
Why it fails: restorecon relabels files to match the SELinux policy context and does not change the SELinux mode. Running it recursively on the root filesystem could be disruptive and would not make the system permissive. It addresses file context mismatches, not global enforcement behavior, so it fails the stated objective.

Question 8mediummulti select

A Linux server becomes unresponsive, and the administrator suspects a process is consuming excessive CPU. The administrator needs to identify the offending process and then terminate it cleanly by PID. Which TWO commands should be used to accomplish these tasks? (Choose two.)

Trap 1: nohup ./service &

nohup with an ampersand runs a command immune to hangup and in the background. It starts a new process rather than locating or stopping an existing high-CPU one. This is unrelated to diagnosing or terminating the offending process and would not help resolve the unresponsive server.

Trap 2: killall -9 bash

killall acts on processes by name rather than PID and, with -9, sends SIGKILL, which cannot be caught and prevents cleanup. Targeting bash could terminate many unrelated shells and user sessions. It neither identifies the CPU consumer nor terminates a specific process cleanly, so it does not meet the stated objectives.

Trap 3: lsof -i :80

lsof -i :80 lists processes with open connections on TCP port 80, which is useful for network or port troubleshooting. It does not rank processes by CPU consumption and does not terminate anything. This command addresses a different problem than identifying and stopping a CPU-bound process.

A
top
top displays a live, sorted view of processes with CPU and memory usage, defaulting to the highest CPU consumers at the top. It lets the administrator quickly identify the process name and its PID during an active incident. This directly satisfies the requirement to find the process driving CPU usage before acting on it.
B
nohup ./service &
Why it fails: nohup with an ampersand runs a command immune to hangup and in the background. It starts a new process rather than locating or stopping an existing high-CPU one. This is unrelated to diagnosing or terminating the offending process and would not help resolve the unresponsive server.
C
killall -9 bash
Why it fails: killall acts on processes by name rather than PID and, with -9, sends SIGKILL, which cannot be caught and prevents cleanup. Targeting bash could terminate many unrelated shells and user sessions. It neither identifies the CPU consumer nor terminates a specific process cleanly, so it does not meet the stated objectives.
D
kill -SIGTERM <PID>
kill sends a signal to a process identified by PID. Using SIGTERM requests a graceful shutdown, allowing the process to flush buffers and clean up, which matches the requirement to terminate the process cleanly. This is the standard, safe way to end a well-behaved process once its PID is known.
E
lsof -i :80
Why it fails: lsof -i :80 lists processes with open connections on TCP port 80, which is useful for network or port troubleshooting. It does not rank processes by CPU consumption and does not terminate anything. This command addresses a different problem than identifying and stopping a CPU-bound process.

Question 9mediummultiple choice

A Linux server hosts a web application that must be able to bind to TCP port 443. The administrator has already installed the application and configured it to listen on 443. However, when the service starts, it fails with a 'Permission denied' error. The administrator confirms that no other process is using port 443 and that the service runs as the non-root user 'webapp'. Which command should the administrator use to grant the necessary capability to the service binary without giving it full root privileges?

Trap 1: chmod u+s /usr/local/bin/webapp

Setting the setuid bit makes the binary run with the privileges of its owner (likely root), which would grant full root access, not just the ability to bind to port 443. This violates the principle of least privilege and introduces a significant security risk. It does not specifically address the capability needed for binding to privileged ports.

Trap 2: firewall-cmd --add-port=443/tcp --permanent

This command opens TCP port 443 in firewalld, which is about network filtering, not about granting a process permission to bind to a privileged port. The error occurs at the bind() system call, before any network traffic is involved. Opening the firewall port does not change the kernel's port binding restrictions for non-root users.

Trap 3: usermod -aG root webapp

Adding the webapp user to the root group does not grant the ability to bind to privileged ports. Group membership in root typically provides access to files owned by the root group, but binding to ports below 1024 is controlled by capabilities, not group permissions. This would not resolve the permission denied error and could grant unintended file access.

A
chmod u+s /usr/local/bin/webapp
Why it fails: Setting the setuid bit makes the binary run with the privileges of its owner (likely root), which would grant full root access, not just the ability to bind to port 443. This violates the principle of least privilege and introduces a significant security risk. It does not specifically address the capability needed for binding to privileged ports.
B
firewall-cmd --add-port=443/tcp --permanent
Why it fails: This command opens TCP port 443 in firewalld, which is about network filtering, not about granting a process permission to bind to a privileged port. The error occurs at the bind() system call, before any network traffic is involved. Opening the firewall port does not change the kernel's port binding restrictions for non-root users.
C
setcap 'cap_net_bind_service=+ep' /usr/local/bin/webapp
This command assigns the cap_net_bind_service capability to the webapp binary, allowing it to bind to privileged ports (below 1024) without running as root. The +ep flags set the effective and permitted capability sets, enabling the process to use the capability. This is the least-privilege approach and directly resolves the permission denied error for a non-root user.
D
usermod -aG root webapp
Why it fails: Adding the webapp user to the root group does not grant the ability to bind to privileged ports. Group membership in root typically provides access to files owned by the root group, but binding to ports below 1024 is controlled by capabilities, not group permissions. This would not resolve the permission denied error and could grant unintended file access.

Question 10hardmultiple choice

A Linux server experiences a kernel panic after a recent driver update. The system is still operational but unstable. Which command should be used to gather detailed information about the kernel modules currently loaded?

Trap 1: modinfo

modinfo reports metadata about one module named on the command line — its parameters, dependencies and licence — rather than enumerating what is currently loaded. It is the right tool when investigating a specific driver's attributes, but the scenario needs a listing of all loaded modules.

Trap 2: dmesg

dmesg prints the kernel ring buffer, showing boot and driver messages, not an inventory of loaded modules. It helps diagnose the panic's cause, but the question asks which modules are currently loaded. dmesg would be correct when tracing hardware or driver errors logged at load time.

Trap 3: modprobe -l

modprobe -l lists modules available on disk in the module tree, not those currently loaded into the running kernel. It is useful for confirming a module file exists before loading it, but it cannot show the loaded set the scenario requires.

A
modinfo
Why it fails: modinfo reports metadata about one module named on the command line — its parameters, dependencies and licence — rather than enumerating what is currently loaded. It is the right tool when investigating a specific driver's attributes, but the scenario needs a listing of all loaded modules.
B
lsmod
lsmod reads /proc/modules and lists every kernel module currently loaded, with size and dependency information. This gives the detailed module inventory needed to identify the suspect driver after the panic, without altering the unstable running system.
C
dmesg
Why it fails: dmesg prints the kernel ring buffer, showing boot and driver messages, not an inventory of loaded modules. It helps diagnose the panic's cause, but the question asks which modules are currently loaded. dmesg would be correct when tracing hardware or driver errors logged at load time.
D
modprobe -l
Why it fails: modprobe -l lists modules available on disk in the module tree, not those currently loaded into the running kernel. It is useful for confirming a module file exists before loading it, but it cannot show the loaded set the scenario requires.

Question 11easymultiple choice

A system fails to boot after installing a new SATA disk. The BIOS recognizes the disk. What is the most likely cause?

Trap 1: GRUB configuration is corrupted

Installing a disk does not modify GRUB, which resides on the existing boot volume; corruption would not be caused by adding hardware. GRUB repair is the right action when bootloader files are damaged or misconfigured, such as after a failed kernel update, not when firmware simply selects the wrong disk.

Trap 2: The new disk is not formatted

Formatting creates a filesystem on an existing partition; a blank disk without one cannot be formatted yet. The boot failure arises because the BIOS now enumerates the new SATA disk ahead of the original boot device, so the firmware attempts to boot from empty media. Formatting is correct when provisioning a data volume.

Trap 3: The new disk is not partitioned

An unpartitioned disk has no partition table, but a boot failure after adding a disk usually stems from boot order or GRUB changes, not partitioning. Partitioning is required before creating filesystems on a data disk, so it would be the right step when preparing new storage, not when diagnosing a boot problem.

A
GRUB configuration is corrupted
Why it fails: Installing a disk does not modify GRUB, which resides on the existing boot volume; corruption would not be caused by adding hardware. GRUB repair is the right action when bootloader files are damaged or misconfigured, such as after a failed kernel update, not when firmware simply selects the wrong disk.
B
Boot order is incorrect
The BIOS detects the disk, so hardware and cabling are functional. If the newly installed SATA disk sits ahead of the original boot disk in the firmware's boot priority list, the system attempts to boot from a disk lacking a bootloader, causing failure. Reordering boot priority restores startup.
C
The new disk is not formatted
Why it fails: Formatting creates a filesystem on an existing partition; a blank disk without one cannot be formatted yet. The boot failure arises because the BIOS now enumerates the new SATA disk ahead of the original boot device, so the firmware attempts to boot from empty media. Formatting is correct when provisioning a data volume.
D
The new disk is not partitioned
Why it fails: An unpartitioned disk has no partition table, but a boot failure after adding a disk usually stems from boot order or GRUB changes, not partitioning. Partitioning is required before creating filesystems on a data disk, so it would be the right step when preparing new storage, not when diagnosing a boot problem.

Question 12easymultiple choice

A junior administrator accidentally modified the /etc/sudoers file and now users report not being able to use sudo. Which command should be used to safely edit the sudoers file?

Trap 1: chmod 400 /etc/sudoers

chmod alters file permissions; it cannot repair malformed sudoers syntax, so sudo stays broken. Editing permissions does not validate entries. The tempting fix is locking the file down after a bad edit, but recovery requires visudo, which parses the file and refuses to save invalid syntax, preventing lockout.

Trap 2: echo 'user ALL=(ALL) ALL' >> /etc/sudoers

Appending with >> bypasses visudo's syntax and lock checks, so a malformed line can break sudo for every user. It is tempting because it adds a grant quickly, but the scenario requires repairing a corrupted sudoers file, which visudo alone validates and edits safely.

Trap 3: usermod -aG wheel user

Adding the user to the wheel group grants sudo rights but does not repair the malformed /etc/sudoers syntax that is blocking sudo. Group membership is the right fix when a valid sudoers file simply lacks an entry for that user.

A
visudo
Editing /etc/sudoers directly risks a syntax error that locks out sudo entirely. visudo validates the file's syntax before saving and writes atomically, so a malformed edit is rejected rather than committed, satisfying the requirement to edit safely.
B
chmod 400 /etc/sudoers
Why it fails: chmod alters file permissions; it cannot repair malformed sudoers syntax, so sudo stays broken. Editing permissions does not validate entries. The tempting fix is locking the file down after a bad edit, but recovery requires visudo, which parses the file and refuses to save invalid syntax, preventing lockout.
C
echo 'user ALL=(ALL) ALL' >> /etc/sudoers
Why it fails: Appending with >> bypasses visudo's syntax and lock checks, so a malformed line can break sudo for every user. It is tempting because it adds a grant quickly, but the scenario requires repairing a corrupted sudoers file, which visudo alone validates and edits safely.
D
usermod -aG wheel user
Why it fails: Adding the user to the wheel group grants sudo rights but does not repair the malformed /etc/sudoers syntax that is blocking sudo. Group membership is the right fix when a valid sudoers file simply lacks an entry for that user.

Question 13mediummultiple choice

An administrator wants to generate a self-signed certificate and private key for testing. Which command creates both in one step?

Trap 1: openssl genrsa -out key.pem 2048

Only generates a key, not a certificate.

Trap 2: openssl req -new -x509 -days 365 -key key.pem -out cert.pem

This creates a CSR and self-signs it, but with -key key.pem it consumes an existing private key rather than generating one, so both artefacts are not produced in one step. Omitting -key would generate the key.

Trap 3: openssl x509 -req -in req.pem -signkey key.pem -out cert.pem

This signs an existing CSR using a key, so it needs req.pem and key.pem to already exist; it creates no private key. It is the correct step for converting a CSR into a certificate once those files are present.

A
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes
The -x509 flag makes openssl req emit a self-signed certificate rather than a CSR, while -newkey rsa:2048 generates the private key in the same invocation. This satisfies the stem's one-step requirement, producing both key.pem and cert.pem without a separate signing command.
B
openssl genrsa -out key.pem 2048
Why it fails: Only generates a key, not a certificate.
C
openssl req -new -x509 -days 365 -key key.pem -out cert.pem
Why it fails: This creates a CSR and self-signs it, but with -key key.pem it consumes an existing private key rather than generating one, so both artefacts are not produced in one step. Omitting -key would generate the key.
D
openssl x509 -req -in req.pem -signkey key.pem -out cert.pem
Why it fails: This signs an existing CSR using a key, so it needs req.pem and key.pem to already exist; it creates no private key. It is the correct step for converting a CSR into a certificate once those files are present.

Question 14mediummulti select

A systems administrator wants to monitor system performance in real time. Which TWO commands can be used to display live updating information about processes, CPU, and memory usage? (Select TWO.)

Trap 1: ps aux

ps aux prints a single static snapshot of current processes and then exits, so it cannot update live. It is tempting because it lists CPU and memory columns, but it would be correct for capturing a one-off process listing rather than continuous real-time monitoring.

Trap 2: sar -u 1 5

sar -u 1 5 samples CPU utilisation five times at one-second intervals, then terminates; it reports historical or interval statistics rather than a live updating display. It is tempting because it collects CPU data, but it would be correct for retrospective performance reporting.

Trap 3: vmstat 1

vmstat 1 refreshes every second, but its columns report aggregate CPU, memory and I/O counters, not per-process detail, so it cannot show which processes are consuming resources. It is tempting because it does provide live updating statistics, and would suit capacity trending or spotting swap and run-queue pressure.

A
top
`top` refreshes process, CPU and memory statistics continuously in the terminal, satisfying the real-time monitoring requirement. Unlike snapshot tools such as `ps`, it updates its display on an interval until quit, letting the administrator observe live resource consumption as it changes.
B
htop
htop provides an interactive, continuously refreshing view of per-process CPU and memory consumption, satisfying the requirement for live updating information. Unlike one-shot tools such as ps or top's batch output, it redraws the process list in real time and supports scrolling and sorting, letting the administrator observe performance changes as they occur.
C
ps aux
Why it fails: ps aux prints a single static snapshot of current processes and then exits, so it cannot update live. It is tempting because it lists CPU and memory columns, but it would be correct for capturing a one-off process listing rather than continuous real-time monitoring.
D
sar -u 1 5
Why it fails: sar -u 1 5 samples CPU utilisation five times at one-second intervals, then terminates; it reports historical or interval statistics rather than a live updating display. It is tempting because it collects CPU data, but it would be correct for retrospective performance reporting.
E
vmstat 1
Why it fails: vmstat 1 refreshes every second, but its columns report aggregate CPU, memory and I/O counters, not per-process detail, so it cannot show which processes are consuming resources. It is tempting because it does provide live updating statistics, and would suit capacity trending or spotting swap and run-queue pressure.