A public-works status site caches road-closure JSON at CloudFront with a multi-hour TTL. After storms, citizens see stale detours for too long even though origin updates quickly. Which cache-effectiveness change best balances performance and freshness?
Select an answer to reveal the explanation.
Short Explanation
Caching yesterday’s flooded bridge is how you send drivers into the river. Keep the edge for speed, but shrink TTLs—and invalidate or version when closures flip—so the map stays honest.
Full Explanation
A public-works status site caching road-closure JSON at CloudFront with a multi-hour TTL leaves citizens on stale detours after storms even when the origin updates quickly. Shortening TTLs—and using cache policies, invalidations, or versioned objects as needed—for rapidly changing closure data keeps edge performance while restoring timely updates. That cache-effectiveness change balances performance and freshness because storm-driven data is volatile; long TTLs optimize the wrong objective. Disabling CloudFront entirely and serving every request from a single Origin EC2 host in one AZ fails scale and availability. Raising the TTL to one week fails conceptually by worsening staleness during incidents. Caching closure documents only in Glacier Deep Archive fails retrieval latency for citizens needing live detours. Exam caveat: prefer versioned object keys or targeted invalidations for sudden storm updates rather than globally tiny TTLs on all site assets—static chrome can stay long-cached. Operational check: set a short TTL or versioning strategy for closure JSON, run a storm-update drill measuring edge freshness, confirm origin load remains acceptable, and document who may invalidate during emergency ops.