A municipal web form that accepts free-text comments has been hit with SQL injection attempts. Which control should the architect place on the public entry point?
Select an answer to reveal the explanation.
Short Explanation
Think of WAF as the metal detector at the form’s front door—it catches nasty payloads before they reach the clerks. Put AWS WAF on the ALB, CloudFront, or API Gateway that faces the public. Opening the database to the world or turning off logs is how injection walks right in.
Full Explanation
A municipal web form that accepts free-text comments and faces SQL injection attempts should place AWS WAF web ACL rules on the Application Load Balancer, CloudFront distribution, or API Gateway stage that fronts the form. WAF inspects HTTP(S) requests at the public entry point and can block common injection patterns before they reach application code—defense in depth alongside secure query practices for citizen-facing input.
Removing all input validation so requests fail faster under attack fails because it increases successful exploit likelihood and confuses “fail fast” with security. Allowing anonymous SQL clients from the internet directly to the RDS endpoint fails conceptually: it bypasses the application tier entirely and exposes the database protocol to the world. Disabling CloudWatch Logs so injection payloads are not retained fails because it destroys forensic evidence and detection signals without stopping the attacks.
Exam caveat: WAF managed rules reduce risk but are not a license to concatenate untrusted input into SQL; parameterized queries and least-privilege DB credentials remain mandatory. Operational check: associate a web ACL with SQLi-relevant managed rule groups on the public entry, review sampled blocked requests, confirm legitimate comment submissions still succeed, and verify the RDS security group still accepts only the application tier—not the internet.