A county emergency archive must replicate Blob data to a secondary Azure region for disaster recovery. Which redundancy concept fits at describe level?
Select an answer to reveal the explanation.
Short Explanation
When the county says “another region,” think geo—GRS (and related geo options) copy data to a paired secondary region. LRS stays local; Hot is just an access tier, not a plane ticket to another geography. File Sync is a hybrid file story, not the blob geo-redundancy label.
Full Explanation
Geo-redundant storage (GRS) to a secondary region fits a county emergency archive that must replicate Blob data beyond the primary region for disaster recovery. GRS asynchronously replicates to a paired secondary region so regional outage scenarios have a copy outside the home geography. At AZ-900 depth, a secondary-region replication requirement maps to a geo-redundant storage option such as GRS (with related variants like RA-GRS adding secondary read access).
Locally redundant storage only inside one rack cannot satisfy cross-region DR—LRS stays in the primary location. Hot tier because hot automatically means multi-region confuses access frequency pricing with redundancy; Hot does not create geo copies by itself. Azure Files Sync as the only geo-replication method for blobs misstates both products: File Sync targets hybrid file-server sync with Azure Files, not Blob geo-redundancy SKUs.
Exam caveat: geo replication is typically asynchronous, so a small amount of very recent data might not yet be in the secondary region at the moment of a failure. Operational check: configure or review GRS (or an approved geo option) on the emergency-archive storage account, document the secondary region in the county DR runbook, and verify staff know whether secondary read access (RA-GRS) is required for restore drills.