Visit here for our full CompTIA XK0-005 exam dumps and practice test questions.
Question 161:
A Linux administrator must detect which process is generating an unusually high number of context switches, causing reduced system performance. Which command provides per-process context switch statistics in real time?
A) ps -eo pid,csw
B) vmstat 1
C) pidstat -w 1
D) mpstat -P ALL
Answer:
C
Explanation:
The correct answer is pidstat -w 1 because pidstat is part of the sysstat package and provides granular per-process statistics related to context switches, including voluntary and involuntary context switches. The -w flag specifically instructs pidstat to report context switching activity, and the trailing 1 ensures that statistics are updated each second. This makes pidstat -w 1 an ideal tool for diagnosing high context switching rates at the process level.
Option A, ps -eo pid,csw, appears plausible but is not correct because ps does not display context switches in a reliable or continuous manner across all systems. Some Linux distributions allow extra columns containing context switch counts, but ps does not provide real-time statistics and does not differentiate voluntary from involuntary context switches. It captures only snapshot data and cannot reveal trends that are diagnostic for performance issues.
Option B, vmstat 1, shows system-wide context switch numbers in the cs column but does not break them down per process. While vmstat is helpful to confirm that excessive context switching is occurring, it cannot identify which process or processes are responsible. This makes it inadequate for targeted troubleshooting.
Option D, mpstat -P ALL, focuses on CPU utilization across individual processors. While mpstat includes interrupts and some CPU-related data, it does not provide per-process context switch information, making it useless for isolating a specific misbehaving process.
Context switches occur when the CPU switches from executing one process or thread to another. In moderation, context switching is normal and expected because multitasking systems must share CPU time among processes. However, excessive context switching can significantly degrade performance. High context switching usually indicates one of several problems:
A process performing many small tasks with frequent system calls
Threads constantly waiting on locks or synchronization mechanisms
Processes sleeping and waking rapidly
CPU contention among many active threads
Poorly designed multithreaded applications
Network or I/O operations that awaken threads excessively
Interrupt storms or driver issues causing kernel-induced switches
By using pidstat -w 1, administrators get detailed per-process data. The report includes two essential metrics:
voluntary context switches, which occur when a process gives up the CPU willingly, such as waiting on system calls
involuntary context switches, which occur when a higher-priority process preempts or the scheduler forces a switch
These two types of context switches tell different system stories. Voluntary context switches may indicate an I/O-heavy application or one that frequently blocks. Involuntary context switches often suggest scheduler pressure or CPU contention.
Diagnosing a high context-switching process allows administrators to take corrective actions such as:
tuning application thread counts
rewriting scripts or services performing inefficient loops
optimizing system calls
adjusting CPU affinity
upgrading hardware
identifying buggy or misconfigured software
Pidstat also integrates seamlessly with other sysstat tools such as sar, mpstat, and iostat, making it part of a powerful diagnostic toolkit. Because it provides continuous, real-time, per-process context switch statistics, pidstat -w 1 is the only correct answer.
Question 162:
A Linux administrator needs to locate a memory leak in a running application by analyzing which memory mappings are growing over time, including heap regions, anonymous mappings, and shared libraries. Which file in the proc filesystem should be examined to obtain detailed memory mapping information?
A) /proc/PID/smaps
B) /proc/PID/status
C) /proc/PID/stat
D) /proc/PID/meminfo
Answer:
A
Explanation:
The correct file is /proc/PID/smaps because it provides detailed, per-mapping statistics including memory usage, resident set size, proportional set size, anonymous pages, shared pages, private pages, and other critical attributes. The smaps interface is indispensable when diagnosing memory leaks, because it reports not only what the memory regions are, but how much memory each region consumes and how that memory behaves over time.
Option B, /proc/PID/status, contains summary information about a process such as VmRSS, VmSize, and memory summary fields. While it offers helpful overviews, it does not break down memory at the level of individual mappings, nor does it provide detailed information such as how memory is shared, which is crucial for leak analysis.
Option C, /proc/PID/stat, provides raw numeric data related to process state, CPU usage, scheduling, and other internal kernel metrics. It does not include mapping details or memory breakdowns. Its fields are useful for performance analysis but are not associated with memory leak investigation.
Option D, /proc/PID/meminfo, does not exist as a standard file. The correct memory-related files are smaps, status, and statm. Because meminfo is a global file located at /proc/meminfo, not under /proc/PID, option D is invalid.
Smaps breaks memory into regions including:
the executable code segment
heap (brk region)
stack
anonymous memory allocated through mmap
shared libraries
memory mapped files
thread stacks
shared memory regions
Each smaps entry contains fields such as:
Size
Rss
Pss
Shared_Clean
Shared_Dirty
Private_Clean
Private_Dirty
Anonymous
KernelPageSize
MMUPageSize
These fields help administrators determine which memory areas are growing and whether the leak stems from heap allocations, mmap allocations, or library-related issues.
A memory leak typically manifests as increasing Private_Dirty values or growing Rss associated with specific mappings. By taking repeated snapshots of /proc/PID/smaps over time, administrators can track memory growth precisely.
Because smaps is the only file that provides detailed mapping-level memory analysis necessary for leak detection, option A is correct.
Question 163:
A Linux engineer needs to restrict a systemd service so it cannot write to any part of the filesystem except its own working directory. Which systemd security directive should be used to enforce this restriction?
A) ReadOnlyPaths=
B) ProtectSystem=strict
C) InaccessiblePaths=
D) PrivateTmp=true
Answer:
B
Explanation:
The correct directive is ProtectSystem=strict because this systemd security setting makes the entire filesystem read-only except for a few safe writable paths essential for the system. When combined with ProtectHome, ReadWritePaths, and other related directives, ProtectSystem=strict ensures that services cannot write outside explicitly permitted directories.
Option A, ReadOnlyPaths=, marks specific paths as read-only but does not globally restrict write access. It is useful for hardening single directories but requires manual specification.
Option C, InaccessiblePaths=, blocks access to specified paths but does not enforce writable restrictions systemwide.
Option D, PrivateTmp=true, isolates /tmp and /var/tmp but does not affect write access outside those areas.
ProtectSystem=strict elevates protection by remounting system directories such as /usr, /etc, and /boot as read-only for the service. It prevents the service from writing or modifying system files, mitigating risks from compromised or faulty applications.
By using ProtectSystem=strict and then specifying allowed writable directories via ReadWritePaths, administrators can create a contained environment where the service writes only to its designated working directory. This prevents many security risks including unauthorized configuration edits, tampering, and filesystem corruption.
Because ProtectSystem=strict provides maximum filesystem write restriction, option B is correct.
Question 164:
A Linux administrator needs to analyze system activity over a historical period to determine when CPU load increased unusually. Which tool provides historical performance data collected automatically by the system?
A) sar
B) vmstat
C) uptime
D) top
Answer:
A
Explanation:
The correct answer is sar because it collects and stores historical system activity statistics including CPU, memory, disk, network, and other performance metrics. Administrators can query sar logs to review performance over hours, days, or weeks.
Option B, vmstat, shows real-time statistics but does not store historical data.
Option C, uptime, displays load averages but cannot provide timestamps or trends.
Option D, top, is real-time only and does not preserve historical records.
Sar stores data in binary log files typically located under /var/log/sa. Administrators can run sar commands specifying timestamps, intervals, and options to retrieve past CPU statistics. This is extremely useful for diagnosing intermittent issues.
Because sar is the only tool listed designed to collect and retrieve historical activity data, option A is correct.
Question 165:
A Linux engineer must determine which system calls a process makes when opening a file to diagnose intermittent access failures. The engineer needs a tool that shows the exact syscall and the path being accessed. Which command should be used?
A) lsof -p PID
B) ps -ef | grep PID
C) strace -e trace=open,openat -p PID
D) netstat -tulnp
Answer:
C
Explanation:
The correct command is strace -e trace=open,openat -p PID because strace traces system calls and shows file access attempts with specific syscall filters. The open and openat syscalls reveal which file paths the process attempts to open and whether the kernel returns success or errors.
Option A, lsof -p PID, shows open files but not syscalls or attempted opens.
Option B, ps -ef, shows process information only.
Option D, netstat, shows network connections only.
Strace provides real-time syscall tracing and clearly indicates permission errors, missing files, or incorrect paths.
Because strace with filtered open-related syscalls reveals precise file access attempts, option C is correct.
Question 166:
A Linux administrator needs to configure a temporary filesystem that stores files only in RAM and is automatically cleared at every reboot. The filesystem must be mounted at /tmp and should support dynamic size allocation based on available memory. Which entry should be added to /etc/fstab?
A) tmpfs /tmp ext4 defaults 0 0
B) tmpfs /tmp tmpfs defaults 0 0
C) none /tmp tmpfs defaults 0 0
D) ramfs /tmp ramfs defaults 0 0
Answer:
B
Explanation:
The correct answer is option B because the correct format for adding a tmpfs mount to /etc/fstab requires specifying tmpfs as both the filesystem type and the source. A tmpfs filesystem uses RAM for storage, automatically clears data upon reboot, and dynamically resizes based on system usage up to optional limits. For a RAM-backed temporary directory such as /tmp, the recommended and standard approach across most Linux systems is the fstab entry: tmpfs /tmp tmpfs defaults 0 0.
Option A incorrectly lists ext4 as the filesystem type. Ext4 is a disk-based filesystem and cannot be applied to tmpfs. Using ext4 here would attempt to mount a device-backed filesystem, which is not applicable.
Option C uses none as the source, which was common in older Linux systems but is no longer recommended. While some legacy configurations may still work, modern Linux standards specify tmpfs as the source to maintain clarity and consistency.
Option D incorrectly uses ramfs. Although ramfs stores files in RAM, it does not support dynamic allocation limits, meaning it can grow indefinitely and potentially consume all memory, leading to system instability or kernel crashes. Tmpfs, in contrast, allows administrators to optionally limit maximum size while still supporting dynamic allocation.
Tmpfs is widely used for high-speed temporary storage. Files stored in tmpfs exist only in memory and swap space. They never touch the disk, making tmpfs extremely fast and ideal for temporary data such as:
runtime-generated files
cache files
application temporary files
build system intermediates
session data requiring fast I/O
The /tmp directory is a common candidate for tmpfs because it often contains short-lived application files. Using tmpfs for /tmp can significantly speed up operations involving temporary data, reduce SSD wear, and improve server workloads that frequently read and write temporary files.
Key advantages of tmpfs include:
auto-clearing at reboot
dynamic resizing
optional size limits
fast I/O performance
secure and isolated lifecycle
does not persist sensitive data to disk
Administrators may add size limits, for example: tmpfs /tmp tmpfs size=2G 0 0, but since the question does not specify limits, defaults is appropriate.
Because tmpfs /tmp tmpfs defaults 0 0 is the correct modern syntax for a RAM-based temporary filesystem, option B is correct.
Question 167:
A Linux engineer must restrict a systemd service so it runs within a limited memory allocation to prevent it from consuming too much RAM and causing system instability. Which systemd directive enforces a strict memory limit for a service?
A) MemorySoftLimit=
B) MemoryHigh=
C) MemoryMax=
D) MemoryLimit=
Answer:
C
Explanation:
The correct directive is MemoryMax= because it establishes a hard upper boundary on memory usage for the service. If the service attempts to exceed this limit, the kernel will enforce constraints through cgroup mechanisms. This prevents runaway processes from consuming excessive RAM, thereby protecting overall system health.
Option A, MemorySoftLimit=, provides only a soft limit, meaning the service can exceed it if necessary. Soft limits do not enforce a strict memory boundary and therefore cannot guarantee prevention of excessive memory usage.
Option B, MemoryHigh=, sets a throttling threshold. When the service exceeds the high value, the kernel gradually slows down memory allocation. This helps reduce memory pressure but does not strictly prevent the service from exceeding the threshold. It is more of a warning-control mechanism rather than an absolute cap.
Option D, MemoryLimit=, is not a valid systemd directive. It may appear intuitive but is not recognized by systemd and has no effect on memory limiting. Therefore, administrators must use the correct directive provided by systemd.
MemoryMax= is part of systemd’s cgroup-based resource management framework. When placed under the [Service] section of a unit file, it ensures that all processes within the service’s cgroup adhere to the same limit. This includes child processes spawned by the service.
MemoryMax= is particularly useful in:
containerized service environments
microservice architectures
application servers
systems susceptible to memory leaks
high-density virtual machine hosts
multi-tenant environments
MemoryMax= works by coordinating with the kernel’s cgroups subsystem. If memory allocation exceeds the limit, the kernel’s out-of-memory killer may terminate the offending process or throttle it depending on configuration. Administrators can also combine MemoryMax= with other systemd security directives for improved process isolation.
Because MemoryMax= provides a hard memory cap that ensures the service cannot exceed a predefined limit, option C is correct.
Question 168:
A Linux administrator needs to troubleshoot a system where CPU load periodically spikes due to heavy kernel-level operations. The administrator wants to profile kernel activity, including context switches, interrupts, and scheduling events. Which tool should be used to gather this low-level kernel performance data?
A) vmstat
B) perf
C) top
D) pidstat
Answer:
B
Explanation:
The correct tool is perf because it is designed for advanced performance profiling and can examine low-level kernel events such as context switches, scheduling behavior, CPU cycles, cache misses, and interrupt frequency. Perf interfaces with the kernel’s performance counters to capture detailed diagnostic information that cannot be gathered by general-purpose tools.
Option A, vmstat, provides high-level performance statistics including context switches and interrupts, but it cannot perform detailed profiling or event sampling. Vmstat is useful for general monitoring but cannot reveal deep kernel behavior required for performance analysis.
Option C, top, shows basic CPU usage, load averages, and per-process statistics but does not expose kernel-level performance events or internal scheduling metrics. It is unsuitable for investigating spikes caused by kernel mechanisms.
Option D, pidstat, analyzes per-process metrics such as CPU usage, memory usage, and I/O activity. It cannot profile kernel-level operations or access hardware performance counters.
Perf is uniquely suited for:
analyzing CPU-bound operations
identifying interrupt storms
profiling kernel functions
studying scheduler decisions
diagnosing hardware-level issues
evaluating memory access patterns
Perf can measure precise kernel events such as:
context-switch counts
IRQ handling time
CPU stall cycles
hardware cache behavior
kernel call stacks
branch mispredictions
Administrators use perf during performance bottlenecks, high-latency scenarios, and kernel debugging sessions. It is especially powerful in environments requiring deep optimization, such as database servers, high-performance computing clusters, or systems running large numbers of containerized workloads.
Because perf is the only tool among the options capable of detailed kernel-level performance profiling, option B is correct.
Question 169:
A Linux administrator must prevent a specific user from logging into the system while keeping the account intact for file ownership purposes. Which method disables login access without deleting or modifying the user’s home directory or files?
A) userdel username
B) passwd -l username
C) rm -rf /home/username
D) chsh -s /bin/false username
Answer:
B
Explanation:
The correct answer is passwd -l username because it locks the user’s password by modifying the shadow entry so the user cannot authenticate with their password. This prevents login while keeping the account and home directory intact. The user still owns files and directories, making this method ideal for temporarily disabling login access.
Option A, userdel username, deletes the user account entirely and may remove the user’s home directory depending on configuration. This is inappropriate when preserving ownership and file structure is required.
Option C, rm -rf /home/username, deletes the user’s home directory. This destroys user data, breaks file associations, and is extremely destructive.
Option D, chsh -s /bin/false username, sets the user’s shell to a non-interactive binary. While this prevents shell logins, it may not completely disable all login methods and may interfere with automated processes run by that user. Additionally, some services may still allow authentication even if the shell is set to false.
Passwd -l modifies the encrypted password field in /etc/shadow by adding an exclamation mark at the beginning. This makes the password invalid without deleting it. The user cannot authenticate, but the administrator can later unlock the account using passwd -u username.
Because passwd -l is the safest and most appropriate method to disable user logins while preserving the account, option B is correct.
Question 170:
A Linux engineer needs to determine whether a system’s hard drive is experiencing slow I/O performance due to high wait times. Which command displays real-time I/O wait percentages and helps identify whether CPU cycles are being stalled by disk operations?
A) iostat -x 1
B) uptime
C) ps -ax
D) df -h
Answer:
A
Explanation:
The correct answer is iostat -x 1 because it provides extended disk statistics including I/O wait times (await), service times, queue depths, utilization percentages, and throughput metrics. The -x flag displays extended statistics, while 1 instructs the tool to refresh every second, offering real-time monitoring.
Option B, uptime, only displays load averages and cannot reveal disk wait-related information.
Option C, ps -ax, displays process lists but offers no disk-related performance statistics.
Option D, df -h, shows disk usage but not performance metrics or wait times.
Iostat -x displays:
r/s and w/s (reads and writes per second)
avgrq-sz (average request size)
avgqu-sz (average queue length)
await (average wait time)
svctm (service time)
%util (device utilization)
High await or %util values indicate disk bottlenecks. When I/O wait is high, processes stall waiting for data, causing CPU underutilization and workflow delays.
Iostat is essential for diagnosing performance issues such as:
failing disks
overloaded storage arrays
slow virtualized storage
excessive I/O-heavy workloads
filesystem bottlenecks
poorly configured caching layers
Because iostat -x 1 provides real-time I/O wait statistics needed to diagnose slow disk performance, option A is correct.
Question 171:
A Linux administrator needs to ensure that a service is restarted automatically by systemd if it consumes too much memory and gets terminated by the kernel’s OOM killer. Which systemd directive must be used so systemd is aware that the service exited due to a resource exhaustion event and should be restarted accordingly?
A) Restart=on-success
B) RestartForceExitStatus=
C) Restart=on-failure
D) SuccessExitStatus=
Answer:
C
Explanation:
The correct answer is Restart=on-failure because this directive specifically tells systemd to restart a service whenever it exits with a non-zero status, is terminated by a signal, or fails due to abnormal conditions such as exceeding memory limits or being killed by the kernel’s out-of-memory mechanism. When the OOM killer intervenes and terminates the process, the resulting exit condition is considered a failure, which aligns with systemd’s interpretation under Restart=on-failure. Therefore, this directive ensures that the service will be automatically restarted in such circumstances.
Option A, Restart=on-success, is not suitable because it only restarts a service when it exits cleanly with a success code. When the OOM killer terminates a process, the exit condition is neither clean nor successful. Thus, this directive would not restart the service after such an event.
Option B, RestartForceExitStatus=, allows administrators to specify exit codes that should always trigger a restart. Although this directive gives administrators fine-grained control, it requires explicit exit codes, which do not apply well to OOM-killed processes because the kernel terminates them using signals rather than regular exit codes. The OOM kill signal varies and cannot always be predicted or forced into a specific code category. Therefore, RestartForceExitStatus is not the reliable choice in this context.
Option D, SuccessExitStatus=, is used to define additional exit statuses that systemd should consider “successful,” meaning the service will be treated as if it exited properly. This is not desirable for services terminated by the OOM killer because treating such an event as a success would prevent systemd from restarting it. The goal is to restart the service after OOM termination, not to ignore the failure or categorize it as successful.
When a process is terminated by the out-of-memory killer, systemd interprets the event as a failure due to a signal-based termination. Under Restart=on-failure, systemd detects that the service did not achieve a clean shutdown and initiates a restart sequence. This is essential for maintaining service availability in memory-constrained environments or in situations where workloads fluctuate unpredictably.
OOM kills are common in environments such as:
servers under sustained memory pressure
containerized workloads
memory-intensive applications
misconfigured services with memory leaks
high-load database servers
environments lacking swap space
When an application is repeatedly killed due to insufficient memory, systemd’s automatic restart capability helps maintain availability while administrators investigate the underlying cause. Additional systemd directives such as MemoryMax and MemoryHigh can also be used to enforce memory limits and prevent uncontrolled growth.
Systemd’s restart behavior allows administrators to create resilient services that recover automatically from unexpected failures. Restart=on-failure ensures that services stay running even when they crash due to resource exhaustion, segmentation faults, uncaught exceptions, or forced signals.
Because Restart=on-failure is explicitly designed to restart services after abnormal terminations such as OOM kills, option C is correct.
Question 172:
A Linux engineer needs to determine which process is causing excessive kernel-level disk flush operations and generating frequent writeback activity. The goal is to analyze writeback queues, dirty pages, and kernel flush behavior. Which tool provides deep visibility into kernel writeback operations?
A) vmstat 1
B) iostat -x 1
C) cat /proc/vmstat
D) pidstat -d 1
Answer:
C
Explanation:
The correct answer is cat /proc/vmstat because this proc interface provides deep insight into kernel-level virtual memory operations including writeback activity, dirty pages, background flushing, and the kernel’s management of active and inactive memory pages. /proc/vmstat includes dozens of counters that reveal how memory is being handled internally by the kernel, which is invaluable for diagnosing issues related to excessive disk flushing or writeback pressure.
Option A, vmstat 1, shows summarized system statistics including some memory and I/O metrics, but it does not provide the complete detailed counters found in /proc/vmstat. Although vmstat displays si and so fields (swap in and out) and some memory statistics, it does not expose the full internal workings of the kernel’s writeback manager such as the number of dirty pages, writeback-in-progress counts, or detailed dirty throttling statistics.
Option B, iostat -x 1, provides extended disk statistics such as I/O operations per second, utilization, and queue depth. While iostat is excellent for device-level performance monitoring, it does not reveal kernel memory behavior or writeback operations, which occur before actual disk I/O is initiated. iostat cannot show how many dirty pages are accumulating in memory or how often the kernel is initiating flushing operations.
Option D, pidstat -d 1, provides per-process disk I/O statistics but cannot reveal kernel-level flushing behavior. It helps detect which processes are issuing read and write operations, but writeback activity sometimes occurs independently of user processes due to the kernel’s background tasks managing dirty pages and cache pressure.
The /proc/vmstat file contains fields such as:
nr_dirty: number of dirty pages
nr_writeback: pages currently being written to disk
nr_writeback_temp: temporary writeback pages
nr_dirty_threshold: limit triggering writeback
nr_dirty_background_threshold: threshold for background writeback
writeback failures
page fault statistics
major and minor faults
memory reclaim counters
kswapd activity
By monitoring changes in these counters over time, administrators can identify:
applications generating excessive dirty pages
filesystem caching issues
delayed writeback behavior
memory pressure conditions that force frequent flushing
potential storage bottlenecks caused by writeback
system thrashing due to dirty page accumulation
Administrators can collect snapshots of /proc/vmstat at intervals to observe trends. If nr_dirty increases rapidly, the system is generating dirty pages faster than the kernel can flush them. If nr_writeback remains high, the disk may be too slow, or the kernel’s flush settings may require tuning.
In high-performance environments such as database servers or write-heavy applications, tuning writeback behavior using sysctl values such as dirty_ratio and dirty_background_ratio may be necessary. /proc/vmstat is the only location that provides granular counters for evaluating such adjustments.
Because cat /proc/vmstat provides the raw kernel counters necessary for deep visibility into writeback activity, option C is correct.
Question 173:
A Linux administrator needs to identify which process opened a deleted file that is still consuming disk space. The goal is to reclaim the space without rebooting. Which command reveals deleted files that remain open and the processes holding them?
A) df -h
B) du -sh /
C) lsof | grep deleted
D) ps -aux
Answer:
C
Explanation:
The correct command is lsof | grep deleted because lsof lists open files, including files that have been removed from the directory structure but remain active because a running process still holds the file descriptor. When a file is deleted while a process still has it open, the file becomes unlinked from the filesystem but the data remains until the last file descriptor is closed. This situation commonly leads to disk space not being reclaimed even after deletion.
Option A, df -h, displays filesystem usage statistics but cannot indicate which deleted files remain open or identify the process responsible.
Option B, du -sh /, calculates disk usage by directory but does not consider deleted files or files held by processes. Deleted-but-open files do not appear in directory listings, so du cannot detect them.
Option D, ps -aux, shows running processes but provides no file-level information, much less data about deleted files.
Lsof is uniquely capable of displaying all open file descriptors and includes entries referring to files that have been deleted. These entries typically appear with a path such as:
somefile.log (deleted)
The command lsof | grep deleted reveals processes that have open handles on deleted files. An administrator can then decide to:
restart the offending service
kill the process holding the file
investigate why the file remains open
reclaim disk space immediately after closing the file descriptor
This technique is essential in scenarios involving log rotation. Sometimes, log files are removed or rotated, but a process continues to write to the old file descriptor, wasting disk space. Restarting or reloading the service frees the descriptor.
Common culprits include:
web servers
database systems
Java applications
background daemons
custom scripts writing logs
Because lsof uniquely identifies deleted-but-open files, option C is correct.
Question 174:
A Linux engineer must prevent a service from gaining network access while still allowing it to run normally. The engineer wants systemd to restrict network communication securely and automatically. Which systemd directive accomplishes this?
A) PrivateNetwork=true
B) ProtectSystem=full
C) PrivateTmp=true
D) ProtectKernelTunables=true
Answer:
A
Explanation:
The correct directive is PrivateNetwork=true because it isolates the service in its own network namespace. When this directive is enabled, the service cannot access the host network, cannot establish outbound connections, cannot accept inbound connections, and cannot see network interfaces beyond a loopback interface dedicated solely to that service. This provides strong network isolation without requiring external firewalls or network-level filtering.
Option B, ProtectSystem=full, makes portions of the filesystem read-only but does not restrict network access.
Option C, PrivateTmp=true, isolates the service’s temporary directory but does not affect networking.
Option D, ProtectKernelTunables=true, prevents modification of kernel parameters but has no effect on a service’s ability to use the network.
PrivateNetwork=true is used for:
services that should not communicate externally
preventing compromised services from spreading
compliance environments requiring strict isolation
reducing attack surface for background helpers
sandboxing risky applications
When enabled, systemd creates a new network namespace for the service with no external interfaces. The only interface available is a private loopback. This ensures that even if the process attempts to open sockets or bind ports, it cannot reach external systems.
Because PrivateNetwork=true is the required systemd directive for blocking all network access, option A is correct.
Question 175:
A Linux administrator needs to analyze why a high-priority real-time process is monopolizing CPU resources and starving other processes. The engineer wants to observe real-time scheduling metrics such as priority levels, policy types, and deadlines. Which command provides detailed information about process scheduling attributes?
A) ps -eo pid,pri
B) chrt -p PID
C) top
D) renice -n -5 PID
Answer:
B
Explanation:
The correct answer is chrt -p PID because chrt can display the real-time scheduling attributes for a running process, including scheduling policy, real-time priority, and deadline scheduling information if applicable. Real-time processes use scheduling policies such as SCHED_FIFO or SCHED_RR, which can cause starvation of normal processes if configured improperly.
Option A, ps -eo pid,pri, shows numeric priority values but does not reveal scheduling policy types or real-time attributes.
Option C, top, shows priority and niceness but cannot reveal the specific scheduling policy.
Option D, renice changes process niceness but cannot display scheduling details and does not interact with real-time classes.
Chrt reveals:
scheduling policy (FIFO, RR, OTHER, BATCH, IDLE, DEADLINE)
real-time priority value
whether deadlines are set
Real-time scheduling issues can cause:
system hangs
starvation
unresponsive applications
CPU lockups
Because chrt -p PID is the correct tool for viewing real-time scheduling information, option B is correct.
Question 176:
A Linux administrator must determine why a systemd service is taking an unusually long time to start. The engineer suspects the service is stuck waiting on a dependency that systemd considers “not ready.” Which systemd command shows detailed information about dependencies, ordering, waiting states, and the service startup chain?
A) systemctl status
B) systemd-analyze blame
C) systemd-analyze critical-chain
D) journalctl -u servicename
Answer:
C
Explanation:
The correct answer is systemd-analyze critical-chain because this command provides a visual and structured representation of the dependency tree that systemd follows during service startup. Unlike other systemd inspection commands, critical-chain shows exactly how long each unit took to start, which units delayed others, and what dependencies must finish before the target service can run. This capability makes systemd-analyze critical-chain the ideal tool for diagnosing services that are slow to start because of dependency ordering or waiting states, which are common issues in complex system environments.
Option A, systemctl status, provides general information about the service’s current state, logs, and recent activity. While this is useful for diagnosing failures or errors, it does not provide a dependency chain view or startup timing information. It cannot reveal which earlier unit caused a delay nor identify the precise stage where the service becomes blocked.
Option B, systemd-analyze blame, lists how long each unit took to start, but it does not show dependency relationships or waiting states. Although it helps identify slow-starting components, it cannot show whether a specific service was delayed because it waited for another unit to complete initialization. Blame is helpful for timing issues but not dependency tracing.
Option D, journalctl -u servicename, displays the logs for the service, but logs alone cannot show whether the service waited on another unit. Logs reveal internal activity but not systemd-level dependency sequencing. If the dependency is outside the service’s control, logs may show nothing unusual, leaving the root cause hidden.
Systemd-analyze critical-chain is unique because it shows the sequence of startup events with timestamps, delays, and relationships. This makes it possible to identify whether:
a network target took too long to reach readiness
a mount unit blocked startup
a device dependency was delayed
a systemd service was waiting on a timeout
a misconfigured After= or Requires= directive caused a stall
systemd was waiting to reach a specific target
In complex Linux systems, many services do not run independently. They depend on mount points, network connectivity, hardware initialization, or system-wide targets. If any dependency takes too long to start, all dependent services may be delayed. In some cases, a service may appear to be failing or freezing when, in reality, it is simply waiting for another component.
Common scenarios where critical-chain is essential include:
systems booting with slow hardware
cloud instances waiting for network configurations
servers depending on remote filesystems such as NFS
incorrectly configured dependencies in unit files
race conditions between systemd targets
slow DNS resolvers delaying networking targets
services waiting on udev device readiness
Critical-chain displays each delay at millisecond granularity, making it easy to pinpoint bottlenecks. For example, if network-online.target takes 25 seconds to become ready, the service relying on that target will also experience a 25-second delay. Without critical-chain, such delays can remain invisible.
The command is also useful in optimization efforts, allowing administrators to restructure dependencies or adjust unit file directives to improve boot performance.
Because systemd-analyze critical-chain is the only tool among the options that shows dependency ordering, waiting states, and startup timing in one complete view, option C is correct.
Question 177:
A Linux engineer must ensure that a systemd service runs inside a restricted environment where it cannot access kernel modules, block devices, or physical hardware interfaces. Which systemd directive provides this strong isolation by creating a new mount namespace and masking sensitive paths?
A) ProtectKernelModules=true
B) ProtectKernelLogs=true
C) ProtectControlGroups=true
D) ProtectSystem=strict
Answer:
D
Explanation:
The correct directive is ProtectSystem=strict because it provides the strongest filesystem isolation available through systemd’s security sandboxing features. ProtectSystem=strict makes the entire system filesystem read-only to the service except for explicitly allowed writeable paths. This includes directories such as /usr, /etc, and /boot, which are critical system locations. With this directive enabled, systemd remounts these directories as read-only within the service’s private mount namespace, preventing it from altering system files, accessing kernel modules, or interacting with privileged system paths.
Option A, ProtectKernelModules=true, prevents loading or unloading kernel modules, but does not restrict access to block devices or other sensitive areas.
Option B, ProtectKernelLogs=true, restricts access to kernel log buffers such as dmesg, but does not prevent filesystem access or hardware interaction.
Option C, ProtectControlGroups=true, prevents modification of cgroup settings but does not restrict broader system access.
ProtectSystem=strict is the most robust option because it applies a comprehensive set of restrictions. When enabled, it:
creates a separate mount namespace for the service
makes system directories read-only
masks sensitive paths so they appear inaccessible
ensures kernel-related directories cannot be written to
prevents access to devices unless explicitly allowed
isolates the environment in a manner similar to containers
This level of restriction helps prevent compromised or misbehaving services from:
overwriting system configuration files
accessing hardware directly
modifying kernel-related settings
writing to protected locations
altering bootloader files
reading sensitive system data
It effectively places the service in a controlled environment where only explicitly permitted paths are writable. Administrators can then use ReadWritePaths= to specify which directories are allowed. For example, a service might only need write access to /var/lib/appdata. Everything else remains protected.
This approach is widely used in:
security-sensitive services
network-facing daemons
sandboxed background tasks
microservices requiring minimal privileges
hardened servers
compliance-driven environments
ProtectSystem=strict is commonly combined with other directives:
ProtectHome=true
PrivateTmp=true
PrivateDevices=true
NoNewPrivileges=true
Together, these directives create an environment similar to a lightweight container without requiring container runtime tools.
Because ProtectSystem=strict offers the strongest built-in filesystem isolation that restricts hardware, kernel access, and system directories, option D is correct.
Question 178:
A Linux administrator must investigate why certain processes are causing excessive page faults, resulting in noticeable performance degradation. The administrator wants to see major and minor faults per process in real time. Which command should be used?
A) vmstat -s
B) ps -eo pid,maj_flt,min_flt,cmd
C) iotop
D) mpstat -P ALL
Answer:
B
Explanation:
The correct command is ps -eo pid,maj_flt,min_flt,cmd because this command lists per-process major and minor page faults. Page faults occur when a process tries to access memory not currently in physical RAM. Minor faults happen when the page exists in memory but not mapped to the process yet, while major faults occur when a page must be read from disk, causing significant delay.
Option A, vmstat -s, provides system-wide statistics but cannot show per-process page faults.
Option C, iotop, shows disk I/O operations but cannot identify whether those operations were caused by page faults or normal read patterns.
Option D, mpstat, provides per-CPU statistics but cannot show fault counts.
Ps with maj_flt and min_flt fields allows administrators to identify which processes are triggering excessive page faults. High numbers of major faults indicate that the process frequently waits for disk reads, which dramatically slows performance.
Common causes of high page faults include:
insufficient RAM
memory-intensive applications
memory leaks
inefficient caching
misbehaving software
excessive use of fork or exec
Administrators use ps output to locate problematic programs and then investigate memory usage, swapping, or application design issues.
Because ps -eo pid,maj_flt,min_flt,cmd provides per-process fault statistics, option B is correct.
Question 179:
A Linux engineer must analyze why the system is spending significant time handling hardware interrupts, causing elevated CPU utilization. Which command displays real-time interrupt statistics broken down by each IRQ line?
A) vmstat
B) mpstat -I CPU
C) iostat
D) top
Answer:
B
Explanation:
The correct answer is mpstat -I CPU because it displays interrupt statistics per CPU and per interrupt type. This includes hardware IRQs, software IRQs, and inter-processor interrupts. By breaking down interrupts at this level, mpstat helps administrators identify whether a specific device, driver, or network interface is generating excessive interrupts.
Option A, vmstat, shows total interrupts as a single number, not per IRQ line. It cannot diagnose which device is causing high interrupt rates.
Option C, iostat, focuses on block device I/O and does not provide interrupt-level details.
Option D, top, shows CPU usage but not interrupt breakdown.
Mpstat reveals:
hardware interrupt frequency per device
software interrupt behavior
CPU-level interrupt distribution
potential interrupt storms
imbalance in interrupt handling
This is essential when diagnosing:
faulty drivers
malfunctioning network cards
storage controller problems
excessive inter-processor signaling
uneven interrupt balancing
Because mpstat -I CPU is the only correct tool among these for detailed interrupt analysis, option B is correct.
Question 180:
A Linux administrator must investigate why a service is repeatedly failing after a short period of running. The engineer suspects resource constraints, but the logs alone are insufficient. Which systemd command displays the cumulative resource usage of a service, including CPU time, memory usage, tasks, and I/O statistics?
A) systemctl show servicename
B) systemctl status servicename
C) systemd-cgtop
D) systemd-run
Answer:
A
Explanation:
The correct answer is systemctl show servicename because this command displays detailed metadata and cumulative resource usage metrics for a systemd service. The output includes fields such as CPUUsageNSec, MemoryCurrent, TasksCurrent, and IOReadBytes. These metrics allow administrators to determine whether the service is exceeding resource thresholds, leaking memory, spawning too many threads, or suffering from high I/O latency.
Option B, systemctl status, provides basic logs and the current state but does not display cumulative resource usage.
Option C, systemd-cgtop, shows resource usage by cgroups but in a dynamic, top-style view. It does not target a single service and does not offer persistent cumulative values.
Option D, systemd-run, is used to launch transient services and does not display usage statistics.
Systemctl show gives deep insight into:
memory consumption trends
CPU time accumulated
I/O operations
task counts
cgroup-level resource enforcement
failure reasons tied to resource exhaustion
Administrators can correlate failures with resource spikes, identifying whether the service crashes due to:
exceeding MemoryMax
hitting TasksMax limits
CPU throttling
runaway threads
excessive I/O
Because systemctl show provides cumulative resource usage essential for diagnosing service failures, option A is correct.
