SOA-C02 Networking and Content Delivery Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create an origin access identity (OAI) and update the S3 bucket policy to grant access only to the OAI

  Why this is correct

  An origin access identity (OAI) is a CloudFront user that serves as the only AWS principal allowed to read objects from your S3 bucket. After you associate the OAI with the CloudFront distribution, update the bucket policy so it grants the s3:GetObject action strictly to that OAI's principal ARN or canonical user ID. Any request that goes directly to the S3 bucket's HTTPS endpoint is then denied with AccessDenied, because the requester is not the OAI. This ensures the only way to fetch content is through CloudFront, which is exactly the intended behavior.

• ✗

  Use AWS WAF to block requests that do not include the CloudFront distribution's domain name

  Why it's wrong here

  AWS WAF can be attached to a CloudFront distribution to inspect the Host header and reject requests that don't match the distribution's domain name, but WAF operates solely at CloudFront edge locations. A user who knows the S3 bucket's direct endpoint can bypass CloudFront entirely and issue anonymous HTTP requests to that S3 URL, so the WAF rule never even evaluates those requests. Since this option does not change the S3 bucket policy or remove public read access, the origin content remains directly accessible and the goal of preventing direct access is not achieved.

• ✗

  Create an AWS Lambda@Edge function to validate headers

  Why it's wrong here

  A Lambda@Edge function can be triggered on viewer-request or origin-request events to check for a specific header and return a 403 response if the header is absent, but this logic only runs for requests that are routed through the CloudFront distribution. Any request sent straight to the S3 bucket endpoint never triggers Lambda@Edge, so the S3 objects are still retrievable without valid headers. Also, a custom header can be trivially added by a client, so header validation is not secure enough to serve as an access-control boundary for an S3 origin.

• ✗

  Use S3 Block Public Access to prevent all public access

  Why it's wrong here

  S3 Block Public Access enforces that no public ACLs or public bucket policies exist, which does block anonymous direct access to S3 URLs, but enabling "Block all public access" alone does not provide CloudFront with any credentials to read the bucket. If the bucket is private and no OAI is configured, CloudFront's origin requests to S3 will fail with 403 Forbidden because CloudFront has no IAM principal to authenticate the request. The correct solution is to combine a deny-public posture with an OAI that grants access exclusively to CloudFront; Block Public Access by itself is insufficient and would break the distribution.

Go deeper

Related to this question