← Back

20 Authentication & System Hardening Practice Questions & Answers

Every Authentication & System Hardening practice question from the CompTIA Linux+ Practice Test, with the correct answer and a short explanation.

Start practice test
  1. 1. An auth stack in /etc/pam.d/login lists a module with the control flag requisite ahead of several other auth modules. What happens when that module returns a failure?

    • A.The stack keeps running the later auth modules, and the overall result is a failure once it ends.
    • B.The failure is recorded but ignored, and the result depends only on the other modules in the stack.
    • C.The remaining modules are skipped and authentication succeeds, because an earlier module already passed.
    • D.The stack stops immediately and authentication fails; the later auth modules are never consulted.Answer

    requisite is fatal on the spot: the library returns failure to the application at once, so nothing later in that management group runs. required also fails the stack, but only after every remaining module has been executed, which is why it is preferred when you do not want to reveal at which step the failure happened.

    Source: Linux-PAM System Administrators' Guide — control flags (requisite, required, sufficient, optional) in /etc/pam.d configurationReport a problem with this question

  2. 2. Policy requires that a new password be at least a set minimum length, draw on several character classes, and not repeat any of the user's recent passwords. Which mechanism enforces those three rules on a Linux host?

    • A.PASS_MIN_DAYS and PASS_MAX_DAYS in /etc/login.defs, which passwd applies at every password change.
    • B.The chage utility with -m and -M, because the aging fields of /etc/shadow hold the strength rules.
    • C.The password management group of the PAM stack, through the pam_pwquality and pam_pwhistory modules.Answer
    • D.The passwd command's own built-in checks, configured per account with the passwd -n and -x options.

    Length, character classes and reuse are quality checks run while a password is being set, so they belong to the password management group of the pluggable stack: pam_pwquality tests the candidate and pam_pwhistory compares it against the stored history. chage and login.defs only control aging — minimum and maximum days, warning and inactivity — and cannot express complexity at all.

    Source: pam_pwquality(8) and pam_pwhistory(8) manual pages; chage(1) and login.defs(5) for aging fieldsReport a problem with this question

  3. 3. A host is joined to a central directory. Running grep alice /etc/passwd returns nothing, yet getent passwd alice prints a full account entry. Which file decides that account lookups may reach beyond the local file?

    • A./etc/pam.d/system-auth, whose auth lines decide which back end validates an incoming login request.
    • B./etc/security/access.conf, whose rules decide which accounts may log in from which hosts or terminals.
    • C./etc/resolv.conf, whose nameserver lines decide which servers resolve names on behalf of the libraries.
    • D./etc/nsswitch.conf, whose passwd and group lines list the sources queried, in order, for account data.Answer

    The name service switch is the table that maps each database — passwd, group, shadow, hosts — to an ordered list of sources, so adding a directory source there is what makes remote accounts visible to every library call. That is also why getent is the correct way to test account resolution: grep only ever reads the flat file, while getent walks the same switch the login path uses.

    Source: nsswitch.conf(5) and getent(1) manual pagesReport a problem with this question

  4. 4. An environment runs both a central directory service and a ticket-based authentication service for Linux clients. Which statement correctly divides the work between the two?

    • A.The directory supplies attributes such as UID, groups and home path, while tickets prove identity without sending the password to each service.Answer
    • B.The directory issues time-limited tickets to each client, while the ticket service stores attributes such as UID, groups and login shell.
    • C.The directory fully replaces /etc/shadow on every client, while the ticket service is only a transport that encrypts directory queries in flight.
    • D.The directory decides which commands a user may run, while the ticket service keeps the offline credential cache used when the network is down.

    A directory is an identity store queried for account attributes and group membership, while a ticket-based protocol is an authentication mechanism: the client proves who it is once to the key distribution centre and then presents tickets, so no service ever handles the user's password. Because tickets carry timestamps and have a short validity window, clients and the key distribution centre must agree on the time, which is why a time synchronisation service is a hard dependency of this design.

    Source: CompTIA Linux+ Security content domain — authentication, authorization and accounting methods (directory services versus ticket-based authentication); krb5.conf(5) and kinit(1)Report a problem with this question

  5. 5. An administrator runs auditctl -w /etc/shadow -p wa -k shadow_changes. The rule appears in auditctl -l and events are recorded, but the rule is gone after a reboot. What makes the watch persist?

    • A.Append the rule to a file under /etc/rsyslog.d and restart the logging service, which reloads it at boot.
    • B.Write the rule into a file under /etc/audit/rules.d and load it with augenrules --load, which rebuilds the rule set.Answer
    • C.Enable persistent journal storage in /etc/systemd/journald.conf, because audit watches are kept with the journal.
    • D.Add the rule with auditctl -e 2, which locks the running configuration and writes it back to disk on shutdown.

    auditctl loads rules into the running kernel only, so anything added that way is lost at the next boot. The persistent path is a rules file under /etc/audit/rules.d, which augenrules compiles into the rule set the audit daemon loads at start; -e 2 does something different, it locks the configuration so no further rule changes are accepted until a reboot.

    Source: auditctl(8) and augenrules(8) manual pagesReport a problem with this question

  6. 6. A web process is denied access to a file even though the mode bits permit it, and nothing appears in the service's journal. Where is the denial recorded, and what distinguishes that subsystem from system logging?

    • A.In /var/log/messages: the logging daemon collects kernel access-control events under its authpriv facility.
    • B.In /var/log/audit/audit.log: the kernel audit subsystem records syscall and access-control events for later review.Answer
    • C.In the journal of the unit itself: access-control denials are emitted as messages by the process that was refused.
    • D.In /var/log/btmp: refused access attempts are appended to that file and are read back with the lastb utility.

    System logging collects messages that applications choose to emit, whereas the audit subsystem is a kernel facility that records events the kernel itself observes — system calls, watched file access and mandatory access-control denials — in its own log, independent of the journal and of the logging daemon. That is why an access-control denial can be invisible in the service's journal and still be fully documented in the audit log.

    Source: auditd(8) and ausearch(8) manual pages; CompTIA Linux+ Security content domain — accounting and audit proceduresReport a problem with this question

  7. 7. Why is delegating a task through sudo generally preferred over having the operator run su - to become root?

    • A.sudo authenticates with the root password but drops privileges after each command, so no root shell stays open.
    • B.sudo authenticates the caller with the caller's own password and records every command run, keeping actions attributable.Answer
    • C.su - consults /etc/sudoers for the caller's rules, so any command not listed there is refused before the shell opens.
    • D.su - authenticates with the caller's own password and logs each command, but cannot limit which commands run.

    sudo re-authenticates the calling user with that user's own credentials, consults a policy that can name individual commands and a target identity, and writes a log entry for each invocation, so the trail says which human ran which command. su - instead requires the target account's password, which means the password must be shared to be usable, and it hands back an interactive shell in which every subsequent action is attributed only to root.

    Source: sudo(8) and su(1) manual pages; sudoers(5) on logging and command specificationsReport a problem with this question

  8. 8. An administrator is about to add a delegation rule. Why should the policy be edited with visudo instead of opening /etc/sudoers directly in a text editor?

    • A.visudo encrypts the file after saving, so the rules cannot be read by users who do not already hold a delegation.
    • B.visudo locks the file against simultaneous edits and parses it on save, refusing to install a file that has a syntax error.Answer
    • C.visudo reloads the running service afterwards, a step that is required before any newly added rule can take effect.
    • D.visudo applies the new rule to the current shell session, so the change can be tested without logging out and back in.

    visudo takes a lock so two administrators cannot overwrite each other, and it runs the policy parser before replacing the live file, offering to re-edit when the syntax is wrong. That matters because a malformed policy file makes the whole delegation mechanism refuse to run, which can leave a host with no way to obtain elevated privileges at all; the same check can be run non-interactively to validate a file before it is put in place.

    Source: visudo(8) manual page — file locking and syntax checking of the sudoers policyReport a problem with this question

  9. 9. Members of the group dba must be able to restart only the database service, as root, on every host. Which entry, placed in a drop-in file under /etc/sudoers.d, expresses exactly that?

    • A.%dba ALL=(root) /usr/bin/systemctl restart postgresqlAnswer
    • B.%dba ALL=(root) NOPASSWD: ALL, restart postgresql only
    • C.dba ALL=(ALL:ALL) /usr/bin/systemctl restart postgresql
    • D.%dba postgresql=(root) /usr/bin/systemctl restart ALL

    A rule reads user host=(runas) commands, the % prefix makes the first field a group, and the host field is the host the rule applies to — ALL, never a service name. Naming the full command path with its argument is what limits the delegation; granting ALL, especially with a no-password tag, hands the group unrestricted root and removes the re-authentication step, which defeats the purpose of delegating a single task. Dropping the % silently creates a rule for a user account called dba instead of the group.

    Source: sudoers(5) manual page — user specifications, group prefix, host and runas fields, and #includedir drop-in filesReport a problem with this question

  10. 10. A rule lets an operator run a text editor as root so one configuration file can be fixed. Auditors object that the editor can spawn a shell with :!sh. Which sudoers tag addresses that?

    • A.NOPASSWD:, which stops the editor from prompting again and therefore from reaching a shell.
    • B.NOEXEC:, which prevents the delegated program from executing any further programs of its own.Answer
    • C.PASSWD:, which forces re-authentication whenever the editor tries to start another program.
    • D.SETENV:, which clears the environment so the editor cannot find a shell on the search path.

    Editors, pagers, interpreters and tools with an exec-style option can launch a child process that inherits the elevated privilege, which turns a narrow delegation into a full root shell. The NOEXEC tag blocks those child executions, so the delegated program can do its own job and nothing more; the password tags only change whether and when the caller must re-authenticate and have no effect on shell escapes.

    Source: sudoers(5) manual page — NOEXEC and EXEC tags, preventing shell escapesReport a problem with this question

  11. 11. Public-key login to a server fails and falls back to a password prompt. On the server, ls -ld shows /home/bob/.ssh as drwxrwxrwx and its authorized_keys as -rw-rw-r--, and the log says "Authentication refused: bad ownership or modes". What fixes it?

    • A.Run chmod 777 on /home/bob/.ssh and 666 on authorized_keys, so the daemon running as root can read the key.
    • B.Set PubkeyAuthentication yes and reload the daemon, because that refusal means public-key authentication is off.
    • C.Copy the private key into /home/bob/.ssh/authorized_keys, because the server compares the offered key with that half.
    • D.Run chmod 700 on /home/bob/.ssh and 600 on authorized_keys, since the server ignores group- or world-writable key files.Answer

    The server refuses to honour an authorized keys file that the owner's group or anyone else could modify, because a writable file would let a third party add their own key; strict mode checking therefore requires the directory at 700 and the file at 600, both owned by the user. Only the public half of the pair is ever installed on the server — ssh-copy-id appends it to authorized_keys — while the private half stays on the client, itself readable only by its owner.

    Source: sshd(8) manual page — AuthorizedKeysFile and StrictModes; ssh-copy-id(1)Report a problem with this question

  12. 12. A server's sshd_config contains PermitRootLogin prohibit-password together with PasswordAuthentication yes. What is the effect of that pair, and what hardens it further?

    • A.root can still log in with a key, and only PermitRootLogin no refuses root logins by every authentication method.Answer
    • B.root cannot log in by any method now; the only remaining change needed is PasswordAuthentication no for ordinary users.
    • C.root can log in with a password but not with a key, and PermitRootLogin no would block only the key-based path.
    • D.root can log in from the console only, and PermitRootLogin forced-commands-only would still allow interactive key login.

    prohibit-password blocks only the password and keyboard-interactive paths for root; public-key and certificate authentication still succeed, so remote root sessions remain possible. Setting the directive to no is what refuses root logins outright, and disabling password authentication separately is what pushes every other account onto keys.

    Source: sshd_config(5) manual page — PermitRootLogin and PasswordAuthenticationReport a problem with this question

  13. 13. Connecting to a server that has been reachable for months, ssh prints WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED and refuses to continue. What does that indicate?

    • A.The account's password was changed on the server, so the credential cached by the agent for that host is no longer accepted.
    • B.The user's private key no longer matches the public key in authorized_keys, so the server rejected the key that was offered.
    • C.The server's host key has reached the end of its validity, and a new pair must be generated on the client to reconnect.
    • D.The server's host key no longer matches the one recorded in known_hosts, as happens after a rebuild or during interception.Answer

    On the first connection the client stores the server's host key, and on every later connection it compares the key presented against that record; a mismatch means either the server's identity genuinely changed — a rebuild, a restored image, a regenerated key — or something is answering in its place. The client stops rather than prompting, because continuing would let an interceptor collect the session, so the correct response is to confirm the new fingerprint out of band before removing the stale entry.

    Source: ssh(1) manual page — host key verification and the known_hosts fileReport a problem with this question

  14. 14. An engineer runs ssh -A to reach internal servers through a shared jump host used by many teams. Why is forwarding the authentication agent discouraged on such a host?

    • A.The private key file is copied to the jump host for the duration of the session and stays readable there after logout.
    • B.The passphrase travels to the jump host in the clear so that the remote side can decrypt the key whenever it is needed.
    • C.The jump host is added to known_hosts as a trusted host, so later changes to its host key are accepted silently.
    • D.Anyone with root on the jump host can use the forwarded agent socket to authenticate as the engineer on other servers.Answer

    Agent forwarding does not copy the key; it exposes a socket on the intermediate host through which signing operations can be requested from the key held on the workstation. A user who can reach that socket — root, or anyone able to read it — can therefore authenticate anywhere the key is trusted, for as long as the session lasts, which is why forwarding should be limited to hosts you trust as much as your own and replaced by a jump-host option that never exposes the agent.

    Source: ssh(1) manual page — ForwardAgent and the -A option security caveat; ssh_config(5) ProxyJumpReport a problem with this question

  15. 15. On a RHEL-family host, getenforce reports Enforcing. An administrator wants first to confirm that policy is what blocks a service, and then to turn the mechanism off entirely. What is true of those two steps?

    • A.setenforce 0 switches the host straight to Disabled, and Permissive can only be selected by editing /etc/selinux/config.
    • B.Both Permissive and Disabled are selected with setenforce, and the value in /etc/selinux/config only governs filesystem labelling.
    • C.setenforce 0 switches to Permissive, where denials are only logged, but reaching Disabled needs /etc/selinux/config and a reboot.Answer
    • D.Permissive still blocks the access while recording it, so only Disabled in /etc/selinux/config can prove the policy is at fault.

    setenforce toggles only between Enforcing and Permissive, and the change lasts until the next boot; in Permissive the policy is still evaluated and denials are written to the audit log, but nothing is blocked, which makes it a diagnostic that confirms the cause. Entering or leaving Disabled means the policy is not loaded at all, so it requires the SELINUX setting in /etc/selinux/config and a reboot — and leaving a host disabled is not a fix, since the correct remedy is usually a label or a boolean.

    Source: setenforce(8), getenforce(8) and selinux(8) manual pages; /etc/selinux/config on RHEL-family systemsReport a problem with this question

  16. 16. On a RHEL-family web server, a file moved with mv into the served directory returns a permission error, and the audit log shows a context type mismatch. Which action corrects the label durably?

    • A.Set the type by hand with chcon -t, which writes the new label into the policy so later relabels keep it.
    • B.Copy the file again with cp --preserve=context, which stamps it with the destination directory's default label.
    • C.Add the path to the file-context rules with semanage fcontext, then apply them to the tree with restorecon -Rv.Answer
    • D.Run setenforce 0 and leave the host permissive, because the label will be corrected automatically at the next boot.

    mv preserves the security context a file already carried, while cp creates a new file that inherits the destination directory's default, which is why moving content into a served directory is the classic cause of a type mismatch. The durable repair is to record the expected context for that path in the file-context rules and then relabel, so the label survives any future relabelling; chcon changes the label immediately but is not recorded in the rules, so a relabel or a filesystem restore silently reverts it.

    Source: semanage-fcontext(8), restorecon(8) and chcon(1) manual pagesReport a problem with this question

  17. 17. On a RHEL-family host, setsebool httpd_can_network_connect on lets the web application reach a back-end service, but after a reboot the outbound connections are refused again. Why?

    • A.The reboot restored the file contexts of the tree, and the boolean is stored as an extended attribute of that directory.
    • B.The boolean chosen was the wrong one, and only a custom policy module can permit outbound connections from a service.
    • C.The change was written only to the running policy; the -P option is needed to store it as the boolean's default value.Answer
    • D.Booleans are read from /etc/selinux/config at boot, so the setting has to be added as a line in that file to survive.

    A boolean is a switch that turns an optional part of the policy on or off without writing any new rules, and setsebool changes it in the running kernel only. Adding -P also writes the value to the persistent policy store, so it is restored at boot; the current values of all booleans can be listed to confirm which ones are set and whether the stored default matches what is live.

    Source: setsebool(8) and getsebool(8) manual pages — the -P option and persistent boolean valuesReport a problem with this question

  18. 18. A hardening standard requires that an account be locked automatically after a number of consecutive failed password attempts and be unlocked again after a defined interval. Where is that enforced, and by what?

    • A.In the PAM stack, by the faillock module, whose deny and unlock_time settings count failures for each account.Answer
    • B.In sshd_config, by MaxAuthTries, which locks the account after that many failed attempts within one connection.
    • C.In /etc/shadow, by the inactive field, which locks the account once the recorded failure count passes the limit.
    • D.In /etc/login.defs, by PASS_MAX_DAYS, which disables the account when repeated failed attempts are recorded.

    Lockout is an authentication-time decision, so it belongs in the pluggable stack: the faillock module keeps a per-user tally of consecutive failures and denies authentication once the configured threshold is reached, releasing the account after the unlock interval, and an administrator can clear a counter early with the faillock utility. The older tally module that once did this job has been removed from the library, so faillock is the current implementation; MaxAuthTries only limits attempts within a single connection and locks nothing.

    Source: pam_faillock(8) and faillock(8) manual pages; sshd_config(5) MaxAuthTriesReport a problem with this question

  19. 19. A package creates a service account that owns files and runs a daemon but must never be able to open an interactive session. Which setting expresses that requirement?

    • A.Set the account's login shell to nologin, so an interactive login attempt prints a short message and exits at once.Answer
    • B.Set an account expiry date in the past with chage -E, so the daemon keeps running while any session is refused.
    • C.Give the account a UID below the regular user range, which the login program refuses to start a shell for.
    • D.Put a single asterisk in the account's password field in /etc/shadow, which removes its access to the home directory.

    Replacing the login shell with nologin is the standard way to say "this identity exists to own processes and files, not to be logged into": the program prints a refusal message and exits with a failure status, so no shell is ever started for that account. A UID inside the system range is only a convention and does not block a shell, and an expiry date is an account-lifecycle control meant for real users rather than a statement about interactive use.

    Source: nologin(8) manual page; useradd(8) -r and -s options for system accountsReport a problem with this question

  20. 20. SSH logins to a server must require both a valid key and a one-time code from an authenticator application, in that order. Which sshd_config setting, paired with a PAM module for the code, expresses that?

    • A.PubkeyAuthentication yes together with PasswordAuthentication yes, so the client may present either of the two methods.
    • B.AuthenticationMethods publickey keyboard-interactive, which lets the client use whichever of the two methods it holds.
    • C.AuthenticationMethods publickey,keyboard-interactive, which makes a session satisfy both methods in turn before it opens.Answer
    • D.UsePAM yes together with PermitEmptyPasswords no, which adds the code prompt once the offered key has been accepted.

    AuthenticationMethods lists the methods a session must complete, and the separator carries the meaning: a comma joins methods that must all succeed in the order given, while a space separates alternative lists of which any one is enough. So the comma form is what produces two factors — something you have in the key, something generated by the authenticator through the keyboard-interactive path into the pluggable stack — whereas simply enabling two methods leaves the client free to use one.

    Source: sshd_config(5) manual page — AuthenticationMethods, comma-separated required methods versus space-separated alternativesReport a problem with this question

Practice questions written to the published CompTIA Linux+ exam objectives and to standard Linux administration practice. CompTIA and Linux+ are marks of CompTIA, and Linux is a registered trademark of Linus Torvalds; this site is not affiliated with or endorsed by CompTIA. The real exam mixes multiple-choice items with performance-based questions that ask you to carry out a task in a simulated environment — those cannot be reproduced in a four-option format, so this bank covers the knowledge half and you should practise on a real system alongside it. CompTIA revises and version-numbers the objectives periodically: confirm the current objectives, exam code and requirements with CompTIA before testing. About the CompTIA Linux+ certification →