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.

• ✓

  Configure Origin Access Control (OAC) with the S3 bucket policy.

  Why this is correct

  Origin Access Control (OAC) is the modern, recommended way to restrict an S3 bucket to serve content only through CloudFront. OAC uses a service principal of cloudfront.amazonaws.com with a condition that requires the distribution's ID to match, and the bucket policy grants only GetObject to that principal. This blocks direct S3 access from outside CloudFront while also supporting encrypted S3 objects and SSE-KMS, giving verifiable origin security.

• ✗

  Use CloudFront signed URLs or cookies.

  Why it's wrong here

  Signed URLs or cookies restrict which viewers can access content by requiring temporary, time-limited tokens at the CloudFront edge, but they do nothing to restrict the S3 origin itself. Without OAC or a restrictive bucket policy, anyone who discovers the S3 bucket's direct URL can still download the objects, bypassing CloudFront and its signing requirements. The origin remains publicly exposed, so this solution fails to secure the connection between CloudFront and S3.

• ✗

  Attach an IAM role to CloudFront that grants S3 read access.

  Why it's wrong here

  CloudFront distributions cannot assume an IAM role to fetch objects from S3 because CloudFront does not support role-based authentication for origins; it uses Origin Access Control (OAC) or the legacy Origin Access Identity (OAI) instead. IAM roles are designed for entities such as EC2 instances, Lambda functions, or container tasks that have a fixed identity and credential lifecycle, whereas CloudFront edge nodes operate as a single managed service. Attaching a role to a distribution is not an available configuration, and even if attempted, it would not grant CloudFront the ability to sign S3 requests.

• ✗

  Create a bucket policy that allows access only from the CloudFront distribution's IP addresses.

  Why it's wrong here

  Restricting by CloudFront's IP addresses is unreliable because CloudFront does not have a dedicated IP range; its global egress IPs are dynamic and can change without notice, so any bucket policy referencing those addresses is brittle and will break. Additionally, S3 bucket policies using aws:SourceIp cannot distinguish a legitimate CloudFront distribution from any other client that happens to come from the same shared IP range, so security can be bypassed. OAC avoids these issues by using cryptographic SigV4 authentication tied to a specific distribution ID, providing a stable and verifiable access control.

Go deeper

Related to this question