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.

• ✗

  Ignore the alert because service accounts often authenticate outside normal business hours.

  Why it's wrong here

  Ignoring the alert solely because service accounts can legitimately authenticate outside business hours is a dangerous assumption. Service accounts are typically configured for non-interactive logons (e.g., Logon Type 5 for services), so an interactive logon using such an account is inherently anomalous regardless of the time of day. Attackers frequently operate during off-hours with compromised service credentials to evade normal monitoring, so dismissing the event without verification could miss lateral movement or privilege abuse. The alert should be triaged by correlating with change calendars, scheduled tasks, and ticketing records rather than dismissed.

• ✓

  Correlate the activity with the change calendar, scheduled-task logs, and ticketing records before escalating.

  Why this is correct

  The best first step in triage is to determine whether the activity is authorized or anomalous. Because service-account use can be legitimate, the analyst should correlate the logon with maintenance windows, scheduled-task history, and approved change records. That quickly separates normal administrative activity from suspicious lateral movement without prematurely disrupting operations.

• ✗

  Immediately disable the service account to stop any potential attacker activity.

  Why it's wrong here

  Immediately disabling the service account based solely on a SIEM alert is premature and operationally disruptive. The account may be required by scheduled tasks, automated workflows, or dependent services, so disabling it could cause widespread outages even if the logon is later deemed legitimate. Furthermore, an attacker may notice the account being cut off and destroy evidence or accelerate their activity. Triage should first validate the context of the logon through logs and ticketing, and only after confirming malicious intent should the account be disabled through the proper incident response process.

• ✗

  Reimage the file server to remove any possible compromise.

  Why it's wrong here

  Reimaging the file server is a drastic recovery action that is entirely inappropriate as an initial triage step. It destroys volatile memory, event logs, and other forensic evidence that would be essential for determining how the logon occurred and whether the system is actually compromised. Reimaging also assumes compromise before validation, which can be unnecessarily costly and disruptive if the alert is a false positive. In incident response, containment and evidence preservation take priority, and reimaging is reserved for later stages after a confirmed compromise and proper forensic collection.

Go deeper

Related to this question