Authentication Factors practice questions

The pattern is most consistent with password spraying across many accounts.

Why it fails: Password spraying is characterized by a small number of common passwords being tried against a large set of usernames, specifically to avoid triggering account lockout policies. In this SIEM data, all 17 failures are concentrated on a single account, not distributed across many accounts. That concentration is the opposite of spraying's low-and-slow approach, so while both are credential attacks, the pattern does not match spraying.

The events primarily indicate a volumetric denial-of-service attack.

Why it fails: A volumetric denial-of-service attack is designed to exhaust network bandwidth, server connections, or other resources by flooding them with high-volume traffic. The events here consist of 17 authentication failures and a token creation — neither of which generates the massive traffic required for a DoS. There is no indication of resource saturation or service unavailability, so the sequence is clearly about credential access and session abuse, not availability disruption.

Token creation proves the account password was never exposed.

Why it fails: Creating a token after a successful login is often the direct result of the attacker authenticating with the correct password, which could have been obtained through the brute-force attack. Tokens are issued by identity providers after authentication succeeds, so their existence is evidence that the password was used, not that it was never exposed. A compromised password frequently leads to token creation as part of persistence, so this option misreads the forensic artifact.

Immediately disable the account and wait for the employee to return.

Why it fails: This is premature containment, not triage. Disabling the account without first validating the alert—such as correlating the sign-in IP, device, and time with the user's normal behavior—may block a legitimate session and cause business disruption. It also violates standard incident response phases (identification before containment), and prevents you from gathering additional log evidence or interviewing the user while the context is still fresh.

Close the alert as a false positive because the user is on vacation.

Why it fails: Vacation status alone does not validate the sign-in; it only indicates the legitimate user is not physically at work. An attacker who has obtained the user's credentials through phishing or credential stuffing can sign in from anywhere, and the alert may reflect that malicious activity. You must review the authentication logs for anomalies like impossible travel, impossible login times, or unusual ASN/IP reputation before dismissing it.

Reimage the user’s workstation before checking any logs.

Why it fails: Reimaging is a final remediation step, not a first triage action, and it destroys volatile and forensic evidence on the endpoint—including Prefetch files, $UsnJrnl records, browser cache, and memory artifacts—that could reveal the attack vector and scope. Additionally, if the sign-in came from a compromised token, stolen credentials via a VPN, or another endpoint, reimaging the local workstation does not address the root cause and could give a false sense of security.

Credential stuffing

Why it fails: Incorrect. Credential stuffing uses previously leaked username and password pairs from other breaches. It typically shows many failed attempts but often with the same password tried across different accounts, not many different passwords against one account.

Password spraying

Why it fails: Incorrect. Password spraying involves using a small number of common passwords against many different accounts to avoid lockout thresholds. The scenario describes many attempts against a single account, which is the opposite of password spraying.

Dictionary attack

Why it fails: Incorrect. A dictionary attack uses a list of common words or phrases as password guesses. While it is a type of brute-force, the term 'dictionary attack' implies a specific subset of guesses. The scenario suggests a more exhaustive, non-dictionary-based iteration (e.g., alphanumeric combinations) typical of a general brute-force attack.

Spear phishing

Why it fails: Spear phishing is a targeted cyberattack that occurs via email or electronic messaging, in which the attacker customizes the content for a specific victim or organization to increase credibility, often enticing the victim to click a malicious link or open an attachment. The attack vector relies on digital text-based communication that can be filtered or analyzed by security tools. In this scenario, the communication channel is a phone call, not email; hence, while the attacker may use a pretext, the lack of any link, attachment, or email component makes spear phishing technically inapplicable, and vishing is the correct voice-specific term.

Pretexting

Why it fails: Pretexting is the act of creating a fabricated scenario (pretext) to obtain information, and it can be used across different communication channels. While the attacker does use a pretext in this scenario, 'vishing' is the more specific term when the attack occurs via phone. In the context of CompTIA Security+, vishing is the best answer because it directly identifies the medium (voice).

Tailgating

Why it fails: Tailgating is a physical security attack in which an unauthorized person follows an authorized individual through a secured entrance, doorway, or checkpoint to gain entry without presenting their own credentials. This attack requires in-person presence at a restricted facility and typically exploits the authorized person's courtesy or inattention to access control measures. Because the scenario involves a phone call rather than physical proximity, tailgating cannot occur; the attacker is not physically following anyone, but is conducting a remote social engineering attempt.

The invoice is confidential because the signature encrypts the document contents.

Why it fails: Digital signatures do not provide confidentiality by themselves. The document may still be readable to anyone who has access to it. The exhibit only shows the signature validated successfully, which speaks to trust and integrity, not secrecy.

The invoice can be edited if the timestamp is still within business hours.

Why it fails: A timestamp does not grant permission to modify a signed document. If the file were edited, the digest would no longer match the signature. The exhibit explicitly says the digest matches, which supports integrity, not a temporary editing window.

The sender’s private key is now public because the certificate verified successfully.

Why it fails: Verifying a certificate does not expose the sender’s private key. The private key remains protected and should never be made public. Successful verification only means the public certificate chain and signature were accepted as valid by the trust store.

Least privilege

Why it fails: The scenario does not describe minimizing user permissions; it focuses on layering different types of controls. Least privilege is about granting only the minimum necessary access rights, which is not the primary principle demonstrated here.

Separation of duties

Why it fails: Separation of duties is an administrative control that splits critical tasks or privileges among multiple individuals to prevent conflicts of interest, fraud, or accidental damage—for example, requiring two different people to approve and execute a wire transfer. The scenario describes only technical security controls (e.g., firewalls, MFA, monitoring) and says nothing about dividing human responsibilities or restricting access per role. Thus, this principle is not demonstrated by the architect's strategy, which is focused on in-depth technical layering rather than on organizational task distribution.

Fail safe

Why it fails: Fail safe refers to a system defaulting to a secure state when a failure occurs (e.g., a door locking on power loss). The architect's approach does not specifically address failure modes but instead builds layered defenses.

Preventive controls, because they stop every possible compromise completely.

Why it fails: The measures do reduce risk, but they do not eliminate all compromise paths and are not being used in the normal ideal way. The important clue is that the primary security requirements cannot be met on the device itself, so alternate controls are used instead.

Corrective controls, because they repair the controller after an incident occurs.

Why it fails: Corrective controls address damage after a security event or restore systems to a secure state. The exhibit describes measures already put in place before an incident to reduce exposure. That makes them compensating, not corrective, controls.

Deterrent controls, because they mainly scare attackers away from trying.

Why it fails: Deterrent controls discourage attacks, such as visible signage or warning banners. The exhibit contains concrete technical and procedural restrictions that limit access and increase visibility. Those measures do more than discourage; they compensate for missing native protections.

Configure an account lockout policy to lock the 'admin' account after three failed attempts.

Why it fails: An account lockout policy on a critical database server could lock out legitimate administrators if they accidentally mistype credentials, and it may not prevent the attacker from moving to other target accounts. This option is incorrect because it negatively impacts availability and does not address the source IP.

Disable the 'admin' account until the source IP can be investigated.

Why it fails: Disabling the 'admin' account is an account-centric response that fails to stop the attack traffic from reaching the server; the brute-force attempts will continue, merely returning authentication failures. More importantly, this account is likely a privileged service or emergency account, so disabling it can break automated processes, lock out other administrators, and violate availability requirements. Because the malicious activity originates from a specific source IP, the correct containment is to block that IP at the perimeter firewall, preserving the account's legitimate use while cutting off the attacker. This option is therefore overly aggressive, operationally risky, and does not remediate the actual network-level threat.

Require multi-factor authentication on the 'admin' account for all remote logins.

Why it fails: While MFA strengthens authentication, it does not stop the current attack because the attempts are still hitting the server and using up processing resources. Also, MFA may not be supported by all legacy systems or could be bypassed. It is a good preventive control but not the best immediate mitigation.

LDAP injection

Why it fails: LDAP injection exploits vulnerabilities in applications that build LDAP filters from user input without proper sanitization, using constructs like `(&(uid=user)(userPassword=pass))` or wildcard `*` to bypass authentication. The observed payloads (`OR '1'='1'`, `DROP TABLE`) are structured for SQL's WHERE-clause logic, not for LDAP filter syntax, which relies on parentheses, ampersands, and pipe characters (e.g., `(|(cn=...)(uid=...))`). Hence, the attack targets a SQL backend, not an LDAP directory.

Command injection

Why it fails: Command injection is an attack where an attacker manipulates user-supplied input to execute arbitrary operating system commands on the host server by injecting shell metacharacters such as `;`, `|`, `&&`, or backticks. The log entries show SQL-specific syntax, not these command separators or OS command names (e.g., `cat`, `ls`, `whoami`). Therefore, this activity is not indicative of command injection.

Cross-site scripting (XSS)

Why it fails: Cross-site scripting (XSS) occurs when an attacker injects malicious client-side scripts, such as JavaScript, into web pages that are then executed in the browsers of other users. The observed log entries contain SQL keywords and operators like `OR '1'='1'` and `DROP TABLE`, rather than script tags, event handlers, or payloads like `<script>alert(1)</script>`, which would be expected for XSS. Thus, the attack pattern does not match XSS.

Immediately delete the account to stop any further access attempts.

Why it fails: Deleting a user account is an irreversible administrative action that destroys the user's mapped access rights, group memberships, and associated ACLs; it also severs any attribution chain needed for forensic investigation. At triage stage, the analyst lacks evidence that the account is truly compromised rather than a misconfigured MFA or a scripted logon. Deleting also interrupts legitimate business operations and can trigger data recovery and identity restoration efforts. The correct immediate step is to gather more context, not to destroy the identity asset.

Assume the account is compromised and notify all users to change their passwords.

Why it fails: Assuming compromise and forcing a company-wide password reset is a classic over-reaction to a single account's anomaly. The event is localized to one finance user, so a mass reset creates broad operational friction and password fatigue without addressing the actual source IP or authentication behavior. Worse, it may tip off an actual attacker and cause them to change tactics before the analyst has correlated logs. Triage requires evidence-based scoping: first confirm whether the failed attempts came from a known baseline, an internal service account, or a legitimate remote user with a stale VPN session.

Close the alert because one successful login means the activity was normal.

Why it fails: A single successful login does not validate the preceding 38 failures as normal; in a brute-force or credential-stuffing attack, the one success is precisely the final event. Attackers often use distributed source IPs and timing offsets to evade simple lockout policies, so the analyst must inspect sign-in timestamps, federated identity provider events, and the user's historical geographic pattern. Closing the alert based on a single success ignores the possibility of account takeover that will be followed by data exfiltration. The alert requires correlation with anti-malware, EDR, or cloud identity analytics to determine if post-authentication behavior is anomalous.

Increase the retention period so the backup console will keep more copies.

Why it fails: Increasing the retention period only dictates how long older backup sets are retained in the repository; it has no effect on the authentication process that occurs when the backup application connects to the storage or encryption service. Restore failed because the service account or encryption credentials are no longer valid, not because there are too few copies available. Even with hundreds of retained backups, a restore will still fail if the restore engine cannot authenticate to the backup data, so retention changes are irrelevant to this symptom.

Disable the backup software firewall rule and try the restore again later.

Why it fails: An authentication failure, typically signified by HTTP 401, 'Access Denied', or 'Invalid password', indicates that the identity presented by the backup application was rejected, which is a credential problem, not a communication problem. Firewall rules control network flow (ports, IPs, protocols) and cannot cause an account to fail password verification; if the firewall were blocking traffic, the error would be a timeout or 'connection refused'. Disabling the backup software's firewall rule would not fix the authentication error and would expose the backup infrastructure to unnecessary attack surface, making it the wrong remedy.

Delete and recreate all protected files because the backup repository is probably corrupt.

Why it fails: Deleting and recreating all protected files would destroy the source data while doing nothing to address the authentication failure that occurs when the restore process tries to access the backup repository. Repository corruption typically manifests as checksum mismatches, I/O errors, or a backup console warning, not as an authentication failure during restore. Before taking such a destructive action, the correct approach would be to verify the backup repository with vendor integrity checks, test an alternate restore point, or validate the service account permissions — not blindly delete data.

Authentication, because the user proved their identity with credentials.

Why it fails: Authentication is the initial step of proving identity via credentials like a password or smart card, but the scenario specifically occurs after the employee has already signed in. At that point, the portal has established the user's identity, so the subsequent check of whether they may upload files to a particular folder is a permission decision, not another identity verification. Thus, while authentication is necessary, it is not the process being described in the post-sign-in access control.

Accounting, because the portal is recording the folder permissions for later review.

Why it fails: Accounting (auditing) involves recording user activities after the fact for review—such as logging which user uploaded a file, the timestamp, and the folder accessed—to enable security monitoring and compliance. The scenario, however, describes the system actively deciding whether to allow or deny the upload based on the user's assigned rights or group membership. Permission enforcement is a real-time authorization decision, not the passive logging of events that accounting entails.

Nonrepudiation, because the portal proves the user cannot deny uploading a file.

Why it fails: Nonrepudiation ensures that a user cannot deny having performed an action, typically through cryptographic mechanisms like digital signatures or robust audit logs that bind an actor to a specific event. It does not, by itself, determine whether the user has the right to upload a file; that access-control decision is made during authorization. In this case, the portal's permission check is a precondition to the action, not a proof of the action's occurrence, so nonrepudiation is irrelevant to the described process.

A hash value published on the mirror site alone

Why it fails: A hash value published on the mirror alone only proves that the file matches a value available at the same location; if the mirror is compromised, an attacker can replace both the package and the hash with a malicious file and a recomputed digest. For the hash to be meaningful, it must be delivered out-of-band from a trusted source, such as the vendor's secure website, but even then it only attests to data integrity, not to the identity or authenticity of the file's creator. Thus, a mirror-published hash cannot prevent an attacker who controls the mirror from distributing a tampered package that still appears to 'verify'.

Symmetric encryption of the package with a shared secret

Why it fails: Symmetric encryption uses a single pre-shared key for both encryption and decryption, so any party with that key can decrypt the package, but it provides no proof of origin. Because the same key is shared between the vendor and the consumer, a malicious distributor who knows the key could re-encrypt a modified package and the receiver would have no way to distinguish it from an authentic one. Additionally, symmetric encryption alone does not generate an integrity tag; the ciphertext can be altered or replaced without detection. Therefore, while it offers confidentiality, it is wholly inadequate for verifying that a package came from a specific vendor and was not tampered with.

Key stretching with a slow password algorithm

Why it fails: Key stretching algorithms such as PBKDF2, bcrypt, and scrypt are designed to make password guessing computationally expensive by deriving a cryptographic key from a low-entropy password through many repeated rounds. They serve a single purpose: to slow down offline brute-force and dictionary attacks on user-chosen passwords. Applying key stretching to a downloaded package would neither generate a vendor-specific identity nor bind the package's content to a signer, and it would not detect modifications because the derived key has no relation to the file's integrity. It is a one-way derivation used in authentication, not a mechanism for software provenance or tamper detection.

Corrective control

Why it fails: Corrective controls are reactive measures that restore systems after an incident, such as patching a vulnerability after exploitation or restoring from backup after ransomware. In this scenario, MFA is unavailable from the start, and the team is proactively deploying alternative safeguards to reduce risk before any breach occurs. The controls described (jump host, approvals, logging) are not remediating an existing compromise; they are compensating for a missing control. Therefore, calling them corrective mischaracterizes their timing and purpose.

Deterrent control

Why it fails: Deterrent controls aim to dissuade potential attackers by signaling that security measures exist, such as warning banners, guard dogs, or visible surveillance. They do not actually block or substitute for authentication mechanisms; they only influence the adversary's decision to attack. The scenario's measures—a hardened jump host, approval workflow, and enhanced logging—actively constrain and monitor access rather than merely discourage it. These are operational safeguards that enforce security, not psychological deterrents, so this classification does not fit.

Preventive control

Why it fails: Preventive controls are primary defenses that stop threats from materializing, such as firewalls, access control lists, or required MFA on the application itself. The legacy payroll app cannot enforce MFA, so the team cannot implement a true preventive control at that layer; they must layer alternative controls around it. While a hardened jump host might prevent unauthorized access, it is fundamentally a compensating measure—not the preferred control—and its purpose is to mitigate the gap left by missing MFA. Calling it preventive ignores the context that it serves as a substitute, not the original safeguard.

A brute-force attack focused on a single locked account.

Why it fails: A brute-force attack on a single locked account would generate a dense burst of password guesses against one username, typically dozens or hundreds of rapid authentication failures, followed by a lockout or successful guess. The log here shows exactly one failed attempt per account across 36 different accounts, which is the opposite of a focused, high-volume attack. Additionally, the account being 'locked' implies the attack already caused a lockout, but SIEM would show the repeated failures that produced it, not isolated single failures.

A replay attack using captured authentication data.

Why it fails: In a replay attack, the attacker captures a valid authentication token, hash, or session cookie and re-sends it to gain access, meaning the original credential still works and authentication would succeed, not fail. The SIEM log showing 36 failed password attempts indicates active guessing of passwords, not reuse of previously captured authentication data. Reused credentials would appear as successful VPN logins, possibly with anomalous source IPs or unusual timestamps, rather than distributed login failures.

A port scan that accidentally triggered authentication failures.

Why it fails: A port scan probes for open TCP/UDP ports and does not submit user credentials, so it would not produce failed VPN authentication events for 36 named accounts. VPN authentication logs are generated only after a VPN client presents a username and password, and a scanner does not typically engage in application-layer login sequences. While a scan might trigger connection timeouts or TLS handshake errors, it would not systematically cause password verification failures across many different usernames.

A brute-force attack focused on a single account with repeated rapid guesses.

Why it fails: In a true brute-force attack, the adversary iterates through a large password list against one target username, generating a high volume of failed authentication events for that single account. This signature contrasts with password spraying, where each account sees only a few failures, because the same guessed password is tried across many usernames to avoid triggering lockout thresholds. Since the SIEM correlation shows the same public IP testing one shared password across a wide set of accounts rather than hammering a single user, the event pattern does not match brute force.

A replay attack using captured authentication traffic from a previous session.

Why it fails: A replay attack involves capturing a valid authentication exchange, such as a Kerberos ticket, NTLM hash, or session cookie, and resending it to trick the service into accepting it as a fresh login. The SIEM would generally see a successful reuse of that captured artifact, not a burst of failed password attempts distributed across many distinct usernames from one source IP. Moreover, the observed events show the attacker testing a password against multiple accounts, which requires interactive guessing rather than the passive replay of prior traffic, so this explanation does not account for the scattered failures that precede the eventual success.

Credential stuffing using known breached username and password pairs.

Why it fails: Credential stuffing relies on username/password pairs obtained from prior data breaches, so each authentication attempt uses a unique credential that is expected to be valid for that specific user. In contrast, the SIEM evidence indicates the same single password value being applied systematically across many accounts, which is the hallmark of password spraying and not of credential stuffing. Additionally, credential stuffing typically produces one failure per username for each breached pair tried, whereas the observed pattern demonstrates a shared guess reused across a broad account set, making the two attack vectors distinguishable by their password reuse characteristics.

SMS one-time code, because it is widely supported and easy for users to adopt.

Why it fails: While SMS one-time codes are convenient and provide an additional authentication factor, they are not phishing-resistant because the SMS channel can be compromised via SIM-swapping attacks, where an attacker asks the carrier to port the victim's number to a device they control. Even without porting, the code can be intercepted by malicious apps with SMS permission or through signaling system vulnerabilities, and a real-time relay can forward the one-time code to the legitimate site to defeat the second factor. NIST SP 800-63B now deprecates SMS for out-of-band verification, underscoring that it is unsuitable for privileged administrator authentication.

Email one-time link, because it can be delivered to any mailbox quickly.

Why it fails: Email one-time links are functionally tied to the security of the mailbox infrastructure and the user's email account, not to a dedicated phishing-resistant device or possession factor. An attacker who gains access to the mailbox, or who is positioned to intercept email in transit, can click the link or extract the embedded token and authenticate as the user without their consent. Additionally, an email link can be manually forwarded by the user under a phishing duress scenario, and it does not cryptographically bind the authentication request to the legitimate destination, so it fails the requirement for a phishing-resistant factor.

Authenticator app TOTP code, because it adds a second factor without special hardware.

Why it fails: TOTP authenticator apps add a true possession factor because the secret key is stored on the user's device, but they lack origin binding, meaning the one-time code is not cryptographically tied to the specific website or application being accessed. An adversary-in-the-middle proxy, such as a real-time phishing kit that simply mounts a live relay, can capture the user's username and password, ask the user for the current TOTP code, and replay it to the legitimate site within the 30-second validity window, successfully authenticating as the user. This vulnerability to real-time intercept and replay is precisely why TOTP is considered a legacy second factor and is not classified as phishing-resistant for privileged access.

The package can only be decrypted by the vendor's private key

Why it fails: This option describes an encryption scenario: if a package were encrypted with a public key, only the corresponding private key could decrypt it. Digital signature verification, however, does not involve decrypting the package content; the vendor signs a cryptographic hash of the file, and the team verifies that signature using the vendor's public key. Thus the statement confuses confidentiality (encryption) with authenticity/integrity (signing).

The package is encrypted with the vendor's public key

Why it fails: Saying the package is encrypted with the vendor's public key would imply the vendor used asymmetric encryption to protect the data's confidentiality, so that only the vendor's private key can read it. Code-signing processes do not require or imply encryption of the payload; they compute a digest and sign that digest, leaving the actual file in plaintext. Successful signature verification tells the team the file's integrity and origin are intact, not that the file was encrypted for secrecy.

The vendor's certificate has not expired

Why it fails: A certificate expiration check is only a part of validating the signer's identity and key lifecycle; it does not demonstrate that a specific signed file has not been modified. Even if the vendor's certificate is currently valid, an attacker could alter the package, causing the signature verification to fail. The verification's core result is a cryptographic binding between the vendor's private key and the package's exact contents, whereas cert expiration merely indicates whether the certificate is within its issuance validity period.

Immediately isolate the Linux server from the network and begin recovery.

Why it fails: Immediately isolating the Linux server and starting recovery skips the triage step, potentially turning an expected operational glitch into an unplanned outage. A burst of 37 failed logins is often caused by a cron job with a rotated credential or a misconfigured admin script, not an active attacker. Isolating first also risks losing volatile evidence such as live SSH sessions, process memory, and network connections, which would be critical if this is a genuine intrusion. Validate the event against change tickets and automation logs before taking any containment action.

Reset the service account password before reviewing any additional evidence.

Why it fails: Resetting the service account password before reviewing evidence would disrupt the exact automation that may have triggered the failed attempts, and it does not confirm whether the alert is genuine. If a legitimate scheduled task is using a stale or mistyped password, rotation will force that task to fail and could cascade into other service failures. It also fails to determine whether an attacker already leveraged the account, making it premature as a response step. Password changes should follow validation and threat scoping, not precede them.

Disable SSH on the server until the next patch cycle is complete.

Why it fails: Disabling SSH on the server is an unnecessarily broad containment measure that breaks remote administration and could block the legitimate maintenance window that the alert likely belongs to. Unlike isolation, which blocks network paths, disabling the service itself would stop all SSH-based automation and monitoring, potentially escalating a noisy SIEM alert into a larger incident. The failed logins may stem from an approved patch script or a scheduled key rotation job, and suppressing SSH would obscure that evidence and delay recovery. The correct first action is to compare the event with maintenance tickets and job scheduler logs.

Shared generic accounts for each department.

Why it fails: Creating a shared generic account for each department (e.g., a single 'sales@' login) would make every member of the department authenticate with identical credentials, destroying non-repudiation and auditability. It is impossible to tell which specific user performed a given action, which complicates incident response and compliance reporting. Additionally, password changes must be communicated to everyone, and when any user leaves, the shared password must be rotated and redistributed, making it both a security and an administrative burden.

Storing the same password inside every SaaS application.

Why it fails: Storing the same password in every SaaS application forces users to use either a single weak password or a memorable one for all services, dramatically increasing the risk of credential stuffing and lateral compromise. If one SaaS provider is breached and hashes are cracked, the same password allows access to all other applications, including sensitive corporate data. This approach also violates the principle of least privilege and does nothing to address centralized authentication or account lifecycle management.

Disabling MFA so the sign-in process is faster.

Why it fails: Disabling MFA is not only unnecessary for achieving single sign-on, but actively undermines security. SSO centralizes authentication at the identity provider, so an attacker who obtains a user's password gains access to every federated application at once. Keeping MFA enabled adds a strong, second-factor verification at the corporate IdP, protecting all downstream SaaS services from a single weak point without degrading the user experience.