SAA-C03 Design High-Performing 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.

• ✗

  Use Lambda@Edge to rewrite all requests to a single origin and compress responses, eliminating the need for multiple cache behaviors and origins.

  Why it's wrong here

  Lambda@Edge can modify requests and responses, but rewriting all requests to one origin does not provide the caching benefits of separate origins or behaviors. It also adds latency and cost for every request. This approach does not inherently reduce origin load or improve global performance as effectively as proper cache behaviors and multiple origins.

• ✓

  Configure the S3 bucket as a CloudFront origin with an Origin Access Control (OAC) and set the bucket policy to allow only the CloudFront distribution to access the objects.

  Why this is correct

  Using OAC lets CloudFront securely access the S3 bucket without making objects public, and the bucket policy restricts direct access. This improves security and allows CloudFront to cache static content at edge locations, reducing latency for global users and lowering the load on the S3 origin because repeated requests are served from cache.

• ✗

  Create a second CloudFront distribution with a different price class and use Route 53 latency-based routing to direct users to the distribution with the lowest latency.

  Why it's wrong here

  CloudFront already uses a global anycast network and automatically routes users to the nearest edge location, so multiple distributions with latency-based routing add complexity without benefit. Price classes affect which edge locations are used but do not require separate distributions. This approach does not improve performance beyond a single well-configured distribution.

• ✓

  Enable CloudFront caching for static assets with a long TTL and configure the Application Load Balancer as a second origin with cache behaviors that forward necessary headers for dynamic requests.

  Why this is correct

  Separate cache behaviors allow static assets from S3 to be cached with long TTLs, while dynamic requests to the ALB can be configured to forward required headers and avoid caching. This design reduces latency for static content, offloads the ALB, and preserves dynamic behavior. It is a standard CloudFront multi-origin pattern for mixed static and dynamic applications.

• ✗

  Set the Application Load Balancer as a custom origin, enable caching for dynamic content with a long default TTL, and forward all headers and cookies to the origin.

  Why it's wrong here

  Caching dynamic content with a long TTL can serve stale or personalized responses incorrectly, and forwarding all headers and cookies prevents effective caching. Dynamic content typically should not be cached or should use short TTLs with cache keys based on relevant headers. This configuration would harm correctness and may not reduce origin load as intended.

Go deeper

Related to this question