SOA-C02 · Question #425
A company is managing a website with a global user base hosted on Amazon EC2 with an Application Load Balancer (ALB). To reduce the load on the web servers, a SysOps administrator configures an…
The correct answer is B. The DNS is still pointing to the ALB instead of the CloudFront distribution. D. The default, minimum, and maximum Time to Live (TTL) are set to 0 seconds on the CloudFront. Options B and D are correct because they each independently break CloudFront's ability to reduce ALB load in different ways. If DNS still points to the ALB, user traffic never reaches CloudFront at all - the distribution is completely bypassed, so ALB load is unchanged. If all…
Question
A company is managing a website with a global user base hosted on Amazon EC2 with an Application Load Balancer (ALB). To reduce the load on the web servers, a SysOps administrator configures an Amazon CloudFront distribution with the ALB as the origin. After a week of monitoring the solution, the administrator notices that requests are still being served by the ALB and there is no change in the web server load. What are possible causes for this problem? (Choose two.)
Options
- ACloudFront does not have the ALB configured as the origin access identity.
- BThe DNS is still pointing to the ALB instead of the CloudFront distribution.
- CThe ALB security group is not permitting inbound traffic from CloudFront.
- DThe default, minimum, and maximum Time to Live (TTL) are set to 0 seconds on the CloudFront
- EThe target groups associated with the ALB are configured for sticky sessions.
How the community answered
(45 responses)- A13% (6)
- B58% (26)
- C4% (2)
- E24% (11)
Explanation
Options B and D are correct because they each independently break CloudFront's ability to reduce ALB load in different ways. If DNS still points to the ALB, user traffic never reaches CloudFront at all - the distribution is completely bypassed, so ALB load is unchanged. If all TTL values are set to 0 seconds, CloudFront treats every object as immediately expired and forwards every request to the ALB origin rather than serving cached content, eliminating any caching benefit.
Why the distractors are wrong:
- A - Origin Access Identity (OAI) is an S3-specific concept used to restrict direct bucket access; it does not exist for ALB origins, so this option is nonsensical in this context.
- C - A misconfigured security group blocking CloudFront would cause CloudFront to return errors to users, not silently allow traffic to flow through to the ALB successfully.
- E - Sticky sessions govern which backend instance handles a request but operate downstream of CloudFront; they can complicate caching for dynamic content but do not prevent CloudFront from functioning or caching eligible responses entirely.
Memory tip: Think of two gates - the traffic gate (DNS must point to CloudFront, not the ALB) and the cache gate (TTL must be > 0 for CloudFront to actually store anything). If either gate is broken, CloudFront is effectively invisible and the ALB does all the work.
Topics
Community Discussion
No community discussion yet for this question.