SAA-C03 Design Secure Architectures Practice Question

Exhibit

{
  "current_state": {
    "bucket_public_access_block": true,
    "bucket_policy": "Allows s3:GetObject to Principal * for debugging",
    "cloudfront_distribution": "d123example.cloudfront.net",
    "direct_s3_test": "https://secure-pdfs-prod.s3.us-east-1.amazonaws.com/manuals/q4.pdf returns 200"
  }
}

Based on the exhibit, a company stores sensitive PDFs in S3 and serves them through CloudFront. Direct requests to the S3 object URL must fail, but CloudFront should still be able to fetch the files securely. Which solution best satisfies the requirement?

⚠ Common exam trap

Many exam-takers confuse signed URLs/cookies (which control user access) with origin access controls (which control how CloudFront fetches from S3), leading them to pick options that still allow direct S3 access.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Configure CloudFront Origin Access Control for the S3 origin and update the bucket policy to allow only that distribution.

CloudFront Origin Access Control (OAC) allows CloudFront to authenticate requests to an S3 origin using a specific identity, and the bucket policy can be configured to grant access only to that CloudFront distribution. This ensures that direct S3 object URL requests fail (since they lack the CloudFront signature), while CloudFront can still fetch the files securely using the OAC mechanism.

Answer analysis

Option-by-option breakdown

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

✗
Leave the bucket public but require CloudFront signed cookies for all users.
Why it's wrong here
Making the bucket public allows any internet user with an S3 endpoint URL to retrieve objects directly, completely bypassing CloudFront. Signed cookies only restrict who can access content through the CloudFront distribution; they have no bearing on S3's own URL. Therefore, the requirement to prevent direct access is violated because the origin remains exposed. The bucket policy must deny direct access, not rely on viewer-side authentication.
✗
Use an S3 access point and give it a public policy so CloudFront can reach the objects.
Why it's wrong here
An S3 access point is a managed entry point for S3, but assigning it a public policy simply grants anonymous read access to the access point's own Amazon Resource Name (ARN). CloudFront can be configured to use a private access point with origin access control, but a public policy would let anyone directly request objects via that access point ARN. This fails the stated requirement because you need to restrict access exclusively to the CloudFront distribution, not make objects publicly reachable.
✓
Configure CloudFront Origin Access Control for the S3 origin and update the bucket policy to allow only that distribution.
Why this is correct
Origin Access Control (OAC) enables CloudFront to authenticate every origin request to S3 using SigV4, so S3 can distinguish requests made by your distribution from all other traffic. You then write a bucket policy that allows s3:GetObject only when the principal is cloudfront.amazonaws.com and the aws:SourceArn matches your distribution's ID, thereby denying direct S3 bucket URL access. This is the standard secure pattern for a private S3 origin and is preferred over the older Origin Access Identity. It ensures that if someone finds a direct S3 URL, the bucket policy rejects it.
✗
Use S3 object ACLs to grant read access only to users behind CloudFront.
Why it's wrong here
S3 object ACLs are a legacy access-control mechanism that grants permissions to AWS accounts or predefined groups like Everyone, but they cannot reference a CloudFront distribution or require that the request came through CloudFront. Even if you set per-object ACLs, direct S3 requests would still be evaluated based on the ACL, and there is no way to enforce CloudFront as the sole source without OAC and a bucket policy. Moreover, ACLs do not support fine-grained source-ARN conditions used to secure an origin, and relying on them is impractical for many objects.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAA-C03 Design Secure Architectures Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question