Lab: Blob replication and customer-managed encryption

Outcome

Configure a two-account object-replication policy and inspect replication status. Then use a managed identity and protected Key Vault key to enable storage customer-managed keys (CMK), diagnose a deliberately missing permission, and return the disposable account to Microsoft-managed keys before cleanup.

Before you begin

Use two disposable general-purpose v2 or premium block-blob accounts without hierarchical namespace. Object replication needs versioning on both accounts and blob change feed on the source. CMK needs a Key Vault or managed HSM with soft delete and purge protection, a managed identity on the storage account, and permission for that identity to get, wrap, and unwrap the key. Do not revoke a key from a production storage account.

Do: replicate a block blob

1. Create source and destination accounts and a private container with the same name in each. Enable blob versioning on both accounts and change feed on the source.
2. Create an object-replication rule from the source container to the destination container. Record the policy ID, source/destination account IDs, and any prefix filter. Upload a small block blob to the source.
3. Inspect the blob’s replication status and destination copy. Replication is asynchronous: capture pending state if it has not completed, then recheck until completion instead of assuming an immediate copy.

Do: enable CMK safely

1. Create a Key Vault with purge protection and an RSA key. Enable a system- or user-assigned managed identity on a separate disposable storage account.
2. Grant that managed identity Key Vault permission to get, wrapKey, and unwrapKey through the vault’s selected authorization model. Configure account encryption to use the key URI and record the assigned identity, vault, key version, and encryption state.
3. Switch the disposable storage account back to Microsoft-managed keys after the exercise. This is the rollback; it does not decrypt stored data because Azure Storage encrypts data at rest throughout the change.

Verify

Capture versioning/change-feed settings, replication policy ID, source blob status, and destination copy. Capture Key Vault soft-delete/purge-protection state, managed-identity principal, effective key permission, CMK key URI, and rollback to Microsoft-managed keys. You should now understand: object replication copies eligible block-blob versions asynchronously between accounts; CMK changes who controls the wrapping key, while Azure Storage continues to encrypt data at rest.

Break and fix

1. Try to create replication before enabling versioning on both accounts or change feed on the source. Record the prerequisite error, enable the missing feature, and create the policy again.
2. On the disposable CMK account, attempt configuration before granting the managed identity access to the key. Diagnose the missing identity/key permission, grant only get, wrapKey, and unwrapKey, and retry. Do not disable or delete a key that protects other resources.
3. Upload a blob outside a replication prefix filter. Diagnose why its replication status is absent or not eligible, then either change the filter deliberately or upload under the matched prefix.

Scenario practice

1. Configure: A regional reporting pipeline needs selected block blobs copied to another account. Specify account prerequisites, policy direction, matching rules, and how you will observe completion.
2. Diagnose: CMK setup reports that the storage identity cannot use the key. Which identity, Key Vault authorization model, key state, permissions, and vault protections do you inspect?
3. Distinguish: Contrast object replication with redundancy, a copied backup, and Azure Files synchronization; contrast Microsoft-managed keys with a customer-managed wrapping key.

Clean up

Delete the replication policy, both containers/accounts, the test Key Vault key and vault, managed identity assignments, and the disposable resource group only after the CMK account has been returned to Microsoft-managed keys and no resource depends on the vault.

Sources and re-audit

• Configure object replication, checked 2026-08-22.
• Customer-managed keys for account encryption, checked 2026-08-22.
• Configure CMK for a new account, checked 2026-08-22.

Re-audit when replication support, identity authorization, Key Vault protection, or CMK configuration changes.

Related

object-replication · storage-encryption · managed-identity · key-vault · All labs