AZ-305 Design business continuity 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.

• ✗

  SQL Server Always On Availability Group with asynchronous commit.

  Why it's wrong here

  With asynchronous commit, the primary replica accepts a transaction and acknowledges it without waiting for the secondary replica to harden that log block. Under normal operation the secondary stays near-real-time, but any lag—network latency, heavy log volume, or a regional disruption—creates a window where committed transactions on the primary are absent from the secondary. If a failover is triggered during that window, those transactions are lost, so the recovery point objective (RPO) is non-zero. Because the requirement mandates zero data loss, asynchronous commit fails even though it avoids the performance penalty of synchronous replication.

• ✓

  SQL Server Always On Availability Group with synchronous commit across regions.

  Why this is correct

  Synchronous commit ensures all transactions are committed on both the primary and secondary replicas before acknowledging the commit to the application. If configured across regions, this provides zero data loss (RPO=0). But network latency can affect write performance.

• ✗

  Azure Site Recovery to another region.

  Why it's wrong here

  Azure Site Recovery continuously copies Azure VM disks asynchronously, producing recovery points that are typically 5–15 minutes old, and it is not application-aware for SQL Server transactional consistency. Even when application-consistent snapshots are enabled, ASR only guarantees that VSS-backed applications are in a consistent state at the snapshot moment—it does not guarantee that every SQL transaction committed before failure is included in the recovered copy. A database failover via ASR therefore restores to a point in time before the outage, losing any transactions committed after the last captured recovery point. This cannot satisfy an RPO of zero and is better suited for crash-consistent DR where limited data loss is acceptable.

• ✗

  Deploy the VMs in a different availability zone within the same region.

  Why it's wrong here

  Deploying the SQL Server VMs in separate availability zones places them in different fault domains and power/cooling/network domains within the same Azure region, which protects against a single datacenter failure but not an outage that takes down the entire region. A regional event—such as a natural disaster or a large-scale platform failure affecting all zones—would still make the database unavailable, and the cluster or AG replicas would be in the same regional blast radius. The requirement explicitly says 'across regions,' so zone-level redundancy is technically outside the scope. While zones do help with in-region SLA, they do not provide cross-region disaster recovery or guarantee zero RPO for a regional outage.

Go deeper

Related to this question