AWS DVA-C02 Drill: Securing S3 Static Website Hosting - Origin Access Control vs. Bucket Policies

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.

For DVA-C02 candidates, the confusion often lies in how to properly lock down S3 buckets to force delivery only via CloudFront. In production, this is about knowing exactly how Origin Access Control works vs. legacy methods, and the nuances between bucket policies and CloudFront configurations. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

A digital solutions startup, InnovateApps, is developing a public-facing marketing website that hosts only static files: HTML, CSS, JavaScript, and images. To optimize global delivery, they store these assets in an Amazon S3 bucket and deliver them via an Amazon CloudFront distribution. The DevOps team wants to ensure that users cannot bypass CloudFront and access the S3 bucket URL directly, thereby preventing direct access to the bucket content.

The Requirement:

#

Ensure the website content is accessible only through CloudFront, blocking any direct S3 bucket access, while maintaining seamless content delivery via CloudFront.

The Options

#

• A) Create a new Origin Access Control (OAC) in CloudFront. Configure the CloudFront distribution origin to use this OAC. Update the S3 bucket policy to grant the CloudFront OAC read access to the bucket content.
• B) Enable the “Block all public access” setting on the S3 bucket. Configure the CloudFront distribution with S3 as its origin. Update the S3 bucket policy to allow CloudFront write access.
• C) Enable static website hosting on the S3 bucket and specify index and error documents. Configure the CloudFront origin to point to the S3 bucket’s static website hosting endpoint.
• D) Configure the CloudFront origin to send a custom HTTP header with each request. Update the S3 bucket policy to require this custom header using a condition based on aws:RequestTag/tag-key and matching header values.

Google adsense

#

leave a comment:

Correct Answer

#

A

Quick Insight: The Developer Imperative

#

• The key is leveraging CloudFront’s Origin Access Control (OAC) for secure and modern S3 access.
• OAC replaces legacy origin access identities (OAI) with a more secure and scalable method.
• Ensure bucket policies are scoped to allow only CloudFront to read, denying all other direct requests.
• Avoid methods that open public access or rely on HTTP headers that can be spoofed.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option A

The Winning Logic

#

Using CloudFront Origin Access Control (OAC) is the recommended approach for securely restricting S3 bucket access to only CloudFront. You create an OAC, associate it with your CloudFront origin, and update the S3 bucket policy to grant read permissions to that Origin Access Control’s IAM role. This enforces a workflow where the bucket is not publicly accessible, but CloudFront can still retrieve content securely.

From a developer standpoint, OAC improves upon the older Origin Access Identity (OAI) method by using AWS SigV4 signing for requests, allowing finer-grained control, better auditability, and eliminating the need for anonymous access. It builds on secure AWS recommended patterns and aligns with the latest SDK and API capabilities.

The Trap (Distractor Analysis):

#

• Why not B? “Block all public access” is a good setting but by itself does not grant CloudFront permission to read from the S3 bucket. Also, ‘write access’ to CloudFront is meaningless here—the distribution only needs read permission.
• Why not C? Pointing CloudFront to an S3 static website endpoint causes it to use HTTP rather than HTTPS, loses Origin Access Control benefits, and makes it difficult to lock down the bucket fully. Static website hosting endpoints are public by design.
• Why not D? Custom headers are spoofable by clients and do not provide a secure way to lock down bucket access. AWS bucket policies cannot reliably authenticate requests based on such headers for preventing direct access.

The Technical Blueprint

#

# Example AWS CLI commands to create an OAC and update bucket policy

# 1. Create Origin Access Control in CloudFront
aws cloudfront create-origin-access-control \
  --origin-access-control-config '{
    "Name": "InnovateAppsOAC",
    "Description": "Grant CloudFront read access to InnovateApps S3 bucket",
    "SigningProtocol": "sigv4",
    "SigningBehavior": "always",
    "OriginAccessControlOriginType": "s3"
  }'

# 2. Attach OAC to CloudFront origin
# (done in CloudFront distribution configuration)

# 3. Update S3 Bucket Policy to allow OAC access (replace OAC Principal ARN accordingly)
aws s3api put-bucket-policy --bucket innovateapps-static-assets --policy '{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity YOUR_OAC_ARN"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::innovateapps-static-assets/*"
    }
  ]
}'

The Comparative Analysis (Developer Perspective)

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick CloudFront Origin Access Control (OAC) when you see a question about securely restricting S3 access through CloudFront.

Real World

#

In real projects, teams might use OAC for new implementations but sometimes see legacy setups using Origin Access Identity (OAI) due to historical reasons. Migrating to OAC is best practice to leverage improved security and AWS support.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam.