The answer is to add an AWS WAF rate-based rule to the CloudFront distribution and configure it to block the source IP after the threshold is exceeded. This is correct because rate-based rules automatically track the request rate from each client IP over a 5-minute sliding window, and once the specified threshold is breached, AWS WAF blocks that IP at the CloudFront edge location. This enforcement at the edge is crucial—it stops excessive traffic as close to the client as possible, preventing upstream saturation of the API backend. On the SAA-C03 exam, this scenario tests your understanding of combining CloudFront with AWS WAF for DDoS mitigation and traffic shaping; a common trap is choosing a NACL or security group, which operate at the VPC level and cannot block based on request rate. Remember the memory tip: “Rate at the Edge”—rate-based rules on CloudFront block bad IPs at the edge, not at the origin.
SAA-C03 Design Secure Architectures Practice Question
This SAA-C03 practice question tests your understanding of design secure architectures. Match the stated requirement to the specific cloud service, access model, or configuration option — many options are valid in isolation but not for this scenario. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
Exhibit
CloudFront access log excerpt:
2026-04-27T10:15:12Z 203.0.113.24 GET /api/orders 200 112ms
2026-04-27T10:15:12Z 203.0.113.24 GET /api/orders 200 109ms
2026-04-27T10:15:13Z 203.0.113.24 GET /api/orders 200 111ms
2026-04-27T10:15:13Z 203.0.113.24 GET /api/orders 200 108ms
2026-04-27T10:15:13Z 203.0.113.24 GET /api/orders 200 110ms
Security requirement:
- Automatically mitigate high-rate requests from a single source IP
- Keep the protection at the edge
Based on the exhibit, a public API is behind CloudFront and is experiencing bursts of requests from the same client IP, causing upstream saturation. The team wants AWS to automatically block that IP when the request rate becomes excessive while keeping enforcement as close to the client as possible. Which control should they add?
CloudFront access log excerpt:
2026-04-27T10:15:12Z 203.0.113.24 GET /api/orders 200 112ms
2026-04-27T10:15:12Z 203.0.113.24 GET /api/orders 200 109ms
2026-04-27T10:15:13Z 203.0.113.24 GET /api/orders 200 111ms
2026-04-27T10:15:13Z 203.0.113.24 GET /api/orders 200 108ms
2026-04-27T10:15:13Z 203.0.113.24 GET /api/orders 200 110ms
Security requirement:
- Automatically mitigate high-rate requests from a single source IP
- Keep the protection at the edge
A
Add an AWS WAF rate-based rule to the CloudFront distribution and configure it to block the source IP after the threshold is exceeded.
AWS WAF rate-based rules are purpose-built for this use case. They evaluate the HTTP request rate from a source IP over a sliding window and can automatically block, CAPTCHA, or count when the threshold is exceeded. Attaching the Web ACL to CloudFront enforces the control at the edge, so abusive requests are stopped before they reach the origin and consume upstream capacity.
B
Add a network ACL rule that denies the source IP after five requests are observed.
Why wrong: Network ACLs are stateless, subnet-level packet filters. They cannot count HTTP requests, apply sliding-window thresholds, or dynamically change based on application-layer behavior. They also do not sit at the CloudFront edge, so they cannot satisfy the requirement to automatically mitigate excessive request rates at the edge.
C
Enable AWS Shield Advanced and create a custom protection group for the single IP address.
Why wrong: AWS Shield Advanced is designed for DDoS detection and mitigation, especially for volumetric and infrastructure-layer attacks. It does not provide the direct HTTP request-rate thresholding and IP-based blocking behavior required here. For edge HTTP filtering and automatic rate limiting, AWS WAF rate-based rules are the correct service.
D
Place the API behind a security group rule that allows only the current client IP range.
Why wrong: Security groups are static, stateful network controls for ENIs. They do not inspect HTTP request rates or react to bursts of traffic from a single IP. They also cannot implement edge-based application-layer blocking for a CloudFront-fronted API.
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add an AWS WAF rate-based rule to the CloudFront distribution and configure it to block the source IP after the threshold is exceeded.
AWS WAF rate-based rules are designed to automatically block IP addresses that exceed a specified request rate within a 5-minute evaluation window. By attaching this rule to a CloudFront distribution, enforcement occurs at the edge location closest to the client, preventing excessive requests from reaching the upstream API and mitigating saturation.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
✓
Add an AWS WAF rate-based rule to the CloudFront distribution and configure it to block the source IP after the threshold is exceeded.
Why this is correct
AWS WAF rate-based rules are purpose-built for this use case. They evaluate the HTTP request rate from a source IP over a sliding window and can automatically block, CAPTCHA, or count when the threshold is exceeded. Attaching the Web ACL to CloudFront enforces the control at the edge, so abusive requests are stopped before they reach the origin and consume upstream capacity.
Related concept
Read the scenario before looking for a memorised answer.
✗
Add a network ACL rule that denies the source IP after five requests are observed.
Why it's wrong here
Network ACLs are stateless, subnet-level packet filters. They cannot count HTTP requests, apply sliding-window thresholds, or dynamically change based on application-layer behavior. They also do not sit at the CloudFront edge, so they cannot satisfy the requirement to automatically mitigate excessive request rates at the edge.
✗
Enable AWS Shield Advanced and create a custom protection group for the single IP address.
Why it's wrong here
AWS Shield Advanced is designed for DDoS detection and mitigation, especially for volumetric and infrastructure-layer attacks. It does not provide the direct HTTP request-rate thresholding and IP-based blocking behavior required here. For edge HTTP filtering and automatic rate limiting, AWS WAF rate-based rules are the correct service.
✗
Place the API behind a security group rule that allows only the current client IP range.
Why it's wrong here
Security groups are static, stateful network controls for ENIs. They do not inspect HTTP request rates or react to bursts of traffic from a single IP. They also cannot implement edge-based application-layer blocking for a CloudFront-fronted API.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is confusing stateless network ACLs or static security groups with the automatic, rate-aware blocking capability of AWS WAF, leading candidates to choose a manual or non-scalable solution.
Detailed technical explanation
How to think about this question
AWS WAF rate-based rules use a token bucket algorithm where each request from a source IP increments a counter, and the rule triggers when the count exceeds the configured threshold within a 5-minute sliding window. The rule is evaluated at CloudFront edge locations, meaning blocking happens before traffic reaches the origin, reducing latency and upstream load. A common real-world scenario is protecting APIs from web scraping or brute-force attacks where a single IP sends thousands of requests per minute.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A healthcare organisation deploys an application with a public-facing web tier and a private database tier. The database subnet has no public IP and only accepts connections from the web tier's security group. Questions like this test whether you can design cloud network isolation using VNets/VPCs, subnets, and security group rules.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Design Secure Architectures — This question tests Design Secure Architectures — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Add an AWS WAF rate-based rule to the CloudFront distribution and configure it to block the source IP after the threshold is exceeded. — AWS WAF rate-based rules are designed to automatically block IP addresses that exceed a specified request rate within a 5-minute evaluation window. By attaching this rule to a CloudFront distribution, enforcement occurs at the edge location closest to the client, preventing excessive requests from reaching the upstream API and mitigating saturation.
What should I do if I get this SAA-C03 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Based on the exhibit, a public API is behind CloudFront. A single client IP is sending bursts of requests that are overwhelming the origin, and the team wants AWS to automatically mitigate the abuse at the edge without changing the application code. What should the team do?
hard
✓ A.Associate an AWS WAF web ACL with CloudFront and add a rate-based rule for the offending IP behavior.
B.Increase the ALB idle timeout to allow the origin to absorb more concurrent requests.
C.Add an Amazon Route 53 health check to fail over traffic to another DNS name.
D.Enable AWS Shield Advanced and rely on automatic DDoS protection for all request bursts.
Why A: AWS WAF rate-based rules automatically block or rate-limit requests from a client IP when the request rate exceeds a threshold you define. By associating the web ACL with CloudFront, the rule is enforced at the edge before traffic reaches the origin, mitigating abuse without modifying application code.
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.