SAA-C03 Design Cost-Optimized Architectures Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Configure a CloudFront cache policy (or update HTTP cache-control headers) to increase TTLs for versioned static assets and enable compression for text assets.

  Why this is correct

  CloudFront cache hit ratio improves when objects are cacheable for longer and requests can be served from edge caches. Proper TTLs for versioned assets prevent unnecessary revalidation. Compression reduces payload size for eligible content types, lowering transfer costs.

• ✗

  Disable CloudFront access logging so fewer requests are recorded and billing decreases automatically.

  Why it's wrong here

  Disabling CloudFront access logging does not lower the per-request or data-transfer charges that drive your bill; those charges are incurred when CloudFront receives requests and serves bytes to viewers, regardless of whether log files are written. Access log delivery to S3 has its own small storage and PUT costs, so turning it off only removes that separate cost and, more importantly, eliminates visibility into cache hit behavior. Since the core problem is a low cache hit ratio causing excessive origin fetches and data transfers, disabling logging does not address the root cause and may even make it harder to diagnose which objects are generating the most origin traffic. The correct approach is to make objects more cacheable by increasing TTLs and enabling compression, not to stop recording metadata about the requests.

• ✗

  Set the distribution’s origin to use S3 Transfer Acceleration to reduce the number of requests hitting S3.

  Why it's wrong here

  Transfer Acceleration affects how data is delivered to S3 when accessed, but it doesn’t change whether CloudFront caches objects. If cache hit ratio is low due to TTL or cacheability headers, origin request volume remains high.

• ✗

  Force CloudFront to forward query strings to the origin for all static content so the latest versions are always fetched.

  Why it's wrong here

  Forwarding query strings to the origin for all static content makes CloudFront treat each unique query string as a separate cache key entry, so even if the underlying file never changes, multiple query string permutations fragment the cache and often result in cache misses. This fragmentation lowers the cache hit ratio and drives more requests back to the S3 origin, which increases origin request costs and data transfer fees—exactly the opposite of the goal. Moreover, using query strings to 'fetch the latest version' is an anti-pattern; modern versioned static assets should embed a version or hash in the object path (e.g., /js/app.v1.js) or use a cache policy with TTLs that reflect immutability, not force revalidation via query parameters. To improve cost, you should configure CloudFront to ignore query strings for static content or use a cache policy that does not include them in the cache key, letting each versioned file be cached and reused efficiently.

Go deeper

Related to this question