LEARN. PRACTICE. GROW.Describe what makes a response different
A cache key identifies representations that can be reused. For a public page varying by language, the relevant language needs to separate cached representations. Forwarding a header to origin does not automatically include it in the key: origin request policies and cache policies serve different roles. Origin may not be consulted on hits. Draw two requests with the same path and different values; if the response should differ, confirm how the key or uncached design respects that difference.
Handle personal content before optimizing hits
In a fictional portal, /statement returns different data according to session. Removing the cookie from the key to increase hits can reuse a statement across sessions. Forwarding the cookie only on misses does not fix an existing hit. For these exercises, prevent shared caching of personal statements and review authorization. If exposure occurred, also address existing copies and incident scope. An architecture choosing private caching requires its own demonstration of authorization and isolation; it does not follow from adding only one header.
Read the policy minimum TTL
With minimum TTL above zero, CloudFront can retain content for that minimum even when origin sends Cache-Control: no-cache, no-store, or private. A review therefore needs to examine the behavior and effective policy, not only headers observed at origin. In the minimum TTL=60 scenario, repeating no-store does not remove that minimum. To prevent caching the content in question, apply an appropriate configuration and verify the actual path. A policy change also does not erase data already exposed to a client.
Separate viewer and origin access
OAC addresses the CloudFront-to-S3 path with appropriate permissions. It does not automatically authenticate every viewer. Signed URLs or cookies can control distribution delivery, but a public bucket still offers a direct path. Define both boundaries and exercise authorized access, an unauthorized viewer, and direct origin access. OAC does not support S3 website endpoints; these are custom origins. If the application depends on website-hosting features, assess that dependency when moving to a compatible S3 origin.
Update content without promising simultaneity
Replacing an origin object does not automatically invalidate a still-valid CloudFront copy. To publish a correction, consider invalidating required paths or using versioned names and updating references. With versioned names, a page still referencing the old name continues requesting it. With invalidation, account for propagation and additional caches, including browsers. In the release plan, define how to observe the delivered version and recover from inconsistent references. The exercise does not assume every client changes version at the same instant.
Calculate efficiency with visible assumptions
In a public-content example, 100 paths and two languages give 200 combinations. Adding 1000 irrelevant session identifiers can produce 200000 possible keys if every combination exists. This is potential cardinality, not guaranteed occupancy. In another model, 10000 requests with 9000 hits produce 1000 origin requests; 9500 hits leave 500, a 50% reduction. The calculation assumes one origin request per miss without revalidation or retries. Never remove a dimension that actually separates personal data merely to improve this metric.
100 paths × 2 languages × 1000 irrelevant IDs = 200000 potential combinations; without the IDs there are 200.
Common pitfalls
Confusing forwarding with keying, no-store with an absolute guarantee, OAC with login, or origin updates with invalidation.
Related topics: Data security · Content delivery and costs
Optimize reuse only after ensuring the correct response reaches the authorized user.
Reference: CloudFront cache policies · SAA-C03