Free CompTIA Linux+ XK0-005 Practice Test

Applying NAT at the host level will allow containers to share the host's IP address to access the external network. The traffic from the containers will appear to originate from the host's IP, thus not requiring a public IP for each container. Direct bridge networking would not solve the problem of public IP allocation for each container, Layer 2 bridging with NAT is not a standard approach for container networking, and VLAN tagging is typically used to separate LAN segments and is not directly related to the NAT process.

The correct command is audit2allow -M mymodule < /var/log/audit/audit.log. It reads the AVC denial messages from the specified log file and generates a custom SELinux policy module named 'mymodule'. The -M option specifies the name of the module. This command is designed to interpret AVC messages and create a tentative policy that permits the denied actions, easing the process of troubleshooting and adjusting SELinux policies.

The other options, audit2why, semanage module -i, and getenforce, serve different purposes. The audit2why command is used to interpret denial messages and provide explanations, not to generate policy modules. semanage module -i would be used to install a module, not create one. getenforce simply reports the current SELinux enforcement mode and does nothing related to policy creation.

The correct answer is pwd, which stands for 'print working directory'. This command is used to output the full pathname of the current working directory, providing users with their exact location in the filesystem hierarchy. This information is especially important when performing operations that are sensitive to the current directory context, such as deploying applications, running scripts, or managing files.

The correct answer is git stash your changes and then use git checkout feature-login. This is because you can save your uncommitted changes with git stash, which acts like a stack where you can push changes to be temporarily stored, and later you can pop them off. After stashing your changes, you can safely change branches using git checkout. Using the other commands might either lead to a loss of local changes or are not correct commands for handling a change in branches.

The correct answer is 'johndoe ALL=(ALL) NOPASSWD: /usr/local/bin/backup.sh', and it should be added using the visudo command. This command specifically allows 'johndoe' to run the backup script without a password. The visudo command is used instead of direct file editing tools because it includes syntax checking to prevent errors that could render the sudoers file unusable or introduce security vulnerabilities. Other options listed either require a password, do not specify the script, grant broader permissions than required, or use incorrect syntax.

The 'Type=notify' setting is used when the service sends a notification message via the sd_notify() function to inform systemd that it has finished its initialization and is ready to handle requests. Other types such as 'simple' assume the service is ready as soon as the binary is executed, while 'forking' assumes readiness when the initial process exits.

The 'make install' command is used after compiling software to copy the binaries, libraries, and any associated files to the appropriate system directories, allowing the software to be run from anywhere on the system. This step often requires administrative privileges because it modifies system-level directories.

In Kubernetes, a Deployment manages a group of identically configured containers, providing declarative updates to the application. Deployments allow for easy scaling, self-healing, and rolling updates to the containerized applications, which is ideal for scenarios needing smooth scaling and high availability. While Pods are the smallest deployable units and can hold one or more containers, they do not by themselves provide scaling or self-healing capabilities. That is orchestrated by a Deployment. Services are used to expose an application running on a set of Pods as a network service, and while they help in communication aspects and remain constant despite changes in Pods, they aren’t the mechanism for managing container scaling. StatefulSets are similar to Deployments but are intended to manage stateful applications and provide unique identity to each pod they manage, which is not the focus of this scenario.

The correct answer is docker logs --tail 50 web-app. The --tail option with the docker logs command allows the user to view the specified number of most recent lines from the container's logs, making it an appropriate choice for checking recent activity or errors that could lead to understanding the issue with the container.

The setenforce 0 command sets SELinux to 'Permissive' mode. In 'Permissive' mode, SELinux continues to evaluate rules and log violations but does not enforce the policy, allowing the administrator to see what would be blocked without impacting the application. Once the evaluation is complete, using setenforce 1 would return SELinux to 'Enforcing' mode. 'setsebool -P' is used to make persistent changes to SELinux booleans, enforce 0 is invalid syntax, and setenforce enforcing uses incorrect terminology. The term 'Disabled' does not apply to runtime changes and is only set in SELinux config files which requires a reboot.

The command pwd (print working directory) is used to display the absolute pathname of the current working directory. This is the most direct and explicit command for this purpose, hence it is the correct answer. Understanding the current directory's absolute path is essential for numerous tasks, like referencing files or changing directories. The other options, ls for listing directory contents, cd - for moving to the previous directory, and dirname for extracting a path's directory part, do not serve the purpose of displaying the current directory's path.

The correct 'awk' command filters the output of 'du' by dividing the first column (size in kilobytes) by 1048576 to convert it to gigabytes and prints the size along with the username, which is inferred from the directory name after the last slash in the second column. The 'substr($2,7)' function is utilized to remove '/home/' (the first 6 characters), leaving the username. Only records with a size greater than 1GB are output.

As for the incorrect answers:

• The second answer overlooks the requirement to convert kilobytes to gigabytes before comparing to 1GB.
• The third answer uses incorrect syntax, merging the 'if' construct improperly.
• The fourth answer is incorrect because it prints all records, and it attempts to use a field '$3' that does not exist in the 'du' output.

The correct answer is 'Deploy both containers within a single pod'. In Kubernetes, a Pod represents one or more containers that should be run together. Containers within the same pod share the same IP address, network, and storage resources, which means they can communicate with each other using 'localhost' and can access shared volumes. This is the exact scenario described, making it the ideal solution. The other options do not correctly represent how containers are co-located to share resources in the Kubernetes context. Creating separate pods for each container would not allow them to share network and storage resources directly. Configuring a service or deploying a DaemonSet would not target the issue at hand, which is the shared network and storage for closely related containers.

The /etc/nsswitch.conf file determines the order of lookups performed when a certain type of information is requested, with the services listed from left to right in order of preference. The correct configuration is passwd: ldap files and group: ldap files, which first attempts to resolve password and group information using LDAP and then falls back to local files if LDAP is not available. The wrong answers suggest looking up files before LDAP, which would not meet the requirement, or including services not mentioned in the scenario, such as NIS.

Docker Compose is a tool for defining and running multi-container Docker applications. With a Compose file (usually docker-compose.yml), you can define the services, networks, and volumes that need to be created and run together. Compose setups help in maintaining consistency in environments and streamlining the deployment process. The other options, such as Kubernetes and Cloud-init, are not as applicable for single-node, local development scenarios. Compose fits perfectly here since it is designed to deal with multi-container Docker applications on a single node, as opposed to orchestrating clusters of nodes.