Prepare for the Linux+ CompTIA Linux+ Exam

Free Linux+ Practice Questions (With Answers)

5 real questions from the Linux+ bank, with the full explanation for each answer. No sign-up needed to read them.

1. Question 1Security [File Permissions and ACLs]Choose all that apply

   A web app runs as user 'www-data' and needs read/write access to /var/app/uploads (currently root:root, mode 755). Which TWO approaches grant the minimum necessary access? (Choose two.)

   • A.chown www-data:www-data /var/app/uploads and set permissions to 700
   • B.setfacl -m u:www-data:rwx /var/app/uploads
   • C.chmod 777 /var/app/uploads
   • D.Add www-data to the root group and chmod 775 /var/app/uploads
   • E.chown www-data /var/app/uploads/* but leave the directory itself at 755
   Show answer and explanation

   Correct answer: A, B

   Correct. Ownership by www-data with 700 gives that user exclusive read/write/execute and no access to anyone else — least privilege via ownership.

   Correct. An ACL grants www-data rwx without changing ownership or exposing the directory to others — often preferred when root must retain ownership.

   Why the other options are wrong

   C. Incorrect. 777 grants write to every user on the system — a serious risk and far more than the minimum needed.

   D. Incorrect. This grants the entire root group access and is broader than necessary, violating least privilege.

   E. Incorrect. Owning the existing files lets www-data modify them, but creating, renaming or deleting entries needs write permission on the directory itself, which stays root-only at 755.

2. Question 2Security [firewalld]

   A company policy requires allowing SSH access ONLY from the 10.0.0.0/8 network on a public-facing server. Which firewall-cmd command sequence correctly implements this as a persistent rich rule?

   • A.firewall-cmd --zone=public --add-service=ssh --source=10.0.0.0/8 --permanent
   • B.firewall-cmd --zone=public --add-port=22/tcp --source-subnet=10.0.0.0/8 --permanent
   • C.firewall-cmd --zone=drop --add-service=ssh --permanent && firewall-cmd --zone=public --remove-service=ssh --permanent
   • D.firewall-cmd --zone=public --remove-service=ssh --permanent && firewall-cmd --zone=public --add-rich-rule='rule family=ipv4 source address=10.0.0.0/8 service name=ssh accept' --permanent
   Show answer and explanation

   Correct answer: D

   Correct. First remove the unrestricted SSH service (--remove-service=ssh), then add a rich rule that explicitly allows SSH only from 10.0.0.0/8. Rich rules support source address matching combined with service or port rules. Without removing the unrestricted service first, SSH would still be open to all.

   Why the other options are wrong

   A. Incorrect. firewall-cmd --add-service and --source are separate directives. --add-service=ssh opens SSH for ALL sources in the zone; you cannot restrict --add-service to a specific source subnet with a single command this way.

   B. Incorrect. --source-subnet is not a valid firewall-cmd option. Source-based filtering requires rich rules or source zones.

   C. Incorrect. The drop zone drops all inbound traffic including SSH. Adding SSH to the drop zone and removing it from public would block SSH entirely, not restrict it to 10.0.0.0/8.

3. Question 3Security [Authentication Services]

   A user can authenticate to a Kerberos-enabled service but receives 'Permission denied' accessing resources after authentication. The Kerberos ticket shows as valid. What is the most likely issue?

   • A.The Kerberos ticket has expired and needs to be renewed with kinit, so the service accepts the stale credential for login but rejects it the moment resources are requested.
   • B.The user's account exists in Kerberos but lacks a corresponding local or LDAP account for authorization checks (UID/group membership)
   • C.The Kerberos realm is misconfigured and the ticket is being issued by the wrong KDC, so authorization fails because the resource server trusts a wholly different realm.
   • D.Kerberos authentication bypasses PAM, so pam_sss.so must be reconfigured
   Show answer and explanation

   Correct answer: B

   Correct. Kerberos handles AUTHENTICATION (proving identity) but not AUTHORIZATION (access rights). After Kerberos confirms who you are, the system still needs to map the Kerberos principal to a local UID and group memberships for file/resource access decisions. If the user exists in Kerberos but not in /etc/passwd or LDAP (via SSSD), authorization checks fail. The fix: ensure user accounts are provisioned in the directory service (LDAP/AD) and SSSD is configured to retrieve them.

   Why the other options are wrong

   A. Incorrect. The question states the ticket shows as valid (kinit succeeded and klist shows a current ticket). Expiry is not the issue.

   C. Incorrect. If the KDC were wrong, ticket issuance itself would fail or the ticket would be rejected by the service — not result in a post-authentication 'Permission denied'.

   D. Incorrect. SSSD integrates PAM and Kerberos together. Kerberos authentication can work through PAM via pam_sss.so or pam_krb5.so. The issue described is an authorization problem, not a PAM configuration problem.

4. Question 4Security [Account Hardening]

   A security policy mandates MFA for all privileged SSH logins. An admin configures TOTP (Time-based One-Time Password) via Google Authenticator PAM module. After setup, admins with SSH keys can still log in without entering a TOTP code. What is the most likely misconfiguration?

   • A.The TOTP secret file has incorrect file permissions, causing the PAM module to silently skip the authentication check and allow the login to proceed
   • B.Google Authenticator PAM only works with password authentication, not key-based authentication
   • C.The pam_google_authenticator.so module must be listed before pam_unix.so in the PAM stack
   • D.The sshd_config is set to AuthenticationMethods publickey, which allows SSH key login to bypass all PAM authentication including TOTP
   Show answer and explanation

   Correct answer: D

   Correct. When sshd_config contains AuthenticationMethods publickey, SSH considers authentication complete after a valid key — PAM is not consulted for further factors. To enforce TOTP after key authentication, the correct setting is AuthenticationMethods publickey,keyboard-interactive (key + TOTP via PAM). Also, ChallengeResponseAuthentication (or KbdInteractiveAuthentication) must be enabled and UsePAM yes set for PAM TOTP to be invoked.

   Why the other options are wrong

   A. Incorrect. Incorrect permissions on the .google_authenticator file cause PAM to fail authentication, not silently skip it. A permissions issue would deny login rather than allow bypassing TOTP.

   B. Incorrect. pam_google_authenticator.so integrates with any PAM-aware authentication flow, including keyboard-interactive over SSH. The issue is the sshd AuthenticationMethods configuration, not a module limitation.

   C. Incorrect. Module ordering affects which module runs first and how required/sufficient flags interact, but it doesn't cause TOTP to be bypassed for key-authenticated sessions. The SSH daemon configuration is the root cause.

5. Question 5System Management [Hardware and Devices]

   After connecting a new USB storage device, it does not appear as a block device under /dev. Which commands should the administrator run to diagnose the issue? (Choose the BEST sequence)

   • A.dmesg | tail → lsusb → lsblk
   • B.lsblk → fdisk -l → mkfs.ext4 /dev/sdc
   • C.mount /dev/sdc /mnt → ls /mnt
   • D.udevadm info /dev/sdc → udevadm trigger
   Show answer and explanation

   Correct answer: A

   Correct. This is the diagnostic sequence: dmesg | tail shows whether the kernel detected the device (hardware events). lsusb confirms the USB device is recognized at the USB level. lsblk shows whether the kernel assigned a block device. This layered approach isolates where the detection failed.

   Why the other options are wrong

   B. Incorrect. This sequence assumes the device appears as sdc and immediately formats it. The correct approach is to first diagnose whether the kernel sees the device at all before attempting to use it.

   C. Incorrect. If the device doesn't appear under /dev, there is nothing to mount. This command would fail with 'No such file or directory'.

   D. Partially useful as a recovery step, but not diagnostic first. udevadm trigger re-runs udev rules but diagnosing whether the kernel saw the device at all (via dmesg) should come first.