CompTIA XK0-006 Practice Test 2026

Explanation:

The provided command outputs indicate a failure in the Domain Name System (DNS) resolution process, which prevents the system from finding the IP address of the third-party API.

curl Analysis:
The output
curl: (6) Could not resolve host: comptia.com
shows that the application cannot proceed because it doesn't know where to send the data.

dig Analysis:
Status: NXDOMAIN — "Non-Existent Domain." The DNS server explicitly states it cannot find a record for the requested name.
ANSWER: 0 → No valid IP address was returned for the query.
Server Information: The system is querying an internal IP address, 10.255.255.254. This local nameserver is failing to provide public internet records.

The Action:
The DNS client configuration file in Linux is typically /etc/resolv.conf.
Reviewing and fixing this file — by adding a valid nameserver such as 8.8.8.8 — will allow the system to correctly resolve the API endpoint.

Explanation of Incorrect Answers

Open a secure port in the server's firewall:
Firewall issues usually result in "Connection Timed Out" or "Connection Refused" errors.
Because the error here is "Could not resolve host," the system hasn't even reached the stage where a firewall would block a port. It cannot connect without an IP address.

Request a new API endpoint from a third party:
The dig output shows the system is querying comptia.com, which is a valid domain.
The endpoint itself is likely fine. The problem lies with the local server's inability to resolve the domain.

Enable internet connectivity on the host:
The system is successfully communicating with its local DNS server at 10.255.255.254 (as evidenced by the dig response).
While general internet access might be required for the API call, the specific error here is DNS resolution, which must be fixed in /etc/resolv.conf first.

Reference:
CompTIA Exam Objective: Domain 5.0 (Troubleshooting) – Subsection 5.3: Analyze and troubleshoot network-related issues (DNS and Name Resolution).
Reference: Linux Man Pages (man resolv.conf, man dig); Official CompTIA Linux+ Study Guide, Chapter on Network Troubleshooting.

Explanation:
The wget error messages indicate that the certificate presented by api.newapp.comptia.org is not trusted because its issuer is not recognized by the local system. The best solution is to verify that the remote certificate is valid (signed by a legitimate CA) and then add that CA certificate to the local trusted certificate store.

Correct Option:

A. Verify the remote certificate is trustworthy, and add it to the local trusted certificates repository.
The error "not trusted" and "does not have a known issuer" means the local system lacks the root or intermediate CA certificate that signed the remote server's certificate. After verifying the certificate's chain (confirming it is not malicious), the administrator should add the appropriate CA certificate to the system's trust store (e.g., /etc/pki/ca-trust/source/anchors/ on RHEL, or /usr/local/share/ca-certificates/ on Debian) and update the trust store. This resolves the error permanently without bypassing security.

Incorrect Options:

B. Replace the remote certificate with a new self-signed CA and application certificate –
Replacing the remote certificate would affect all users, not just this server. A self-signed certificate would still be untrusted by default unless its CA is added locally. This is not the best solution.

C. Replace the expired CA certificate to permanently resolve the problem –
The error does not mention certificate expiration; it mentions issuer trust. The certificate may not be expired at all. This assumes an expiration issue that is not indicated.

D. Add option --no-check-certificate to wget command to permanently resolve the problem –
Using --no-check-certificate disables certificate validation entirely, exposing the system to man‑in‑the‑middle attacks. It is a temporary workaround, not a permanent resolution, and does not fix the root cause.

Reference:
man wget – --no-check-certificate option (insecure, not recommended for permanent use)
Red Hat / Debian documentation – Adding custom CA certificates to system trust store
IETF RFC 5280 – Certificate path validation (trust anchors)

Explanation:

Why this is the most likely cause
The log shows an SELinux AVC denial:

- comm="sshd" and scontext=system_u:system_r:sshd_t:... → the sshd process is trying to read the key file.
- name="authorized_keys" → the file sshd is trying to read.
- tcontext=unconfined_u:object_r:home_root_t:s0 → the target file is labeled home_root_t, which is not the expected SELinux type for SSH authorized keys.

The system is in enforcing mode, so SELinux will block the read.
So even if the file permissions are correct, sshd can’t read it because SELinux denies access based on the file label/type → SSH key auth fails and it falls back to password prompting.

Why the other options are not best

- Incorrectly targeting the unconfined_u context: unconfined_u here is the SELinux user part of the label; the critical mismatch is the type (home_root_t), not “targeting unconfined_u.”
- Forgot to restart sshd: sshd does not require a restart to read authorized_keys—it reads it on login attempts.
- Incorrect root permissions: The file shows -rw------- owned by root:root, which is typically acceptable; the denial is explicitly from SELinux, not UNIX permissions.

Typical fix (what an admin would do)

Restore the proper SELinux context, e.g.:
restorecon -Rv /root/.ssh

(or wherever the authorized_keys file lives), ensuring it gets the expected SSH-related SELinux type (commonly ssh_home_t on SELinux systems).

Explanation:

The system is experiencing a CPU bottleneck, which is preventing the application from completing tasks on time. We can determine this by looking at three key metrics in the output:

Load Average vs. Core Count:
The uptime command shows a 1-minute load average of 7.75. However, the nproc command shows the system only has 4 CPU cores. In Linux, a load average significantly higher than the number of cores (7.75 > 4) indicates that processes are queuing and waiting for CPU time.

Process Queue (vmstat):
Looking at the vmstat -w 1 3 output, the 'r' column (runnable processes) shows a value of 8. This means there are 8 processes either running or waiting for a CPU cycle. With only 4 cores, at least 4 processes are constantly stalled in the queue.

CPU Utilization (vmstat):
The us (user) column is at 100, and id (idle) is at 0. This confirms the CPUs are fully saturated by user-space applications with zero idle time available.

Increasing CPU resources (adding more vCPUs or upgrading the processor) is the only way to resolve a queue of 8 processes competing for 4 cores.

Explanation of Incorrect Answers

Increase the amount of free memory available to the system:
The free -h output shows that the system has 3.5Gi available out of 3.8Gi total. The system is barely using RAM (only 334Mi used). Adding more memory will not help because the current memory is not being fully utilized.

Increase the amount of swap space available to the system:
The free -h output shows that swap usage is negligible (65Mi used out of 7.8Gi). Furthermore, the vmstat output shows 0 in the si (swap in) and so (swap out) columns, proving there is no memory pressure or swapping activity causing the slowdown.

Increase the amount of disks available to the system:
In the vmstat output, the bi (blocks in) and bo (blocks out) columns are 0, and the wa (I/O wait) column is also 0. This indicates that the system is not waiting on disk operations; the bottleneck is purely CPU-related.

Reference
CompTIA Exam Objective: Domain 5.0 (Troubleshooting) – Subsection 5.2: "Troubleshoot system-related issues" (focusing on CPU, memory, and I/O performance monitoring).
Reference: The Linux Command Line (William Shotts), Chapter 10: Processes; and Official CompTIA Linux+ Study Guide, Chapter on Performance Monitoring and Tuning.

Explanation:

The administrator updated the authoritative zone file for abc.com on the BIND server (at 192.168.40.251, which is also the DNS server used in the nslookup output). However, when querying www.abc.com, the response still shows the old IP (199.168.20.81) as a non-authoritative answer.
This indicates the issue is not with the authoritative server (BIND would serve the updated record immediately after reload/restart or rndc reload), but with caching on the client machine where the query is run.
The client is using a local caching resolver (likely systemd-resolved, common on modern Linux distros like Ubuntu 18.04+, Debian 10+, Fedora, etc.), which caches DNS responses to improve performance. The old record is stuck in this local DNS cache.

systemd-resolve query www.abc.com: Incorrect.
This performs a DNS lookup using systemd-resolved (similar to dig or nslookup), but it does not flush or clear the cache. It would still return the cached (old) answer.

systemd-resolve status: Incorrect.
This shows the current configuration of systemd-resolved (per-interface DNS servers, search domains, etc.), but does not affect or flush the cache.

service nslcd reload: Incorrect.
nslcd is the daemon for NSS LDAP (Name Service Switch LDAP), used for authenticating users/groups via LDAP/AD — not for DNS resolution or caching. Reloading it has no effect on DNS.

resolvectl flush-caches: Correct.
resolvectl is the modern client tool for interacting with systemd-resolved (introduced around systemd v239+; the preferred command on current systems).
flush-caches clears the DNS cache maintained by systemd-resolved.
After running this (usually with sudo), subsequent queries (e.g., nslookup, dig, or browser) will go to the authoritative server again and retrieve the updated IP (192.168.30.30).

Note on older systems:
In systemd versions before ~239 (e.g., older Ubuntu 16.04/18.04 setups), the equivalent was systemd-resolve --flush-caches. On modern distributions (2020+), resolvectl flush-caches is the standard and correct command.

Explanation:
The output shows 96% packet loss and significant error counters (RX: errors 400000, TX: errors 150000) on the network interface. High error counts at the interface level indicate hardware problems (failing NIC, bad cable, faulty switch port). The gateway and route are correctly configured, so the NIC itself is the likely culprit.

Correct Option:

B. Replace the NIC
The ip -s link show output displays thousands of receive (RX) and transmit (TX) errors. Such high error rates at the physical interface level typically indicate defective hardware (NIC), damaged cable, or a faulty switch port. After ruling out cable/port issues, replacing the NIC is the appropriate resolution. The severe packet loss (96%) and error counts are consistent with hardware failure.

Incorrect Options:

A. Assign a proper gateway –
The ip route output shows a default gateway (192.168.1.1) is already assigned. Ping reaches the gateway (4 responses out of 100), so gateway assignment is correct. The issue is not routing.

C. Increase the ping's TTL –
Time To Live (TTL) affects routing loops and hop limits, not link-level errors or packet loss. The ping reaches the gateway (responses received), so TTL is sufficient. Increasing TTL will not fix RX/TX errors.

D. Increase the MTU size –
MTU mismatches can cause fragmentation or packet loss, but they do not produce the massive interface error counters shown (errors 400000). MTU issues typically show as "frag needed" or ICMP errors, not raw RX/TX error increments.

Reference:
man ip – link show error counters explanation
Linux networking troubleshooting – High RX/TX errors indicate hardware issues
IEEE 802.3 – Ethernet error conditions (CRC errors, frame alignment errors)

Explanation:

OpenSCAP (Open Security Content Automation Protocol) is a framework designed specifically for:

✅ Security compliance automation
✅ Vulnerability assessment
✅ Configuration auditing
✅ Policy enforcement
✅ Automated security scanning against standards

It uses standardized security content such as:

SCAP
CVE (Common Vulnerabilities and Exposures)
OVAL definitions
CIS benchmarks
DISA STIG profiles

Example Usage:
oscap xccdf eval --profile stig /usr/share/xml/scap/...xml
This command scans a system and automatically reports compliance status.

Why the Other Options Are Incorrect

❌ SELinux
Mandatory Access Control (MAC) system.
Enforces runtime security policies.
Does not perform compliance scanning or vulnerability management.

❌ Nmap
Network scanner.
Used for port scanning and service discovery.
Not a compliance automation tool.

❌ AIDE
Advanced Intrusion Detection Environment.
File integrity checker that detects file changes.
Does not manage vulnerabilities or compliance policies.

Linux+ XK0-006 Exam Tip

Memorize this mapping:

Tool → Purpose
SELinux → Access control enforcement
Nmap → Network scanning
AIDE → File integrity monitoring
OpenSCAP → Compliance and vulnerability automation

Exam Keyword Trigger:
If you see automation, compliance, and vulnerability management together, think OpenSCAP immediately.

Explanation:

The renice command allows an administrator to alter the scheduling priority of an already running process.

The Concept of "Niceness": In Linux, process priority is represented by a "nice" value, ranging from -20 (highest priority) to 19 (lowest priority).

Alleviating CPU Contention: By increasing the nice value of the CPU-heavy maintenance task (e.g., changing it from 0 to 10), the administrator tells the kernel's scheduler to give that task less CPU time when other processes need it.

Impact on Other Apps: This effectively "lowers the priority" of the maintenance task, allowing the other applications to receive the CPU cycles they need to remain responsive.

Explanation of Incorrect Answers

Increase the available CPU time with pidstat:
pidstat is a monitoring tool used to report statistics for Linux tasks (CPU, memory, I/O).
It is used for observation and diagnosis, not for modifying process behavior or increasing CPU allocation.

Run the maintenance task with nohup:
nohup (no hangup) is used to run a command so that it continues running even after the user logs out.
It does not affect CPU usage or process priority; its only purpose is to ignore the SIGHUP signal.

Execute the other applications with the bg utility:
The bg (background) utility is used to resume a suspended job in the background.
Moving a process to the background does not change its priority or CPU consumption; it simply frees up the terminal's foreground for other commands.

Reference
CompTIA Exam Objective: Domain 1.0 (System Management) – Subsection 1.1: "Summarize and utilize Linux command line tools" and Domain 5.0 (Troubleshooting) – Subsection 5.1: "Analyze and troubleshoot system-level issues" (specifically Process Management).
Reference: Linux Man Pages (man renice, man nice); Official CompTIA Linux+ Study Guide, Chapter on Process and Resource Management.

Explanation:
The top output shows a high load average (2.43) and 154 zombie processes. The iostat -m output shows %iowait = 70.38%, indicating that the CPU is spending the majority of its time waiting for I/O operations (disk reads/writes) to complete. High I/O wait explains both the system slowness and high load average.

Correct Option:

C. The storage I/O latency is high.
%iowait (from iostat) represents the percentage of time the CPU was idle while waiting for pending disk I/O to complete. A value of 70.38% means the system is severely bottlenecked by storage performance. High I/O wait leads to high load averages and slow responsiveness because processes are blocked waiting for disk operations (e.g., reads, writes, swapping).

Incorrect Options:

A. The system ran out of swap space –
The output shows no swap-related metrics. Running out of swap typically causes OOM kills, not high I/O wait. Even if swapping, %iowait might increase, but the primary indicator is swap usage, which is not shown here.

B. The CPU is overutilized –
CPU user + system = 6.2 + 5.1 = 11.3% in the first output, and 4.30 + 2.02 + 0.29 = 6.61% in iostat. CPU idle is 79.2% and 19.01%. CPU is not overutilized; it is waiting for I/O.

D. The system needs to be patched –
No kernel version, security patch, or update information is provided. There is no evidence that patching would resolve high I/O wait, which is typically a storage performance or application pattern issue.

Reference:
man iostat – %iowait interpretation
man top – Load average and zombie processes
Linux performance tuning – High I/O wait troubleshooting

Explanation:

Password complexity is determined by the variety of character types and the length of the string. In professional certifications like CompTIA Linux+, a "complex" password is traditionally defined as one that combines all four major character categories: uppercase letters, lowercase letters, numbers, and special characters (symbols).

H3s@1dSh3t0|d (Choice C):
This is the most complex because it uses:
Uppercase letters: H, S
Lowercase letters: s, d, h, t, d
Numbers: 3, 1, 0
Special characters: @, | (pipe)
Length: 13 characters

he$@ID$heTold (Choice B):
While it has symbols and letters, it lacks any numbers.

H3sa1dt01d (Choice A):
Uses uppercase, lowercase, and numbers, but lacks any special characters (symbols).

HeSaidShetold (Choice D):
A simple combination of uppercase and lowercase letters, lacking both numbers and special characters.

Key Complexity Rules:
According to standard exam objectives, a strong password should follow the "8 and 4" rule: a minimum of 8 characters and at least one from each of the 4 categories (Upper, Lower, Number, Symbol). Choice C is the only one that meets all four criteria while also maintaining a robust length.