CompTIA XK0-005 Practice Test

rpm -qf /etc/httpd/conf/httpd.conf

Summary:
A critical application configuration file is missing. To restore it, the administrator first needs to identify which RPM (Red Hat Package Manager) package originally installed the file. This will allow them to know which package to reinstall to get a fresh copy of the default configuration file. The correct RPM command must be one that queries the package database to find the owner of a specific file.

Correct Option:

A. rpm -qf /etc/httpd/conf/httpd.conf:
This is the correct command. The -qf flags stand for query file. This command interrogates the RPM database to determine which installed package owns, or provided, the specified file (/etc/httpd/conf/httpd.conf). Once the package name (e.g., httpd) is known, the administrator can reinstall it with rpm -Uvh --replacepkgs httpd or yum reinstall httpd to restore the missing file.

Incorrect Options:

B. rpm -ql /etc/httpd/conf/httpd.conf:
The -ql flags stand for query list. This command is used to list all the files that are installed by a given package name. For example, rpm -ql httpd would list all files from the httpd package. Using a file path as the argument is incorrect syntax and will result in an error.

C. rpm —query /etc/httpd/conf/httpd.conf:
The --query option is used to query packages, but it requires specific query flags (like -f or -l) to define the type of query. Using it alone with a file path is invalid syntax and will not work.

D. rpm -q /etc/httpd/conf/httpd.conf:
The -q flag is for querying a package, but it expects a package name as an argument, not a file path. For example, rpm -q httpd checks if the httpd package is installed. Providing a file path will cause RPM to look for a package with that exact name, which does not exist, and will return "package /etc/httpd/conf/httpd.conf is not installed."

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 1.1: "Given a scenario, perform a Linux installation and configuration," which includes managing software using package management. Knowing how to use rpm -qf to identify the package that owns a file is a fundamental troubleshooting skill.

systemctl status systemd-resolved.service

Summary:

The administrator needs to verify the current runtime state of a specific systemd service, including whether it is active, any recent errors, and its log output. The command must provide a concise, human-readable status overview that is used for immediate troubleshooting and verification of service health.

Correct Option:

A. systemctl status systemd-resolved.service:
This is the primary command for checking a service's runtime status. It displays a summary showing whether the service is active (running), enabled, the main process ID, and the most recent log entries from the service's journal. This is the ideal tool for quickly determining if a service is running without errors.

Incorrect Options:

B. systemctl enable systemd-resolved.service:
This command configures the service to start automatically at boot. It does not show the current running status or any error messages; it only changes the startup configuration.

C. systemctl mask systemd-resolved.service:
This command prevents a service from being started, both manually and automatically, by linking it to /dev/null. It is a powerful administrative action to completely disable a service, not a command to check its status.

D. systemctl show systemd-resolved.service:
This command displays all the low-level properties and settings of the service unit from the systemd manager itself. While it provides extensive configuration data, its output is very verbose and not optimized for a quick check of operational status and errors.

Reference:
systemd Official Documentation (systemctl): The official man page details the status command and its purpose for showing brief runtime status information.

mv /home/tmp/tempa /home/tmp/temp

Summary:
A directory was created with the incorrect name /home/tmp/tempa instead of the required /home/tmp/temp. Users and applications are trying to save files to the correct path but receiving a "Path not found" error. The solution is to rename the existing misnamed directory to the correct name, which will immediately resolve the path issue for all users without needing to copy data or change application configurations.

Correct Option:

B. mv /home/tmp/tempa /home/tmp/temp:
This is the correct and most efficient command. The mv (move) command is used in Linux to both move and rename files and directories. This command will rename the directory from tempa to temp in its current location. Once the directory has the correct name, the users' save operations will succeed as the expected path will now exist.

Incorrect Options:

A. cp /home/tmp/tempa /home/tmp/temp:
This command would attempt to copy the contents of the tempa directory into a new directory named temp. If temp does not exist, it might create it, but it would result in two separate directories (tempa and temp). The original, incorrectly named tempa directory would still exist, and the copy operation might not preserve all file attributes and permissions correctly.

C. cd /temp/tmp/tempa:
This command is used to change the current working directory of the shell to the incorrectly named path. It is a navigation command only and performs no action to fix the underlying problem of the misnamed directory.

D. ls /home/tmp/tempa:
This command lists the contents of the incorrectly named directory. Like the cd command, it is a read-only diagnostic command that only displays information. It does not modify the filesystem or resolve the issue.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 3.2: "Given a scenario, manage storage, files, and directories in a Linux environment," which includes using commands to manage and manipulate files and directories. The mv command is a fundamental tool for this objective.

docker cp container_id:/deployment.yaml deployment.yaml

Summary:
The task requires copying a file from a running Docker container to the host filesystem. The correct command must use the proper docker cp syntax, which requires specifying the source as : and the destination as a path on the local host. The command executes from the host's shell.

Correct Option:

B. docker cp container_id:/deployment.yaml deployment.yaml: This command uses the correct syntax.
container_id:/deployment.yaml correctly identifies the source as the file /deployment.yaml located inside the container with the specified ID.

deployment.yaml specifies the destination as a file in the current working directory on the host machine. This will successfully copy the file from the container to the host.

Incorrect Options:

A. docker cp container_id/deployment.yaml deployment.yaml:
This syntax is incorrect because it uses a forward slash (/) instead of a colon (:) to separate the container ID from the file path. The command will fail because it interprets container_id/deployment.yaml as a path on the host, not inside the container.

C. docker cp deployment.yaml local://deployment.yaml:
This command is reversed and uses invalid syntax. It attempts to copy a file named deployment.yaml from the host into the container, but the local:// prefix is not valid for the docker cp command.

D. docker cp container_id/deployment.yaml local://deployment.yaml:
This command has the same source syntax error as option A (missing colon). Furthermore, the local:// destination prefix is invalid. The correct way to specify a host path is to use a simple file path.

Reference:
Docker Documentation (docker cp): The official documentation explains the command syntax for copying files between a container and the local filesystem.

Create a mount unit and enable it to be started at boot.

Summary:
The issue occurred because a filesystem was mounted manually, and this temporary mount was lost after a reboot since it was not configured to persist. The manual mount was not recorded in the system's configuration. To prevent this from happening again, the administrator must create a permanent configuration that automatically mounts the filesystem during the boot process.

Correct Option:

C. Create a mount unit and enable it to be started at boot.:
This is the correct and modern solution. On systems using systemd, persistent filesystem mounts are managed by creating mount unit files (e.g., /etc/systemd/system/mnt-data.mount). These units define what to mount, where to mount it, and the filesystem type. Enabling this unit ensures the filesystem is mounted automatically at boot, making the mount persistent across reboots. Alternatively, adding an entry to /etc/fstab accomplishes the same goal and is the traditional method, which systemd also reads.

Incorrect Options:

A. Sync the mount units.:
This is not a standard command or procedure. While systemctl daemon-reload is used to reload unit files after creating or modifying them, "syncing mount units" is not the specific action that solves the root cause of a missing persistent configuration.

B. Mount the filesystem manually.:
This is exactly what caused the problem. A manual mount (using the mount command) is temporary and only lasts until the next reboot. It does not solve the persistence issue.

D. Remount all the missing filesystems.:
Remounting the filesystems manually would restore access for the current session, but it is a temporary fix. The mounts would be lost again after the next reboot, as it does not address the lack of a permanent configuration.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 3.2: "Given a scenario, manage storage, files, and directories in a Linux environment," which includes configuring the fstab file (or systemd mount units) for persistent mounting. This is a fundamental concept for ensuring data availability after system restarts.

/etc/fstab

Summary:
To ensure a filesystem is automatically mounted every time the system boots, its configuration must be added to the system's filesystem table. This table is read by the mount command during the system's startup sequence. The correct file contains a list of all filesystems, their mount points, types, and options that should be mounted automatically.

Correct Option:

C. /etc/fstab:
This is the correct file. The fstab (filesystem table) file is the central configuration file that defines how and where storage devices and partitions should be mounted. Adding an entry for the new filesystem to /etc/fstab ensures the operating system will attempt to mount it automatically at boot time.

Incorrect Options:

A. /etc/sysctl:
This file is used to configure kernel parameters at boot time, such as network settings and system limits. It is not used for defining filesystem mount points.

B. /etc/filesystems:
This file is used to set the default search order for filesystem types when mounting a device without specifying a type. It does not define which filesystems to mount at boot.

D. /etc/nfsmount.conf:
This file contains default options for NFS (Network File System) mounts. It is specific to NFS and is not the general configuration file for all filesystem mounts at boot.

Reference:
Linux man-pages project (fstab): The official documentation explains the purpose and format of the /etc/fstab file.

ssh-copy-id

scp

Summary:
The administrator needs to transfer the public SSH key to a remote server to enable passwordless authentication. This involves copying the ~/.ssh/id_rsa.pub file (or similar) to the remote server and appending it to the ~/.ssh/authorized_keys file in the target user's home directory. The correct commands must securely transfer the file and handle its placement correctly.

Correct Options:

D. ssh-copy-id:
This is the dedicated and recommended command for this task. It automatically copies the public key to the remote server, ensures the ~/.ssh directory exists with correct permissions, and appends the key to the authorized_keys file, all in one secure step.

F. scp:
The Secure Copy command can be used to manually transfer the public key file to the remote server. The administrator would then need to manually log in via SSH and append the key to the authorized_keys file (e.g., cat id_rsa.pub >> ~/.ssh/authorized_keys). It is a manual two-step process but achieves the goal.

Incorrect Options:

A. wget:
This is a command-line tool for downloading files from the web (HTTP, HTTPS, FTP). It is not used for securely transferring files to a remote server via SSH.

B. ssh-keygen
This command is used to generate new SSH key pairs, not to copy them to remote servers. Its job is complete once the keys are created on the local machine.

C. ssh-keyscan:
This utility is used to collect public SSH host keys from remote servers. It helps populate the local known_hosts file to avoid trust-on-first-use prompts, but it does not copy user keys to the server.

E. ftpd:
This is the File Transfer Protocol daemon, a service that runs on a server. It is not a client command for copying files, and using FTP is insecure compared to SCP or SSH-based methods.

Reference:
OpenSSH Manual (ssh-copy-id): The official documentation explains that ssh-copy-id installs public keys in a remote machine's authorized_keys.

rsync -a /data remote:/backup/

Summary:
The task requires efficiently synchronizing an entire local directory (/data) to a specific location on a remote server. The command must handle the transfer over the network, preserve file attributes (like permissions and timestamps), and copy the contents of the directory into the target path. The tool must be suitable for backing up directory structures.

Correct Option:

C. rsync -a /data remote:/backup/: This is the ideal command for this task.
rsync is designed for efficient file synchronization and transfer.

The -a (archive) flag preserves permissions, timestamps, and performs a recursive copy, which is essential for a complete backup.

The syntax /data remote:/backup/ will copy the entire contents of the local /data directory into the remote /backup/ directory, effectively creating /backup/data on the remote server.

Incorrect Options:

A. scp -p /data remote:/backup/data:
While scp can copy files over SSH, the -p flag only preserves timestamps, not all file attributes. More importantly, if /backup/data doesn't exist on the remote server, scp may fail or behave unexpectedly with directories. rsync is generally more robust for directory synchronization.

B. ssh -i /remote:/backup/ /data:
This command is completely invalid. The ssh command is used to log into a remote shell, not to copy files. The syntax is nonsensical for a file transfer operation.

D. cp -r /data /remote/backup/:
The cp command is for local copies only. It cannot transfer files to a remote server. It would interpret /remote/backup/ as a local directory path, which does not exist.

Reference:
rsync Official Documentation: The man page details the -a flag and the command's syntax for remote transfers.

$ nice -10 wget https://foo.com/installation.zip

Summary:
The engineer needs to start a new process (downloading a file with wget) with a specific scheduling priority, also known as a "nice" value. A lower nice value (like -10) gives the process higher priority for CPU time. The correct command must be one that launches a new command with a modified nice value.

Correct Option:

D. nice -10 wget https://foo.com/installation.zip:
This is the correct command. The nice command is used to start a new process with a specified priority. The syntax nice -n [value] [command] is used, where the -n can often be omitted. Therefore, nice -10 starts the wget command with a nice value of -10, giving it a higher priority.

Incorrect Options:

A. nice -v -10 wget https://foo.com/installation.zip:
This is incorrect syntax. The -v flag for nice typically stands for "version," which prints version information and exits. It is not used for setting the nice value. The correct flag for the priority is -n, but it can be omitted as in option D.

B. renice -v -10 wget https://foo.com/installation.zip:
The renice command is used to change the priority of an already running process. It cannot be used to launch a new command. The -v flag is also not a standard option for renice in this context.

C. renice -10 wget https://foo.com/installation.zip:
This is incorrect because renice modifies the priority of existing processes, identified by their PID, process group ID, or user. You cannot pass a command line to renice to start a new process.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 3.1: "Given a scenario, use the appropriate system and service management commands to accomplish administrative tasks," which includes managing process execution priorities. Knowing the distinction between nice (for new processes) and renice (for existing processes) is a key skill.

sysctl -w net.ipv4.ip_forward=1

sysctl –p

Summary:
The task requires persistently enabling IPv4 forwarding, meaning the setting must survive a system reboot. This involves two distinct actions: changing the current, live kernel parameter and ensuring that change is saved in a configuration file that is read during the boot process. The correct pair of commands must accomplish both the runtime change and the persistent configuration.

Correct Options:

B. sysctl -w net.ipv4.ip_forward=1:
This command makes the immediate, runtime change. The -w (write) flag instructs sysctl to change the net.ipv4.ip_forward kernel parameter to 1, enabling IPv4 forwarding for the current session.

E. sysctl -p:
This command loads the settings from the persistent configuration file (/etc/sysctl.conf or files in /etc/sysctl.d/). After adding the setting to the file (as in option C), running sysctl -p makes it active without a reboot. This command is the final step to activate the persistent setting immediately.

Incorrect Options:

A. sysctl net.ipv4.ip_forward:
This command only queries and displays the current value of the parameter. It is a read-only operation and does not change any settings.

C. echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf:
While this command correctly adds the setting for persistence, it is only one part of the solution. By itself, it does not activate the change for the current runtime environment. It needs to be paired with a command like sysctl -p (option E) to be complete.

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

F. echo "net.ipv6.conf.all.forwarding=l" >> /etc/sysctl.conf:
This command configures IPv6 forwarding, not IPv4. The parameter is incorrect for the task, and it also contains a typo (l instead of 1).

Reference:
Linux man-pages project (sysctl): The official documentation explains the -w option for changing settings and the -p option for loading from the configuration file.