SAA-C03 Design Resilient 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 latency-based routing with one record per region and no health checks.

  Why it's wrong here

  Latency-based routing chooses the region with the lowest network latency for each individual user, but without health checks it will continue to return an endpoint even after that region becomes unhealthy. Because it has no primary/secondary concept, failover is not deterministic, and the response can vary per user based on their geographic location, causing some users to keep hitting the failed region until the DNS TTL expires. It also cannot automatically shift all traffic to a single healthy standby region, as required for a controlled disaster-recovery failover.

• ✓

  Use failover routing policy: create two alias records for the same name (primary and failover) and associate health checks with the primary record.

  Why this is correct

  Failover routing with two alias records for the same DNS name (one marked primary, one marked secondary) gives you deterministic active-passive failover. You attach a health check to the primary alias; when that health check fails, Route 53 automatically returns the secondary record's endpoint in the next DNS response, without manual intervention. Alias records allow you to point directly to regional load balancers or other AWS resources, and the secondary record ensures that all traffic moves to the healthy region once the primary is considered unhealthy.

• ✗

  Use weighted routing and manually change the weights during incidents.

  Why it's wrong here

  Weighted routing distributes traffic according to assigned weights, and while you could manually change weights during an incident, that requires human intervention, which slows recovery and risks configuration mistakes. Even if you associate health checks, weighted routing does not enforce a strict primary/secondary relationship; it simply removes unhealthy endpoints from rotation, meaning traffic could still be split across regions when both are healthy, and failover is not deterministic. Manual weight changes also do not account for DNS TTL caching, so impacted users may continue to receive the old answer until resolvers refresh.

• ✗

  Create a single alias record only for the primary region and rely on client-side DNS retries.

  Why it's wrong here

  A single alias record pointing only to the primary region has no fallback target, and relying on client-side DNS retries is ineffective because most clients and resolvers cache DNS answers for the TTL and do not automatically re-query on connection failure. Without a health check and a secondary record, Route 53 has no mechanism to change the response; even if the client re-resolves, it receives the same primary IP because the record itself is unchanged. This creates a single point of failure and fails to meet the requirement for automated, deterministic failover across regions.

Go deeper

Related to this question