CompTIA Linux+ (XK0-006) Practice Test

Explanation

The USER Dockerfile instruction sets the user for all subsequent RUN, CMD, and ENTRYPOINT instructions in the Dockerfile. Creating the user with RUN useradd -r -s /bin/false nodeuser followed by USER nodeuser correctly establishes a non-root runtime user. The -r flag creates a system account and -s /bin/false prevents shell login, which is good practice. Using RUN su nodeuser in the first option does not persist across layers; su only affects the current RUN layer, not subsequent instructions. Using USER nobody is problematic because nobody is a shared system user with minimal privileges that may have unintended access to other system resources, and chmod 777 /app creates a security vulnerability. Using su in CMD in the fourth option is unnecessarily complex, and setting ENV USER does not actually change the execution context.

Explanation

Systemd timers require two separate unit files: a .service file that defines what command to execute, and a .timer file that defines when to run the associated service. The service file needs at minimum a [Service] section with ExecStart specifying the command to run. The timer file needs a [Timer] section with OnCalendar to specify the schedule and Persistent=true to enable catch-up behavior when the system missed a scheduled run. Without Persistent=true, if the system is off at 2:30 AM, the task will be skipped until the next scheduled time. Using a cron entry would work for scheduling but does not provide the persistent catch-up functionality and is not a systemd timer approach. Systemd does not support combining service and timer definitions in a single unit file. The timesyncd.conf file is for NTP time synchronization configuration, not scheduling.

Explanation

The command 'journalctl -u sshd -b -1 --grep=Failed' correctly queries the systemd journal for the sshd service unit (-u sshd), restricts output to the previous boot session (-b -1), and filters messages containing 'Failed' using the --grep flag which applies PCRE2 pattern matching against the MESSAGE field. The -b flag uses a relative offset system where -1 means one boot prior to the current boot, -2 means two boots prior, and so on. This is the correct and only supported way to target a single previous boot session. Specifying multiple -b flags simultaneously (such as -b 0 -b -1) does not query two boot sessions at once. The second -b flag overrides the first, or the behavior is undefined depending on the systemd version. This option does not correctly address the requirement. The lastb command reads the binary /var/log/btmp file and shows failed login attempts, but it does not filter by service or limit output to a specific boot session. It also lacks the structured journal integration needed to reliably isolate pre-reboot events. Using --since yesterday queries by calendar time rather than by boot session boundary. If the server rebooted at 11:58 PM, '--since yesterday' would include entries from the current boot as well, and it does not guarantee results are limited to the previous boot session.

Explanation

set -e causes the script to exit immediately when any command returns a non-zero exit status. set -u treats references to unset variables as errors rather than expanding them to empty strings. set -o pipefail causes a pipeline to return the exit status of the last command that failed rather than the exit status of the final command, preventing silent failures in chains like 'grep pattern file | wc -l'. Combining these as 'set -euo pipefail' is the standard bash strict mode pattern used in production scripts. set -x prints each command before executing it (useful for debugging) and set -v prints input lines as they are read, but neither provides error handling or pipefail behavior. pipefail is NOT enabled by default — without it, 'false | true' returns 0. Using only -e and -u without pipefail leaves pipeline failures undetected.

Explanation

The correct approach is semanage fcontext to add a permanent file context rule followed by restorecon to apply that rule immediately to existing files. semanage fcontext -a adds a persistent rule to the SELinux policy database that survives relabeling and system reboots. restorecon -Rv then reads the policy database and applies the correct contexts to the specified path recursively. setenforce 0 only sets SELinux to permissive mode, which disables enforcement but does not fix the underlying context problem. chcon temporarily changes the context but the change is lost when the filesystem is relabeled or files are restored. setsebool adjusts boolean values for specific behaviors and is not the appropriate fix for a file context issue.