You have an RDS for MySQL instance running in a single AZ. You want to improve DB availability so that it remains available during an AZ failure. Which configuration minimizes application-side changes?

Explanation

RDS Multi-AZ improves availability during an AZ failure with synchronous replication and automatic failover.

Per-choice explanations

Practical Use

An RDS Multi-AZ deployment automatically builds a standby DB in a different Availability Zone within the same Region and performs synchronous replication with the primary DB. When the primary AZ fails, automatic failover occurs, and the DB endpoint (DNS name) is redirected to the standby side. The application can recover without changing its connection string. Failover typically completes in roughly 60 to 120 seconds, greatly shortening the RTO compared with a single-AZ configuration. The distinction between Multi-AZ and Read Replicas is a frequent topic on SAA-C03. Multi-AZ is a standby configuration for availability, and the standby DB usually cannot serve reads (an exception is the Multi-AZ DB Cluster option, which provides two readable standbys). A Read Replica is an asynchronous replica for improving read performance. Its main purpose is not availability, and as a failover target it requires manual promotion. The standard pattern for large RDS configurations is to combine the two: protect writes with Multi-AZ and scale reads with Read Replicas. Multi-AZ has a cost trade-off. Because an additional standby DB instance runs, the compute charges are roughly twice those of a single-AZ configuration. Even so, it is the standard choice for workloads with availability requirements because it handles failover without application changes. On SAA-C03, Multi-AZ is the correct answer for requirements such as "maintain availability during an AZ failure" and "minimize application changes," while distractors line up operations on a different axis from availability, such as changing the storage type, disabling backups, or moving to a public subnet.