CompTIA XK0-005 Practice Test

ssh-copy-id user@server

Summary:
The user needs to transfer the public key to a remote server and place it in the correct file with the correct permissions to enable passwordless SSH login. This involves copying the ~/.ssh/id_rsa.pub (or similar) file to the remote server and appending it to the ~/.ssh/authorized_keys file in the user's home directory. The process must also ensure the remote .ssh directory and authorized_keys file have secure permissions.

Correct Option:

D. ssh-copy-id user@server:
This is the dedicated, safe, and correct command for this task. It automatically copies the default public key (~/.ssh/id_rsa.pub) to the specified server and user account. It handles creating the ~/.ssh directory and the authorized_keys file on the remote server with the proper permissions (700 for the directory and 600 for the file), eliminating manual steps and potential errors.

Incorrect Options:

A. scp ~/.ssh/id_rsa user@server:~/:
This command copies the private key (id_rsa) to the remote server. The private key should never be shared or transmitted. It must remain secure on the local workstation. This action is a severe security mistake.

B. rsync ~/.ssh/ user@server:~/:
This command would attempt to sync the entire local ~/.ssh directory, including the private key, to the remote server's home directory. This is incorrect and insecure for the same reason as option A. It also does not correctly place the public key into the authorized_keys file.

C. ssh-add user server:
The ssh-add command is used to add private keys to the SSH authentication agent, which manages keys for convenience (so you don't have to type the passphrase repeatedly). It does not copy keys to remote servers.

Reference:
OpenSSH Manual (ssh-copy-id): The official documentation explains that ssh-copy-id is used to install your public key in a remote machine's authorized_keys.

flrewall-cmd --zone-public --add-port-53/udp --permanent

Summary:
A DNS forwarder needs to accept incoming queries from internal servers on the standard DNS port (UDP 53). The requirement is to modify the firewall to allow this traffic and, critically, to make the change persistent across reboots. The solution must use a command that both opens the correct port and saves the rule to the permanent configuration.

Correct Option:

D. firewall-cmd --zone=public --add-port=53/udp --permanent:
This is the correct command. It uses firewalld, the default dynamic firewall manager on many modern Linux distributions. The --add-port=53/udp specifically opens port 53 for UDP traffic, which is the standard for DNS queries. The --permanent flag is crucial as it writes the rule to the configuration file, ensuring it persists after a reboot. The rule is applied to the public zone, which is commonly used for server interfaces.

Incorrect Options:

A. ufw allow out dns:
This command is incorrect for two main reasons. First, it uses ufw (Uncomplicated Firewall), which is common on Ubuntu but not the standard tool referenced in the exam objectives. Second and more importantly, it creates an outbound rule (allow out), but the requirement is to allow inbound connections to the DNS forwarder from other servers.

B. systemctl reload firewalld:
This command only reloads the firewalld service to apply existing permanent rules; it does not create or add any new firewall rules itself. It is a step that would be taken after running the correct command (Option D) to apply the change, but it does not accomplish the primary task of opening the port.

C. iptables -A OUTPUT -p udp --dport 53 -j ACCEPT:
This command uses the lower-level iptables tool to add a rule. However, like option A, it is an output rule (-A OUTPUT), which is for outbound traffic. Furthermore, an iptables rule added this way is not persistent by default and would be lost after a reboot unless saved with a separate utility like iptables-save.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This question aligns with Objective 4.2: "Given a scenario, implement and configure Linux firewalls and access control options." The firewall-cmd utility is the primary tool listed for managing firewalld, and the --permanent flag is a key concept for making runtime changes persistent.

systemctl isolate graphical.target

Summary:
The task requires setting the server to runlevel 5. In modern Linux systems that use systemd, the concept of runlevels is mapped to specific "targets." Runlevel 5 is the multi-user system with a graphical user interface (GUI), which corresponds to the graphical.target in systemd. The correct command must switch the system to this target.

Correct Option:

B. systemctl isolate graphical.target:
This is the correct command. The systemctl isolate command is used to start a specific target and stop all others. Since graphical.target is the systemd equivalent of the traditional runlevel 5, this command will ensure the server is in the required environment for the application installation.

Incorrect Options:

A. systemctl isolate multi-user.target:
This corresponds to runlevel 3 (multi-user, text-based interface without a GUI). This is not the runlevel 5 environment specified in the installation guide.

C. systemctl isolate network.target:
This is a basic target that is pulled in as a dependency for network functionality. It is not a system state (runlevel) and does not provide a full user environment for installing applications.

D. systemctl isolate basic.target:
This is a minimal target that serves as a foundation for other targets. It is not a complete system state and is equivalent to runlevel 1 (single-user mode), not runlevel 5.

Reference:
systemd Official Documentation (systemd.special): The official man page describes the various special targets, including graphical.target and multi-user.target, and their purposes.

free -h

vmstat -a 1 4

Summary:
The mysqld process was killed by the kernel due to an Out of Memory (OOM) condition. This indicates the system exhausted its physical RAM and swap space, forcing the kernel to terminate a process (in this case, MySQL) to prevent a complete system crash. The next logical step is to investigate the current memory usage and system performance to understand the resource constraints that led to the OOM event.

Correct Options:

A. free -h:
This command provides a quick, human-readable overview of the system's current memory usage, showing total, used, free, and available RAM, as well as swap space. This is essential to see if the system is still under memory pressure.

F. vmstat -a 1 4:
This command provides a detailed, real-time report on system performance. It shows memory (active, inactive), swap, I/O, and CPU activity. Running it with an interval (1 second) for a few iterations (4 times) helps identify if the system is currently experiencing high memory pressure, swapping (si/so), or other resource contention that could lead to another OOM kill.

Incorrect Options:

B. nc -v 127.0.0.1 3306:
This command tests if the MySQL service is listening on its default port (3306). Since the process was killed, it is unlikely to be running, making this check less useful than diagnosing the root cause (memory exhaustion).

C. renice -15 $( pidof mysql ):
The renice command changes the priority of a running process. Since the MySQL process was killed, its PID no longer exists, so this command would fail. Furthermore, changing the priority would not resolve a lack of physical memory.

D. lsblk:
This command lists information about block devices (disks and partitions). The problem is related to memory (RAM), not disk space or storage configuration.

E. killall -15:
This command is used to send a SIGTERM signal to processes. The MySQL process is already dead, so there is nothing to kill. Using this would be irrelevant to troubleshooting the OOM condition.

Reference:
Linux man-pages project (free): The official documentation for the free command.

gzip

Summary:
The administrator needs to extract files from a compressed software package. The correct command depends on the compression format used for the file. Common compression formats in Linux include .gz (gzip), .bz2 (bzip2), and .zip. The question implies a standard compressed file, and gzip is one of the most common utilities for this purpose, used to decompress files with the .gz extension.

Correct Option:

C. gzip:
This is the correct command for decompressing files compressed with gzip. The typical usage is gzip -d filename.gz or gunzip filename.gz, which will extract the contents of the compressed file. The gzip command by default decompresses when used with the -d flag.

Incorrect Options:

A. unzip -v:
The unzip command is specifically for .zip archives. The -v flag is for verbose listing of the archive contents, not for extraction. A more general extraction command would be unzip without flags.

B. bzip2 -z:
The bzip2 command is for files compressed with the .bz2 format. However, the -z flag is for compression, not extraction. The correct flag for decompression with bzip2 is -d.

D. funzip:
This is a specialized utility that unzips the first file in a .zip archive and sends it to standard output. It is not a general-purpose extraction tool for all compressed formats and is less commonly used than unzip or gzip.

Reference:
Linux man-pages project (gzip): The official documentation explains that gzip -d is used to decompress files.

Jenkins

Summary:
The question asks for a tool specifically designed for creating CI/CD (Continuous Integration/Continuous Deployment) pipelines. A CI/CD pipeline is an automated process that encompasses building, testing, and deploying code. The correct tool is one that orchestrates these stages through a defined workflow, often triggered by code commits.

Correct Option:

C. Jenkins:
This is the primary tool among the options for creating CI/CD pipelines. Jenkins is an open-source automation server that is specifically designed to set up and manage continuous integration and continuous delivery pipelines. It uses a flexible, plugin-based architecture to define complex workflows that can include building code, running tests, and deploying applications.

Incorrect Options:

A. Chef & B. Puppet:
These are Configuration Management tools. Their primary purpose is to automate the provisioning and configuration of servers to a desired state (e.g., installing packages, managing files). While they can be integrated into a CI/CD pipeline (e.g., a Jenkins job can trigger a Puppet run to configure a server), they are not the pipeline orchestration tools themselves.

D. Ansible:
Like Chef and Puppet, Ansible is primarily a Configuration Management and application deployment tool. It excels at defining and executing playbooks to configure systems. While it has features like Ansible Tower (AWX) that can help orchestrate workflows, the core Ansible engine is not a dedicated CI/CD pipeline tool in the way Jenkins is. Jenkins is more synonymous with the role of a pipeline orchestrator.

Reference:
Jenkins Official Website: The homepage describes Jenkins as "the leading open-source automation server" used for building, deploying, and automating any project, which is the definition of a CI/CD pipeline tool.

systemctl mask nginx

push

Summary:
The administrator has made commits to a local feature branch. To share these changes with others and integrate them into the collaborative project, the local commits must be uploaded to the shared, remote repository. The action that transfers local commits to a remote repository is a distinct command from those used for local history management.

Correct Option:

D. push:
This is the correct action. The git push command is used to upload local repository content to a remote repository. It transfers commits from your local branch (in this case, the feature branch) to the corresponding branch on the remote server, making them available to other team members. To get the changes into the main branch, the administrator would typically push the feature branch and then create a Pull Request or merge it on the remote platform (like GitHub or GitLab), or merge it locally and then push the main branch.

Incorrect Options:

A. rebase:
This is a history-rewriting command used to move or combine a sequence of commits to a new base commit. It is often used to maintain a clean project history. It is an operation performed on the local repository history and does not publish changes to a remote server.

B. tag:
This command is used to create, list, delete, or verify a tag object. Tags are typically used to mark specific points in history as being important (e.g., release versions like v1.0.0). It does not publish the changes from a feature branch.

C. commit:
The git commit command is used to save the staged changes to the local repository. The administrator has already performed this step. Committing records changes locally but does not share them with the remote repository.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This question aligns with Objective 1.2: "Given a scenario, perform version control using Git," which requires knowledge of core Git commands. Understanding the workflow of commit (local save) followed by push (remote publish) is fundamental. The official Git website, git-scm.com, is the primary reference.

ip route get 192.163.1.40 from 10.0.2.15

Summary:
The administrator needs to trace the exact network path a packet would take from a specific source IP (10.0.2.15) to a specific destination IP (192.168.1.40). This is different from simply viewing the routing table; it requires asking the kernel to resolve the path for a specific connection, showing the next-hop gateway and the egress interface. This is often called a "route lookup."

Correct Option:

B. ip route get 192.168.1.40 from 10.0.2.15:
This is the correct and modern command for this task. The ip route get command instructs the kernel to perform a route lookup as if a packet were being sent from the source IP to the destination IP. It displays the complete path, including the gateway and the network interface that would be used.

Incorrect Options:

A. route -e get to 192.168.1.40 from 10.0.2.15:
The route command is part of the deprecated net-tools package. While route -n can display the routing table, it does not have a get function that accepts a from parameter to test a specific source-destination pair.

C. ip route 192.169.1.40 to 10.0.2.15:
This command has multiple errors. First, the IP address is incorrect (192.169.1.40). Second, the syntax is invalid. The ip route command is primarily for managing the routing table (e.g., ip route add or ip route show), not for performing a specific route lookup with a source address.

D. route -n 192.168.1.40 from 10.0.2.15:
The route -n command displays the entire kernel routing table in numerical form. It does not take destination and source IP addresses as arguments to test a specific path.

Reference:
ip-route man page: The official documentation for the ip route command, which includes the get action for route lookups.

~/.ssh/authorized_keys

Summary:
The administrator is configuring key-based authentication for SSH. This method requires the user's public key to be stored on the server in a specific, standardized file. The SSH daemon (sshd) is programmed to look for this file in a predetermined location within the target user's home directory when a login attempt is made. The correct location is defined by the SSH protocol and server configuration.

Correct Option:

C. ~/.ssh/authorized_keys:
This is the standard and default location where the SSH daemon looks for public keys to authorize a user's login. Each line in this file contains one public key. When a user tries to connect, the server checks if the corresponding private key matches any of the public keys listed in this file.

Incorrect Options:

A. ~/.sshd/authkeys:
This path is incorrect. The .sshd directory is not a standard directory for SSH configuration on the client or server side for user keys.

B. ~/.ssh/keys:
While a .ssh directory is correct, the keys file is not the standard name recognized by the SSH daemon for authorized public keys.

D. ~/.ssh/keyauth:
This is also a non-standard filename. The SSH daemon will not check this file for authorization keys by default.

Reference:
OpenSSH Manual (sshd): The official documentation specifies that the authorized_keys file in the user's ~/.ssh directory lists the public keys that are permitted for logging in.