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.

• ✓

  Multi-AZ deployment

  Why this is correct

  Multi-AZ deployment creates a primary DB instance and a standby replica in a different Availability Zone, using synchronous physical replication to keep the standby transactionally consistent. When an AZ failure, network outage, or instance health check failure occurs, Amazon RDS automatically flips the DNS CNAME to the standby within about 60–120 seconds, providing automatic failover without manual intervention. This is the only option that gives the DB instance true high availability with a single endpoint, which is why it is correct.

• ✗

  Amazon RDS Proxy

  Why it's wrong here

  Amazon RDS Proxy is a fully managed connection pooling and multiplexing service that sits between client applications and the database, reducing connection overhead and protecting the database from connection storms. It can preserve existing application connections during a failover, making failover faster and more graceful, but it does not itself provision a standby instance or trigger the DB instance to fail over. Without Multi-AZ configured on the underlying RDS instance, the proxy remains a connection manager and cannot rescue availability—so it is incorrect for high availability.

• ✗

  Single-AZ with automated backups

  Why it's wrong here

  Single-AZ with automated backups performs continuous backups to Amazon S3 and enables point-in-time recovery to any second within the backup retention window, but that only restores to a new DB instance after a failure. If the single Availability Zone experiences an outage, the database becomes unavailable until you manually initiate a restore, exposing you to a potentially long RTO and some data loss (up to the last 5 minutes). Automated backups do not include a standby or automatic failover, so the instance is not highly available—making this option wrong.

• ✗

  Read replicas in multiple AZs

  Why it's wrong here

  Read replicas in multiple AZs are asynchronous copies of the primary database used solely to offload SELECT traffic and scale read-heavy workloads, and they require an engine that supports asynchronous replication. You may manually promote a read replica to become a standalone primary, but this is a manual administrative action, not an automatic failover mechanism—so if the primary fails, the database remains unavailable until someone intervenes. Furthermore, because replication is asynchronous, a promoted replica can miss committed transactions from the primary, making it unsuitable as a high-availability strategy—hence this option is incorrect.

Go deeper

Related to this question