AZ-305
Deep Dive
Databases have their own continuity toolkit: failover groups, geo-replication, PITR and LTR for SQL; multi-region replicas for Cosmos. The AZ-305 requires distinguishing which mechanism meets each combination of RTO, RPO and application requirement.
Contents
What already comes out of the box
Design
| Aspect | Active Geo-Replication | Failover Groups |
|---|---|---|
| Unit | Individual database | GROUP of databases (they fail over together) |
| Replicas | Up to 4 readable secondaries, in any region | 1 secondary (on another logical server) |
| Connection string | CHANGES on failover (the app must re-point) | Does NOT change: listener endpoints (read-write / read-only) redirect automatically |
| Automatic failover | No — manual or via your own tooling | Yes — optional automatic failover policy |
| MI support | No (SQL Database only) | Yes — failover groups is THE mechanism for Managed Instance |
| When | Geo read scale-out + fine per-DB control | Full application DR without touching connection strings — the typical exam answer |
Quick rule
"Without changing connection strings" or "automatic failover of several DBs together" → failover group. "Readable replicas across several regions" → active geo-replication. Asynchronous replication in both → RPO of seconds (not zero).
Point-in-Time Restore (PITR)
Long-Term Retention (LTR)
Distinction that always comes up
Geo-restore (from geo-replicated backup): cheap DR, RPO ≤ 1h, restoration RTO — no pre-provisioned infrastructure. Failover group: RPO of seconds, RTO of seconds-minutes — a paid active replica. The RPO/RTO requirement decides.
Availability
Data recovery
| Service | HA | DR |
|---|---|---|
| SQL Managed Instance | GP/BC same as SQL DB; zone redundancy | Failover groups (with the Link feature, also DR to/from SQL Server on-prem) |
| PostgreSQL Flexible | Zone-redundant HA: SYNCHRONOUS standby in another zone (0 RPO intra-region) | Read replicas (asynchronous) in another region + manual promotion; geo-backup |
| MySQL Flexible | Same zonal HA (synchronous standby) | Cross-region read replicas + promotion |
| SQL Server on VM | Always On Availability Groups across zones | Asynchronous AG to another region, or ASR |
| Requirement | Design |
|---|---|
| DB survives a zone outage without a geo-replica | Tier zone redundancy |
| Regional failover without changing connection strings | Failover group (listener endpoints) |
| 5 DBs of an app must fail over TOGETHER | Failover group with all 5 |
| Readable replicas in 3 regions for global users | Active geo-replication (up to 4 secondaries) |
| Recover a table deleted 3 days ago | PITR (restore as a new DB) |
| DB backups retained 7 years (compliance) | Long-Term Retention |
| Cheapest possible SQL DR, 1h RPO and hours-long RTO OK | Geo-restore from geo-redundant backup |
| DR for Managed Instance | Failover group (geo-replication doesn't apply to MI) |
| Cosmos keeps writing if a region goes down | Multi-region writes (or service-managed failover) |
| PostgreSQL with 0 RPO intra-region | Flexible Server zone-redundant HA (synchronous standby) |
Did you get this topic?
Test what you just learned
An application uses 4 databases on Azure SQL Database that must fail over to West US as a group if East US goes down, automatically, without the application changing its connection strings. What mechanism do you design?
Put what you learned to the test with original AZ-305 exam questions.
Start AZ-305 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.