CS0-003 Security Operations Practice Question
A security analyst is tuning a SIEM rule that generates alerts for every failed login attempt. The rule is causing alert fatigue. Which TWO actions would reduce false positives while maintaining security visibility?
⚠ Common exam trap
The trap is choosing severity threshold changes or retention increases as if they reduce alert volume — they do not; only aggregation, correlation, and suppression actually cut false positives.
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
✓
Aggregate alerts by source IP and time window
Option A is correct because aggregating failed-login alerts by source IP and time window (e.g., using a threshold such as 5 failures in 5 minutes) collapses repetitive noise into a single meaningful event, preserving visibility into brute-force patterns while cutting alert volume. Option C is correct because whitelisting known internal service IPs that legitimately produce repeated failed logins (e.g., misconfigured service accounts or scanners) suppresses expected benign activity without hiding genuine external attack attempts. Option B is wrong because disabling the rule entirely eliminates detection of brute-force and credential-stuffing attacks, destroying security visibility. Option D is wrong because raising the severity threshold only changes how alerts are labeled or escalated; it does not reduce the number of false-positive alerts generated. Option E is wrong because increasing log retention affects storage duration, not alert generation, so it does nothing to address alert fatigue.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Aggregate alerts by source IP and time window
Why this is correct
Aggregating alerts by source IP and time window groups multiple failed login attempts into a single, consolidated alert, effectively suppressing repetitive notifications while still preserving detection of brute-force or credential-stuffing activity. This correlation technique condenses dozens or hundreds of individual events into one actionable incident, reducing analyst alert fatigue and allowing the security team to focus on the actual attack pattern rather than being overwhelmed by event-level noise.
- ✗
Disable the rule entirely
Why it's wrong here
Disabling the rule entirely removes all visibility into failed login attempts, which are often the first indicator of brute-force attacks, credential stuffing, or account compromise. This leaves the SIEM blind to a critical early-warning signal, and even if the rule is noisy, providing zero detection coverage is a much greater security risk. The correct approach is to tune the rule's aggregation and filtering logic, not to delete it outright.
- ✓
Whitelist IP addresses of internal services that generate repeated failed logins
Why this is correct
Whitelisting IP addresses belonging to internal services that legitimately generate repeated failed logins suppresses known-benign events, such as an application with misconfigured credentials or a service account whose password expired. This targeted exclusion reduces false positives while preserving detection for truly suspicious IPs, but it must be applied narrowly and reviewed periodically because if a whitelisted service account is compromised, its malicious activity would also be silently ignored.
- ✗
Increase the alert severity threshold
Why it's wrong here
Raising the alert severity threshold does not reduce the number of alerts generated by the rule; it only changes how severe the resulting alert is labeled (e.g., from high to critical) and may affect notification pathways, not the frequency of alert creation. Noisy rules need to be filtered via aggregation, whitelisting, or by adjusting the rule's match conditions, not by altering severity, which can actually worsen the problem by causing critical-level alerts to be ignored due to the same noise volume.
- ✗
Increase the log retention period
Why it's wrong here
Increasing the log retention period affects only how long raw logs are stored for compliance or forensic analysis, and has no bearing on real-time alert generation or rule matching. The SIEM evaluates inbound event streams against rule logic essentially at the moment they arrive, so keeping logs longer will not lower the number of triggered alerts. Log retention is an operational and compliance concern, not a detection and tuning control.
Go deeper
Related to this question
Learn chapter
Container and Kubernetes Security Analysis
Key term
Alert fatigue
Alert fatigue is the desensitization and overwhelming feeling security analysts experience when they receive so many security alerts that they begin to ignore or miss them.
Key term
Event
An event is any identifiable occurrence or action in a computer system, network, or application that can be logged, monitored, or analyzed for security or operational purposes.
About these practice questions
This CS0-004 question is part of Courseiva's 701-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CS0-004 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 CS0-004 exam.