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.

• ✗

  Enable automated backups on the replica before promotion

  Why it's wrong here

  Automated backups on a read replica govern point-in-time recovery and are independent of the promotion operation. Enabling backups before promotion won't make the replica writable or accelerate the failover process, because promotion simply removes the replication metadata and flips the instance to read-write. Moreover, if the replica was created from a source with backups enabled, it already has its own backup window; enabling backups manually is an administrative task, not a DR prerequisite.

• ✓

  Configure applications to use the new database endpoint

  Why this is correct

  A promoted read replica is a new database instance with a distinct DNS endpoint; the original master endpoint does not automatically reroute to the replica. Applications that connect using the old endpoint will continue hitting the original instance (or fail if it is down), so you must update your connection strings or configuration to use the promoted replica's endpoint. In complex environments, this is often managed via a CNAME that can be repointed to the replica, but the core requirement is that clients resolve to the new master.

• ✓

  Update Route 53 DNS record to point to the new master

  Why this is correct

  If your applications already rely on a logical DNS name instead of the RDS endpoint, updating the Route 53 record to an alias or CNAME value of the new master is an effective way to redirect traffic without touching each application's configuration. This works only when clients use the custom domain name; if they hardcode the RDS endpoint, changing DNS alone won't update their connections. Route 53 can also be combined with a health check to automate the repointing, but the action itself is only one part of the overall failover sequence.

• ✓

  Promote the read replica to a standalone database instance

  Why this is correct

  Promotion detaches a read replica from the replication topology and converts it from a read-only instance to a standalone writable DB instance, a requirement before it can serve writes in a disaster recovery scenario. Until promotion, the replica continues to stream and apply changes from the source and rejects INSERT/UPDATE/DELETE statements. The promotion process is a metadata-level operation that can take a few minutes to complete, after which the replica's promotion status changes and it becomes the new independent master.

• ✗

  Enable Multi-AZ on the read replica before promotion

  Why it's wrong here

  Multi-AZ requires a synchronous standby secondary and is a standalone high-availability feature, not a prerequisite for failing over to a read replica. A read replica is already a physically separate instance; attempting to enable Multi-AZ on it before promotion would either be invalid or force it to create a new standby, which doesn't help the promotion itself. Best practice is to promote the replica first, then enable Multi-AZ on the new standalone primary to protect it from future AZ failures.

Go deeper

Related to this question