Implement and manage storage
Storage Redundancy and Object Replication
CoreMap durability, zonal, regional, read-access, and object-level replication requirements to the right setting.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
Redundancy determines how the storage platform protects an account from hardware, zone, or regional failure, while object replication solves a different data-placement problem.
Must Know
- LRS keeps copies in one datacenter region location; ZRS synchronously spreads copies across availability zones in the primary region.
- GRS adds asynchronous replication to a secondary region; GZRS combines zonal primary-region protection with secondary-region replication.
- RA-GRS and RA-GZRS expose read access to the secondary endpoint before failover, unlike their non-RA counterparts.
- Object replication asynchronously copies block blobs between supported general-purpose v2 or premium block blob accounts; blob versioning must be enabled on both accounts, and change feed must be enabled on the source.
- Changing redundancy, initiating account failover, and configuring object replication have different prerequisites and effects.
Compare and Distinguish
- LRS vs ZRS: single primary-region datacenter resilience vs synchronous availability-zone resilience.
- GRS vs GZRS: locally redundant primary plus secondary region vs zone-redundant primary plus secondary region.
- GRS/GZRS vs RA variants: protected secondary copy vs readable secondary endpoint before failover.
- Object replication vs redundancy: selected object copies under rules vs platform-managed copies for account durability and disaster recovery.
Scenario examples
- Scenario: Data must survive a datacenter-zone failure without depending on regional failover. Think: Choose ZRS or GZRS according to whether secondary-region protection is also required.
- Scenario: Reporting must read a secondary-region endpoint during normal operation. Think: Choose an RA geo-redundant option, not plain GRS or GZRS.
- Scenario: Only a subset of block blobs must be copied into another account for processing. Think: Configure object replication rules rather than changing account redundancy.
Exam traps
- Geo-redundant storage does not mean applications can always read the secondary endpoint.
- Object replication is not a substitute for platform durability and does not replicate every storage service or object type.
- A secondary-region copy is asynchronous, so regional protection still has an RPO implication.
Key takeaways
- Choose redundancy from the failure boundary and whether normal secondary reads are required.
- Use object replication for rule-based block-blob placement between accounts, not as a synonym for redundancy.
How it works
- Local and zone copies are written synchronously in the primary region, while geo copies reach the paired secondary asynchronously.
- Object replication observes source blob changes and copies matching versions to the destination under the policy.
Objects and administrative surfaces
- Storage account — redundancy configuration, primary and paired secondary relationship, read-access option, and failover state.
- Source and destination accounts plus containers — object replication policy and rules for supported blobs.
When to use it
- Use ZRS when zone failure is the target boundary and cross-region protection is not required.
- Use GZRS or an RA form when both zonal primary protection and geo protection or secondary reads are required.
Security and governance implications
- Confirm data-residency requirements before enabling cross-region copies.
- Restrict who can change redundancy, fail over an account, or edit replication policies.
How to reason about this
- For an unavailable secondary read, check whether an RA option is configured and use the correct secondary endpoint.
- If policy creation fails or no blobs replicate, confirm both accounts support object replication, both have blob versioning enabled, the source has change feed enabled, and the policy targets block blobs before checking rule filters and asynchronous lag.
More detail
- The chosen redundancy setting applies at storage-account scope and feature support varies by account type, region, and service.
- Replication policies bind source and destination containers and depend on supported Blob settings in both accounts.
Ready for the quiz?
- Which options protect the primary copy across availability zones?
- What does the RA prefix add to a geo-redundant option?
- When is object replication the relevant control instead of account redundancy?
Related objectives
- D2.2.S2 — Configure Azure Storage redundancy
- D2.2.S3 — Configure object replication