SAA-C03 Practice Question 4: RDS Multi AZ Failover

A Multi-AZ DB instance deployment provisions a standby in a different Availability Zone and replicates to it synchronously, so a commit is not acknowledged until it is durable on both sides; that is what delivers "no committed transactions lost". RDS detects the failure and fails over automatically, and because the DB instance endpoint DNS name is repointed at the promoted standby, the application keeps using the same connection string. Converting an existing single-AZ instance is a modify operation, not a rebuild.

Option A gets the geography right but not the automation or the durability. Read replicas replicate asynchronously, so in-flight transactions can be lost, promotion is a manual action that someone has to notice and trigger, and the promoted replica has its own endpoint; the application's connection string would have to change.

Option B confuses backup retention with availability. A longer retention window gives you more restore points, but restoring a snapshot creates a brand-new DB instance, takes a long time for a large database, is entirely manual, and loses everything written since the restore point.

Option C is a disaster-recovery design for losing an entire Region, not an Availability Zone. It carries cross-Region replication lag and cost, still requires manual promotion, and Route 53 failover only redirects clients; it does not promote the replica for you. It is far more machinery than the stated requirement needs.

Note the related distinction: the standby in a Multi-AZ DB instance deployment does not serve read traffic. If you also need reads from the standbys, that is a Multi-AZ DB cluster deployment, which uses two readable standbys.

Reference: Multi-AZ DB instance deployments for Amazon RDS