SOA-C02 Cost and Performance Optimization 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 multiple origins with failover.

  Why it's wrong here

  Configuring multiple origins with failover is a high-availability feature: CloudFront routes requests to a secondary origin only when the primary returns an error such as 5xx or a connection timeout. This does nothing to reduce the number of requests sent to your origin or the amount of data transferred, so it cannot lower your cost; in fact, maintaining a second origin adds operational overhead and storage expense, making it a poor choice for cost optimization.

• ✗

  Enable Lambda@Edge to modify requests and responses.

  Why it's wrong here

  Lambda@Edge runs JavaScript functions at CloudFront edge locations for every matched request and response, and you are billed per invocation and per GB-second of compute time used. While it can customize content, manipulate headers, or generate responses, it does not inherently increase cache hit ratios or reduce the data transfer from origin to edge; instead, it introduces an additional compute cost that would raise your overall spend, making it counterproductive when the goal is to reduce costs.

• ✓

  Enable Origin Shield to create a central caching layer.

  Why this is correct

  Origin Shield adds a centralized caching layer in a specific AWS Region, so all CloudFront edge locations forward cache misses to that single regional endpoint rather than directly to your origin. This consolidates requests from multiple edges, dramatically improving the global cache hit ratio and reducing both the volume of origin requests and the data transfer from origin to edges—and because you pay less for data transfer and origin load, it directly lowers your cost. Origin Shield is an AWS-native feature purpose-built for this cost-reduction scenario.

• ✗

  Increase the TTL for cache behaviors to the maximum allowed value.

  Why it's wrong here

  Increasing the TTL for cache behaviors to the maximum allowed value extends how long objects are retained in each edge cache, which can produce more cache hits on a given edge. However, each CloudFront edge location still has its own independent cache, so the same object may be fetched separately at many different edges, limiting the overall reduction in origin requests. Additionally, very long TTLs risk serving stale content to users for extended periods, and for content with unpredictable changes this is unacceptable; Origin Shield achieves a higher hit ratio more safely by centralizing the cache.

Go deeper

Related to this question