A question asks for resilient storage, and several answers sound convincing. One mentions availability zones, another a second region, and another backup. Before choosing, identify the failure the design must survive and what the application must still be able to do. That makes the acronyms easier to reason about.
Compare replication geography first
| Option | Primary-region replication | Secondary-region copy |
|---|---|---|
| LRS | Local replication | None |
| ZRS | Synchronous replication across availability zones | None |
| GRS | LRS | Asynchronous geo-replication; LRS in the secondary |
| GZRS | ZRS | Asynchronous geo-replication; LRS in the secondary |
ZRS addresses a zone-level failure within a region; it is not itself a second-region copy. The difference between GRS and GZRS is the primary-region arrangement. The read-access variants, RA-GRS and RA-GZRS, additionally permit reads from the secondary endpoint before a failover. They do not turn that endpoint into a second writable primary.
Separate read access from write recovery
Microsoft's geo-redundant application guidance explains that a secondary read copy is eventually consistent. An application can therefore see older data there. Selecting a read-access option is only part of the design: the application must know when to use the secondary and how to behave when updates cannot be accepted.
Imagine a document library whose users may keep reading an earlier approved document during an outage, but must not upload a replacement until writes recover. That requirement gives you two separate tasks: provide an appropriate secondary read path and define a clearly communicated read-only mode. Simply saying 'geo-redundant' does not finish the application design.
Read the recovery requirement carefully
Geo-replication is asynchronous, so an unplanned failover can lose writes that have not reached the secondary. Microsoft's disaster-recovery guidance describes Last Sync Time as evidence for evaluating that exposure. Data written after it might already have replicated, but you cannot assume that all such writes are safely present.
Do not treat planned and unplanned failover as interchangeable. Their prerequisites, data-loss expectations and resulting redundancy configurations differ. For a study answer, state which kind of outage or exercise the scenario describes before discussing failover. For a real system, follow an approved recovery plan rather than performing a failover to test a guess.
Do not confuse redundancy with deletion recovery
Keeping replicas available is not the same as retaining an earlier version of an object. Microsoft documents separate protections for account deletion, container deletion and blob changes. Blob soft delete, versioning and backup address recovery needs that a redundancy label alone does not establish.
An Azure Resource Manager lock can protect the storage account from a management-plane deletion, but it does not by itself stop a data-plane operation from deleting a blob. Match the protection to the object and operation at risk. See Azure RBAC, Policy and resource locks for the broader distinction between these controls.
Work through three requirement changes
- A workload must tolerate a zone outage, and its data must stay within one region. Start by assessing ZRS support and the application's transient-failure handling. A second region is not automatically the right answer.
- A workload additionally needs a copy outside the primary region. Now compare geo-redundant options and write down the permitted recovery data loss, rather than assuming all acknowledged writes reach both regions immediately.
- A workload must recover an accidentally deleted report. Add a suitable data-protection and restore strategy; increasing the geographical distance between replicas does not define the required retention history.
These are requirement-analysis examples, not complete architecture recommendations. Each deliberately leaves room for account compatibility, cost and application constraints. A strong answer identifies the missing information instead of selecting the option with the most letters in its name.
Use a short decision record for revision
- Failure scope: what specifically is unavailable or lost?
- Required behavior: reads, writes, or restoration of an earlier object?
- Data tolerance: how much staleness or loss is acceptable?
- Compatibility: which service, account features and regions must be supported?
- Evidence: which official source supports the choice, and what would make you change it?
Connect those notes to the AZ-104 storage practice domain and the Azure Administrator study guide. For architecture-focused study, reuse the AZ-305 decision journal. The useful outcome is a defensible design explanation, not a memorized ranking of redundancy options.