SY0-701 Security Operations Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Password spraying against many accounts with a low number of attempts per account.

  Why this is correct

  The observed pattern is classic password spraying: an attacker tries one or two common passwords (e.g., 'Company123' or 'Winter2024') against 36 distinct usernames, spacing attempts to stay below lockout thresholds. Because each account sees only a single failure, no account locks, and the attack spreads horizontally rather than hammering one user. A SIEM would see many different users with one failed VPN authentication each, exactly matching this low-and-slow credential-stuffing variation.

• ✗

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

  Why it's wrong here

  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's wrong here

  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's wrong here

  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.

Go deeper

Related to this question