AZ-305 Practice Question 7: SQL Resiliency Tiers
Microsoft Azure Solutions Architect Expert (AZ-305) · Test 1 · question 7 of 10
A payments platform stores its ledger in an Azure SQL Database in the East US region. The resiliency design must satisfy all of the following:
- The loss of a single availability zone must be recovered transparently, with no data loss. - The loss of the entire East US region must be recoverable with an RTO measured in seconds, not hours. - After a regional failover the application's connection string must not change. - The company's own incident commander must decide when a regional failover happens; failovers must never be triggered on Microsoft's schedule.
Which configuration should you include in the design?
Show answer and explanation
Answer:
Each requirement maps to one element of this design. Zone redundancy spreads the database replicas across availability zones in East US, giving an RTO typically under 30 seconds and an RPO of zero for a zonal failure, handled transparently by the service. A failover group layered on top provides continuous replication to a second region with a geo-failover RTO typically under 60 seconds. The group's read-write listener is a DNS CNAME that always points at the current primary, so the application keeps the same server name across a failover. Finally, the customer-managed failover policy, the option Microsoft recommends, leaves the decision to initiate a forced failover with the customer.
Option A meets none of the timing requirements. Geo-restore rebuilds a new database from geo-replicated backups; its RTO and RPO are typically minutes to hours depending on database size and storage replication, and the restored database sits on a different server, so the connection string changes too.
Option B breaks the last requirement, which is the discriminating one. With a Microsoft-managed policy, Azure decides when to fail over after a grace period that cannot be configured below one hour, and it fails over *every* Microsoft-managed group in the region at once, not this company's group on this company's call.
Option C is the closest wrong answer. Active geo-replication does provide a continuously synchronized secondary with comparable failover timing, but it exposes no listener endpoint. The option itself concedes the problem by requiring the connection string to be updated, which directly violates the third requirement. Failover groups exist precisely to add that listener abstraction on top of geo-replication.
Reference: Business continuity, high availability, and disaster recovery in Azure SQL Database