DOP-C02 Resilient Cloud Solutions 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 health checks, then lower TTL, then promote RDS, then update DNS, then verify

  Why this is correct

  This is correct because health checks must be in place to detect the failure, then TTL is lowered to speed up DNS propagation, then RDS is promoted to make the secondary writable, DNS records are updated to point to the new primary, and finally verification confirms successful failover.

• ✗

  Lower TTL, then configure health checks, then promote RDS, then update DNS, then verify

  Why it's wrong here

  Lowering the TTL before health checks are configured is backwards: health checks must be the first step so Route 53 can reliably evaluate endpoint status and govern DNS failover. If you reduce TTL first, edge resolvers will cache the current primary record more briefly, but there is no health-based routing logic yet to act on that faster expiration during an outage. A premature TTL change also causes unnecessary DNS request amplification before your routing policy is ready, and any subsequent health check misconfiguration could still send traffic to an unhealthy endpoint.

• ✗

  Configure health checks, then promote RDS, then lower TTL, then update DNS, then verify

  Why it's wrong here

  Promoting the RDS replica before lowering the TTL means the DNS record still points to the (now standby) old primary with a long TTL; clients with cached DNS will keep hammering the old primary, which is no longer writable or may be mid-promotion. In a fast-failover scenario you must shrink the TTL first so the eventual DNS update propagates quickly, otherwise you create an extended window of mixed routing where some clients hit the read-only old primary and others hit the new primary before DNS converges. This ordering also violates the principle of making the control-plane changes in dependency order: monitoring and propagation settings must precede the actual promotion cutover.

• ✗

  Configure health checks, then update DNS, then lower TTL, then promote RDS, then verify

  Why it's wrong here

  Updating DNS before promoting RDS is dangerous because Route 53 would point at the secondary RDS instance while it is still a read replica, so application writes fail with read-only errors and you risk data loss if the promotion is not completed cleanly. The DNS change must come after the promotion so that the record set only starts resolving to an instance that is already the writable primary. Additionally, updating DNS while the old primary is still serving traffic can cause split-brain writes between the old primary and the new primary during the final replication handoff, which is a classic data-integrity failure in disaster recovery runbooks.

Go deeper

Related to this question