chattr +a /opt/app/logs

Summary:
The requirement is to protect a log file so that new data can be appended (written to the end), but existing data cannot be deleted or overwritten, and the file itself cannot be removed. This calls for a filesystem attribute that enforces append-only mode, which is a common security measure for critical log files to preserve an audit trail.

Correct Option:

A. chattr +a /opt/app/logs:
This is the correct command. The +a flag sets the "append-only" attribute. When this attribute is set, the file can only be opened in append mode for writing. This prevents any existing content from being overwritten or truncated and also prevents the file from being deleted, perfectly meeting the requirement to preserve log history.

Incorrect Options:

B. chattr +d /opt/app/logs:
The +d flag sets the "no dump" attribute, which means the file will be skipped by the dump backup utility. It has no effect on file writing or deletion permissions.

C. chattr +i /opt/app/logs:
The +i flag sets the "immutable" attribute. This is stronger than required; it prevents all modifications to the file, including writing new data (appending). The file becomes completely read-only, which would stop the application from logging altogether.

D. chattr +c /opt/app/logs:
The +c flag enables automatic compression on the filesystem level. The kernel will automatically compress the file as it is written. This does not protect the file from being deleted or overwritten.

Reference:
Linux man-pages project (chattr): The official documentation describes the a attribute, which allows a file to be only opened in append mode for writing.

df

du

Summary:
A storage capacity issue has been reported without a specific location, meaning the administrator does not know which filesystem or directory is full. The troubleshooting process requires a two-step approach: first, identifying which mounted filesystem is low on space, and second, drilling down into that filesystem to find which specific files and directories are consuming the most disk space.

Correct Options:

B. df:
This is the most critical first command. The df (disk free) command, especially with the -h flag (df -h), provides a high-level overview of disk space usage for all mounted filesystems. It quickly shows the administrator which specific mount point (e.g., /, /home, /var) is at or near 100% capacity, narrowing down the problem area.

D. du:
Once the full filesystem is identified with df, the du (disk usage) command is used to investigate within that filesystem. Running du -sh /path/to/full/mountpoint/* sorts the subdirectories by size (du -sh /* | sort -h is also very effective), revealing the specific large files or directories responsible for the consumption.

Incorrect Options:

A. parted:
This is a disk partitioning and resizing tool. It is used to manage the partition table on a disk, not to troubleshoot filesystem capacity usage.

C. mount:
This command shows which filesystems are currently mounted and their options, but it does not show how much space is free or used on them.

E. fdisk:
This is a partition table manipulator. Like parted, it is used for managing disk partitions, not for analyzing disk space usage on existing filesystems.

F. dd:
This is a low-level tool for converting and copying files, often used for creating disk images or writing ISO files to USB drives. It is not a tool for diagnosing disk capacity.

G. ls:
The ls command lists directory contents and file names. While ls -lh shows file sizes, it is not efficient for recursively calculating the total size of directories, which is the primary function of du.

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 df and du commands are the fundamental tools for this objective.

The service does not have permissions to read write the startupfile.

Summary:
The systemctl status command reveals that the service failed to start and the log snippet shows a "Permission denied" error when trying to open a file. The file in question, /etc/startupfile, is owned by root:root with permissions 640 (rw-r-----). This means only the root user can read and write it, while the root group can only read it. All other users have no access. The service likely runs under a non-root user account that does not have the necessary read permissions for this file.

Correct Option:

A. The service does not have permissions to read the startupfile:
The "Permission denied" error is a direct indicator of this issue. The permissions 640 on a file owned by root:root grant read access only to the root user and members of the root group. If the service process runs as a different user (e.g., a dedicated service account), it will not have read access, causing the failure.

Incorrect Options:

B. The service startupfile size cannot be 81k:
There is no inherent restriction on service file sizes being 81k. This size is perfectly normal for a configuration or startup script and is not the cause of the "Permission denied" error.

C. The service startupfile cannot be owned by root:
It is standard and secure practice for system configuration and startup files in /etc to be owned by the root user. Ownership by root is not the problem; the problem is the lack of read permissions for the specific user context the service runs under.

D. The service startupfile should not be owned by the root group:
While fine-grained group ownership can be used, it is very common for system files in /etc to be owned by the root group. The current group ownership is not inherently wrong. The core issue remains the permissions (640) that exclude the service's user.

Reference:
systemd Official Documentation (System Unit Configuration): While not a direct permissions guide, the documentation emphasizes that services often run as specific users and must have appropriate file access.

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