SY0-701 Security Operations Practice Question
During morning SIEM review, an analyst sees 37 failed SSH logins followed by a successful login to a Linux server from a jump host. The account belongs to a configuration-management service account, and the activity occurred inside the normal maintenance window. What should the analyst do next to determine whether the alert is a true positive or a false positive?
⚠ Common exam trap
Test-takers frequently assume any failed logins followed by a success indicate a brute-force attack, but the context of a maintenance window and a service account points to legitimate automation retries, not malicious activity.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Correlate the event with the approved maintenance ticket and automation job logs.
The analyst should correlate the failed SSH logins with the approved maintenance ticket and automation job logs to verify if the activity is expected. The failed logins followed by a successful login from a jump host during a maintenance window are consistent with a configuration-management tool (e.g., Ansible, Puppet) retrying authentication. This correlation confirms whether the alert is a true positive (unauthorized access) or a false positive (routine automation).
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Immediately isolate the Linux server from the network and begin recovery.
Why it's wrong here
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.
- ✓
Correlate the event with the approved maintenance ticket and automation job logs.
Why this is correct
Matching the authentication pattern to a change ticket and automation logs is the best validation step. It confirms whether the repeated failures and successful login were produced by an approved task rather than malicious activity. This is the most efficient way to distinguish a true positive from an expected operational event without disrupting a legitimate maintenance process.
- ✗
Reset the service account password before reviewing any additional evidence.
Why it's wrong here
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's wrong here
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.
Go deeper
Related to this question
Learn chapter
Identity and Access Management
Key term
Service account
A service account is a special type of account used by an application or a virtual machine, rather than a human user, to authenticate and interact with cloud services and APIs securely.
Key term
SIEM
SIEM (Security Information and Event Management) is a system that collects and analyzes log data from across an IT environment to detect and respond to security threats in real time.
About these practice questions
This SY0-701 question is part of Courseiva's 1,013-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.