CompTIA Linux+ Practice Test (XK0-006)

GRUB 2's human-editable settings are stored in /etc/default/grub. When grub2-mkconfig runs, it combines the values in this file (especially the GRUB_CMDLINE_LINUX line) with the scripts in /etc/grub.d/ to build a fresh /boot/grub2/grub.cfg. Editing /etc/default/grub therefore ensures that any kernel parameters you add-such as noapic-are written into every menu entry and are kept when future kernels are installed.

The other choices are unsuitable:

• /boot/grub2/grub.cfg is the generated file; any manual edits are overwritten the next time grub2-mkconfig or a kernel update runs.
• /etc/grub.d/10_linux is a script snippet, not the central place for simple kernel-parameter changes, and editing it risks syntax errors that break the whole menu.
• /boot/grub2/custom.cfg is intended for custom menu entries only; modifications there are not propagated to new kernels installed by the package manager.

Therefore, editing /etc/default/grub is the correct and supported method.

The remount option tells the kernel to change the mount options of an already-mounted file system in place. Adding ro sets the mount to read-only. Therefore, mount -o remount,ro / immediately flips the root file system to read-only while it remains mounted at /.

The other choices are incorrect:

• mount -o bind,ro / / attempts a bind mount; it would create a second mount of the same directory and is not how you change an existing mount's permissions.
• mount -o remount,nosuid / changes only the nosuid flag; the file system would still be read-write.
• mount -o remount,rw / explicitly keeps the file system read-write, the opposite of what is required.

GRUB2 stores the menu that the firmware actually reads in /boot/grub/grub.cfg, but on Debian-based systems that file is regenerated automatically from templates each time update-grub (or a kernel package) is run. Persistent kernel command-line changes are therefore made in /etc/default/grub, usually by editing the GRUB_CMDLINE_LINUX (or GRUB_CMDLINE_LINUX_DEFAULT) variable and then regenerating the menu with update-grub. Editing /boot/grub/grub.cfg directly will work only until the next update overwrites it. The script /etc/grub.d/40_custom is meant for adding entirely new menu entries, not for changing the parameters of the distribution-generated entries. /etc/fstab influences how filesystems are mounted after the kernel has already mounted its root filesystem, so changing it will not fix a root= mismatch during early boot.

The correct command is xfs_repair -n /dev/sdb1. The xfs_repair utility is specifically designed to check and repair XFS filesystems. The -n option runs the command in no-modify mode, performing a read-only check without changing the filesystem, which is a crucial first step in assessing corruption. The command must be run on an unmounted filesystem, specified by its device name, such as /dev/sdb1.

• xfs_repair /dev/sdb1 is incorrect because, without the -n option, it would immediately attempt to repair the filesystem, which is not what the scenario asks for. The administrator wants to check for issues first.
• fsck /dev/sdb1 is incorrect because, for XFS filesystems, the fsck command is a wrapper that typically does nothing and exits, recommending the use of xfs_repair.
• xfs_growfs /dev/sdb1 is incorrect as this command is used to expand or grow an existing XFS filesystem, not to check or repair it.

The correct command is script.sh > /dev/null 2>&1. This command structure first redirects standard output (stdout, file descriptor 1) to the special device file /dev/null, which discards all data written to it. Then, 2>&1 redirects standard error (stderr, file descriptor 2) to the same location as standard output, effectively discarding error messages as well. Redirecting to /dev/zero is incorrect; its primary purpose is to provide a stream of null characters when read. Using a pipe (|) with /dev/null is incorrect because /dev/null is a device file, not a command that accepts standard input. Redirecting to /dev/random is also incorrect as this file is a source for random data and not intended for discarding output.

GRUB 2 regenerates its binary menu (/boot/grub2/grub.cfg) from templates in /etc/grub.d and the settings found in /etc/default/grub. Red Hat documentation states that you should edit /etc/default/grub (for example, by adding ipv6.disable=1 to the GRUB_CMDLINE_LINUX line) and then rebuild the menu with grub2-mkconfig -o /boot/grub2/grub.cfg. Editing grub.cfg directly is discouraged because the file is overwritten whenever grub2-mkconfig or update-grub is run. Placing the parameter in /etc/grub.d/40_custom or in /etc/sysconfig/kernel does not automatically propagate the option to every new kernel and therefore is not the preferred, maintainable approach.

The correct answer is that the root (/) directory is the primary hierarchy and contains the entire filesystem. According to the Filesystem Hierarchy Standard (FHS), all files and directories appear under the root directory, even if they are on different physical devices. The other options are incorrect as they describe other specific top-level directories:

• System-wide configuration files are stored in /etc.
• Shareable, read-only user utilities and applications are stored in /usr.
• Variable data files, such as logs and spools, are stored in /var.

The correct command is iperf3 -c 10.0.1.10 -R. By default, an iperf3 test sends data from the client to the server, which measures the upload speed of the client. The -R (or --reverse) flag reverses the direction of the test, causing the server (ServerA) to send data to the client (ServerB). This correctly measures the download speed on the client machine. The command iperf3 -c 10.0.1.10 would measure the upload speed from ServerB to ServerA. The command iperf3 -s -c 10.0.1.10 is invalid because the -s (server) and -c (client) flags are mutually exclusive. The --get-server-output flag is used to retrieve the server's final report at the client, but it does not alter the direction of the data transfer.

Using an unquoted delimiter with the standard here-document operator (<<) allows the shell to treat the body of the document like a double-quoted string: parameter expansion and command substitution occur. Crucially, all characters, including literal leading spaces, are copied to the command's standard input. This meets both requirements. Quoting the delimiter (<<'EOF') disables all expansions, so $SERVERNAME and $DOCROOT would be written literally. The <<- operator strips leading tab characters from each line of the document. Because the required indentation consists of spaces, this operator is not the correct tool for the job. The <<< operator is a here-string, not a here-document; it is designed to supply a single string to a command's standard input and is not the correct tool for embedding multi-line blocks of text. Therefore, the construction that uses an unquoted delimiter with << and a >> redirection is the only choice that satisfies both requirements.

The correct command is export PATH=$PATH:/usr/local/sbin. The PATH environment variable contains a colon-separated list of directories that the shell searches for executable files. To allow the shell to find the new scripts, their directory must be added to the PATH. The syntax $PATH:/usr/local/sbin takes the existing value of the PATH variable ($PATH) and appends the new directory, /usr/local/sbin, to the end of the list. The export command makes this new PATH variable available to any subsequent commands executed in the current session. Overwriting the PATH with export PATH="/usr/local/sbin" would remove all other essential system directories, causing most standard commands to fail. The source command is used to execute a script in the current shell, not to add a directory to the PATH. Setting permissions with chmod is a necessary step to make a script runnable, but it does not solve the issue of the shell not being able to locate the file.

The correct command is ./update.sh | tee update.log. The tee command reads from standard input and writes to both standard output and one or more files simultaneously. The pipe symbol | sends the standard output of the ./update.sh script to the standard input of the tee command. tee then displays that output on the terminal (its standard output) and saves it to the update.log file.

• The command ./update.sh > update.log uses the output redirection operator >, which sends the standard output only to the file, not to the screen.
• The command ./update.sh > update.log && tail -f update.log would only run tail -f after the ./update.sh script has finished successfully, which does not allow for real-time monitoring of the script as it runs.
• The command tee update.log < ./update.sh incorrectly tries to use the script file itself as standard input for tee, rather than executing the script and capturing its output.

The kernel itself cannot access an encrypted, LVM-based root filesystem without first loading extra drivers and user-space helpers. Those drivers (dm-crypt, LVM, the storage controller) and the utilities that unlock the LUKS container and activate the volume group are packaged inside the initramfs. When the kernel finishes its own hardware initialization, it runs the /init script from the initramfs. That script loads the required modules, starts cryptsetup to decrypt the volume, runs vgchange to make the logical volumes available, mounts the real root filesystem, and then hands control to the regular init system. If the initramfs were missing or incomplete, the kernel would have no way to reach the encrypted root device and the boot would fail. The other options describe tasks handled by GRUB, systemd, or the system firmware, none of which solve the problem of accessing an encrypted LVM root early in boot.

The correct answer is that /usr contains sharable, read-only data, including user programs and applications. According to the Filesystem Hierarchy Standard (FHS), /usr is designated for installed software, libraries, and documentation that is not required for the initial boot process and can be shared across multiple machines. /etc is the correct location for host-specific system configuration files. /var is designated for variable data files, such as logs, caches, and spool files, which are expected to change in size during normal system operation. /home is the standard directory for storing users' personal files and data.

The kernel maintains the definitive mount table and exposes it through the pseudo-file /proc/mounts (a symbolic link to /proc/self/mounts on modern kernels). Because the contents are generated on demand by the kernel, the file always shows the mounts that are visible in the calling process's mount namespace, regardless of whether /etc/mtab exists, is stale, or is a symlink. Reading /etc/fstab only shows administrator-configured entries, /proc/partitions lists block devices but not current mount options, and /run/mount/utab is a private runtime database used by libmount (util-linux) to track user-mount metadata-it is not maintained by the kernel and can be missing or stale. Therefore, parsing /proc/mounts is the most reliable way to verify that /tmp-or any filesystem-is currently mounted with the desired flags.

The /tmp directory is intended for temporary files that do not need to survive a reboot. It should be world-writable so every process can create temporary files, but it must also have the sticky bit set so that only the file owner (or root) can rename or delete each file. Setting the sticky bit is done by placing a leading "1" in the numeric mode, making the correct permission 1777 (displayed as drwxrwxrwt). Using 0777 leaves the directory world-writable without any protection; 2777 sets the SGID bit, which affects group ownership rather than deletion protection; 0755 removes write permission for non-owners, breaking many applications that rely on /tmp.

The persistent way to add a kernel parameter in GRUB 2 is to edit /etc/default/grub and then regenerate the main configuration. Add nomodeset to the GRUB_CMDLINE_LINUX or GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub, save the file, and run the appropriate command to rebuild the menu: update-grub on Debian/Ubuntu systems or grub2-mkconfig -o /boot/grub2/grub.cfg on RHEL-derived systems (UEFI systems use the /boot/efi/EFI/<distro>/grub.cfg stub). Editing /boot/grub2/grub.cfg (or /boot/grub/grub.cfg) directly is incorrect because those files are auto-generated and will be overwritten the next time the rebuild command runs-such as during a kernel update. /proc/cmdline only reflects the parameters of the currently running kernel, and /etc/sysctl.conf controls runtime kernel tunables, not boot-loader parameters.

resize2fs with the -P (print minimum) option calculates and displays the minimum number of blocks required for the current contents and then exits without altering the file system. Using -M would immediately shrink the file system to that minimum, -f merely forces a resize operation if one is attempted, and e2fsck only checks or repairs consistency-it does not report the minimum shrinkable size. Therefore the correct choice is the command that uses -P.

The initramfs (or initrd) image is a compressed archive that the bootloader loads into memory together with the kernel. The kernel unpacks it to create a temporary root filesystem that contains the drivers, modules, and early-boot scripts required to locate and mount the real root filesystem-whether it resides on LVM, RAID, encrypted storage, or over the network. Once the real root is mounted, control passes to the normal init system and the initramfs is discarded from RAM. It is therefore not a GRUB configuration file (that is grub.cfg), a compressed kernel image (that is vmlinuz), or a sector-map file generated by LILO (that is /boot/map).

The FHS designates /home as the default location for regular users' home directories. Placing a dedicated filesystem at /home lets every non-root account store its personal files and hidden configuration files in a predictable path such as /home/alice or /home/bob. The other paths serve different purposes: /usr/local is reserved for locally installed software that should survive distribution upgrades, /opt is intended for add-on application packages, and /srv holds data offered by network services such as web or FTP servers. Mounting the user volume at any of those locations would break established conventions and could confuse system tools or administrators; therefore /home is the correct choice.

The correct answer is /etc. The Filesystem Hierarchy Standard (FHS) specifies that the /etc directory is for host-specific, system-wide configuration files and directories. It should not contain any binaries. The /var directory is for variable data files, such as logs, spool files, and caches, which change during normal system operation. The /home directory is the default location for user-specific files and configurations, not system-wide ones. The /boot directory contains the static files required for the system's boot process, such as the kernel and bootloader files, not general service configurations.