CompTIA XK0-005 Practice Test

The administrator did not set the default target to graphical.target.

Summary:
The administrator temporarily fixed the issue by using systemctl isolate graphical.target, which switched the current session to the graphical interface. The systemctl reboot command then restarted the system. However, because the change was not made permanent, the server reverted to its default boot target upon the next startup. The core issue is that the system's default target was not set to start the GUI environment automatically on boot.

Correct Option:

C. The administrator did not set the default target to graphical.target:
The systemctl isolate command only changes the active target for the current session; it is a temporary state. To make this change permanent across reboots, the administrator needed to run systemctl set-default graphical.target. This command creates a symlink from the default target to graphical.target, ensuring the system boots into the GUI environment every time.

Incorrect Options:

A. The administrator did not reboot the server properly:
The systemctl reboot command is a standard and proper way to restart a Linux system. The issue persisted after a full reboot cycle, confirming the reboot itself was not the problem.

B. The administrator did not set the default target to basic.target:
basic.target is a minimal system initialization target that serves as a foundation for other targets. Setting the default to basic.target would not enable the graphical user interface and is not the desired state for a system requiring a GUI.

D. The administrator did not shut down the server properly:
There is no indication of an improper shutdown. The issue is consistent and reproducible: the system consistently boots into a non-GUI terminal, which points directly to a misconfigured default boot target, not a filesystem or state error caused by a bad shutdown.

Reference:
systemd Official Documentation (systemctl): The official man page explains the set-default command for permanently changing the default target.

When an administrator decides to create one

Summary:
An SSH private key file can be encrypted with a passphrase for an additional layer of security. If this passphrase is weak and gets cracked, the user needs a way to change it to a stronger one without generating a whole new key pair. The tool used to create SSH keys also has the functionality to change the passphrase on an existing private key.

Correct Option:

C. ssh-keygen:
This is the correct command. The ssh-keygen tool, which is used to generate new SSH key pairs, can also change the passphrase of an existing private key. The command ssh-keygen -p -f /path/to/private_key will prompt the user for the old passphrase and then for a new, stronger one, thereby re-encrypting the private key file with the new password.

Incorrect Options:

A. passwd:
This command is used to change the login password of a user account on the Linux system. It has no effect on the passphrase of an SSH key file, which is a separate form of encryption on the key file itself.

B. ssh:
This command is used to initiate SSH connections to remote servers. It does not have a sub-command or functionality for managing or changing key passphrases.

D. pwgen:
This is a utility for generating random passwords. It can be used to create a strong password, but it cannot set that password on the SSH key file. The user would still need to use ssh-keygen to apply the newly generated password to the key.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 4.2: "Given a scenario, implement and configure Linux firewalls and access control options," which includes managing SSH and key-based authentication. Knowing how to use ssh-keygen to manage key passphrases is a fundamental security practice.

The filesystem is mounted with the wrong options.

Summary:
The task requires enabling IPv4 packet forwarding and making the change persistent across reboots. Packet forwarding is a kernel parameter controlled by the net.ipv4.ip_forward setting. The correct command must change this runtime parameter and ensure the change is written to the system's configuration so it survives a restart.

Correct Option:

B. sysctl -w net.ipv4.ip_forward=1:
This is the correct command. The sysctl command is used to modify kernel parameters at runtime. The -w flag writes the value. More importantly, to make it persistent, the administrator must also add net.ipv4.ip_forward = 1 to the /etc/sysctl.conf file or a file in /etc/sysctl.d/. The sysctl command itself is the standard tool for this task, and using it is the first step in the persistent configuration process.

Incorrect Options:

A. echo 1 > /proc/sys/net/ipv4/ip_forward:
This command will enable packet forwarding immediately by writing directly to the virtual file in /proc/sys/. However, this change is only temporary and will be lost after a system reboot. It does not accomplish the "persistent" requirement.

C. firewall-cmd --enable ipv4_forwarding:
This is not a valid firewall-cmd command. firewall-cmd is used to configure firewalld zones and rules, not to set core kernel networking parameters like IP forwarding. The correct flag for masquerading or forwarding in firewalld is different (--add-masquerade).

D. systemctl start ipv4_forwarding:
There is no systemd service called ipv4_forwarding. IP forwarding is a kernel parameter, not a service that can be started or stopped.

Reference: Linux man-pages project (sysctl): The official documentation explains how to use sysctl to configure kernel parameters.

ip addr add 10.0.6.5/24 dev enpls0f1

Summary:
The administrator's goal is to temporarily assign an IP address to a network interface. A temporary assignment is one that is effective only for the current session and will be lost upon a system reboot. This requires using a command that makes a runtime change to the network interface's configuration without writing the change to a persistent configuration file.

Correct Option:

A. ip addr add 10.0.6.5/24 dev enp1s0f1:
This is the correct command. The ip addr add command from the iproute2 toolkit is the modern standard for making runtime changes to network interfaces. It immediately assigns the IP address 10.0.6.5/24 to the interface enp1s0f1 without saving the configuration to disk. This change is purely temporary and meets the requirement exactly.

Incorrect Options:

B. echo "IPV4_ADDRESS=10.0.6.5/24" > /etc/sysconfig/network-scripts/ifcfg-enplsOfl:
This command writes the IP address to a persistent configuration file. Any change made by writing to a file in /etc/sysconfig/network-scripts/ will not take effect immediately and will persist after a reboot. The administrator would need to run a separate command like ifup or restart NetworkManager to apply it, which contradicts the "temporary" requirement.

C. ifconfig 10.0.6.5/24 enpsIs0f1:
The ifconfig command is considered deprecated and its syntax is often incorrect for modern use. The standard syntax for a temporary assignment with the older ifconfig would be ifconfig enp1s0f1 10.0.6.5 netmask 255.255.255.0. Even if syntactically corrected, ip addr is the tool recommended for new scripts and configurations.

D. nmcli conn add ipv4.address-10.0.6.5/24 ifname enpls0f1:
This nmcli command has a syntax error (it should be ipv4.addresses, not ipv4.address-). More importantly, nmcli conn add creates a new persistent connection profile in NetworkManager. This profile is saved to disk and will be active across reboots, which is the opposite of a temporary assignment.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 4.1: "Given a scenario, configure and manage networking and storage," which includes using command-line utilities to configure network interfaces. Knowing the difference between temporary (ip addr) and persistent (nmcli, config files) configuration methods is a key skill.

sudo useradd -e 2021-09-30 Project_user

Summary:
The administrator needs to create a user account with a specific expiration date, after which the account will be automatically disabled and unable to log in. The useradd command is used for this purpose, and it has a specific option to set an account expiration date. The correct command must use this option with the specified date in the correct format.

Correct Option:

A. sudo useradd -e 2021-09-30 Project_user:
This is the correct command. The -e (expire) flag is used to set the account expiration date. The date must be in the format YYYY-MM-DD. After 2021-09-30, the Project_user account will be locked and inaccessible.

Incorrect Options:

B. sudo useradd -c 2021-09-30 Project_user:
The -c flag is used to set a comment, typically the user's full name or a description. It does not set an expiration date.

C. sudo modinfo -F 2021-09-30 Project_uses:
The modinfo command is used to display information about kernel modules and is completely unrelated to user account management. The syntax is also incorrect.

D. sudo useradd -m -d 2021-09-30 Project_user:
The -d flag is used to specify the user's home directory path. The -m flag tells useradd to create the home directory. This command would incorrectly try to use the date string as a directory path.

Reference:
Linux man-pages project (useradd): The official documentation explains the -e option for setting the account expiration date.

podman run -d -p 443:8443 httpd

Summary:
The task requires mapping a container's internal port to a different port on the host. The -p (publish) flag in Podman/Docker is used for this purpose. The syntax is -p :. The container's internal application (httpd) is configured to listen on port 8443, and this needs to be accessible via port 443 on the host machine.

Correct Option:

A. podman run -d -p 443:8443 httpd: This command is correctly structured.
-d runs the container in detached (background) mode.

-p 443:8443 correctly maps host port 443 to the container's internal port 8443.

httpd is the image name.

This allows users to connect to https://hostname (port 443) and have the traffic routed to the web server inside the container on port 8443.

Incorrect Options:

B. podman run -d -p 8443:443 httpd:
This command has the port mapping reversed. It maps host port 8443 to the container's port 443. This would mean the service inside the container would need to be listening on port 443, and users would have to connect to the host on port 8443, which does not meet the requirement.

C. podman run –d -e 443:8443 httpd:
The -e flag is used to set environment variables inside the container, not to publish ports. This syntax is invalid for port mapping and the command will not work as intended. The long double-dash before d is also a typo.

D. podman exec -p 8443:443 httpd:
The podman exec command is used to run a command inside an already running container. It is not used to create and start a new container, and it does not support the -p flag for port publishing.

Reference:
Podman Documentation (podman-run): The official documentation explains the -p flag for publishing container ports to the host.

The application is listening on the loopback interface.

Summary:
Users cannot connect to an application that should be listening on port 9443. The netstat output shows that a process is indeed listening on port 9443, but the "Local Address" column reveals it is bound to 127.0.0.1:9443. The IP address 127.0.0.1 is the loopback interface, which is only accessible from the server itself. This configuration prevents any remote connections from other machines on the network.

Correct Option:

B. The application is listening on the loopback interface:
This is the direct cause of the issue. The application is bound to 127.0.0.1 (localhost), which restricts connections to the local machine only. For the application to be reachable from other hosts, it needs to be bound to the server's external IP address or to 0.0.0.0 (which means all interfaces).

Incorrect Options:

A. The IP address 0.0.0.0 is not valid:
The address 0.0.0.0 is valid and has a specific meaning; it indicates that a service is listening on all available network interfaces. The problem is that the service is not using 0.0.0.0.

C. The application is listening on port 1234:
The netstat output shows a process listening on port 1234, but this is unrelated to the application in question, which is specified to use port 9443. The application on port 9443 is running, but on the wrong interface.

D. The application is not running:
The netstat output proves the application is running and listening on port 9443. The issue is its network binding, not its execution state.

Reference:
Linux man-pages project (netstat): The official documentation explains the output, including the meaning of the Local Address column.

Interrupt the boot process in the GRUB menu and add systemd.unit=rescue.target in the kernel line.

Interrupt the boot process in the GRUB menu and add systemd.unit=single.target in the kernel line.

Summary:
The system is failing to start due to issues with critical processes, and the administrator needs to boot into a minimal, single-user environment for troubleshooting. This mode provides a root shell with a minimal set of started services, allowing for repair operations. On modern systems using systemd, this is achieved by specifying a specific target at the bootloader.

Correct Options:

C. Interrupt the boot process in the GRUB menu and add systemd.unit=rescue.target in the kernel line:
This boots the system into the rescue target. It is a more basic state than multi-user, mounting the root filesystem read-only and starting only a few essential services, providing a single-user root shell for emergency repair.

F. Interrupt the boot process in the GRUB menu and add systemd.unit=single.target in the kernel line:
This is the direct systemd equivalent of traditional single-user mode. It starts the system with a minimal set of services and provides a root shell, which is ideal for system recovery when multi-user boot fails.

Incorrect Options:

A. Execute the following command from the GRUB rescue shell: mount -o remount,ro /sysroot:
This command is used after booting into a rescue environment to remount the root filesystem as read-only. It is not a method to boot into single-user mode.

B. Interrupt the boot process in the GRUB menu and add systemd.unit=single in the kernel line:
The correct target name is single.target, not just single. This syntax is incomplete and would not work.

D. Interrupt the boot process in the GRUB menu and add single=user in the kernel line:
This is an older SysVinit-style parameter. While some systems might translate it for compatibility, the correct and modern method for systemd systems is to use the systemd.unit= syntax.

E. Interrupt the boot process in the GRUB menu and add init=/bin/bash in the kernel line:
This tells the kernel to run /bin/bash as the first process (init) instead of systemd. This bypasses the entire init system, which can be useful but is more drastic and may not properly set up the environment (like virtual consoles) compared to the rescue or single targets.

Reference:
systemd Official Documentation (systemd.target): The official man page describes the special targets, including rescue.target and single.target.

Two default routes are configured.

Summary:
The server is experiencing intermittent connectivity, where some connections work and others fail. The provided network configuration shows two default gateways (0.0.0.0) configured on the same network interface, ens3. A default gateway is the path a server uses to reach networks it is not directly connected to, and having two defined on the same interface causes a routing conflict, leading to unpredictable packet routing and the described intermittent failures.

Correct Option:

C. Two default routes are configured.:
This is the most likely cause. A system should typically have only one default route to avoid ambiguity. With two default routes via different gateways (172.16.0.1 and 172.16.0.2) on the same interface, the kernel's routing logic may send some packets out one path and others out the second path. If one of these gateways is incorrect or has limited external access, it results in the observed intermittent connectivity.

Incorrect Options:

A. An internal-only DNS server is configured.:
While the DNS server 172.16.0.10 is likely internal, this would not cause intermittent connectivity. A misconfigured DNS would cause consistent failures in name resolution, but IP-based connections (like pinging an external IP) would still work. The problem described is more fundamental network reachability.

B. The IP netmask is wrong for ens3.:
The netmask of 255.255.0.0 (/16) is correct for the IP address 172.16.0.10, as both gateways (172.16.0.1 and 172.16.0.2) are within the same 172.16.0.0/16 network. An incorrect netmask would typically cause a complete failure to communicate with the gateway, not an intermittent issue.

D. The ARP table contains incorrect entries.:
The ARP table maps IP addresses to MAC addresses on the local network. While incorrect ARP entries can cause connectivity problems, they are usually transient and localized to specific hosts on the same subnet. A corrupted ARP table is less likely to be the root cause of a systemic, intermittent Internet connectivity issue compared to a fundamental routing misconfiguration like duplicate default gateways.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 4.1: "Given a scenario, analyze and troubleshoot network connectivity issues," which includes troubleshooting and configuring routing and routing tables. Understanding that a host should not have multiple default routes is a key troubleshooting concept.

docker images prune -a

Summary:
The task is to clean up unused Docker images, specifically "dangling" images. These are layers that have no relationship to any tagged images, often created during the build process. The correct command must use the docker image prune subcommand, which is specifically designed for this type of cleanup, and the -a flag is needed to remove all unused images, not just dangling ones.

Correct Option:

A. docker image prune -a:
This is the correct and standard command. The prune subcommand is used to remove unused data. docker image prune by itself removes only dangling images. Adding the -a (or --all) flag instructs it to remove all images that are not used by any container, which includes both dangling and other unused images.

Incorrect Options:

B. docker push images -a:
The docker push command is used to upload a local image to a registry. It is completely unrelated to the task of deleting local images. The syntax is also incorrect.

C. docker rmi -a images:
The docker rmi command is used to remove one or more specific images by their ID or name. The -a flag is not a valid option for docker rmi. The correct flag to remove all images would be docker rmi $(docker images -q), but this is a more dangerous, non-standard approach.

D. docker images rmi --all:
This command mixes the docker images (which lists images) and docker rmi (which removes them) commands. The syntax is invalid and will not work. The --all flag is also not a valid option for docker rmi.

Reference:
Docker Documentation (docker image prune): The official documentation explains the purpose and flags of the prune command.