AWS DVA-C02 Drill: CloudFront Origin Access Control - Enabling Directory Access Without Public S3 Exposure

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 serve static website content with CloudFront and S3 without making the S3 bucket publicly accessible—especially to handle URLs ending with a directory path (e.g., /products/) rather than a full file name (/products/index.html).

In production, this is about knowing exactly how CloudFront origin access control works together with S3 static website hosting endpoints and request rewriting capabilities. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

AcmeTech’s marketing team needs a fast, secure static website hosted on AWS. A lead developer has uploaded all the site’s static HTML, CSS, and JavaScript files to an Amazon S3 bucket. To improve global content delivery and security, the content is served through an Amazon CloudFront distribution configured with origin access control (OAC) that restricts direct public access to the S3 bucket.

Users can access the home page and specific pages like /products/index.html with no issues. However, when users browse to directory URLs without specifying the file name—such as /products/—they encounter an error page.

The lead developer wants users to access directory paths seamlessly, with the default document (e.g., index.html) auto-served, but without making the S3 bucket publicly accessible.

The Requirement:

#

Enable directory-style URL access (URLs ending with /) to serve the correct default index file, using CloudFront in front of the S3 bucket with OAC, without exposing the bucket publicly.

The Options

#

• A) Update the CloudFront distribution’s settings to configure index.html as the default root object.

• B) Enable static website hosting on the S3 bucket, specify index.html as the index document, update the bucket policy for access, and change the CloudFront origin to the S3 website endpoint.

• C) Create a CloudFront function to intercept viewer requests and append index.html to URLs ending with a directory, and attach this function as a viewer request function on the distribution.

• D) Create a custom error response on the CloudFront distribution that returns /index.html with a 200 status code for 404 errors.

Google adsense

#

leave a comment:

Correct Answer

#

C

Quick Insight: The Developer Imperative

#

CloudFront distributions configured with origin access control (OAC) use S3 REST API endpoints that do not support default root objects for directories like website endpoints do.
Simply setting a default root object applies only to the distribution’s root URL, not subdirectories.
Enabling static website hosting on S3 and pointing CloudFront to the S3 website endpoint exposes the S3 bucket publicly, violating the security requirement.
Using a CloudFront function allows you to dynamically rewrite requests to append index.html on directory accesses without exposing S3 or relying on website hosting.

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 C

The Winning Logic

#

CloudFront distributions using OAC access S3 via the REST API endpoint, which does not support S3 bucket static website hosting features such as default index documents on directory paths. This means that when a user requests /products/, the request is passed directly as /products/ to S3 and returns an error since no object at that exact key exists.

• Setting the CloudFront default root object (index.html) only applies at the root URL (/), not to nested directories.
• Enabling S3 static website hosting and pointing CloudFront to the S3 website endpoint would allow default index documents on directory requests but requires making the bucket public because OAC does not work with website endpoints.
• Creating a CloudFront Function (or Lambda@Edge) to intercept viewer requests and append index.html transparently rewrites directory requests like /products/ → /products/index.html before CloudFront forwards to S3, preserving security and functionality without exposing the bucket.
• Custom error responses on CloudFront for 404 to serve /index.html are a brittle workaround and cause issues, such as unexpected caching and incorrect HTTP status codes.

The Trap (Distractor Analysis)

#

• Why not A?
  This only sets a default root object for the root / URL. It won’t affect subdirectory URLs like /products/, so users will still see errors.

• Why not B?
  Using S3 static website hosting endpoint exposes your bucket publicly because origin access control does not work with website endpoints—breaking the security requirement.

• Why not D?
  Using custom error responses for 404 to serve index.html looks like a hack and causes confusing HTTP semantics and caching behavior. It’s generally discouraged in modern CloudFront static site architectures.

The Technical Blueprint

#

# Example: Creating a CloudFront function to append index.html to viewer requests ending with /
aws cloudfront create-function \
    --name AppendIndexToPath \
    --function-config Comment="Append index.html to directory URLs",Runtime=cloudfront-js-1.0 \
    --function-code fileb://append-index.js

# Example JavaScript for the cloudfront function (append-index.js):
function handler(event) {
    var request = event.request;
    var uri = request.uri;

    if (uri.endsWith('/')) {
        request.uri += 'index.html';
    }
    return request;
}

Attach this function as a Viewer Request function in your CloudFront distribution behavior to enable seamless directory URL resolution.

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick CloudFront Functions when you see requiring custom URL rewriting on viewer requests in front of a private S3 bucket.

Real World

#

In production, some teams use Lambda@Edge for more complex rewrites or internationalization, but CloudFront Functions are lighter weight, cheaper, and faster for this use case.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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