AWS DVA-C02 Drill: CloudFront Cache Behaviors - Serving Public & Private Content

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 configure CloudFront cache behaviors to serve both public and signed content correctly. In production, this is about knowing exactly how CloudFront cache behavior path patterns and viewer restrictions interact with origin access identity permissions and signed cookies. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

DataByte Solutions is developing a cloud-based file storage web application hosted on AWS. They use a CloudFront distribution to serve files from an S3 bucket secured with an origin access identity (OAI) so only CloudFront can read from the bucket. All S3 objects are locked down to deny direct user access. The app shows a public login page for user authentication, after which users get signed cookies granting access to their private directories. The CloudFront distribution is configured with the default cache behavior set to restricted viewer access and the origin points to the secure S3 bucket. However, when developers try to access the login page URL, they receive HTTP 403 Forbidden errors. They need a solution that allows unauthenticated users open access to the login page but keeps all private content secure behind signed cookies.

The Requirement:

#

Enable unauthenticated access to the login page through CloudFront without exposing private S3 content. Private directories remain fully protected behind signed cookie validation.

The Options

#

• A) Add a second cache behavior to the distribution with the same S3 origin. Set the path pattern for the second cache behavior to the login page path, and make viewer access unrestricted. Keep the default cache behavior’s settings unchanged.
• B) Add a second cache behavior to the distribution with the same S3 origin. Set the path pattern for the second cache behavior to ‘*’ with viewer access restricted. Change the default cache behavior’s path pattern to the login page path and make viewer access unrestricted.
• C) Add a second origin as a failover origin to the default cache behavior. Point the failover origin to the same S3 bucket. Set the path pattern for the primary origin to ‘*’ and make viewer access restricted. Set the path pattern for the failover origin to the login page path with viewer access unrestricted.
• D) Add a bucket policy granting read access specifically to the login page object. Add a CloudFront function on the default cache behavior to redirect unauthorized requests to the login page’s S3 URL.

Google adsense

#

leave a comment:

Correct Answer

#

A

Quick Insight: The Developer Imperative

#

• When serving mixed public and private content via CloudFront backed by an OAI-restricted S3 origin, using multiple cache behaviors with explicitly scoped path patterns and differing viewer access settings is the cleanest way to manage authentication flows.
• CloudFront cache behaviors allow you to selectively open access for specific URL paths (like the login page) without weakening security on private content areas that require signed cookies.

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

#

The core issue is that the default cache behavior is set with restricted viewer access and the S3 origin is locked down by an OAI. As a result, all requests including unauthenticated ones (like the login page) require valid signed cookies and S3 permissions, causing 403 Forbidden errors for the login page.

Option A correctly adds a second cache behavior with the same S3 origin but changes these key settings:

• It uses a path pattern specific to the login page (e.g., /login.html)
• It allows unrestricted viewer access, meaning no signed cookies are required for this path
• The default cache behavior remains restricted and secured for all other paths

This separation enables the login page to be publicly accessible, but keeps all private content secure behind the OAI and signed cookies. CloudFront evaluates path patterns from most specific to least specific, so requests to the login page bypass viewer restrictions and get served immediately.

The Trap (Distractor Analysis):

#

• Why not B? It swaps the path patterns incorrectly, making the login page unrestricted in the default behavior and requiring signed cookies for all other paths. This causes unintended access exposure for all content.
• Why not C? Failover origins manage error conditions, not path-based routing, so this doesn’t solve path-specific access control.
• Why not D? Opening the S3 bucket policy for even the single login page object exposes it directly via S3 URLs, bypassing CloudFront caching and OAI protections. Also, a CloudFront function redirect adds unnecessary complexity and potential security gaps.

The Technical Blueprint

#

# Example AWS CLI command to add second cache behavior with unrestricted access

aws cloudfront update-distribution \
  --id E123ABC456DEF \
  --distribution-config file://dist-config.json

# In dist-config.json under "CacheBehaviors", add:

{
  "PathPattern": "/login.html",
  "TargetOriginId": "S3-secure-origin",
  "ViewerProtocolPolicy": "allow-all",
  "AllowedMethods": ["GET", "HEAD"],
  "CachedMethods": ["GET", "HEAD"],
  "TrustedSigners": [],
  "ForwardedValues": {
    "QueryString": false,
    "Cookies": {"Forward": "none"}
  },
  "MinTTL": 0,
  "DefaultTTL": 86400,
  "MaxTTL": 31536000
}

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the exam, always choose multiple cache behaviors to handle mixed public/private CloudFront content with OAI.”

Real World

#

“In actual applications, sometimes a dedicated public origin (like a separate S3 bucket or a static site hosting service) hosts the login and public assets, reducing complexity in your CloudFront distribution.”

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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