A city open-data static site is stored in Amazon S3 and must be delivered publicly through Amazon CloudFront without leaving the bucket widely open to direct public access. Which design should the architect use?
Select an answer to reveal the explanation.
Short Explanation
CloudFront is the public reading room; the S3 shelf stays locked except to that room attendant. Origin Access Control (or OAI) lets only CloudFront fetch objects. World-writable buckets, anonymous FTP, or HTML inside IAM policies miss secure content delivery.
Full Explanation
A city open-data static site stored in Amazon S3 should be delivered publicly through Amazon CloudFront using Origin Access Control (or legacy OAI) so only CloudFront can read a private S3 origin. Citizens hit the CDN edge while the bucket policy grants the CloudFront service principal access—avoiding wide-open direct bucket access that bypasses edge controls, logging patterns, and WAF attachments.
Enabling full public PutObject for the world so CloudFront is optional fails because world-writable buckets invite vandalism and malware uploads to civic content. Disabling CloudFront and requiring anonymous FTP to the S3 website endpoint fails conceptually: S3 is not an FTP server for citizen delivery, and anonymous website endpoints lack the private-origin CDN model. Storing static HTML inside IAM policy documents for each viewer fails because IAM policies are authorization documents, not a content distribution system.
Exam caveat: OAC/OAI must be paired with blocking public ACLs/policies that still allow s3:GetObject from “*”, or users will bypass CloudFront and any edge WAF. Operational check: keep Block Public Access on, attach a bucket policy allowing only the CloudFront distribution/OAC, confirm direct bucket URL GetObject fails for anonymous users, and verify the CloudFront URL serves the open-data pages.