Quick Note — Recommend a High Availability Solution for Relational Data
AZ-305 › Unit 3: Design business continuity solutions › Design for high availability › Recommend a high availability solution for relational data
Quick Note — Recommend a High Availability Solution for Relational Data
A logistics platform takes orders all day from 12 countries and balances its books overnight. One Tuesday at Central European Time, the primary Azure SQL DB instance for the European order ledger becomes unreachable for nine minutes. Replicas in the same zone are unreachable too — the entire zone is offline. The CTO learns about it from a dashboard nine minutes after the event ended, because the database failed over automatically and no customer saw an outage. The architect who designed that database six months earlier had checked a single box: Zone Redundant.…
Retrieval target
- Recommend a High Availability Solution for Relational Data
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Zone-redundant Business Critical (Azure SQL DB) | An opt-in flag that spreads the BC replica set (3+1 quorum) across availability zones in the region. Lifts SLA from $99.99% %$. No extra cost — same vCore price as non-ZR BC. Pick whenever the region supports AZs and the workload is BC tier. Same flag exists for Premium DTU and Hyperscale. |
Active Geo-Replication | A SQL DB feature that creates up to 4 readable secondary databases in any Azure region. Async replication (RPO < 5 s typically). Each secondary has its own connection string — apps can offload read traffic to nearest replica. Manual failover (you call the API). Pre-cursor to Failover Groups, still useful for fine-grained per-DB control. |
Auto-Failover Group | A server-level grouping of one or more SQL DBs (or one SQL MI) that's replicated to a secondary server in another region with automatic, policy-driven failover. Provides read-write listener + read-only listener endpoints that always point at the current primary/secondary — apps don't have to update connection strings on failover. RPO ~5 s; RTO seconds–minutes. |
Always On Availability Group (SQL on VM) | SQL Server's native multi-replica HA feature, deployed on SQL Server on Azure VM workloads. Two+ VM nodes in a Windows Server Failover Cluster, replicate via log shipping (sync or async). Provides a listener for client connections. Required for IaaS SQL parity with on-prem HA; managed via SSMS or PowerShell. Use when SQL DB / MI features aren't sufficient. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.