Examkin

Question

Difficulty: Very hardConfigure Blob Storage Lifecycle and Replication

An organization has an Azure subscription containing a General Purpose v2 (GPv2) storage account named storage1 configured with Geo-Redundant Storage (GRS). The storage account contains two blob containers:

* media-delivery – Stores active, frequently accessed media assets used by a web application.
* compliance-logs – Stores historical logs.

To minimize storage costs, a lifecycle management policy is applied to storage1 with a rule that transitions all blobs in compliance-logs to the Archive tier 30 days after creation.

A major regional outage occurs in the primary region of storage1. An administrator attempts to initiate a customer-managed failover of storage1 to the secondary region to restore write capabilities for the web application, but the failover operation is blocked.

Which of the following is the most appropriate action to resolve this issue and ensure the web application can fail over to the secondary region in the event of a future primary region outage?

  1. Create a separate storage account for the historical logs, configure its lifecycle policy to archive the logs, and keep only the active media assets in storage1.Answer
  2. B
    Rehydrate the archived logs to the Cool tier by updating their blob tier directly on the secondary endpoint, and then initiate the failover.
  3. C
    Change the replication configuration of storage1 from GRS to Locally Redundant Storage (LRS), and then retry the failover.
  4. D
    Modify the lifecycle policy rule to delete the archived logs immediately, and wait for the policy to execute on the secondary region.

Answer

Create a separate storage account for the historical logs, configure its lifecycle policy to archive the logs, and keep only the active media assets in storage1.
The correct action is to split the active and archived workloads into separate storage accounts. Azure customer-managed failover is blocked for any storage account that contains archived blobs. Because rehydration is a write operation that cannot be performed when the primary endpoint is offline, the administrator cannot rehydrate the blobs during an outage to bypass the block. Separating the logs to a different storage account ensures the active media storage account contains no archived blobs and can be failed over immediately.

Step-by-Step Solution

1
Identify the blocker preventing the customer-managed failover of the storage account.
The failover is blocked because the storage account contains archived blobs, which is a known limitation of customer-managed failover in Azure.
Azure blocks customer-managed failover for any storage account containing one or more blobs in the Archive tier.
2
Evaluate the viability of rehydrating the blobs or modifying the lifecycle policy during a primary region outage.
Both rehydration and lifecycle policy modifications are write operations that must be processed by the primary endpoint, which is currently offline.
During a primary region outage, the secondary endpoint is read-only (in RA-GRS) and cannot accept write commands, meaning blobs cannot be rehydrated and policies cannot be modified.
3
Formulate a design pattern to prevent this failover blocker in future scenarios.
Split the workloads by creating a separate storage account for the compliance logs (which require archiving) and keeping the active media assets in the primary GRS storage account.
Separating the active and archived workloads ensures that the active storage account does not contain archived blobs, allowing customer-managed failover to succeed instantly during a disaster.

Key Concept

Customer-managed failover limitations with archived blobs and storage account design
Estimated Time:3m 0s
Rate this question

Topics

Configure Blob Storage Lifecycle and Replication

More questions from this topic