Storage Redundancy & Replication
How many copies of the data exist and where they live: LRS, ZRS, GRS, GZRS and their read-access variants.
Readiness
0%
1h 40m baseline
Exam memorization points
- LRS keeps three copies inside a single datacenter in one region.
- ZRS keeps three copies synchronously across three availability zones in one region.
- GRS keeps three LRS copies in the primary region plus three asynchronous copies in the paired region, with an RPO measured in minutes (roughly 15).
- GZRS is ZRS in the primary region plus asynchronous geo-replication; RA-GRS and RA-GZRS add a read-only secondary endpoint with a -secondary suffix.
- Geo-replication is asynchronous, so a regional failover can lose the most recent writes; an unplanned failover is a last resort.
- Object replication copies blobs between accounts and requires versioning and change feed enabled on the source.
Traps & distractors
- Assuming GRS exposes a usable read endpoint. Without the RA- prefix the secondary copies are not readable.
- Expecting to switch directly between any two redundancy options. Some conversions are unsupported and others require a new account or live migration.
- Assuming zone redundancy is available everywhere. ZRS support depends on the region.
- Treating object replication as a backup. It is asynchronous replication and can propagate a deletion unless soft delete protects the target.
- Forgetting that customer-initiated failover changes which region is primary and requires a capability check on the account.
Suggested lab
Compare redundancy endpoints and replicate blobs
See the difference between replicas, endpoints and read access.
- 1Create three accounts: one LRS, one ZRS (if the region supports it) and one RA-GRS.
- 2List the blob/queue/table endpoints for each and identify the -secondary endpoint present only on the RA account.
- 3Write a blob to the RA-GRS account and read it from the secondary endpoint.
- 4Enable versioning and change feed on the source and target accounts, then configure an object replication policy.
- 5Upload to the source, wait for replication and verify the copy on the target while confirming that soft delete protects the target.
Microsoft Learn
- Azure Storage redundancydoc
- Search Microsoft Learn: object replication blob storage GRS GZRS failoversearch
Live Microsoft Learn ingestion is a Sprint 2 item; until then links are curated and the search fallback always resolves.
Status
No time invested yet. Baseline assumptions only.
Self-assessed mastery
0%
High priority
Strong exam value. Schedule this week.
- Exam importance80% × 30% = 24.0
Learner-agnostic frequency on the real exam (4/5).
- Blueprint weight78% × 25% = 19.4
This topic's domain carries 17.5% of the exam objectives.
- Dependency leverage0% × 20% = 0.0
Nothing else in the graph depends on this topic.
- Current gap100% × 25% = 25.0
Readiness is 0%, so 100% of the topic is still uncovered.
Exam Priority Score = 30% importance + 25% blueprint + 20% dependency + 25% gap. Importance is exam frequency, blueprint is the domain's official exam weight, dependency is how many later topics this one unlocks, and gap is how far you currently are from ready.
Unlocks next
Leaf topic - nothing depends on it.
Baseline study time
1h 40m
Complexity
3 / 5
Remaining to target
1h 25m
Status weight
0%
Topics: lrs, zrs, grs, gzrs, ra-grs, replication, failover, rpo
Weak neighbours in Storage