A city disaster-recovery policy requires Blob Storage copies in another Azure region, not only within one datacenter. Which choice correctly matches that policy?
Select an answer to reveal the explanation.
Short Explanation
Policy says another region—LRS alone cannot keep that promise. Pick a geo-redundant option so copies actually leave the primary region. Tweaking Hot versus Cool does not create regional DR copies.
Full Explanation
When a city disaster-recovery policy requires Blob Storage copies in another Azure region—not only within one datacenter—the correct action is to select a geo-redundant option such as GRS instead of LRS-only. Cross-region copies are a redundancy-SKU decision: geo options replicate to a secondary region, while LRS keeps durability local. Matching the written policy to a geo-redundant configuration is the fundamentals outcome.
Keeping LRS-only because local copies satisfy every cross-region policy contradicts the requirement; local copies do not leave the primary region. Changing only the blob access tier from Hot to Cool for regional failover fails because tiers control access cost and retrieval characteristics, not whether data is geo-replicated. Disabling all redundancy so Azure Migrate can invent regional copies later invents a false dependency—Migrate assesses and migrates workloads; it does not replace storage geo-redundancy configuration.
Exam caveat: choosing GRS or GZRS is necessary but not sufficient for a full DR plan—teams still need restore procedures, identity access in failover scenarios, and clarity on RPO/RTO expectations. Operational check: update the storage account from LRS to an approved geo-redundant option, record the secondary region in the city’s DR policy appendix, and run a tabletop that verifies how Blob data would be accessed after a regional event.