Sequence 4 — Encryption at Rest & Object Replication

Prerequisites: Sequences 1–3 (storage account basics, redundancy). · What you'll be able to do: explain how Azure encrypts data at rest and who holds the keys · choose between Microsoft-managed, customer-managed, and customer-provided keys · enable infrastructure (double) encryption and encryption scopes · stand up an object replication policy and recall its prerequisites. · Est. time: ~13 min.

This episode has two halves that AZ-104 loves to test together but which solve different problems. Encryption at rest protects data confidentiality — who can read the bytes on disk. Object replication is a data-distribution feature — copying block blobs between accounts. Do not confuse object replication with the geo-redundancy of Sequence 3: geo-redundancy is built-in account durability, object replication is an explicit, rule-based copy you configure.

1. Storage Service Encryption (SSE): the always-on baseline

Every Azure storage account encrypts data at rest automatically. This is service-side encryption (SSE) — sometimes written "server-side encryption."

Memorize these non-negotiable facts:

• 256-bit AES, specifically AES-256 in Galois/Counter Mode (AES-GCM) for uploaded objects — one of the strongest block ciphers available.
• FIPS 140-2 compliant. (The newer FIPS 140-3 standard is superseding 140-2 across Microsoft cloud services; either way, SSE is FIPS-validated.)
• Always on. Cannot be disabled. There is no toggle to turn it off, for any account type.
• No additional cost.
• No code or app changes required — encryption and decryption are fully transparent. Conceptually it is like BitLocker for the Azure platform.

SSE is comprehensive. It applies regardless of:

Exam trap: SSE protects data at rest. It is not transport security (that's HTTPS/TLS, the "secure transfer required" setting) and not client-side encryption. Don't pick "enable SSE" as an answer to a data-in-transit question.

2. Who holds the key? Three key-management models

SSE always happens. The only real decision is who manages the encryption key. There are three models; you can combine them.

• Microsoft-managed keys are the default for every new account. Microsoft rotates them per compliance requirements. Zero effort, zero control over rotation timing.
• Customer-managed keys (CMK) let you own and audit the key in Key Vault or Managed HSM. Choose CMK when you have specific rotation, auditing, or "bring your own key" compliance mandates.
• Customer-provided keys are an advanced, per-request option for Blob only — the client supplies the key on the API call itself. Rarely used; know that it exists and that it breaks object replication (Section 6).

Terminology note: the modern term is Microsoft-managed keys (older docs may say "service-managed" or reference "Azure AD" — read those as Microsoft Entra ID).

3. Customer-managed keys (CMK) in depth

This is the most exam-heavy topic of the episode. Here is the mental model and the flow.

Key wrapping ("envelope encryption") is the core idea: your data is encrypted by an account encryption key (AEK). With CMK, Azure wraps (encrypts) that AEK with your customer-managed key — the key encryption key (KEK) — which never leaves Key Vault. To read or write, Azure asks Key Vault to unwrap the AEK. Your data stays encrypted the whole time; switching key models only changes how the root key is protected, with no downtime and immediate effect.

3.1 Key Vault requirements (memorize)

The key vault or Managed HSM holding the key must have:

• Soft delete enabled
• Purge protection enabled

Both are mandatory so a deleted/purged key can't permanently orphan your data. Supported key types: RSA and RSA-HSM, sizes 2048, 3072, or 4096 bits.

3.2 Managed identity & permissions

Azure Storage authenticates to Key Vault using a managed identity (no secrets in code):

• At account creation → you must use a user-assigned managed identity.
• On an existing account → you may use a user-assigned or system-assigned managed identity.

The identity needs at minimum these three key permissions:

The storage account and the key vault can live in different regions, subscriptions, and even different Microsoft Entra tenants (cross-tenant CMK).

3.3 Key rotation: automatic vs. manual

Best practice: rotate the protecting key at least every two years. Azure Storage never rotates the key for you — you create a new key version in Key Vault (or use a Key Vault auto-rotation policy). How the account picks up the new version depends on how you configured it:

Exam trap: "omit the version → automatic." Specifying a pinned version means you must update the account each rotation.

3.4 Revoking access (the kill switch)

To revoke access, disable (or delete) the key in Key Vault. Afterward, read/write data operations and metadata operations fail with HTTP 403 (Forbidden) for all users. Re-enable/restore the key to resume. This is the fast way to render a compromised account's data unreadable without touching the data itself.

4. Infrastructure encryption (double encryption)

For workloads needing the highest assurance, you can opt into infrastructure encryption — data is encrypted twice:

• Once at the service level (Microsoft- or customer-managed key), and
• Once at the infrastructure level — always Microsoft-managed, always a separate key, different algorithm.

This protects against the unlikely event that one algorithm or key is compromised; the second layer still holds.

Critical constraint: infrastructure encryption is opt-in only at account creation. You cannot enable it on an existing account — plan it up front.

5. Encryption scopes (blobs)

By default the encryption key is scoped to the whole account. Encryption scopes let you apply a different key at the container or individual blob level — useful for multi-tenant storage where data for different customers shares one account but must sit behind separate cryptographic boundaries.

• A scope can use a Microsoft-managed key or a customer-managed key.
• You assign a default scope to a container, or specify a scope when writing a blob.

# Create a customer-managed-key encryption scope on a storage account
az storage account encryption-scope create \
  --name tenantAscope \
  --account-name mystorageacct \
  --resource-group rg-storage \
  --key-source Microsoft.KeyVault \
  --key-uri "https://mykv.vault.azure.net/keys/tenantA-key"

6. Object replication for block blobs

A completely different feature. Object replication asynchronously copies block blobs from a source storage account to a destination account. Use it to reduce read latency (serve data closer to consumers), distribute results of compute, run multi-region compute, and optimize cost (replicate, then archive at destination via lifecycle policies — see Sequence 12).

Not geo-redundancy. Geo-redundancy (Sequence 3) is automatic, account-wide durability you don't configure blob-by-blob. Object replication is an explicit, rule-based, async copy between two accounts you choose — possibly different regions, subscriptions, or tenants.

6.1 Prerequisites (the #1 exam question)

Object replication uses the change feed to detect changes on the source, then replicates them. It works with Microsoft-managed or customer-managed keys, but not with customer-provided keys. It is not supported with hierarchical namespace (Data Lake Gen2) enabled, and customer-managed (account) failover is not supported on either account in a policy.

Mnemonic: "Change feed on the Source, Versioning on Both."

6.2 Policies and rules

• A replication policy names the source and destination accounts. You create it on the destination (policy ID = default, Azure assigns the real ID), then associate it with the source using that same policy ID. The IDs must match on both ends.
• A policy contains one or more rules; each rule maps one source container → one destination container. Up to 1,000 rules per policy; each container can appear in only one rule.
• A source account replicates to at most 2 destination accounts; an account is a destination for at most 2 policies.

Rule filters control which blobs copy:

• Prefix match — only blobs whose name starts with a prefix (e.g. b).
• minCreationTime — copy only blobs created on/after a date ("copy-over from a date"). By default, only new blobs after rule creation are copied; you can opt to include existing blobs, or set minCreationTime to 1601-01-01T00:00:00Z to copy all blobs.

{
  "properties": {
    "policyId": "default",
    "sourceAccount": "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<source>",
    "destinationAccount": "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<dest>",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "logs",
        "destinationContainer": "logs-copy",
        "filters": {
          "prefixMatch": [ "b" ],
          "minCreationTime": "2026-01-01T00:00:00Z"
        }
      }
    ]
  }
}

6.3 Behavior you must know

• The destination container is read-only for writes: any write attempt fails with HTTP 409 (Conflict). To write there, disable the rule or delete the policy first. Reads and deletes on the destination are allowed.
• Versions, metadata, and properties are replicated; snapshots are not. The version ID is not copied — the destination assigns a new version ID.
• Replication works across Hot/Cool/Cold, but fails if either side is in Archive. Rehydrating an archived blob does not by itself trigger replication — only a subsequent update does.
• (Preview) index-tag replication can be enabled per rule.
• Cross-tenant replication is disabled by default for accounts created on/after 15 December 2023 (AllowCrossTenantReplication = false); use full resource IDs in the policy file. Priority replication offers an SLA (~99% of objects within 15 min, same-continent) for supported workloads.

Billing: configuring object replication (and enabling change feed/versioning) is free, but you pay for read/write transactions, extra version storage, and network egress of the replicated data. Test on a small account first.

Key takeaways

• SSE is mandatory: AES-256 GCM, FIPS-validated, always on, can't disable, free, transparent — covers all services, tiers (incl. Archive), redundancy, and metadata.
• SSE ≠ TLS. Encryption at rest, not in transit.
• Three key models: Microsoft-managed (default) · customer-managed (Key Vault / Managed HSM, you rotate) · customer-provided (Blob, per request).
• CMK requires: Key Vault with soft delete + purge protection, a managed identity with get / wrapKey / unwrapKey. New account → user-assigned identity.
• Rotation: omit the version → automatic (daily check, wait 24 h before disabling old). Disable the key = revoke (403).
• Infrastructure encryption = double encryption, opt-in at creation only.
• Object replication mnemonic: Change feed on Source, Versioning on Both, block blobs only, GPv2/premium block blob.
• Policy created on the destination, linked to source by matching policy ID; destination is write-locked (409).

Exercises

1. (Recall) What cipher and mode does Azure Storage SSE use for uploaded objects, and can you turn SSE off to save cost?
2. (Recall) Which two settings must be enabled on the Azure Key Vault holding a customer-managed key?
3. (Applied) You want SSE to use a key you can rotate automatically without updating the storage account each time. How do you configure the key version, and how often does Azure check for a new one?
4. (Applied) Your security team asks you to immediately make a CMK-encrypted account's data unreadable after a suspected breach, without deleting any data. What single action achieves this, and what error will clients then see?
5. (Scenario) A teammate enabled object replication but blobs aren't appearing at the destination. List the prerequisites you'd verify on the source and on the destination, and name two account-level conditions that silently block replication.
6. (Scenario) Auditors require double encryption with two different keys/algorithms on an existing production account. Can you meet this in place? What do you tell them?

Coming up next

Sequence 5 — Managing Data: Storage Explorer & AzCopy — the hands-on tools for moving, copying, and migrating data between accounts (including the migration you'd need to adopt infrastructure encryption).