AZ-104
Deep Dive
Azure's replication strategies and services for ensuring availability and disaster recovery. The AZ-104 tests RPO/RTO, per-service replication options, and failover configuration.
Contents
RPO (Recovery Point Objective)
The maximum amount of data you can afford to lose, measured in time. If RPO is 1 hour, in the worst case you lose 1 hour of data.
RPO = 0: synchronous replication, no loss. RPO = 5 min: asynchronous replication with a typical 5-min lag.
RTO (Recovery Time Objective)
The maximum allowed time to recover the service after a failure. If RTO is 1 hour, the service must be operational within 1h at most.
RTO = 0: immediate automatic failover (Business Critical SQL). RTO = 30 min: manual failover with preparation time.
Synchronous vs asynchronous replication
Synchronous: the write is confirmed only after all replicas receive it. RPO = 0, but higher latency. Asynchronous: the write is confirmed on the primary and replicated afterward. Lower latency, RPO > 0.
SQL Business Critical: synchronous. SQL General Purpose: asynchronous. Storage GRS: asynchronous.
Storage redundancy is configured when the account is created and affects every service inside it (Blob, File, Queue, Table). See full details in the Storage Accounts topic.
| Redundancy | RPO (approx.) | RTO (failover) | Replication type | Read availability during a regional outage |
|---|---|---|---|---|
| LRS | N/A (1 region) | N/A | Synchronous (3 copies, same DC) | No — if the DC fails, there is no read access |
| ZRS | N/A (1 region, 3 AZs) | Automatic (seconds) | Synchronous (3 AZs) | Yes — if 1 AZ fails, the other 2 serve traffic |
| GRS | <15 min (typical) | Hours (manual or automatic failover) | Asynchronous to the secondary region | No — secondary only available post-failover |
| RA-GRS | <15 min | N/A for reads (secondary always available) | Asynchronous to the secondary region | Yes — .secondary endpoint always available |
| GZRS | <15 min | Hours (failover) | Synchronous (3 primary AZs) + Asynchronous (secondary) | No (without RA-) |
| RA-GZRS | <15 min | N/A for reads | Synchronous (3 AZs) + Asynchronous (secondary) | Yes — maximum availability |
Storage Account failover
• Failover turns the secondary region into the primary (the account starts serving from the new primary)
• After failover, redundancy becomes LRS in the new primary — you must reconfigure GRS/ZRS manually
• Failover can be initiated from: Portal → Storage Account → Geo-replication → Prepare for failover
• Microsoft can trigger an automatic failover during major disasters (no timing guarantee)
• Possible data loss: Azure shows the "Last sync time" — data written after that time may be lost
Object Replication automatically copies blobs from a source container to a destination container (in the same or a different account/region). It differs from GRS redundancy — it operates at the level of a specific container.
How it works
• Asynchronous replication based on the blob Change Feed
• You can define filters: only blobs with certain prefixes, or from a specific creation date
• Does not replicate operation metadata (only the blob content)
• The destination can be in a different account, subscription, or region
• There's no time guarantee (SLA) for when replication reaches the destination
Requirements
• Blob Versioning enabled on the source AND destination
• Change Feed enabled on the source account
• Block Blobs only (not Page Blobs or Append Blobs)
Use cases
Content distribution
Replicate images/videos to multiple regions to serve them locally. APAC users read from a Storage account in APAC, reducing latency.
Distributed analytics
Replicate operational data (East US region) to a dedicated analytics account (West US) without affecting the primary production account.
Differentiated retention
The source account retains data for 30 days on the Hot tier. The replica in another account automatically applies the Archive tier. Cost optimization without complex lifecycle rules on the source account.
Active Geo-Replication
Up to 4 readable secondary replicas in different regions. Continuous asynchronous replication from the primary DB. Secondaries are active read-only databases.
• RPO: ~5 seconds under normal conditions (asynchronous)
• RTO: ~30 seconds for manual failover
• Failover: always manual — there is no native automatic failover in plain geo-replication
• Read scale-out: redirecting read queries to secondaries reduces load on the primary
• Available only on Azure SQL Database (not SQL MI)
• On failover, the app must update its connection string to the new primary
Auto-Failover Groups
Extends geo-replication with configurable automatic failover and connection-string endpoints that don't change during failover.
• RW Listener: stable DNS name — automatically points to the current primary
• RO Listener: points to the secondary — to separate read/write
• Grace period: wait time before automatic failover (min. 1 hour, configurable)
• Failover policy: Automatic or Manual
• Available on SQL Database and SQL Managed Instance
• A failover group can include multiple DBs — they switch over together
Internal HA vs Geo-Replication vs Failover Groups
| Mechanism | Scope | Automatic | RPO | Protects against |
|---|---|---|---|---|
| Internal HA (always on) | Replicas within the same region | Yes | ~0 sec (Business Critical) / ~25 sec (GP) | Node failure, hardware |
| Geo-Replication | Another region | No (manual) | ~5 sec | Full region failure |
| Auto-Failover Groups | Another region | Optional | ~5 sec | Regional failure + transparent to the app (endpoint does not change) |
Multi-region replication
In Cosmos DB you can add or remove regions at any time from the Portal with zero downtime. Replication is asynchronous between regions (except with Strong consistency).
• Read latency: <10ms when reading from the local region
• Write latency: depends on the write region and the chosen consistency
• Number of regions: up to ~25+ simultaneous regions
• Cost: each replica region adds the cost of the provisioned RU/s
Single-write vs Multi-write (Multi-master)
Single-write region
One region accepts writes. The others are read-only. Configurable automatic failover if the write region goes down. Failover order: manual priority.
Multi-region writes
All regions accept writes. Minimal global write latency. Requires managing write conflicts (LWW or custom). Effectively 0 RPO for local writes.
Failover in Cosmos DB
• Automatic: if the write region is unavailable, Cosmos picks the next one in the failover priority list
• Manual: you can change the write region in the portal (no downtime with multi-write, a brief window with single-write)
• With multi-write: no failover needed — any region accepts writes
Failover behavior comparison by service
Azure Storage (GRS/GZRS)
Automatic failover
Only for major disasters declared by Microsoft. No time SLA.
Manual failover
Portal → Geo-replication → Prepare failover. Can take 1+ hour. May involve data loss (data after the "last sync time").
Post-failover
The account ends up on LRS in the new region. You must reconfigure GRS manually.
Azure SQL Database (Auto-Failover Groups)
Automatic failover
Yes — if Grace Period is set and Failover Policy = Automatic. Failover starts if the primary does not respond during the grace period.
Manual failover
Portal → Failover Group → Failover. The app uses the DNS listener (unchanged). Forced failover can cause data loss.
Post-failover
The secondary becomes the primary. The old primary becomes the secondary (automatic reverse sync).
Azure Cosmos DB (single-write)
Automatic failover
Yes — if "Enable automatic failover" is turned on. Cosmos picks the next region in the priority list.
Manual failover
Portal → Replicate data globally → Manual failover → choose the new primary region.
Post-failover
The new region accepts writes. The old one automatically becomes a read replica.
| Service | Replication option | Type | RPO | Read from replica | Failover |
|---|---|---|---|---|---|
| Storage | LRS/ZRS | Synchronous | 0 | Not applicable | No |
| Storage | GRS/GZRS | Asynchronous | <15 min | No (only post-failover) | Manual / Auto (MS) |
| Storage | RA-GRS / RA-GZRS | Asynchronous | <15 min | Yes (.secondary endpoint) | Manual / Auto (MS) |
| SQL Database | Internal HA (GP) | Asynchronous (remote storage) | ~0 sec | No | Automatic ~25 sec |
| SQL Database | Internal HA (BC) | Synchronous (Always On) | 0 | Yes (1 free read replica) | Automatic <8 sec |
| SQL Database | Active Geo-Replication | Asynchronous | ~5 sec | Yes (all secondaries) | Manual |
| SQL DB / MI | Auto-Failover Groups | Asynchronous | ~5 sec | Yes (RO listener) | Automatic or manual |
| Cosmos DB | Multi-region (single-write) | Asynchronous | Depends on consistency | Yes (all replicas) | Automatic or manual |
| Cosmos DB | Multi-region writes | Asynchronous | ~0 (local) | Yes | Not needed |
Design patterns for high availability
Active-Passive
One region active, another on standby. Manual or automatic failover. Lower cost (the replica does not serve traffic). Higher RTO.
E.g.: SQL DB with Active Geo-Replication (no automatic redirect).
Active-Active
Both regions serve traffic. Lower global latency. Higher cost. Requires managing data consistency.
E.g.: Cosmos DB multi-write, SQL with Auto-Failover Groups + traffic split by geography.
Did you get this topic?
Test what you just learned
An e-commerce application needs the SQL database to fail over automatically in the event of a primary region failure, without the app needing to change its connection string. Which configuration should you implement?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.