Quick Note — Recommend a High Availability Solution for Relational Data — Designing Microsoft Azure Infrastructure Solutions (AZ-305) Study Notes | BrainyBee

A logistics platform takes orders all day from 12 countries and balances its books overnight. One Tuesday at $03{:}14$ 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

Objective: Recommend a High Availability Solution for Relational Data
Mode: Closed-book recall
Target time: 5 minutes
Escalation: 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 $\geq 2$ availability zones in the region. Lifts SLA from $99.99% $\to 99.995$ %$. 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 equal to or greater than 0; RTO typically less than 60 s for a customer-initiated geo-failover). 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.
`Failover Groups`	A server-level grouping of one or more SQL DBs (or one SQL MI) that's replicated to a secondary server in another region. Two failover policies: customer-managed (`manual` in PowerShell/CLI/REST), the policy Microsoft recommends, where you trigger the geo-failover; and Microsoft-managed (`automatic`), which Azure triggers only for a region-wide outage after a grace period that cannot be set below 1 hour — Microsoft tells customers not to rely on it, so it is not the answer to a tight-RTO requirement. 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. With customer-managed failover, RTO is typically less than 60 s and RPO is equal to or greater than 0 (data changed but not yet replicated).
`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; the primary replica sends transaction log records to every secondary in a process known as data synchronization, in synchronous-commit or asynchronous-commit mode (log shipping is a separate SQL Server feature, not how an AG replicates). 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.

Recommend a High Availability Solution for Relational Data — quick retrieval

Card 1 of 4

Zone-redundant Business Critical (Azure SQL DB)

easy

Recommend a High Availability Solution for Relational Data — quick retrieval

Card 1

Front: Zone-redundant Business Critical (Azure SQL DB)
Back: An opt-in flag that spreads the BC replica set ( $3$ +1 quorum) across $\geq 2$ availability zones in the region. Lifts SLA from $99.99\% \to 99.995\%$ . 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.

Card 2

Front: Active Geo-Replication
Back: A SQL DB feature that creates up to $4$ readable secondary databases in any Azure region. Async replication (RPO equal to or greater than $0$ ; RTO typically less than $60$ s for a customer-initiated geo-failover). 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.

Card 3

Front: Failover Groups
Back: A server-level grouping of one or more SQL DBs (or one SQL MI) that's replicated to a secondary server in another region. Two failover policies: customer-managed (manual in PowerShell/CLI/REST), the policy Microsoft recommends, where you trigger the geo-failover; and Microsoft-managed (automatic), which Azure triggers only for a region-wide outage after a grace period that cannot be set below $1$ hour — Microsoft tells customers not to rely on it, so it is not the answer to a tight-RTO requirement. 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. With customer-managed failover, RTO is typically less than $60$ s and RPO is equal to or greater than $0$ (data changed but not yet replicated).

Card 4

Front: Always On Availability Group (SQL on VM)
Back: 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; the primary replica sends transaction log records to every secondary in a process known as data synchronization, in synchronous-commit or asynchronous-commit mode (log shipping is a separate SQL Server feature, not how an AG replicates). 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.

Loading flashcards…

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.

A server-level grouping of one or more SQL DBs (or one SQL MI) that's replicated to a secondary server in another region. Two failover policies: customer-managed (manual in PowerShell/CLI/REST), the policy Microsoft recommends, where you trigger the geo-failover; and Microsoft-managed (automatic), which Azure triggers only for a region-wide outage after a grace period that cannot be set below $1$ hour — Microsoft tells customers not to rely on it, so it is not the answer to a tight-RTO requirement. 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. With customer-managed failover, RTO is typically less than $60$ s and RPO is equal to or greater than $0$ (data changed but not yet replicated).