SOA-C02 Security and Compliance Practice Question

A company hosts a critical web application on EC2 instances behind an Application Load Balancer. The security team enabled AWS WAF on the ALB to block SQL injection and XSS attacks. They also use AWS Shield Advanced for DDoS protection. Recently, the application experienced intermittent performance degradation during normal traffic patterns. The security team reviewed the WAF logs and found that legitimate user requests with query strings containing the word "select" (e.g., ?category=select+option) were being blocked. The team wants to ensure that only actual SQL injection attempts are blocked, not legitimate requests with similar patterns. What course of action should the SysOps administrator take to resolve this issue while maintaining security?

⚠ Common exam trap

SOA-C02 often tests the balance between security and availability — candidates may choose to disable the rule to stop false positives, but the exam expects a solution that maintains security while reducing false positives, such as a custom rule with precise regex.

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

✓

Create a custom WAF rule that inspects specific query string parameters with a more precise regex pattern to reduce false positives.

The issue is that the AWS WAF SQL injection rule is triggering false positives on legitimate query strings containing the word 'select' (e.g., '?category=select+option'). The best course of action is to create a custom WAF rule that inspects specific query string parameters with a more precise regex pattern, allowing legitimate patterns while still blocking actual SQL injection attempts. This maintains security by targeting the actual attack vectors rather than disabling protection entirely.

Answer analysis

Option-by-option breakdown

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

✗
Disable the SQL injection rule in AWS WAF and rely solely on AWS Shield Advanced for protection.
Why it's wrong here
Disabling the AWS WAF SQL injection rule removes the application-layer inspection that is specifically designed to block SQL injection payloads, leaving the web application exposed to attacks such as UNION-based or boolean-based SQLi. AWS Shield Advanced is a DDoS mitigation service that focuses on volumetric, protocol, and resource-exhaustion attacks at the network and transport layers; it does not provide the granular rule-based inspection or customization needed to manage false positives in SQL injection detection. Relying solely on Shield Advanced would neither restore the WAF protection nor address the original false positive issue, and it would also require you to lose the tightly integrated WAF rule that allows conditional matching and rate-based exceptions.
✗
Enable AWS Shield Advanced's automatic mitigation feature to handle all layer 7 attacks.
Why it's wrong here
AWS Shield Advanced's automatic mitigation capabilities are centered on DDoS defenses, such as network-layer anomaly detection and traffic rerouting via AWS Global Accelerator or Route 53, not on application-layer attacks like SQL injection. It cannot be 'enabled' to perform WAF rule tuning, inspect specific query string parameters, or apply regex-based manipulations to reduce false positives. Even if a Layer 7 DDoS event triggers AppLayer mitigation, Shield Advanced relies on the associated AWS WAF web ACL for those mitigations and still requires appropriately scoped WAF rules; it will not automatically create or refine custom rules, so it does not solve the problem of false positives from a broad SQL injection rule.
✓
Create a custom WAF rule that inspects specific query string parameters with a more precise regex pattern to reduce false positives.
Why this is correct
Creating a custom AWS WAF rule that inspects only the specific query string parameters with a more precise regex pattern is the correct solution because it narrows the detection scope while maintaining SQL injection protections. For example, instead of using a managed rule that flags any occurrence of 'select' across the entire request, a custom rule can apply a SQL injection match condition to a parameter like 'id' and use a regex pattern that requires SQL keywords to appear in a syntactically suspicious sequence, such as after a quote or with UNION operators. This reduces false positives by ignoring benign uses of words like 'select' in other fields, while still detecting actual SQLi attempts that target the parameter the application expects to be numeric or constrained.
✗
Replace the WAF SQL injection rule with a rate-based rule to limit request rates from specific IPs.
Why it's wrong here
Replacing the WAF SQL injection rule with a rate-based rule would not address SQL injection attacks at all, since rate-based rules function by counting requests from a client IP and blocking when the count exceeds a threshold within a specified time window. Such a rule might suppress a flood of malicious requests, but it does nothing to distinguish a legitimate request containing the word 'select' from an actual SQL injection payload, and it could inadvertently block legitimate users who happen to be making many requests. The problem described is a false-positive issue with the existing SQL injection rule, not a volumetric or rate-based DDoS issue, so swapping in a rate-based rule would lose SQL injection detection and fail to resolve the root cause of legitimate traffic being flagged incorrectly.

Visual reference

Go deeper

SOA-C02 Security and Compliance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question