13.1 Recommending HA/DR Strategy from RPO and RTO

Why RPO and RTO Anchor the DP-300 HA/DR Decision

Domain 5 of the DP-300 exam is built around one idea: the business states how much data it can lose and how long it can be down, and you translate that into a concrete Azure SQL configuration. Two metrics drive everything. Recovery Point Objective (RPO) is the maximum amount of data loss, measured in time, that a business tolerates - an RPO of 5 minutes means up to 5 minutes of committed transactions may be lost in a disaster. Recovery Time Objective (RTO) is the maximum downtime to restore service to a usable state, including detection, failover, and client reconnection. RPO governs data loss; RTO governs downtime. They are independent: a strategy can have an RPO of zero (no data loss) yet an RTO of hours (slow manual recovery), or an RPO of 15 minutes yet an RTO of under a minute (fast automatic failover with some data loss).

The exam repeatedly presents a scenario with business wording - "the order-entry system must not lose more than a few seconds of transactions and must be back online in under a minute" - and asks which technology to choose. Your job is to map that wording to RPO and RTO numbers, then pick the technology whose SLA satisfies both. A frequent trap is fixing only one objective: an answer that meets RPO but blows RTO (or vice versa) is wrong.

Technology-to-SLA Mapping

Each Azure SQL HA/DR technology has a characteristic RPO/RTO profile. The table below summarizes the values the exam expects you to know.

Notice the contrast the exam leans on. Active geo-replication uses asynchronous replication to up to four secondaries in paired or any regions with an RPO approaching zero, but failover is manual and forced - you initiate it, there is no grace period, and the application must reconnect to the new primary's connection string. Failover groups layer automatic, graceful failover on top of geo-replication for all databases in the group, with a read-write and read-only listener endpoint that stays stable across failover, so application connection strings do not change. Failover groups add a configurable grace period (default 1 hour) before automatic failover triggers, intended to avoid failing over during a transient regional issue; you can lower it, but the SLA applies after the grace period elapses.

Always On availability groups (on SQL Server VMs and behind Business Critical SQL MI) give synchronous-commit replicas with an RPO of 0-5 seconds and an RTO of seconds to minutes via automatic failover when properly configured with a cluster quorum and listener. Log shipping is the budget async option: you set the log backup frequency (every N minutes), copy the backups to the secondary, and restore them WITH NORECOVERY. RPO equals the gap between the last restored log on the secondary and the failure moment; RTO is the time to copy the tail (if any), restore it, bring the secondary online, and repoint clients. Backup and restore is the floor under everything - it is the only option when no secondary exists, with RPO equal to the backup interval and RTO equal to restore time.

Single-Region vs Multi-Region

A separate axis is the scope of failure you tolerate. Single-region HA (availability groups, zone redundancy, FCI) protects against hardware or datacenter failure but not regional outage. Multi-region DR (geo-replication, failover groups, geo-restore) protects against regional failure at higher cost and complexity. The exam expects a two-layer strategy: HA within a region for low-RTO local failures, DR across regions for catastrophic loss. A common scenario: "The application must survive a datacenter failure with no data loss and a regional outage with up to 5 minutes of data loss" - the answer is zone-redundant or Business Critical deployment for HA plus failover groups or active geo-replication for DR.

Tradeoffs: Cost, Complexity, RPO/RTO

Lower RPO and RTO cost more. The tradeoff ladder is a reliable exam frame:

• Backup-only is cheapest, highest RPO/RTO, suitable for dev/test and non-critical databases.
• Log shipping adds an async secondary cheaply, moderate RPO, manual RTO.
• Always On AG (synchronous) adds a sync replica for near-zero RPO, moderate cost, fast automatic failover; cost rises with the sync replica's compute and the network latency requirement.
• Active geo-replication adds multi-region near-zero RPO, manual failover, higher cost (secondary compute billed).
• Failover groups add automatic failover and stable endpoints on top of geo-replication - highest cost, lowest operational RTO.

Cost grows with every step down the RPO/RTO scale because each tier provisions additional replicas, cross-region traffic, or synchronization infrastructure. The exam's right answer is always the lowest tier that meets both RPO and RTO - over-provisioning resilience is a cost waste the exam penalizes.

Manual vs Automatic Failover and Grace Period

Failover type changes the operational RTO. Automatic failover (failover groups, AG with a properly configured failover condition) reduces operational RTO because no human is in the loop. Manual forced failover (active geo-replication) requires an operator to act, so the realized RTO includes detection time and human response - longer and less predictable. The grace period on failover groups is a deliberate delay before automatic failover to ride out transient issues; a shorter grace period lowers RTO but raises the risk of failing over unnecessarily, while a longer grace period (default 1 hour) avoids needless failovers at the cost of a longer realized RTO. The exam tests both directions: shortening the grace period for a revenue-critical workload that must fail over fast, and leaving it long for a workload sensitive to unnecessary failovers.

Documenting the HA/DR Strategy

A complete strategy documents, per workload: the RPO and RTO targets, the chosen technology and tier, the failover trigger and owner, the recovery runbook, the backup schedule and retention, and the test cadence. The decision matrix below is the artifact the exam expects you to reason from.