Security Operations →mediumMultiple ChoiceObjective-mapped

SY0-701 Security Operations Practice Question

A web application was updated at 10:00. At 10:05, the SIEM reports a sharp rise in HTTP 500 errors and WAF blocks from the same source range. The application owner says customers are seeing failures only on the new checkout page. What is the best next step?

⚠ Common exam trap

A common mix-up: candidates assume WAF blocks always indicate an attack and choose Option A, failing to recognize that a recent deployment could introduce bugs that cause both 500 errors and false positive WAF triggers.

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 deployment, WAF, and application logs to determine whether the release or an attack caused the failures.

The temporal correlation between the deployment at 10:00 and the spike in HTTP 500 errors and WAF blocks at 10:05 strongly suggests a causal relationship. The best next step is to correlate deployment logs, WAF logs, and application logs to determine whether the new checkout page code introduced a bug (causing 500 errors) or whether an attacker is exploiting a vulnerability in the new code (triggering WAF blocks). This diagnostic step avoids premature conclusions and ensures the root cause is identified before any remediation.

Answer analysis

Option-by-option breakdown

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

✗
Close the incident because the WAF is blocking the suspicious traffic.
Why it's wrong here
WAF activity alone does not confirm an attack; false positives can block legitimate traffic and itself cause an outage. The customer-facing failures began right after a deployment, so the same symptoms could result from a code defect or misconfiguration. Closing the incident without correlating WAF events with release and application logs leaves the true root cause unaddressed and risks repeated disruption.
✓
Correlate deployment, WAF, and application logs to determine whether the release or an attack caused the failures.
Why this is correct
This is the best next step because the timing strongly suggests either a bad deployment or an exploit attempt against the new checkout page. Correlating release records with WAF events and application logs helps determine whether the errors are caused by a coding defect, an input validation issue, or hostile traffic. That analysis lets the team respond appropriately instead of assuming the WAF alone has solved the problem.
✗
Disable all customer accounts until the failures disappear from the dashboard.
Why it's wrong here
Disabling all customer accounts is a broad, denial-of-service action that harms legitimate users and violates the availability principle without targeting the actual cause. The failures might stem from an application bug or a specific exploit, not from account status, so this measure would not resolve the issue. It also prevents effective investigation by altering the environment, making it impossible to correlate logs and determine whether the release or an attack caused the outage.
✗
Increase the server's disk space and memory thresholds immediately.
Why it's wrong here
Increasing disk space and memory is a reactive resource fix that addresses only possible symptom-level exhaustion, not the root cause indicated by the deployment timeline and WAF alerts. The SIEM pattern points to a need for correlating release records, WAF rules, and application logs to distinguish a bad update from a legitimate attack. Tuning thresholds without baseline analysis can destabilize the environment and may temporarily mask a code defect or security issue that will recur.

Go deeper

SY0-701 Security Operations Practice Question

Why each option matters

Option-by-option breakdown

Related to this question