CompTIA XK0-005 Practice Test

Modify the /etc/hosts file and change the db.example.com entry to 192.168.20.88.

Summary:
The administrator is troubleshooting access to db.example.com. The dig command shows that the DNS server correctly returns the IP address 192.168.20.88. However, the local /etc/hosts file has a static entry that maps db.example.com to a different, incorrect IP address (192.168.20.89). On most systems, /etc/hosts is checked before DNS, causing the system to use the wrong IP from the hosts file, leading to the connectivity issue.

Correct Option:

D. Modify the /etc/hosts file and change the db.example.com entry to 192.168.20.88.:
This is the correct solution. The local /etc/hosts file is overriding the correct DNS lookup. By correcting the entry in /etc/hosts to the intended IP address (192.168.20.88), the system will resolve db.example.com correctly, and connectivity should be restored.

Incorrect Options:

A. Modify the /etc/hosts file and change the db.example.com entry to 192.168.20.89.:
This would make the problem worse or, at best, keep it the same. The IP 192.168.20.89 is already the incorrect entry causing the issue. Changing it to the same value is pointless, and confirming the wrong address would not help.

B. Modify the /etc/network file and change the db.example.com entry to 192.168.20.88.:
There is no standard /etc/network file used for hostname-to-IP mapping. The correct file for static local host entries is /etc/hosts. The /etc/network/ directory typically contains interface configuration scripts, not hostname resolution entries.

C. Modify the /etc/network file and change the db.example.com entry to 192.168.20.89.:
This is incorrect for the same reasons as option B. The file is wrong, and the IP address is also wrong.

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 name resolution. Understanding the order of name resolution (e.g., /etc/hosts before DNS in /etc/nsswitch.conf) and knowing how to correct static entries in /etc/hosts is a fundamental skill.

sed -i 's/auto/persistent/g' /etc/systemd/journald.conf && sed -i 'persistent/s/ˆ#//q'
/etc/systemd/journald.conf

Summary:
By default, the systemd-journald service stores logs in a volatile, in-memory location (/run/log/journal/), which is cleared on reboot. To make logs persistent, the configuration in /etc/systemd/journald.conf must be changed. The Storage= parameter needs to be set to persistent and, crucially, the line must be uncommented by removing the leading # symbol.

Correct Option:

C. sed -i 's/auto/persistent/g' /etc/systemd/journald.conf && sed -i 'persistent/s/ˆ#//q' /etc/systemd/journald.conf:
This command accomplishes the task, though the q at the end is a typo and should likely be g. The first command changes the Storage parameter from auto to persistent. The second command uses a pattern to find the line containing "persistent" and removes the comment character (#) from the beginning of that line (s/ˆ#//), thereby activating the setting. A service restart would also be needed, which is implied for the change to take effect.

Incorrect Options:

A. grep -i auto /etc/systemd/journald.conf && systemct1 restart systemd-journald.service:
This command only searches for the word "auto" in the config file and then restarts the service. It does not actually modify the configuration file to change the Storage parameter to persistent or uncomment the necessary line, so it will not enable persistence.

B. cat /etc/systemd/journald.conf | awk '(print $1,$3)':
This is a purely diagnostic command that formats and displays the contents of the configuration file. It is a read-only operation and makes no changes to the system, so it cannot enable persistent logging.

D. journalctl --list-boots && systemct1 restart systemd-journald.service:
The journalctl --list-boots command displays a list of boot sessions currently available in the journal. This only shows data that is already stored; it does not configure future log persistence. Restarting the service without a configuration change will not enable persistence.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 4.3: "Given a scenario, analyze and troubleshoot application and hardware issues," which includes managing logs. Configuring the systemd-journald service for persistent storage is a key task for ensuring log data is available for troubleshooting after a system reboot. The official systemd documentation for journald.conf is the primary reference.

vmstat

Summary:
The top output shows a critical issue: extremely high I/O wait (%wa is 70.2%) and zero idle time (%id is 0.0%). This clearly indicates the system is bottlenecked by disk I/O; processes are stalled waiting for read/write operations to complete. The next logical step is to investigate the details of this I/O activity to identify the root cause, such as which processes are causing heavy I/O, the read/write rates, and swap activity.

Correct Option:

A. vmstat:
This is the most likely next command. vmstat provides a detailed breakdown of system resources, including crucial I/O statistics that top does not show. Key columns to check would be:

si (swap in) and so (swap out): To see if high I/O is due to memory pressure and swapping.

bi (blocks in) and bo (blocks out): To see the actual disk block I/O rates.

us, sy, id, wa: To confirm the CPU breakdown in a different view.

It gives a broader, system-wide view of memory, swap, and I/O, which is the logical next step after top has identified I/O wait as the problem.

Incorrect Options:

B. strace:
strace is a debugging tool that traces system calls and signals made by a specific process. It is far too granular and would be used later to investigate a specific problematic process identified by broader tools like vmstat or iotop.

C. htop:
htop is an enhanced, interactive version of top. While it might provide a nicer interface or slightly more information, it essentially shows the same type of high-level data as top. Since top has already identified the general problem (I/O wait), the administrator should move to a more diagnostic tool like vmstat, not a similar one.

D. lsof:
lsof (list open files) is used to see which files a specific process has open. Like strace, this is a tool for drilling down into a specific process once it has been identified as the culprit. It is not the right tool for getting a system-wide overview of I/O and memory pressure.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 4.3: "Given a scenario, analyze and troubleshoot application and hardware issues," which includes troubleshooting performance issues. The standard methodology is to start with general tools like top, then use more specific tools like vmstat (for memory/I/O) or iostat (for disk-specific I/O) to pinpoint the cause.

dnf update

Summary:
The task is to install the most recent versions of all packages on an RPM-based operating system. This requires a command that performs two key actions: first, it must refresh the local cache of available packages from the remote repositories, and second, it must download and install the newer versions of all installed packages. The command must be the primary package manager for the system.

Correct Option:
D. dnf update:
This is the correct and modern command. dnf is the next-generation package manager for RPM-based distributions like Red Hat Enterprise Linux, Fedora, and CentOS. The dnf update command refreshes the repository metadata and then upgrades all installed packages to their latest available versions. It has effectively replaced yum as the default in newer versions of these distributions.

Incorrect Options:

A. apt-get upgrade:
This command is used on Debian-based distributions (like Ubuntu and Debian), not RPM-based systems. apt and yum/dnf are package managers for two different Linux families.

B. rpm -a:
This is an invalid command. The rpm command is the low-level package manager, but it does not have an -a flag to update all packages. It is used to install, query, and verify individual .rpm files, but it does not resolve dependencies or manage repositories like yum or dnf.

C. yum updateinfo:
This command is used to display information about available updates, including security advisories (errata). It is a diagnostic command that lists available updates but does not actually install any packages.

E. yum check-update:
This command checks the repositories for available updates and lists which packages have newer versions. Like yum updateinfo, it is a read-only command that checks for updates but does not download or install them.

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 the correct command to update all packages on an RPM-based system (dnf update or yum update) is a fundamental administrative task.

rpm -e

Summary:
The administrator needs to uninstall or remove a software package that was installed using the RPM package manager. RPM (Red Hat Package Manager) has a specific command and option for erasing a package from the system, including its files and metadata. The correct option must initiate the removal process.

Correct Option:

D. rpm -e:
This is the correct command. The -e (erase) option is used to remove a previously installed package from the system. The administrator would use the command rpm -e packagename to uninstall the specified software.

Incorrect Options:

A. rpm -s:
There is no standard -s option for the rpm command that performs a removal. This is an invalid or distractor option.

B. rm -d:
The rm command is for deleting files and directories from the filesystem. It is not a package management command and cannot properly handle the complex task of removing an installed software package, which involves updating the RPM database.

C. rpm -q:
The -q (query) option is used to get information about installed packages. It is a read-only operation used for checking if a package is installed or listing its files, not for removing it.

Reference:
RPM Man Page: The official documentation for the rpm command, which explains the -e option for erasing packages.

find /var/log -type f -mtime +180 -exec rm {} \

Summary:
The administrator needs to locate and delete old log files to free up disk space. The command must search recursively in the /var/log directory for items that are files (not directories), have a modification time older than 180 days, and then securely remove them. The find command is the correct tool for this job, as it can search based on criteria and execute a removal command on the results.

Correct Option:

C. find /var/log -type f -mtime +180 -exec rm {} \;:
This command is correctly structured.

find /var/log starts the search in the log directory.

-type f restricts the search to files only.

-mtime +180 matches files whose data was last modified more than 180 days ago.

-exec rm {} \; executes the rm command on each found file ({} is the placeholder).

Incorrect Options:

A. find /var/log -type d -mtime +180 -print -exec rm {} \;:
This command uses -type d, which searches for directories older than 180 days. Deleting directories in /var/log would be destructive to the logging structure and is not the task's goal.

B. find /var/log -type f -modified +180 -rm:
The -modified flag is not a standard find predicate. The correct flag for modification time is -mtime. Also, -rm is not a valid action; the correct method is to use -exec or -delete.

D. find /var/log -type c -atime +180 –remove:
The -type c flag searches for character special files, not regular log files. The -atime flag checks access time, not modification time. Finally, –remove is not a valid find command action.

Reference:
Linux man-pages project (find): The official documentation explains the -type, -mtime, and -exec options in detail.

bg %1 job name

Summary:
A technician needs to run long-running commands (microservices) but cannot wait for each one to finish before starting the next deployment task. The solution requires placing a currently running or suspended process into the background, allowing it to continue execution while freeing up the terminal for new commands. This is a core function of shell job control.

Correct Option:

D. bg %1:
This is the correct command. The bg (background) command resumes a suspended job (one stopped with Ctrl+Z), but runs it in the background. The %1 specifies job number 1. After placing the job in the background, the terminal prompt returns, allowing the technician to run subsequent commands or deploy other microservices. The job will continue running without occupying the terminal.

Incorrect Options:

A. gedit & disown:
While gedit & would start the graphical gedit text editor in the background, the disown command is unnecessary and counterproductive here. disown severs the job from the shell's job table, meaning you can no longer manage it with commands like fg or bg. This is overkill for simply wanting to continue working in the same terminal.

B. kill 9 %1:
This command forcefully terminates job number 1 using the SIGKILL signal (-9). This would stop the microservice, not allow it to continue running in the background.

C. fg %1:
The fg (foreground) command brings a background or suspended job into the foreground. This has the opposite effect of what is desired; it would make the job occupy the terminal again, preventing the technician from running other commands until it completes.

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 jobs and processes. Understanding job control commands (&, Ctrl+Z, bg, fg, jobs) is essential for efficient command-line workflow.

systemctl restart sshd.service

Summary:
The administrator is trying to set up passwordless SSH login by placing a public key in a file. The ls -la output reveals the critical issue: the file is named .ssh/authorized_key (singular). The SSH daemon looks for a file specifically named .ssh/authorized_keys (plural) by default. The incorrect filename is why the key is being ignored, and the SSH server falls back to password authentication.

Correct Option:

B. mv .ssh/authorized_key .ssh/authorized_keys:
This command directly fixes the root cause of the problem by renaming the file to the correct name that the SSH daemon expects. After this change, the SSH server will read the public key from the properly named authorized_keys file and allow passwordless login.

Incorrect Options:
A. restorecon -rv .ssh/authorized_key:
This command would reset the SELinux security context for the incorrectly named file. While SELinux could be a cause for SSH key issues, the primary and most obvious problem here is the filename. Fixing the name should be the first step.

C. systemctl restart sshd.service:
Restarting the service is unnecessary. The SSH daemon reads the authorized_keys file on each connection attempt. A restart would not make it recognize a file with the wrong name.

D. chmod 600 mv .ssh/authorized_key:
This command is syntactically incorrect and would try to change the permissions of a command called mv. Furthermore, the permissions on the authorized_key file are already correct (600), as shown in the output. The problem is the filename, not the permissions.

Reference:
OpenSSH Manual (sshd): The official documentation specifies the expected filename for authorized keys.

mount disk by-blkid

Summary:
When a Linux server is cloned, the new virtual machine often receives new virtual SCSI controller IDs, causing the kernel to assign different device names (e.g., /dev/sda becomes /dev/sdb). However, the cloned system's /etc/fstab file still contains the old device identifiers (/dev/sda1), leading to a boot error because the specified device is not found. The solution is to mount the filesystem using an identifier that remains consistent across clones, rather than the volatile device name.

Correct Option:

A. mount disk by device-id:
This refers to using the filesystem's UUID (Universally Unique Identifier). Every filesystem has a UUID that is unique and persistent, even after cloning. The administrator must edit /etc/fstab and replace the device name (e.g., /dev/sda1) with UUID=correct-uuid, which can be found using the blkid command. This ensures the correct filesystem is mounted regardless of the device node assignment.

Incorrect Options:

B. fsck -A:
This command checks and repairs all filesystems listed in /etc/fstab. It is a filesystem repair tool and does not resolve the underlying issue of the device name mismatch in the /etc/fstab configuration.

C. mount disk by-label:
While mounting by a filesystem label is a valid and persistent method, it requires that the filesystem was created with a label. The scenario describes a device mismatch, and labels are not guaranteed to be unique or present. The UUID is a more reliable and universally available identifier.

D. mount disk by-blkid:
blkid is a command used to display the UUIDs and labels of block devices. It is not a mounting method itself. The correct action is to use the information from blkid (the UUID) to update the /etc/fstab file.

Reference:
Linux man-pages project (fstab): The official documentation for /etc/fstab explains the different field specifications, including using the UUID= prefix for identifying filesystems.

Option A

Summary:
This question addresses a security incident where compromised servers cause service disruptions, including inaccessible web pages. Kernel log messages indicate issues with firewall rules, likely due to unauthorized modifications by attackers, such as blocking ports or dropping packets. The task is to select the command that remediates the issue by restoring or reloading standard firewall configurations to re-enable access while containing the compromise.

Correct Option:

A. [Assumed: iptables -F; iptables -X; iptables -t nat -F; iptables -t mangle -F; iptables -P INPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -P OUTPUT ACCEPT]
This sequence flushes all custom rules (-F), deletes user-defined chains (-X), clears NAT and mangle tables, and sets default policies to ACCEPT, effectively resetting iptables to a permissive state.

It remediates the issue by removing malicious or erroneous rules blocking services, allowing immediate access restoration.

This is a common first-response action in compromise scenarios, followed by securing the system.

Incorrect Option:

B. [Assumed: systemctl restart firewalld]
Restarting firewalld reloads its current configuration but won't remove or override malicious rules if the config files (e.g., zones) have been altered.

It may perpetuate the block if the compromise affected firewalld settings, making it insufficient for remediation.

C. [Assumed: iptables-restore < /etc/iptables.rules]
This restores rules from a backup file, but if the backup is outdated or compromised, it could reapply faulty rules or fail to address the current kernel-logged issues.

Without verification, it's riskier than a full flush and reset, and the file may not exist or be intact post-compromise.

D. [Assumed: firewall-cmd --reload]
The --reload option reapplies the current firewalld configuration without restarting the service, but it doesn't purge malicious changes embedded in the config.

Similar to B, it assumes the config is clean, which isn't guaranteed in a compromise, delaying resolution.

Reference:
https://www.comptia.org/training/resources/exam-objectives (CompTIA Linux+ XK0-005 objectives)