AZ-104 Practice Question 5: Lifecycle Archive Tier Redundancy
Microsoft Azure Administrator Associate (AZ-104) · Test 1 · question 5 of 10
To cut costs, you add a blob lifecycle management policy to a general-purpose v2 storage account that moves block blobs in the audit-logs container to the archive tier 90 days after last modification. The account was created with geo-zone-redundant storage (GZRS).
A week later the blobs are still shown as Cool and none have moved to Archive, although other rules in the same policy (moving blobs from Hot to Cool) are working. What is the most likely cause?
Show answer and explanation
Answer:
The archive tier has a redundancy restriction that the hot, cool, and cold tiers do not: only storage accounts configured for LRS, GRS, or RA-GRS support moving blobs to archive. The zonal variants (ZRS, GZRS, and RA-GZRS) do not. Because this account is GZRS, the archive step of the policy can never take effect, while the Hot-to-Cool rules on the same account run normally. The fix is to place archival data in an account that uses a supported redundancy option; changing an existing account's redundancy is not something to do casually, and it would require rehydrating any already-archived blobs first.
Option A is wrong: setting the tier is a core capability of lifecycle management. The real limitation is the reverse; you cannot *rehydrate* an archived blob to an online tier with a lifecycle policy.
Option B confuses two independent features. Soft delete for blobs coexists with tiering; its only interaction is that a soft-deleted blob is not subject to the early deletion penalty until its retention period expires.
Option D misstates the retention rules. 180 days is the minimum recommended retention *for data already in the archive tier* (below which an early deletion charge applies); the cool tier minimum is 30 days, and neither is a precondition for a policy to archive a blob.
Reference: Access tiers for blob data