Azure Storage Accounts for AZ-104: Redundancy, Encryption and AzCopy

Introduction

Azure storage account management for AZ-104 requires matching account types, redundancy and encryption to workload requirements. This lesson continues the skills area Implement and manage storage (15–20% of the exam). The study guide objective is configure and manage storage accounts: create and configure storage accounts, configure Azure Storage redundancy, configure object replication, configure storage account encryption, and manage data by using Azure Storage Explorer and AzCopy.

The storage account is the top-level container for Azure Blob, Azure Files, Queue and Table data. Every choice you make when creating it (performance tier, redundancy, region, access tier default, networking) affects cost, durability and available features, and some choices are hard or impossible to change later. Understanding those trade-offs is the heart of this objective.

After this lesson you will be able to choose the right account type and redundancy for a scenario, change redundancy safely, replicate blobs between accounts, protect data with the right encryption keys, and move data with Storage Explorer and AzCopy.

Learning objectives

• Select a storage account type, performance level and default access tier for a workload.
• Compare LRS, ZRS, GRS, RA-GRS, GZRS and RA-GZRS and map them to failure scenarios.
• Change a redundancy configuration and understand the conversion rules and customer-managed failover.
• Configure object replication between storage accounts and list its prerequisites.
• Explain Azure Storage encryption, customer-managed keys, encryption scopes and infrastructure encryption.
• Copy and synchronize data with AzCopy and manage data with Azure Storage Explorer.

Creating a storage account

A storage account has a globally unique name of 3–24 characters, lowercase letters and digits only. The name becomes part of the endpoint, for example https://stcontosoprod01.blob.core.windows.net.

Account types and performance

Key points:

• Premium block-blob and file-share accounts support LRS or ZRS in supported regions and do not support geo-redundancy. Premium page-blob redundancy must be checked separately: the detailed redundancy and account-creation tables list LRS. Do not infer support from another premium account type.
• General-purpose v1 (GPv1) is retired in October 2026. Microsoft disabled new GPv1 creation in September 2026 and documents automatic migration of remaining accounts to GPv2, with possible pricing changes. Use GPv2 or an appropriate premium type for new designs; inspect any remaining legacy account and its migration status instead of planning a new GPv1 deployment.
• The default access tier for GPv2 can be Hot, Cool or Cold and applies to block blobs without an explicitly assigned tier. Archive is set per blob and cannot be the account default.
• Region matters for latency, data residency and which redundancy options exist. Zone-redundant options require a region with availability zones.
• Account-wide infrastructure encryption must be selected at creation. Hierarchical namespace (Azure Data Lake Storage) can also be enabled through a supported, irreversible upgrade of an existing account after compatibility validation and preparation; it is not restricted to account creation.

az storage account create --name stcontosoprod01 --resource-group rg-data \
  --location westeurope --sku Standard_ZRS --kind StorageV2 \
  --access-tier Hot --min-tls-version TLS1_2 --https-only true \
  --allow-blob-public-access false

Good defaults to know: require secure transfer (HTTPS), set the minimum TLS version to 1.2 or higher, and turn off anonymous blob access unless the content is meant to be public.

These creation options complement the network and authorization controls covered in Azure Storage firewalls, SAS and identity-based access.

Redundancy

Azure Storage always keeps multiple copies of your data. You choose how far apart those copies are.

Remember:

• Replication to the secondary region is asynchronous, so a failover can lose recent writes. The Last Sync Time is a timestamp: writes before it are guaranteed to be on the secondary, while later writes may be missing. An unplanned failover therefore has potential data loss; a supported planned failover synchronizes the available regions before switching.
• The secondary copy is in the paired region and cannot be chosen freely.
• Only the RA variants expose a readable secondary endpoint (<account>-secondary.blob.core.windows.net). For plain GRS or GZRS the secondary is not readable until failover.
• Pricing depends on region, service, capacity and operations; do not assume a universal price ordering among ZRS and geo options. Compare current costs and choose the least expensive supported configuration meeting the requirement. If a scenario says "survive loss of a datacenter" it needs ZRS, not GRS. If it says "survive loss of the region", it needs a geo option. If it says both, GZRS.

Changing redundancy

For a supported standard account already using ZRS, adding geo-redundancy can be requested in Redundancy or with the CLI:

az storage account update --name stcontosoprod01 --resource-group rg-data --sku Standard_GZRS

How the change behaves:

• Changes within the geo dimension (for example LRS to GRS, or ZRS to GZRS) are done with a simple update; Azure copies the data in the background. A one-time egress charge applies when you add geo-redundancy to an existing account.
• Changes that alter zone redundancy (LRS to ZRS and the reverse) are performed as a conversion, which can be requested from the portal and happens with no downtime in supported regions and configurations. Some configurations block conversion (for example certain NFS or hierarchical namespace combinations), and conversion completion has no guaranteed SLA. After a zone-redundancy conversion, wait at least 24 hours before another redundancy change.
• LRS to GZRS takes two steps: first add zone redundancy (to ZRS), wait at least 24 hours after completion, then add geo-redundancy (to GZRS), following the supported conversion path.
• Premium accounts cannot be converted to a geo option.

Customer-managed account failover

If the primary region is unavailable, an eligible GRS, RA-GRS, GZRS or RA-GZRS account can use a customer-managed unplanned failover. Check account features and service restrictions before invoking it. Azure makes the secondary region the new primary. Consequences:

• Writes made after the Last Sync Time can be lost.
• After an unplanned failover the account becomes LRS in the new primary region until you reconfigure geo-redundancy; and conversions to zonal options are blocked until a failback.
• The DNS endpoints are updated to the new primary, so connection strings do not change.

A planned failover is a separate operation requiring both regions to be available; it is designed to avoid data loss and retains geo-redundancy. Plan the application retries and recovery checks in either case. For the wider recovery design, see Azure backup and disaster recovery.

Worked example: choosing redundancy

Scenario. Northwind stores 20 TB of invoices in West Europe. Requirements: (1) the data must survive the loss of a single datacenter without downtime; (2) a regional disaster must not destroy the data; (3) the DR team wants to read invoices from the secondary region during an outage of the primary without waiting for a failover; (4) the budget is limited.

Reasoning.

1. Requirement 1 means zone redundancy: ZRS or better. LRS fails here.
2. Requirement 2 adds geo-redundancy: so GZRS (zones in primary plus a copy in the secondary), not ZRS alone.
3. Requirement 3 needs a readable secondary: RA-GZRS. Plain GZRS exposes the secondary only after a failover.
4. Requirement 4 prevents a more expensive option beyond what is needed; RA-GZRS is the least extensive option in the comparison that satisfies all three; confirm the region's current pricing. RA-GRS fails requirement 1, because its primary copy is LRS in one datacenter.

Answer: RA-GZRS.

Object replication

Object replication asynchronously copies block blobs from a container in a source storage account to a container in a destination account, according to rules.

Prerequisites and rules:

• Blob versioning must be enabled on both accounts. Change feed must be enabled on the source account.
• Source and destination accounts can be in different regions, subscriptions or tenants. (Cross-tenant replication can be blocked with the allowCrossTenantReplication account property.)
• Only block blobs in supported GPv2 or premium block-blob accounts are replicated. Append/page blobs and accounts with hierarchical namespace are not supported. Source blobs encrypted with customer-provided request keys are also unsupported.
• A policy contains one or more rules, each mapping a source container to a destination container with optional filters (prefix) and a choice of replicating existing blobs or only new ones.
• Standard replication is asynchronous without a guaranteed completion time. Priority replication is an optional policy setting with a conditional SLA: for eligible workloads whose accounts are on the same continent, 99.0% of objects replicate within 15 minutes. This is not a guarantee for every object. Check per-blob status and replication metrics.
• Ordinary destination writes are blocked while its replication rule is active, but reads and deletes are permitted. Manage retention and permissions separately.
• Object replication is not a substitute for an independently protected backup. The current overview documents propagation of writes and delete state: a source delete leaves previous versions without a current version, and that state is replicated. Recovery depends on retained versions, retention rules and access controls.
• Blob snapshots are not replicated. Destination tiering is independent and online Hot/Cool/Cold tiers are supported. Moving a participating source or destination blob to Archive causes replication to fail; rehydration alone does not restart it without another data update. Use Archive only with an explicit plan for objects no longer requiring updates.

az storage account blob-service-properties update --account-name stsource01 \
  --resource-group rg-a --enable-versioning true --enable-change-feed true
az storage account blob-service-properties update --account-name stdest01 \
  --resource-group rg-b --enable-versioning true

az storage container create --account-name stsource01 --name invoices --auth-mode login
az storage container create --account-name stdest01 --name invoices-copy --auth-mode login

policyId="$(az storage account or-policy create --account-name stdest01 --resource-group rg-b \
  --source-account stsource01 --destination-account stdest01 \
  --source-container invoices --destination-container invoices-copy \
  --query policyId --output tsv)"

az storage account or-policy show --account-name stdest01 --resource-group rg-b \
  --policy-id "$policyId" |
  az storage account or-policy create --account-name stsource01 --resource-group rg-a --policy "@-"

This Bash example assumes compatible accounts, appropriate container/data and policy management permissions, and network access. The same policy ID must exist on both accounts; configuring only the destination is incomplete. The default rule copies newly created blobs; configure the copy scope explicitly if existing blobs must be included. The object-replication feature guide currently excludes customer-managed failover for participating accounts: do not assume geo-redundancy makes a combined design eligible for every failover operation.

Use object replication to reduce read latency (a copy near users), to compute on the data in another region, to optimize cost by tiering the copy, or to keep a second copy under different governance.

Encryption

Azure Storage Service Encryption (SSE) encrypts all data at rest with 256-bit AES encryption. It is always on, cannot be disabled, and has no performance overhead.

Details for customer-managed keys:

• The storage account authenticates to Key Vault with a managed identity (system-assigned or user-assigned) that holds the Key Vault Crypto Service Encryption User role (or equivalent access policy permissions).
• You can pin a key version or enable automatic key version update by leaving the version empty. Configure Key Vault rotation separately to create new versions; Azure Storage checks for them daily. Wait at least 24 hours after rotation before disabling the older version.
• Disabling the CMK or revoking access prevents the documented operations that require it until access returns; it does not delete stored data or guarantee that every API operation stops. Do not describe this as an instantaneous erase or a way to revoke copies already downloaded by clients.
• Encryption scopes let you apply different keys (Microsoft-managed or customer-managed) at container or blob level within one account, for example to use a separate key for one customer. Create the container with that default scope and prohibit overrides when every uploaded blob must use it; authorization isolation still requires appropriate data permissions.
• Infrastructure encryption adds a second layer of AES-256 encryption with a different algorithm and key. The account-wide setting is immutable after account creation. An existing account can instead have a new encryption scope created with infrastructure encryption enabled; that scope's setting is also immutable and does not retroactively encrypt all existing data twice.
• Encryption in transit is separate: enforce HTTPS and a minimum TLS version.

Worked example: meeting a key-control requirement

Scenario. Litware's compliance team requires that the company control the encryption key used to protect stored data and be able to disable access through that key. Keys must rotate yearly without changing application credentials. A subset of data from one customer must use a different key from the rest.

Solution.

1. Use customer-managed keys in Azure Key Vault with purge protection and soft delete enabled, so the company holds the key.
2. Give the storage account a managed identity with Key Vault Crypto Service Encryption User.
3. Configure annual rotation on the Key Vault key, then configure Storage without a fixed version so daily automatic version checks adopt new versions. Keep the older version enabled for at least 24 hours after rotation.
4. Create an encryption scope with a separate key for the customer's container, and make it the default when creating the container, with scope overrides prohibited. Existing blobs require a planned copy/rewrite into the intended scope.
5. Revocation: disable the active key or remove the identity's access, then verify the affected read/write operations fail. Restore access to recover service. This controls access to encrypted storage; it does not recall downloaded data or replace a documented access-revocation procedure.

Why not customer-provided keys? They apply per request on Blob storage, so every client would have to send the key, and they are not supported across all services; a managed Key Vault key is simpler for account-wide control.

Managing data: Storage Explorer and AzCopy

Azure Storage Explorer

Azure Storage Explorer is a free graphical tool for Windows, macOS and Linux; the Azure portal provides a separate Storage browser experience. You sign in with an Entra account, or connect with a connection string, account name and key, or a SAS URL. You can upload and download, manage containers, shares, queues and tables, edit blob properties and access tiers, generate SAS tokens, manage stored access policies, and attach to the local emulator. Access under Entra ID requires the appropriate data-plane role; a missing role is a common reason the tool shows "no data" or authorization errors.

AzCopy

AzCopy is a command-line tool optimized for fast, scripted transfers.

azcopy login
azcopy copy "./exports/*" "https://stcontosoprod01.blob.core.windows.net/exports/" --recursive
azcopy copy "https://stsource01.blob.core.windows.net/invoices?<SAS>" \
            "https://stdest01.blob.core.windows.net/invoices?<SAS>" --recursive
azcopy sync "./exports" "https://stcontosoprod01.blob.core.windows.net/exports" --delete-destination=false
# Set jobId to the interrupted job identifier shown by AzCopy.
azcopy jobs resume "$jobId"

What to remember:

• Authentication: azcopy login (Entra ID, requires a data role such as Storage Blob Data Contributor) or a SAS token appended to the URL. With a SAS you do not log in.
• copy transfers data once and can conditionally overwrite (--overwrite=ifSourceNewer). sync compares names and last-modified times by default. It deletes destination-only files only when --delete-destination=true or prompt is explicitly chosen; the example preserves them. Keep the workstation clock accurate, or use an appropriate hash comparison.
• Copy between two storage accounts is a server-to-server operation: data does not pass through your machine.
• AzCopy supports resuming interrupted jobs and logs under the user's .azcopy folder.
• It supports Blob, Azure Files and Data Lake Storage; for Azure Files over REST, supported Entra transfers require file data roles such as Storage File Data Privileged Reader/Contributor, not merely the SMB Share roles used for a drive mount. Follow the current AzCopy authorization guide for the protocol and operation.
• Running through a firewall-restricted account requires the client IP or network to be allowed, as explained in the previous access lesson. For server-to-server copies, both source and destination network/authorization requirements must be satisfied. Resumed SAS-authorized jobs may need fresh SAS credentials.

Comparison: which tool for which data movement

Pitfalls and exam tips

• LRS to ZRS is a zone-redundancy conversion, while adding geo is a normal update; some paths take two steps.
• RA means readable secondary; GZRS without RA does not offer that.
• Premium accounts cannot be geo-redundant.
• Object replication needs versioning on both sides and change feed on the source, and only handles block blobs.
• Replication is not a backup: deletes propagate.
• Account-wide infrastructure encryption is chosen at account creation; scope-level infrastructure encryption is chosen when creating the scope.
• Customer-managed keys require soft delete and purge protection on Key Vault and a managed identity for the storage account.
• AzCopy sync can delete destination files if you add --delete-destination.
• Account names are globally unique, lowercase and 3–24 characters.
• Failover can lose data written after the Last Sync Time; the account becomes LRS after an unplanned failover.

Mini case study: Adatum archive project

Adatum is moving a media library to Azure. The library is 80 TB, mostly videos rarely read after 60 days. Requirements:

1. Data must survive a datacenter failure and a regional disaster.
2. Newly uploaded videos in the West Europe account must appear automatically in a North Europe account, where they are kept at lower cost.
3. The security team wants the data encrypted with a key the company can revoke.
4. An editor will upload a 5 GB folder daily from a workstation; the upload must be scriptable and skip files already uploaded.

Solution.

1. Use a general-purpose v2 account with GZRS (zones in the primary region plus a geo copy). RA-GZRS is not needed because no secondary reads are required.
2. Enable versioning on both accounts and change feed on the source, then create an object replication policy to a North Europe container. Set the destination blobs to the Cool or Cold online tier. Configure the matching policy on both accounts. Keep the source HNS disabled and avoid Archive while replication updates are required.
3. Configure customer-managed keys in Key Vault with soft delete and purge protection, accessed by a managed identity.
4. Use azcopy sync from the workstation with a user delegation SAS or azcopy login, which normally compares names and last-modified times to skip unchanged files. Use --delete-destination=false because this requirement does not authorize deleting remote-only files.

Commentary. The trap in requirement 2 is thinking GZRS or GRS replicates to a chosen account; geo-redundancy goes to the paired region and is not directly readable. Object replication gives you a separate, accessible account and control of its online tier. Check failover compatibility for accounts participating in replication before approving the DR runbook; the feature guide lists a customer-managed failover restriction.

To configure shares, blob tiers and data protection in more depth, continue with Azure Files and Blob Storage management.

Key terms

• General-purpose v2: standard account type supporting all services and redundancy options.
• LRS / ZRS / GRS / GZRS: redundancy within one datacenter, across zones, across regions, and zones plus regions.
• RA: read access to the secondary endpoint.
• Last Sync Time: timestamp bounding data loss on a geo failover.
• Object replication: asynchronous blob copy between accounts according to rules.
• Customer-managed key: encryption key held in Key Vault controlled by the customer.
• Encryption scope: key applied to a container or blob within an account.
• AzCopy: command-line transfer tool with copy and sync.

Summary checklist

• I can select account type, performance and default tier for a workload.
• I can map failure scenarios to LRS, ZRS, GRS, GZRS and their RA variants.
• I understand how redundancy changes and failover behave.
• I can list the prerequisites of object replication.
• I can explain Microsoft-managed, customer-managed and customer-provided keys, encryption scopes and infrastructure encryption.
• I can write basic AzCopy copy and sync commands and choose between authentication methods.

Official sources

• Study guide for Exam AZ-104 (opens in a new tab)

• Data redundancy - Azure Storage (opens in a new tab)

• Azure storage disaster recovery planning and failover (opens in a new tab)

• Object replication overview (opens in a new tab)

• Azure Storage encryption for data at rest (opens in a new tab)

• Get started with AzCopy (opens in a new tab)

• GPv1 retirement and migration timeline (opens in a new tab)

• Default access tiers (opens in a new tab)

• Upgrade an existing account to Data Lake Storage (opens in a new tab)

• Change storage redundancy (opens in a new tab)

• Configure both sides of object replication (opens in a new tab)

• Priority replication SLA eligibility (opens in a new tab)

• Customer-managed keys and version updates (opens in a new tab)

• Infrastructure encryption for accounts and scopes (opens in a new tab)

• Encryption scope enforcement (opens in a new tab)

• AzCopy synchronization behavior (opens in a new tab)

• Authorize AzCopy with a user identity (opens in a new tab)