SAA-C03 Design Secure Architectures 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.

• ✓

  Use a rate-based rule in AWS WAF to block when requests per IP exceed a configured threshold over the WAF rate-based evaluation window.

  Why this is correct

  Rate-based rules are designed specifically to mitigate abusive traffic by limiting the number of requests from an identified source (typically by IP). When the threshold is exceeded, you can set the rule action to Block (or count first for tuning).

• ✗

  Use an AWS IAM policy on the ALB listener to deny requests when request count exceeds a threshold.

  Why it's wrong here

  IAM policies are identity-based authorization controls that govern what an IAM principal can do to AWS API actions; they do not apply to individual HTTP requests arriving at an ALB listener. A listener cannot have a resource policy that inspects per-source request counts, and IAM condition keys do not include dynamic rate or time-window attributes. Even a resource-based policy attached to a load balancer (which ALB doesn't support for traffic) could only enforce static conditions like source VPC, not a sliding request threshold. Therefore, this option confuses authentication/authorization with real-time traffic rate limiting, which is outside IAM's scope.

• ✗

  Enable S3 server access logs for the bucket that stores API responses and alert on high log volume.

  Why it's wrong here

  S3 server access logs record requests made to the S3 bucket itself (such as object GET/PUT operations) and are delivered asynchronously on a best-effort basis, often with delays of several hours. They do not capture requests hitting the Application Load Balancer, because ALB traffic is handled at the edge before any S3 bucket is involved for request routing. Alerting on the volume of these logs is purely a post-incident, observability measure; it provides no mechanism to block or throttle the originating IP addresses in real time. This option fails because it addresses forensic visibility, not enforcement, and the log source is entirely different from the API request path.

• ✗

  Configure an AWS Lambda authorizer to reject requests after the Nth request from an IP address.

  Why it's wrong here

  A Lambda authorizer is designed for custom authentication and authorisation logic, not for rate limiting based on request count per IP. It cannot natively track and enforce a threshold of requests from a single IP across multiple invocations without an external data store like DynamoDB, adding latency and complexity. This option is tempting because Lambda authorizers can reject requests conditionally, so in a scenario requiring custom token validation or user-specific access rules, they would be the correct choice.

Go deeper

Related to this question