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.

• ✗

  Create a single Route 53 record using weighted routing across both ALBs with weights adjusted manually during an incident.

  Why it's wrong here

  Weighted routing with manual weight adjustments is inherently reactive and not an operational failover mechanism. While you could assign weights to A records that point to each ALB, Route 53 will still distribute traffic according to those weights even if one ALB is impaired, unless you attach a health check to each weighted record and remove the unhealthy set automatically. Manually editing weights during an incident relies on DNS TTL expiration and propagation, which can take minutes, and requires someone to detect the outage first—so it does not meet the need for automatic, fast regional failover.

• ✓

  Use Route 53 failover routing with a primary record pointing to the us-east-1 ALB and a secondary record pointing to the us-west-2 ALB, each using health checks.

  Why this is correct

  Failover routing is the correct active–passive DNS pattern for regional redundancy. You create a primary A record for the us-east-1 ALB with an associated Route 53 health check, and a secondary A record for the us-west-2 ALB; when the health check fails for the primary, Route 53 automatically responds to DNS queries with the secondary record. This shifts client traffic to the healthy secondary region without manual intervention. Route 53 can also use health checks on both records to detect secondary failure, though the primary health check is the key trigger for failover.

• ✗

  Use latency-based routing so Route 53 always selects the fastest region; health checks are unnecessary because client latency reflects availability.

  Why it's wrong here

  Latency-based routing chooses the record that offers the lowest round-trip time for each individual client, not the region that is actually healthy. If the us-east-1 endpoint begins returning HTTP 5xx errors or is completely unavailable, latency-based routing will still return that record to clients in eastern North America because latency measurements do not reflect application health. Health checks are mandatory if you want latency-based routing to fail over, and the option explicitly says they are unnecessary—making this configuration incapable of detecting or responding to an outage.

• ✗

  Use a single A record with a static IP address that points to a NAT gateway, and update that IP during failure events.

  Why it's wrong here

  A NAT gateway is designed for outbound internet access from private subnets, not for accepting inbound traffic to an ALB; it cannot serve as a public endpoint for an API. Moreover, ALBs are typically accessed via their DNS names, not a static IP, and using a static IP requires an Elastic IP attached to a Network Load Balancer or an instance, not a NAT gateway. Manually updating the A record during a failure is not an automated failover approach; it introduces DNS TTL delays and requires external monitoring, so it is both architecturally invalid and operationally unsafe for this use case.

Go deeper

Related to this question