SAA-C03 Design Secure Architectures Practice Question
You use Amazon CloudFront in front of a private content S3 origin. To mitigate an OWASP Top 10 issue, you created a WAF web ACL and associated it to the CloudFront distribution, but attacks are still reaching the origin.
CloudWatch logs show the web ACL rules never match for the CloudFront requests.
What is the most likely configuration mistake?
⚠ Common exam trap
Many candidates assume WAF web ACLs can be created in any region for CloudFront, not realizing that CloudFront requires a global-scope web ACL that must be created in us-east-1, regardless of where the origin or other resources reside.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The WAF web ACL intended for CloudFront must be created in the us-east-1 (N. Virginia) region (CloudFront scope), even if the rest of the stack is in another region.
When using AWS WAF with CloudFront, the web ACL must be created in the US East (N. Virginia) region (us-east-1) because CloudFront is a global service that only supports WAF web ACLs with a global scope, which are always defined in us-east-1. If the web ACL is created in any other region, it will be a regional web ACL and cannot be associated with a CloudFront distribution, causing the rules to never be evaluated against incoming requests. This explains why CloudWatch logs show no rule matches—the web ACL is effectively not attached to the CloudFront distribution.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The WAF web ACL intended for CloudFront must be created in the us-east-1 (N. Virginia) region (CloudFront scope), even if the rest of the stack is in another region.
Why this is correct
CloudFront-scoped WAF web ACLs use a global scope that is provisioned/managed in us-east-1. Creating the web ACL in the wrong region (or with the wrong scope) prevents CloudFront from evaluating the expected web ACL rules, which would lead to no rule matches in logs.
- ✗
WAF rules only evaluate requests after they reach the origin, so the absence of matches means the origin is blocking traffic first.
Why it's wrong here
WAF rules are evaluated by CloudFront at the edge location, before any request is forwarded to the S3 origin. If a rule matches, the request is blocked and the origin never sees it; if no rule matches, the request is forwarded normally. Therefore an absence of WAF matches cannot be explained by the origin blocking traffic first—if the web ACL were properly associated, the edge would have logged an evaluation. The real cause is usually a missing association, wrong AWS region/scope, or rules that do not have the intended conditions.
When this WOULD be correct
If the question described a scenario where the origin (e.g., an ALB) has its own WAF web ACL that is blocking traffic before CloudFront's WAF rules are evaluated, then option B could be correct in the sense that the origin's WAF is blocking requests first, but the statement as written is still inaccurate because WAF rules evaluate before reaching the origin.
- ✗
For CloudFront, you must use a regional WAF endpoint and cannot use a global web ACL.
Why it's wrong here
CloudFront does not use a regional WAF endpoint; it requires a web ACL with the CloudFront scope, which is created and managed in us-east-1 (N. Virginia). Regional web ACLs are for Application Load Balancers, API Gateway, and other regional resources. Attempting to use a regional endpoint would make the web ACL unusable for the distribution, so the correct fix is to create a global-scope ACL in us-east-1 and associate it with CloudFront.
When this WOULD be correct
If the question stated that you are using an Application Load Balancer (ALB) or API Gateway in a specific region, then you must create a regional WAF web ACL in that same region and associate it with the ALB or API Gateway.
- ✗
WAF web ACL rules never apply to signed URLs or signed cookies, so the web ACL is bypassed by design.
Why it's wrong here
Signed URLs and signed cookies do not exempt a request from WAF inspection. CloudFront still forwards the request metadata to the WAF at the edge, and every rule in the associated web ACL is evaluated against the request before it is allowed through. The signature only authenticates access to the S3 origin; it does not disable or bypass the web ACL, so an absence of matches indicates a scope/association issue rather than a signed-request bypass.
When this WOULD be correct
If a question states that a WAF web ACL is associated with a CloudFront distribution but requests with signed URLs are still bypassing the WAF and reaching the origin, and the WAF logs show no matches, then the correct answer could be that signed URLs bypass WAF evaluation. However, this is incorrect in practice; WAF evaluates all requests. A more plausible scenario: a question about CloudFront signed URLs and WAF might incorrectly claim that WAF does not inspect signed URLs, but that would be a trick.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓The WAF web ACL intended for CloudFront must be created in the us-east-1 (N. Virginia) region (CloudFront scope), even if the rest of the stack is in another region.Correct answer▾
Why this is correct
CloudFront-scoped WAF web ACLs use a global scope that is provisioned/managed in us-east-1. Creating the web ACL in the wrong region (or with the wrong scope) prevents CloudFront from evaluating the expected web ACL rules, which would lead to no rule matches in logs.
✗WAF rules only evaluate requests after they reach the origin, so the absence of matches means the origin is blocking traffic first.Wrong answer — click to see why▾
Why this is wrong here
WAF rules evaluate requests before they reach the origin, not after. The absence of matches indicates the web ACL is not being applied to CloudFront traffic, not that the origin is blocking requests.
★ When this WOULD be the correct answer
If the question described a scenario where the origin (e.g., an ALB) has its own WAF web ACL that is blocking traffic before CloudFront's WAF rules are evaluated, then option B could be correct in the sense that the origin's WAF is blocking requests first, but the statement as written is still inaccurate because WAF rules evaluate before reaching the origin.
Why candidates choose this
Candidates may confuse the order of evaluation or think that WAF only inspects traffic at the origin, not realizing that CloudFront integrates with WAF to inspect at the edge before forwarding to the origin.
✗For CloudFront, you must use a regional WAF endpoint and cannot use a global web ACL.Wrong answer — click to see why▾
Why this is wrong here
CloudFront requires a global (CloudFront scope) web ACL, not a regional one. Associating a regional WAF web ACL with CloudFront is not supported, but the mistake here is that the web ACL was created in the wrong region (not us-east-1), not that it was regional.
★ When this WOULD be the correct answer
If the question stated that you are using an Application Load Balancer (ALB) or API Gateway in a specific region, then you must create a regional WAF web ACL in that same region and associate it with the ALB or API Gateway.
Why candidates choose this
Candidates may confuse the regional vs. global scope of WAF, thinking CloudFront can use a regional endpoint, or they may not know that CloudFront requires a global web ACL created in us-east-1.
✗WAF web ACL rules never apply to signed URLs or signed cookies, so the web ACL is bypassed by design.Wrong answer — click to see why▾
Why this is wrong here
WAF rules do apply to requests using signed URLs or signed cookies; the web ACL evaluates all requests that reach CloudFront, regardless of authentication method. The issue here is that the web ACL is not being applied at all because it was created in the wrong region.
★ When this WOULD be the correct answer
If a question states that a WAF web ACL is associated with a CloudFront distribution but requests with signed URLs are still bypassing the WAF and reaching the origin, and the WAF logs show no matches, then the correct answer could be that signed URLs bypass WAF evaluation. However, this is incorrect in practice; WAF evaluates all requests. A more plausible scenario: a question about CloudFront signed URLs and WAF might incorrectly claim that WAF does not inspect signed URLs, but that would be a trick.
Why candidates choose this
Candidates may confuse signed URLs/cookies with authentication mechanisms that bypass WAF, thinking that pre-signed URLs skip WAF inspection, when in fact WAF evaluates all requests at the CloudFront edge.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.