SAA-C03 Design Cost-Optimized Architectures Practice Question

A website serves versioned JavaScript and CSS files through CloudFront, but origin fetches are still high and the CloudFront bill increased. Developers confirm that URLs include a version in the filename (for example, app.1.4.2.js). What CloudFront behavior/configuration is most likely to reduce origin fetches and associated costs?

⚠ Common exam trap

Many candidates think lowering TTLs or removing versioning helps with freshness or cost, but the key insight is that versioned filenames already solve cache invalidation, so extending cache duration is the cost-optimized approach.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Set long cache headers (for example, Cache-Control: max-age and immutable) on those versioned assets so CloudFront caches them longer.

Setting long cache headers like `Cache-Control: max-age=31536000, immutable` on versioned assets tells CloudFront to cache these objects at edge locations for an extended period. Since the filename changes with each new version, CloudFront treats each version as a unique object and will not re-fetch the old version from the origin, dramatically reducing origin fetches and associated costs.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Set long cache headers (for example, Cache-Control: max-age and immutable) on those versioned assets so CloudFront caches them longer.
Why this is correct
Versioned filenames (e.g., app-1a2b3c.js) enable CloudFront to treat each URL as immutable. Setting Cache-Control: max-age=31536000, immutable on the origin tells CloudFront and browsers to cache the object for a full year without revalidation. Because every new release uses a new URL, stale content is never served, and future requests hit CloudFront's edge cache instead of going to the origin, improving cache hit ratio and reducing transfer cost.
✗
Disable compression to reduce CPU time spent at the edge and therefore reduce total cost.
Why it's wrong here
Disabling compression would force the edge to deliver larger JavaScript and CSS files, increasing network transfer time and bandwidth consumption to end users. CloudFront compression is performed when the object is first fetched or on the fly and does not meaningfully affect edge CPU cost; the charges that matter are data transfer out and origin requests. Larger payloads also increase latency, so this change hurts both cost and performance.
✗
Lower the cache policy TTLs so clients always get the newest assets quickly.
Why it's wrong here
Lowering cache policy TTLs on versioned assets would cause CloudFront to treat already-cached immutable objects as expired and re-request them from the origin, even though the content has not changed. This elevates origin load, increases per-request origin fees, and adds latency; freshness is not improved because every new version has a distinct filename. The correct way to guarantee fresh content is to version the filename, not shorten cache duration.
✗
Remove version identifiers from filenames so CloudFront caches fewer unique objects.
Why it's wrong here
Removing version identifiers from filenames makes the URL for a file stable, so when its contents change, CloudFront and browsers could continue serving an old cached copy unless you issue frequent invalidations or set impractically short TTLs. The number of unique objects cached does not drive CloudFront's cost—what matters is requests and bytes transferred—so this change adds operational overhead and risks stale assets without reducing cost.

Go deeper

SAA-C03 Design Cost-Optimized Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question