Set PermitRootLogin to no in the /etc/ssh/sshd_config file.

Summary:
The requirement is to prevent remote administrative login specifically via the SSH service. This means blocking the ability to log in as the root user over an SSH connection. The configuration must be applied to the SSH daemon (server) itself, as it controls which authentication methods and users are permitted for remote logins.

Correct Option:

B. Set PermitRootLogin to no in the /etc/ssh/sshd_config file:
This is the direct and correct method. The PermitRootLogin directive in the SSH server's configuration file (sshd_config) explicitly controls whether the root user can log in via SSH. Setting it to no disables this capability, which is a standard security practice for hardening servers.

Incorrect Options:

A. Add the line DenyUsers root to the /etc/hosts.deny file:
The /etc/hosts.deny file is used by the TCP Wrappers system (hosts_access) to control access for services compiled with libwrap support. While SSH often supports this, the more specific and reliable method is to use the native SSH configuration. Furthermore, the correct syntax in hosts.deny for the SSH daemon would be sshd : root or similar, not DenyUsers root.

C. Add the line account required pam_nologin.so to the /etc/pam.d/sshd file:
The pam_nologin.so module prevents all non-root users from logging in if the /etc/nologin file exists. It does not specifically target the root user or remote administrative logins via SSH.

D. Set PubKeyAuthentication to no in the /etc/ssh/ssh_config file:
The ssh_config file is the client configuration file, not the server configuration. This change would affect outgoing SSH connections from this server, not incoming connections to it. Furthermore, it disables public key authentication for all users, which is a common and secure authentication method, not a specific restriction on the root user.

Reference:
OpenSSH Manual (sshd_config): The official documentation for the SSH daemon configuration file describes the PermitRootLogin directive.

YAML

Summary:
Ansible is a widely used configuration management and automation tool. Its core components, playbooks, are files that define a set of automation tasks, configurations, and roles to be executed on managed nodes. Playbooks are designed to be human-readable and easy to write, using a specific data serialization language that relies on indentation and simple key-value pairs to define the desired state of the systems.

Correct Option:
B. YAML:
This is the correct and required language for writing Ansible playbooks. Ansible playbooks are almost exclusively written in YAML (YAML Ain't Markup Language). YAML's clean, indentation-based syntax is ideal for defining the hierarchy of plays, tasks, variables, and modules that make up an Ansible automation workflow. Its readability is a key feature for maintaining and sharing automation code.

Incorrect Options:

A. SQL:
SQL (Structured Query Language) is a domain-specific language used for managing and querying data in relational database management systems (RDBMS). It is not used for writing system automation scripts or configuration management playbooks.

C. HTML:
HTML (HyperText Markup Language) is a standard markup language used for creating web pages and applications that are displayed in a web browser. It defines the structure and presentation of web content and is not a programming or automation language.

D. JSON:
While Ansible can technically accept JSON for its playbooks, this is the exception and not the rule. JSON is more verbose and error-prone for humans to write due to its strict requirement for quotes, brackets, and commas. The Ansible documentation and community overwhelmingly use and recommend YAML for playbook creation due to its superior readability and simplicity.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This question aligns with Objective 4.1: "Given a scenario, implement and configure automation," which specifically lists Ansible as a key automation technology. Knowledge that Ansible playbooks are written in YAML is a fundamental prerequisite for using the tool. The official Ansible documentation states that playbooks are expressed in YAML format.

df -h

Summary:
A filesystem is reported as full, meaning the disk space allocated to a mounted partition is 100% utilized. The administrator needs a command that provides a high-level, summarized overview of disk space usage for all mounted filesystems. This allows for quick identification of which specific mount point is at or near capacity.

Correct Option:

C. df -h:
This is the ideal command for this task. The df (disk free) command reports the amount of disk space used and available on mounted filesystems. The -h (human-readable) option presents the sizes in a readable format (e.g., G for gigabytes, M for megabytes), making it easy to quickly scan and identify which filesystem is at 100% usage.

Incorrect Options:

A. lsblk:
The lsblk (list block devices) command lists information about all available block devices (disks, partitions, LVM). It shows the hierarchy and size of storage devices but does not show the disk space usage or how full a mounted filesystem is. It shows capacity, not consumption.

B. fdisk:
The fdisk command is a utility for manipulating disk partition tables. It is used for creating, deleting, and managing partitions, not for reporting real-time disk space usage on mounted filesystems.

D. du -ah:
The du (disk usage) command is used to estimate file and directory space usage. The -ah flags show disk usage for all files and directories in a human-readable format. While powerful, it is used to drill down within a filesystem to find which specific files or directories are consuming the most space, after df -h has been used to identify the full filesystem.

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 managing disk quotas and file compression. The first step in managing disk space is using df to identify the problem filesystem.

chage -E -1 accountname

Summary:
The administrator needs to remove the expiration date from a user account. Account expiration is managed by the shadow password system, which stores this information. The correct command must interact with the user's aging information and specifically clear the field that holds the expiration date.

Correct Option:

D. chage -E -1 accountname:
This is the correct command. The chage command is used to change user password expiry information. The -E option sets the account expiration date. Using -E -1 is the standard way to remove an account expiration date, effectively making the account never expire.

Incorrect Options:

A. chgrp system accountname:
The chgrp command changes the group ownership of a file, not the properties of a user account. It cannot modify account expiration dates.

B. passwd -s accountname:
The passwd -s command reports the password status for a user account (e.g., if it's locked). It is a read-only command and cannot change account expiration settings.

C. chmod -G system accountname:
The chmod command changes file permissions. The -G flag is invalid in this context. This command is syntactically incorrect and unrelated to user account management.

Reference:
Linux man-pages project (chage): The official documentation explains the -E option and states that setting the date to -1 will remove the account expiration date.

docker exec ls

Summary:
The administrator needs to check the contents of a container's root directory to confirm the presence of a specific file (app.go). This requires a command that can execute a listing command inside a running container to view its filesystem directly. The solution involves interacting with a running container instance to inspect its live directory structure.

Correct Option:

C. docker exec ls:
This is the correct command. The docker exec command runs a new command inside a currently running container. The command docker exec ls / will execute the ls command in the container's root directory (/) and display the results, allowing the administrator to see if app.go is listed there. This provides a direct view of the container's filesystem.

Incorrect Options:

A. docker image inspect:
This command provides detailed, low-level information about the image itself in JSON format, such as its layers, creation history, and configuration. It does not show a simple directory listing of the files within the root directory of a built container.

B. docker container inspect:
Similar to image inspect, this command returns low-level configuration and state information about a container in JSON format. While this data includes the container's defined working directory and entry point, it does not provide a directory listing of the container's filesystem contents.

D. docker ps :
The docker ps command is used to list running containers (or all containers with the -a flag). It shows high-level information like container ID, image, command, status, and ports. It does not allow you to inspect the contents of the container's filesystem.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 1.5: "Given a scenario, manage and configure containers," which includes using Docker commands to manage containers. The docker exec command is a fundamental tool for interacting with running containers and troubleshooting their contents.

find . -type f -print | xrags grep -li denied

Summary:
The administrator needs to search through multiple log files for the word "denied" in a case-insensitive manner (matching "denied", "DENIED", "DeNiEd", etc.) and generate a list of filenames that contain this pattern. The solution requires a command that recursively finds all regular files, searches their content without regard to case, and prints only the names of the files where a match is found.

Correct Option:

D. find . -type f -print | xargs grep -li denied:
This is the correct command combination.

find . -type f -print finds all regular files in the current directory and its subdirectories.

xargs takes this list of filenames and passes them to the grep command.

grep -li denied:
-l (lowercase L) lists only the filenames where a match is found.

-i makes the search case-insensitive, which meets the requirement to find "denied" in any case.

The pattern denied will be matched regardless of case.

Incorrect Options:

A. find . -type f -print | xargs grep -ln denied:
The -n flag tells grep to print the line number along with the matching line. The -l flag is not present, so it will output the matching lines themselves instead of just the filenames. This creates a verbose output of content, not a clean list of filenames. It also lacks the -i flag for case-insensitive search.

B. find . -type f -print | xargs grep -nv denied:
The -n shows line numbers, and the -v flag inverts the match, showing lines that do NOT contain the word "denied". This would list files and lines that are unrelated to the search term, which is the opposite of what is requested. It also lacks the -i flag.

C. find . -type f -print | xargs grep -wL denied:
The -w flag matches only whole words, which is good, but the -L flag (uppercase L) lists files that do NOT contain the pattern. This would generate a list of all log files that do not have "denied" in them, which is the opposite of the goal. It also lacks the -i flag for case-insensitivity.

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 searching and extracting data from files using tools like find and grep. Knowing the key grep options like -i, -l, and -L is essential for log analysis.

usermod -s /bin/bash joe

Summary:
The output shows the result of searching for user joe in the key user databases. The /etc/passwd file reveals that Joe's login shell is set to /bin/nologin, which explicitly prevents interactive shell logins. The /etc/shadow file shows his password hash and account policy settings. The core issue preventing login is the restrictive shell assignment.

Correct Option:

A. usermod -s /bin/bash joe:
This is the correct command to resolve the issue. The usermod command is used to modify an existing user account. The -s option specifically changes the user's login shell. By setting Joe's shell to /bin/bash (a standard, interactive shell), it overrides the current /bin/nologin setting, thereby allowing him to log in to the system successfully.

Incorrect Options:

B. pam_tally2 -u joe -r:
This command is used to reset the failed login counter for a user, which would unlock an account that was locked due to too many failed password attempts. There is no evidence in the output (like a "Account locked" message or a high failed count in the shadow file) that suggests this is the problem.

C. passwd -u joe:
This command is used to "unlock" a user's password, which is only relevant if the password was explicitly locked using passwd -l. The password status field in the /etc/shadow output (the second field) does not show a ! or !! prefix that would indicate a locked password; it shows a valid hash, so the password is not locked.

D. chage -E 90 joe:
This command sets an absolute expiration date for the user account itself (90 days from the epoch, which is a date in 1970). This is not the issue, as the "Account expires" field in the chage -l output would be empty or set to "never". The problem is the login shell, not an expired account.

Reference:
Official CompTIA Linux+ (XK0-005) Certification Exam Objectives: This scenario falls under Objective 3.3: "Given a scenario, manage users and groups," which includes user account creation and modification. The usermod command is a core utility for this objective, specifically the -s option for defining a user's login shell.

id_rsa.pub

Summary:
The administrator has set up SSH key-based authentication, which uses a pair of cryptographic keys. The private key remains securely on the client machine and is used to prove identity. The public key is the one that must be distributed to remote systems and placed in the ~/.ssh/authorized_keys file of the target user account. This allows the remote server to verify a login attempt from a client that possesses the corresponding private key.

Correct Option:

D. id_rsa.pub:
This is the public key file for the default RSA key pair. This is the file that must be transferred to the remote server and appended to the authorized_keys file to enable passwordless login. The .pub extension explicitly denotes it as the public key.

Incorrect Options:

A. id_dsa.pem:
This filename is a combination of an old key type and a common certificate format. Standard SSH private keys are not typically named with a .pem extension, and DSA keys are considered weak and deprecated for modern SSH use.

B. id_rsa:
This is the private key for the default RSA key pair. This file must never be shared or moved to remote servers. It should be kept secure and private on the local client machine.

C. id_ecdsa:
This is the private key for an ECDSA key pair. Like id_rsa, this is a private key and must not be shared with remote servers. The corresponding public key that would be shared is named id_ecdsa.pub.

Reference:
OpenSSH Manual (ssh-keygen): The official documentation explains the key generation process and the files created, including the private and public key pairs. https://man.openbsd.org/ssh-keygen

docker image pull java:7

Summary:
The administrator needs to make the Java 7 container image available locally on the machine so developers can use it. Container images are typically stored in a central registry, such as Docker Hub. The correct command must download (or "pull") the specified image from the registry to the local machine's image cache, making it available for creating containers.

Correct Option:

B. docker image pull java:7:
This is the standard and correct command. It contacts the configured container registry (by default, Docker Hub) and downloads the image tagged as java:7 to the local system. After this command completes, both java:8 and java:7 will be available for use with docker run or in container deployments.

Incorrect Options:

A. docker image load java:7:
The load command is used to import an image from a tar archive that was previously created with docker save. It is used for loading images from a file, not from a registry. Since the image is on a registry, pull is the correct operation.

C. docker image import java:7:
The import command creates a filesystem image from a tarball (often a root filesystem). It is not used for downloading pre-built application images like Java from a registry.

D. docker image build java:7:
The build command creates an image from a Dockerfile. It is used for creating custom images from source code and instructions, not for downloading existing, pre-built images from a registry.

Reference:
Docker Documentation (docker pull): The official documentation explains that docker pull downloads an image from a registry.

/etc/systemd/journald.conf

Summary:
The question asks for the configuration file that controls the behavior of the systemd-journald service. This service is responsible for collecting and storing log data (journal logs) on systems using systemd. Like other core systemd components, it has a dedicated configuration file where settings like log storage location, size limits, and forwarding rules can be defined.

Correct Option:

A. /etc/systemd/journald.conf:
This is the correct and standard location for the system-wide configuration of the systemd-journald service. Administrators edit this file to set parameters like Storage=, SystemMaxUse=, and ForwardToSyslog= to control how journal logs are handled.

Incorrect Options:

B. /etc/systemd/systemd-journalctl.conf:
This file name is incorrect and does not exist. journalctl is the command-line tool for querying the logs, not the service that collects them. The service is named systemd-journald.

C. /usr/lib/systemd/journalctl.conf:
This path is also incorrect. The /usr/lib/systemd/ directory is typically reserved for default unit files and configuration provided by the distribution packages. The administrator should not edit files here; the active configuration is in /etc/.

D. /etc/systemd/systemd-journald.conf:
This is a commonly chosen distractor due to the accurate service name. However, the official and standard configuration file is named journald.conf, not systemd-journald.conf.

Reference:
systemd Official Documentation (journald.conf): The official man page details all the configuration options available in the journald.conf file.