Troubleshooting Lab: Configure object replication
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team configured an object replication policy between two storage accounts in different regions. The source account is storageaccorigin (West US 2) and the destination account is storageaccdest (East US). Both accounts are StorageV2 type.
After 48 hours of configuration, no objects were replicated. The responsible engineer checks the Azure portal and confirms that the replication policy appears with Enabled status in both accounts.
During the investigation, he collects the following information:
# Checking versioning on source account
az storage account blob-service-properties show \
--account-name storageaccorigin \
--query "isVersioningEnabled"
# Output:
true
# Checking versioning on destination account
az storage account blob-service-properties show \
--account-name storageaccdest \
--query "isVersioningEnabled"
# Output:
false
# Checking change feed on source account
az storage account blob-service-properties show \
--account-name storageaccorigin \
--query "changeFeed.enabled"
# Output:
true
Additionally, the engineer observes that the destination account has a lifecycle policy configured to move blobs to Cool tier after 7 days, and that the destination container was created manually before the replication policy was configured.
What is the root cause of the missing replication?
- A) The change feed is not enabled on the destination account, which prevents received changes from being logged and confirmed
- B) Blob versioning is disabled on the destination account, breaking a mandatory prerequisite for replication to work
- C) The lifecycle policy configured on the destination is in conflict with the replication policy, blocking the writing of new objects
- D) The destination container was created manually before the policy, and replication requires the container to be automatically provisioned by the service
Scenario 2 — Action Decision
The engineering team identified that the replication policy between storage-prod-origin and storage-dr-dest is working correctly for most objects, but objects with the prefix logs/raw/ are not being replicated. The investigation confirmed that the configured replication rule contains only the prefix filter logs/processed/, and the prefix logs/raw/ was never included.
The environment has the following restrictions:
- The source account is in active production, receiving continuous writes
- The existing replication policy has 8 rules already configured and validated
- The security team requires any changes to replication policies to be logged with an approved change ticket, which takes 2 hours to be released
- The engineer has Contributor permission on the subscription
What is the correct action to take at this time?
- A) Delete the existing replication policy and recreate from scratch including the new prefix, taking advantage of reviewing all rules at the same time
- B) Wait for the change ticket approval and, after release, add a new rule with the prefix
logs/raw/to the existing policy - C) Immediately add the new rule to the existing policy without waiting for the ticket, as the change is additive and does not affect the already configured rules
- D) Create a second separate replication policy containing only the rule for the prefix
logs/raw/, avoiding changing the existing policy
Scenario 3 — Root Cause
A solutions architect reports that objects are being replicated correctly between two storage accounts, but when trying to read the replicated objects at the destination, the application receives the following error:
BlobAccessTierNotSupported: The specified access tier is not supported
for this blob type or account type.
The architect provides the following information about the environment:
| Property | Source Account | Destination Account |
|---|---|---|
| Account type | Block Blob Storage (Premium) | StorageV2 (Standard) |
| Default access tier | N/A (Premium doesn't have tier) | Hot |
| Versioning | Enabled | Enabled |
| Change feed | Enabled | N/A |
| Active replication | Yes | Yes |
The application consuming the destination data is configured to use Azure Storage SDK version 12.x and makes SetBlobAccessTier calls immediately after detecting a new replicated blob, trying to move it to Archive tier.
Additionally, the architect mentions that the destination container has an immutable access policy configured in Audit mode, and that the destination account has soft delete enabled with 14-day retention.
What is the root cause of the observed error?
- A) The StorageV2 destination account is not compatible with object replication from Premium accounts, and blobs arrive in a corrupted state
- B) The immutable access policy in Audit mode is blocking the
SetBlobAccessTieroperation on newly replicated blobs - C) Blobs replicated from a Premium Block Blob account arrive at the destination without a defined access tier, and the
SetBlobAccessTieroperation to Archive fails because blobs without explicit tier at the destination cannot be moved directly to Archive via this call - D) Soft delete enabled on the destination account conflicts with tier changes on replicated blobs, generating the reported error
Scenario 4 — Collateral Impact
During a security audit, the team discovers that the change feed on the source account storage-compliance-src was storing the complete history of operations indefinitely, occupying significant space. To fix this, the administrator configures change feed retention to 7 days through the following command:
az storage account blob-service-properties update \
--account-name storage-compliance-src \
--resource-group rg-compliance \
--enable-change-feed true \
--change-feed-retention-days 7
The command executes successfully and retention is applied immediately. The object replication policy linked to this account is active and healthy at the time of the change.
What secondary consequence could this action cause?
- A) The change feed with 7-day retention will be automatically disabled after this period, permanently interrupting object replication
- B) Objects that were written to the source more than 7 days ago and have not yet been replicated due to pipeline delay will no longer be replicated, as the corresponding creation event will have been removed from the feed
- C) 7-day retention on the change feed forces object replication to operate in synchronous mode, increasing write latency on the source account
- D) Blobs already replicated at the destination will be automatically deleted after 7 days to maintain parity with the change feed retention window on the source
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
Explanation:
- The direct clue is in the command output:
isVersioningEnabledreturnsfalseon the destination account. Blob versioning is mandatory on both accounts for object replication to work. The absence of versioning at the destination prevents the service from writing versions of received objects, silently blocking all replication. - The information about the lifecycle policy and manual container creation is irrelevant to this diagnosis. Lifecycle policies do not conflict with writing replicated objects, and manually created containers are fully supported by replication.
- Option A represents a classic diagnostic error: the change feed is only needed at the source, not the destination. Focusing on the destination for this prerequisite is a typical deviation by those who confuse the role of each account in the pipeline.
- The most dangerous distractor is C, as lifecycle policies are a visible and tangible element in the scenario. Acting on it would waste time without solving the real problem.
Answer Key — Scenario 2
Answer: B
Explanation:
- The cause has already been identified in the statement, so the reasoning here is about process restriction, not technical. The security team requires an approved ticket for any changes to replication policies, and this process takes 2 hours. Ignoring this control violates organizational policy, regardless of whether the change is technically safe.
- Option C is technically correct in terms of infrastructure impact (adding a rule doesn't affect others), but ignores the governance restriction explicitly stated in the scenario. This is the central trap: the right action applied in the wrong context.
- Option A would be destructive and unnecessary: deleting 8 validated rules to recreate everything implies high operational risk and there's no technical justification for it.
- Option D seems like an intelligent workaround, but creating a second separate policy for a single additional prefix unnecessarily fragments management and would still need to go through the same approval process.
- The real consequence of choosing C would be a compliance violation that could result in auditing, regardless of the technical success of the operation.
Answer Key — Scenario 3
Answer: C
Explanation:
- When a blob is replicated from a Premium Block Blob Storage account to a Standard StorageV2 account, it arrives at the destination without an explicit access tier assigned, as Premium accounts don't have the access tier concept. The
SetBlobAccessTieroperation trying to move directly to Archive fails because the blob hasn't gone through Hot or Cool tiers at the destination first, and the API doesn't accept this direct transition in this condition. - The information about the immutable access policy in Audit mode is irrelevant: Audit mode only logs violations without blocking them, so it doesn't interfere with tier change operations.
- Soft delete with 14-day retention is also irrelevant to the observed error; it only affects blob deletion behavior.
- Option A is incorrect: Standard StorageV2 is a fully supported destination for replication from Premium accounts.
- The most dangerous distractor is B, as immutability policies are intuitively associated with write restrictions. Investigating this path would lead the engineer to open tickets with the security team unnecessarily.
Answer Key — Scenario 4
Answer: B
Explanation:
- The change feed works as the event log that feeds the replication pipeline. When retention is set to 7 days, events older than 7 days are removed from the feed. If there are objects in the replication queue with creation events older than 7 days (for example, due to pipeline delay or a maintenance window), these events will be removed before being processed by replication, and the corresponding objects will never be replicated.
- Option A is incorrect: configuring retention doesn't disable the feed after the period. The feed remains active, only expiring old events continuously.
- Option C is incorrect: feed retention doesn't change the replication operation mode from asynchronous to synchronous. These are completely independent aspects.
- Option D is incorrect and represents a serious misunderstanding: change feed retention on the source has no effect on objects already written to the destination. Object replication is unidirectional and has no automatic deletion mechanism at the destination based on source policies.
- The most serious practical consequence of ignoring this collateral impact is silent data loss: objects that should have been replicated will simply never reach the destination, without any visible alert or error on the replication policy dashboard.
Troubleshooting Tree: Configure object replication
Legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start with the root node describing the observed symptom and follow the branches answering each question based on what you can directly verify in the environment. The questions are ordered from the most fundamental prerequisite to the most specific, which means answering "no" to any blue node immediately identifies the cause without needing to continue the investigation. When all previous questions are "yes" and replication still hasn't occurred, the orange validation node indicates that the behavior may simply be the expected asynchronous delay of the service.