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.

• ✗

  Existing connections are automatically redirected to the standby without interruption.

  Why it's wrong here

  Amazon RDS Multi-AZ failover does not provide a transparent network-layer redirect; previously established TCP connections to the primary instance's IP are immediately severed when the standby is promoted. The DNS CNAME is updated after the failover, but any existing socket remains invalid, and there is no built-in connection proxy to replay in-flight transactions. Applications must use retry logic to reconnect, so 'without interruption' is inaccurate.

• ✗

  The RDS endpoint IP address changes, and the application must update its configuration.

  Why it's wrong here

  The RDS endpoint is a DNS CNAME that remains stable across a Multi-AZ failover; AWS changes the underlying A record to point to the newly promoted primary's IP address. The application's configuration should continue to use the same database endpoint hostname and does not need manual updates or IP reconfiguration. While the resolved IP changes, the endpoint name itself does not, so requiring an application configuration change is incorrect.

• ✓

  Existing connections are dropped, and applications must reconnect to the new primary using the same endpoint.

  Why this is correct

  A Multi-AZ failover promotes the standby instance to primary and updates the RDS DNS record to the new primary's IP, but existing connections are not preserved. Because the old primary is no longer reachable, active TCP sessions and open database connections are dropped, forcing client applications to re-establish them. Applications must reconnect to the same CNAME endpoint—ideally with retry/backoff logic—to transparently recover once DNS propagation completes. This is the expected and documented behavior.

• ✗

  The primary DB instance is promoted to standby and connections remain active.

  Why it's wrong here

  When the primary fails, RDS promotes the standby to become the new primary; the original primary does not get 'promoted to standby'—if it recovers, it is demoted to standby later. This role reversal is a management-plane operation that does not keep existing connections alive; clients receive an error as their current TCP connection is terminated. Thus the standby becomes primary, not the other way around, and active connections do not remain active.

Go deeper

Related to this question