DOP-C02 Incident and Event Response 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.

• ✓

  Configure AWS WAF rate-based rules to block excessive requests from specific IP addresses.

  Why this is correct

  AWS WAF rate-based rules track the number of requests from each client IP over a rolling evaluation window (typically 5 minutes) and, when a configured threshold is exceeded, automatically block that IP for a specified duration. This provides immediate, in-place mitigation on the existing ALB without DNS changes, making it the fastest L7 DDoS countermeasure. You can tune the rate limit and scope (e.g., by URI or session) to allow legitimate bursts while dropping attack traffic.

• ✗

  Enable AWS Shield Advanced on the ALB for additional DDoS protection.

  Why it's wrong here

  AWS Shield Advanced is a paid service that requires a 12-month commitment and engagement with the AWS DDoS Response Team for proactive mitigations; enabling it on an ALB after an attack has started is not possible instantly because provisioning, subscribing, and associating resources takes time. While it provides enhanced volumetric attack detection and mitigation, it is not an immediate operational action you can take mid-incident. For a rapid L7 response, WAF rate-based rules are the right first step; Shield Advanced is a longer-term protection investment.

• ✓

  Enable VPC Flow Logs to analyze traffic patterns and identify the source of the attack.

  Why this is correct

  VPC Flow Logs capture metadata about IP traffic traversing your VPC interfaces, including source/destination addresses, ports, and protocol, and publish it to CloudWatch Logs or S3. In the middle of a DDoS attack, enabling flow logs helps you identify anomalous source IPs, request patterns, or ports so you can craft precise WAF rules or security group adjustments. They do not directly block traffic, but they are an essential diagnostic component that informs the rate-based rule thresholds and validates whether mitigations are working.

• ✗

  Scale up the EC2 instances by increasing their instance size.

  Why it's wrong here

  Scaling up EC2 instances by moving to a larger size increases compute and memory capacity, but a DDoS attack typically overwhelms network bandwidth, connection state, or application resources, and a larger instance simply gives the attack a larger target. It does not filter out malicious requests, so legitimate traffic and attack traffic compete for the same resources, and the cost increase is immediate while the attack continues. This approach is neither a mitigation nor an immediate response; capacity scaling cannot absorb or stop a large-scale volumetric attack without other protections.

• ✗

  Place an Amazon CloudFront distribution in front of the ALB to cache content.

  Why it's wrong here

  Placing a CloudFront distribution in front of the ALB can offer edge-level caching and absorb some spoofed or volumetric traffic, but it requires creating a distribution, configuring origins, attaching SSL certificates, and updating DNS records to point to CloudFront—none of which can be completed quickly during an active attack. For dynamic content that is not cacheable, CloudFront will still forward requests to the ALB, so it does not reduce the load on the origin unless you also configure edge behaviors and rate controls. It is a useful architectural improvement for future resilience, not a tactical immediate mitigation.

Go deeper

Related to this question