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.

• ✗

  The RDS failover took longer than expected; increase the Multi-AZ timeout

  Why it's wrong here

  Multi-AZ failover is an automatic RDS feature, not a tunable CloudFormation or RDS parameter; there is no such thing as a 'Multi-AZ timeout' to increase. While failover typically completes in 60–120 seconds, the actual issue is that the application's existing connections are terminated when the endpoint's DNS record updates, and without retry logic, the app never reconnects. Extending a client-side timeout only delays the error, it does not restore the broken connection.

• ✗

  The read replica was promoted incorrectly; recreate the read replica

  Why it's wrong here

  Multi-AZ DB instances do not use read replicas for high availability; they use a synchronous standby replica in a different Availability Zone that is not accessible for reads and is not manually promoted. Failover is triggered automatically by RDS, so the concept of 'promoting' a read replica is irrelevant to a Multi-AZ deployment. Recreating a read replica would neither fix the connection failure nor change how Multi-AZ failover behaves.

• ✗

  The RDS proxy is misconfigured; disable the proxy for Multi-AZ

  Why it's wrong here

  RDS Proxy does not eliminate the need for application-level retry logic; it pools and reuses existing connections to reduce the connection storm during failover, but it still relies on the application to retry after the brief outage. Disabling the proxy for Multi-AZ would remove that pooling benefit and make the problem worse, as the app would face more connection failures and reconnection overhead. The proxy is not misconfigured; the application simply lacks retry behavior.

• ✓

  The application does not implement connection retry logic; implement exponential backoff and retry

  Why this is correct

  During an RDS Multi-AZ failover, the existing TCP connections to the primary instance are forcibly closed, and the database endpoint's DNS CNAME is updated to point to the new primary. If the application does not implement connection retry with exponential backoff, it will never re-establish those dropped connections, causing an outage even after the failover completes. Retry logic with backoff and jitter is the standard, required practice for any production application using RDS, especially when combined with a connection pool or RDS Proxy.

Go deeper

Related to this question