CompTIA XK0-006 - Questions & Answers

The lsscsi command is used to list information about SCSI devices (including storage arrays) that are attached to the system. This is critical when integrating a new storage array because it allows the administrator to verify that the operating system detects the new device at the SCSI layer, which is the underlying interface for most enterprise storage solutions. lsscsi outputs a list of recognized SCSI devices, their device nodes, and associated information.

Other options:

B. lsusb: Lists USB devices, not storage arrays on SCSI/SATA/SAS.

C. lsipc: Displays information on IPC (inter-process communication) facilities, unrelated to hardware
detection.

D. lshw: Lists hardware details and can show storage, but lsscsi is specifically designed for SCSI device
detection and is the most direct method for this task.

References:
CompTIA Linux+ Study Guide: Exam XK0-006, Sybex, Chapter 7: "Managing Storage", Section:"Identifying
and Accessing Storage Devices"
CompTIA Linux+ XK0-006 Objectives: Domain 4.0 - Storage and Filesystems

Process scheduling and resource management are essential Linux administration skills covered in Linux+
V8. When a process consumes excessive CPU resources, it can negatively impact overall system performance.

The correct solution is to lower the priority of the CPU-intensive task using the renice command. Niceness values influence how much CPU time a process receives relative to others. Increasing the niceness value reduces the process's priority, allowing other applications to receive CPU resources more fairly.

Option B directly addresses the issue. The other options do not. pidstat monitors processes but does not modify CPU allocation. nohup allows a process to continue running after logout but does not affect scheduling priority. bg resumes a stopped job in the background but does not reduce CPU usage.

Linux+ V8 documentation explicitly references nice and renice for managing CPU contention.

The SSH configuration option PermitRootLogin prohibit-password prevents the root user from logging in with password authentication. This setting means root cannot use a password to log in via SSH; only key-
based authentication is permitted for root. The administrator can still log in as root locally, which is not affected by this SSH configuration. To allow SSH access as root, the administrator must use an SSH key instead of a password.

Other options:

A. MaxSessions controls the number of simultaneous SSH sessions but is not causing the login denial
here.

B. PAM (Pluggable Authentication Modules) is disabled, but enabling it is not required for basic SSH
authentication.

C. Changing the SSH port is unrelated to the authentication method issue.

References:
CompTIA Linux+ Study Guide: Exam XK0-006, Sybex, Chapter 11: "Securing Linux", Section: "Securing
SSH Access"
CompTIA Linux+ XK0-006 Objectives, Domain 3.0: Security

Directory services are a key part of enterprise Linux environments and are covered under the Security domain in Linux+ V8. The Lightweight Directory Access Protocol (LDAP) is specifically designed to access and manage distributed directory information.

LDAP directories store structured, hierarchical data such as users, groups, computers, and organizational units. Linux systems commonly use LDAP for centralized authentication, authorization, and identity management. LDAP is also the foundation for services like Active Directory and FreeIPA.

The other options are incorrect. SMB is a file and printer sharing protocol. TLS is an encryption protocol used to secure communications. Kerberos (KRB-5) is an authentication protocol often used alongside LDAP but does not store directory information itself.

Linux+ V8 documentation highlights LDAP as the primary protocol for directory-based identity services.

This scenario is a classic performance troubleshooting case covered under the Troubleshooting domain of the CompTIA Linux+ V8 objectives. The key indicators to analyze are the load average values and the
CPU utilization statistics .

The uptime command shows load averages of 8.71, 8.24, and 7.71 over the 1-, 5-, and 15-minute intervals. Load average represents the average number of processes that are either running on the CPU or waiting to run. On a system with 4 CPU cores , a healthy load average would typically be close to or below 4. Load averages consistently near or above 8 indicate that there are significantly more runnable processes than available CPU resources, causing processes to wait and resulting in poor system responsiveness.

The CPU output further confirms this condition. The %idle value is , meaning the CPU has no idle time 0 available. The majority of CPU time is spent in user space (65.88%) and system/kernel space (20.54%) , indicating heavy computational and kernel activity. While %iowait is present at 5.65%, it is not high enough to suggest that disk I/O is the primary bottleneck.

Option C , high CPU load, best explains the symptoms. High CPU load causes commands to execute slowly because processes are competing for limited CPU time. This directly matches the observed behavior of the system being unresponsive.

The other options are incorrect. High uptime simply indicates how long the system has been running and does not cause performance issues by itself. High latency is a general term and not a specific diagnosis shown by the metrics provided. High I/O wait times would require a significantly higher %iowait value.

According to Linux+ V8 documentation, correlating load averages with CPU core count and utilization is essential for accurate performance diagnosis.

This scenario represents a name resolution failure , which is a common troubleshooting case addressed in CompTIA Linux+ V8. The critical clues are the error messages returned by both curl and dig.

The curl error "Could not resolve host" indicates that the system is unable to translate the hostname into an IP address. This is confirmed by the dig output, which returns NXDOMAIN , meaning the DNS resolver cannot resolve the requested domain name. Importantly, the dig output shows that the query is reaching a DNS server (10.255.255.254), but the resolution fails, strongly pointing to a DNS client configuration issue .

Option C , reviewing and fixing the DNS client configuration file (such as /etc/resolv.conf or systemd-resolved settings), is the correct action. Linux+ V8 documentation highlights DNS misconfiguration as a primary cause of application connectivity issues. Incorrect nameserver entries, unreachable DNS servers, or misconfigured resolvers commonly produce NXDOMAIN responses.

The other options are incorrect. Firewall issues would result in connection timeouts, not DNS resolution failures. Requesting a new API endpoint is unnecessary without first confirming local DNS functionality.
Internet connectivity issues would typically prevent any DNS communication, but here a DNS server is clearly being contacted.
Linux+ V8 stresses a layered troubleshooting approach: verify DNS resolution before investigating network ports or application logic.

Firewall configuration is a key topic in the Security domain of CompTIA Linux+ V8. DNS primarily uses UDP port 53, but TCP port 53 is also required for zone transfers, large responses, and certain reliability scenarios. In this case, the administrator explicitly needs to allow DNS over TCP from a specific network.

The correct command is ufw allow 53/tcp from 10.0.0.0/24. This rule allows incoming TCP traffic on port 53 only from the specified subnet, following the principle of least privilege . Linux+ V8 documentation emphasizes restricting firewall rules by source network whenever possible to minimize attack surfaces.

Option A is incorrect because UFW service aliases like dns are not always guaranteed to map explicitly to TCP, and the syntax is incomplete.
Option B is invalid because ufw enable is used to enable the firewall globally and does not define rules.
Option D disables firewall protections and introduces a major security risk.

Linux+ V8 best practices stress precise, minimal firewall rules instead of broad or disabling actions.

The initial troubleshooting step when experiencing slow performance and potential memory or CPU issues is to analyze the current resource usage. Running tools like top or htop allows the administrator to observe real-time data on CPU, memory, and processes, providing insights into high resource usage. This is a non-invasive first step, helping to identify whether issues are due to overuse, application memory leaks, or specific processes. CompTIA Linux+ recommends understanding system resource behavior before taking
further action.
References:
CompTIA Linux+ Study Guide.

In Docker, a Dockerfile is a script that contains instructions to build a container image. The first line in a Dockerfile is typically the FROM directive, which specifies the base image from which the container will be built. The correct syntax for specifying a base image is:rubyCopyEditFROM <image>:<tag>If no tag is
provided, Docker will pull the latest version of the specified image by default. httpd is the official Apache HTTP Server image available in Docker Hub.
The incorrect options:
Thus, the correct answer is A. FROM httpd.