A hybrid municipal portal serves static open-data files from S3 and dynamic pages from an ALB-backed app. How should Amazon CloudFront be composed?
Select an answer to reveal the explanation.
Short Explanation
CloudFront can wear two badges: one origin for the S3 brochure rack, another for the ALB desk that builds pages live. One lonely EC2 IP or a basement proxy farm isn’t a multi-origin CDN design.
Full Explanation
Amazon CloudFront for a hybrid municipal portal should use multiple origins—Amazon S3 for static open-data files and the Application Load Balancer for dynamic paths—with cache behaviors routing each URL pattern appropriately. Static brochure and dataset assets cache at the edge from S3; dynamic pages go to the ALB origin with suitable TTLs or no-cache behaviors. That composition is how CloudFront serves mixed static/dynamic civic sites.
Attaching CloudFront only to a single EC2 public IP and disabling S3 origins permanently fails by concept because it loses the S3 static origin and pins the CDN to a fragile single host address. Using CloudFront exclusively as a DNS CNAME without any origins configured fails because a distribution requires origins; CNAME alone is not a CDN design. Replacing CloudFront with an Auto Scaling group of squid proxies in one AZ fails because a single-AZ proxy farm is not a global managed CDN for citizens.
Exam caveat: Hybrid static + dynamic → CloudFront multi-origin with cache behaviors (S3 + ALB/API). Single EC2 origins only, origin-less CNAMEs, and DIY single-AZ proxies miss the managed multi-origin pattern.
Operational check: Verify behaviors send /static or asset paths to S3 and application paths to the ALB, TLS certificates match viewer names, cache hit ratios look healthy for static content, and origin failover or error pages are defined as needed. If all traffic still hairpins to one EC2 IP, multi-origin CloudFront is not configured.