You deploy a Web ACL with an AWS WAF rate-based rule intended to limit abusive traffic to your API. After the deployment, attackers still reach the backend service. ALB access logs show requests arrive at the ALB, but WAF logs indicate the Web ACL is not evaluating those requests. Which change most likely fixes the issue?
For an ALB, the Web ACL must be associated with the load balancer resource itself. If it is not attached to the ALB, WAF will not inspect those requests.
Why this answer
A Web ACL must be explicitly associated with a resource (such as an ALB) for AWS WAF to evaluate incoming requests. In this scenario, the Web ACL was deployed but not associated with the ALB resource ARN, so WAF never inspected the traffic. Associating the Web ACL with the ALB ensures that all requests to the ALB are evaluated by the rate-based rule before reaching the backend.
Exam trap
The trap here is that candidates assume deploying a Web ACL automatically applies it to all resources in the account, when in fact it must be explicitly associated with each resource ARN to take effect.
How to eliminate wrong answers
Option B is wrong because security group rules operate at the instance ENI level and can block traffic, but they do not integrate with WAF rate-based rules or provide application-layer rate limiting; they also cannot be dynamically updated by WAF. Option C is wrong because target group stickiness (sticky sessions) ensures a client is routed to the same target, but it does not cause WAF to evaluate requests or count them per client IP; WAF evaluation is independent of load balancer routing policies. Option D is wrong because AWS Shield Advanced provides DDoS protection and automatic application-layer mitigation, but it does not replace the need for an associated Web ACL to enforce custom rate-based rules; Shield Advanced works alongside WAF, not as a substitute for Web ACL association.