Storage Accounts — AZ-104 Study Guide

Account kinds, performance tiers, and what you fix at creation

Get the account kind and performance tier right the first time, because you cannot change either afterward: moving tiers means creating a new account and copying the data across. Everything else here (redundancy, object replication, who holds the encryption key) you can still adjust later, but kind and tier are the one decision the account locks in at creation, so they are where the exam concentrates.

A storage account^[1] is the Azure resource that holds all of your Azure Storage data (blob containers, Azure Files shares, queues, and tables) under one globally-unique namespace served over HTTPS. Because the account is the management boundary, the choices below (kind, performance, redundancy, encryption) apply to every service inside it; isolate data with conflicting requirements into separate accounts.

Account kinds

Four account kinds are recommended for new work, and the kind decides which services the account can host. The figure groups them by performance tier: the one Standard kind hosts all four services, while each Premium kind is single-purpose.

Standard general-purpose v2 (StorageV2): supports Blob, Azure Files, Queue, and Table storage^[1] together. This is Microsoft's recommended default for most scenarios.
Premium block blobs (BlockBlobStorage): block and append blobs only, for high transaction rates or low-latency small objects.
Premium file shares (FileStorage): Azure Files only, supporting both SMB and NFS shares.
Premium page blobs (StorageV2/page-blob): page blobs only.

Performance tier

The Standard tier is backed by hard-disk drives and is the cost-effective choice for general use. The Premium tier is backed by solid-state drives^[1] for low, consistent latency and high throughput. The decisive point for the exam: you choose the kind and tier at creation and cannot change a storage account to a different type afterward: to move tiers you create a new account and copy the data with a tool such as AzCopy. The only in-place change Azure supports is upgrading a legacy general-purpose v1 or BlobStorage account to general-purpose v2^[1], which is one-way.

Naming and endpoints

The account name must be 3–24 characters, lowercase letters and numbers only, and globally unique across Azure^[1]: it forms the subdomain of every endpoint. Each service gets its own standard endpoint, e.g. https://<account>.blob.core.windows.net for Blob Storage and https://<account>.file.core.windows.net for Azure Files.

az storage account create \
  --name mystorageacct01 \
  --resource-group rg-storage \
  --location westeurope \
  --kind StorageV2 \
  --sku Standard_GRS

Account kinds by tier: one Standard kind hosts all four services; each Premium kind is single-purpose.

Redundancy: LRS, ZRS, GRS, GZRS and the read-access variants

The redundancy setting is shared by every service in the account, so all resources in one account share one durability profile, and the option you pick is what matches a durability and data-residency requirement. Building on the account model above, redundancy is the next decision that profile turns on.

The unifying model is two independent questions: (1) how do copies spread within the primary region, and (2) is there also a copy in a second, distant region? Answering question 1 gives a local option; layering question 2 on top gives a geo option.

Question 1: within the primary region

Locally redundant storage (LRS) replicates your data three times within a single physical datacenter^[2] in the primary region. It is the lowest-cost option and gives at least eleven 9s (99.999999999%) durability over a year. It survives drive, server, and rack failures, but if the datacenter itself is lost, all replicas are lost.
Zone-redundant storage (ZRS) writes your data synchronously across three availability zones^[2] in the primary region, each a separate datacenter with independent power, cooling, and networking. It gives at least twelve 9s (99.9999999999%) durability, and reads and writes keep working even if a whole zone goes down.

Question 2: adding a second region

Geo-redundant options copy your data asynchronously to a paired secondary region hundreds of miles away^[2]. The secondary region is fixed by the primary you chose and can't be changed. The only difference between the two geo options is how copies spread in the primary region. In the secondary region both always use LRS:

Geo-redundant storage (GRS) = LRS in the primary region + async copy to the secondary. Durability is at least sixteen 9s (99.99999999999999%).
Geo-zone-redundant storage (GZRS) = ZRS in the primary region + async copy to the secondary. Same sixteen 9s durability, plus zone resilience in the primary.

Because the geo copy is asynchronous, a disaster that destroys the primary region can lose the most recent writes. The gap between the last primary write and the last write that reached the secondary is the recovery point objective (RPO), which is non-zero. The secondary copy is not readable or writable until you trigger a customer-managed account failover^[2], after which the secondary becomes the new primary.

Read access to the secondary (RA-)

If an application must read the secondary copy before any failover, enable the read-access variants: RA-GRS or RA-GZRS. These expose a read-only secondary endpoint formed by appending -secondary to the account name (e.g. myaccount-secondary.blob.core.windows.net), using the same access keys. Two constraints are heavily tested: Azure Files does not support RA-GRS or RA-GZRS, and the archive blob tier is supported on LRS, GRS, and RA-GRS but not on any ZRS-based option (ZRS, GZRS, RA-GZRS).

How each redundancy option is composed: a within-region base (LRS or ZRS) optionally plus an asynchronous LRS copy in the paired secondary region (GRS, GZRS).

Object replication for block blobs

Object replication is different from the account-wide redundancy above: redundancy keeps hidden copies for durability, whereas object replication^[3] asynchronously copies block blobs from one account (the source) to another account (the destination) that you can read and use directly, to cut read latency for a distant region, distribute compute, or stage results. It runs on a general-purpose v2 or premium block blob account, and setting it up turns on a handful of prerequisites.

Prerequisites

Three settings must be in place before replication will work:

Blob versioning must be enabled on both the source and destination accounts.
Change feed must be enabled on the source account (Azure reads it to find new writes to replicate).
Both accounts must be general-purpose v2 or premium block blob^[3]; object replication supports block blobs only (not append or page blobs) and is not supported on accounts with a hierarchical namespace.

Policies and rules

You create a replication policy on the destination account; Azure assigns it a policy ID that you then apply to the source account so the two ends match. The source and destination accounts can be in the same or different regions, subscriptions, or even Microsoft Entra tenants^[3] (cross-tenant replication is disabled by default for accounts created on or after December 15, 2023). A policy holds one or more rules, each mapping one source container to one destination container, with optional prefix filters. By default a rule copies only new blobs written after the rule is created; you can opt in to also copy pre-existing blobs, or copy everything created after a chosen time.

Replication is one-directional: the destination container is read-only while the policy is active, and write attempts there fail with HTTP 409 (Conflict). To write to it you must first remove the rule or policy.

Object replication asynchronously copies block blobs from a source account (change feed + versioning on) to a read-only destination account (versioning on).

Encryption: Microsoft-managed, customer-managed, and infrastructure

Encryption at rest is not optional: all data in every storage account is automatically encrypted with 256-bit AES service-side encryption^[4], it is FIPS 140-2 compliant, it covers blobs, files, queues, and tables (including metadata and all access tiers), and it cannot be disabled. Once the account is created, the only decisions are who controls the encryption key and whether to double-encrypt. The figure shows the two encryption layers and how the key-management choice sits inside the always-on service layer.

Microsoft-managed vs customer-managed keys

By default a new account uses a Microsoft-managed key (MMK): Microsoft stores and rotates it, no configuration needed. Choose a customer-managed key (CMK) when you must control rotation, auditing, or revocation yourself. A CMK must be stored in Azure Key Vault or Azure Key Vault Managed HSM^[5], and the key vault must have soft delete and purge protection enabled. The storage account reaches the key through a managed identity (system-assigned or user-assigned) that holds get, wrapKey, and unwrapKey permissions on the key. The CMK does not encrypt your data directly: it wraps the account's root encryption key, so disabling the key in the vault revokes access (reads/writes then fail with 403) without re-encrypting anything. You can switch between MMK and CMK at any time, and applying a CMK to an existing account takes effect immediately.

Infrastructure (double) encryption

For a second, independent layer, enable infrastructure encryption: data is then encrypted twice, once at the service level and once at the infrastructure level^[4], each with a different 256-bit AES key and algorithm, so a single compromised key or algorithm still leaves the data protected. The infrastructure layer always uses a separate Microsoft-managed key even when the service layer uses your CMK. The catch the exam loves: infrastructure encryption can only be turned on when the account is created: it cannot be added to an existing account.

Encryption scopes

By default the encryption key is scoped to the whole account, but encryption scopes let you apply a different key (MMK or CMK) at the container or individual-blob level, useful for keeping different tenants' blobs under separate keys inside one account.

Two encryption layers: an always-on service layer (key choice: MMK or CMK in Key Vault) and an optional infrastructure layer set only at creation.

Managing data with Storage Explorer and AzCopy

Two first-party tools cover almost every transfer task for a created, configured account, and they sit at opposite ends of the GUI-versus-CLI spectrum, each authenticating its own way. The decision tree below routes a scenario to the right tool, then to the right AzCopy verb.

Azure Storage Explorer

Azure Storage Explorer is a free, cross-platform desktop GUI for browsing and managing blobs, files, queues, and tables: uploading, downloading, copying, and editing objects by point-and-click. It is the right choice for ad hoc, interactive, exploratory work, and it uses AzCopy under the hood for its bulk transfers, so it inherits AzCopy's throughput.

AzCopy

AzCopy is a command-line utility^[6] that copies data to, from, or between storage accounts, and it is the tool for scripted, repeatable, or high-throughput bulk transfers. AzCopy v10 runs on Windows, Linux, and macOS. The two commands to know:

azcopy copy copies source data to a destination: local-to-Azure, Azure-to-local, or account-to-account (server-to-server).
azcopy sync makes the destination match the source (one-directional synchronization), so re-running it transfers only what changed.

AzCopy authenticates two ways: Microsoft Entra ID (run azcopy login once, so you don't repeat credentials), or a shared access signature (SAS) token appended to the resource URL on each command.

# Authenticate once with Entra ID, then copy a local folder to a container
azcopy login
azcopy copy "C:\data\*" "https://myaccount.blob.core.windows.net/mycontainer" --recursive=true

A SAS-token alternative appends the token to the URL instead of logging in: azcopy copy "C:\data\*" "https://myaccount.blob.core.windows.net/mycontainer?<SAS-token>" --recursive=true.

Exam-pattern recognition

"Move terabytes between two storage accounts efficiently / in a script" → AzCopy (azcopy copy server-to-server), not Storage Explorer's GUI.
"Keep a destination container in sync with a source folder" → azcopy sync.
"A non-technical admin needs to occasionally upload a few files" → Azure Storage Explorer.
"You need read access to a GRS account's secondary copy during a primary outage" → the account must be RA-GRS (plain GRS isn't readable until failover), and remember Azure Files can't do RA-.

Choosing a transfer tool: interactive work goes to Storage Explorer; scripted or bulk work goes to AzCopy, then sync vs copy.

Azure Storage redundancy options at a glance

Dimension	LRS	ZRS	GRS / RA-GRS	GZRS / RA-GZRS
Copies in primary region	3 copies, single datacenter	3 copies across 3 availability zones	3 copies, single datacenter (LRS)	3 copies across 3 availability zones (ZRS)
Copy in a second region	No	No	Yes, async to paired region	Yes, async to paired region
Durability over a year (at least)	11 nines	12 nines	16 nines	16 nines
Survives loss of a whole datacenter / zone	No	Yes	Yes	Yes
Survives a region-wide disaster	No	No	Yes (after failover)	Yes (after failover)
Read the secondary copy before failover	N/A	N/A	Only with RA-GRS	Only with RA-GZRS

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Standard general-purpose v2 is the default account kind, and it hosts all four services

A Standard general-purpose v2 (StorageV2) account supports Blob, Azure Files, Queue, and Table storage together, and it is Microsoft's recommended kind for almost all new work. The premium kinds are single-purpose: premium block blobs (block/append blobs), premium file shares (Azure Files), and premium page blobs. Reach for a premium kind only when one service needs SSD-backed low latency or high transaction rates; otherwise StorageV2 keeps everything in one account.

Standard is HDD-backed, Premium is SSD-backed

The Standard performance tier runs on hard-disk drives and is the cost-effective choice for general blob, file, queue, and table workloads. The Premium tier runs on solid-state drives for low, consistent latency and high throughput, and it costs more. Pick Premium when a workload is latency-sensitive or has a high transaction rate against small objects; pick Standard for everything else.

Account kind and performance tier are fixed at creation. You can't change them in place

You choose the account kind and performance tier when you create a storage account, and you cannot convert an account to a different type afterward. To move from Standard to Premium (or change kind), you create a new account and copy the data across with a tool like AzCopy. The single exception is the one-way in-place upgrade of a legacy general-purpose v1 or BlobStorage account to general-purpose v2.

Trap Assuming you can switch a Standard account to Premium in the portal. There is no in-place tier change; you must create a new account and copy the data.

1 question tests this

You have an Azure subscription that contains a General-Purpose v1 storage account named storage1. You need to configure a private endpoint…

Storage account names are 3–24 lowercase alphanumeric characters and globally unique

A storage account name must be between 3 and 24 characters, contain only lowercase letters and numbers (no hyphens, underscores, or uppercase), and be unique across all of Azure because it forms the subdomain of every endpoint, such as account.blob.core.windows.net. A name that is taken anywhere in Azure, or that uses an illegal character, is rejected at creation.

Redundancy answers two questions: spread within the primary region, and whether to add a second region

Within the primary region you choose LRS (three copies in one datacenter) or ZRS (synchronous copies across three availability zones). Layering a distant secondary region on top gives the geo options: GRS (LRS in primary + async copy to the paired region) or GZRS (ZRS in primary + async copy). The redundancy setting is account-wide, so every service in the account shares one durability profile.

LRS keeps three copies in one datacenter. It survives hardware failure, not a datacenter loss

Locally redundant storage replicates data three times within a single physical datacenter in the primary region and gives at least eleven 9s (99.999999999%) of durability over a year. It is the lowest-cost option and protects against drive, server, and rack failures, but if that datacenter is destroyed, every replica is lost. Choose it only when data is easily reconstructed or residency rules forbid leaving the region and a zone outage is acceptable.

Trap Treating LRS as protection against a datacenter or zone outage. All three LRS copies sit in one datacenter, so losing it loses everything.

1 question tests this

You are provisioning an Azure Storage account that will hold temporary processing files for a development and test environment. The data…

ZRS spreads three synchronous copies across three availability zones

Zone-redundant storage writes data synchronously across three availability zones in the primary region (each a separate datacenter with independent power, cooling, and networking) and gives at least twelve 9s (99.9999999999%) durability. Reads and writes keep working through a full zone outage. It is the right within-region choice when you must survive losing a whole datacenter but data must stay in the region.

2 questions test this

GRS and GZRS add a distant secondary region; they differ only in how the primary spreads copies

Both geo options copy data asynchronously to a paired secondary region hundreds of miles away and give at least sixteen 9s (99.99999999999999%) durability. The only difference is the primary region: GRS uses LRS there, GZRS uses ZRS there (so GZRS also survives a primary-region zone outage). In the secondary region both always use LRS. Use a geo option to survive a region-wide disaster.

Trap Thinking GRS and GZRS differ in the secondary region. Both use LRS in the secondary; the difference (LRS vs ZRS) is entirely in the primary region.

3 questions test this

The paired secondary region is fixed by your primary and can't be chosen

When you create a geo-redundant account you pick the primary region; Azure determines the paired secondary region automatically, and it cannot be changed. The pairing is a hundreds-of-miles-away region in the same geography, so you can't, for example, point a West Europe account's secondary at a US region. If a scenario needs a specific secondary, geo-redundancy can't deliver it.

Geo-replication is asynchronous, so a primary disaster can lose recent writes (non-zero RPO)

Writes commit in the primary region first and replicate to the secondary asynchronously, so the secondary trails the primary. The gap between the last primary write and the last write that reached the secondary is the recovery point objective (RPO), and it is non-zero: a disaster that destroys the primary before it catches up loses that window of data. This is the inherent trade for cross-region protection.

A GRS/GZRS secondary isn't readable or writable until you initiate account failover

With plain GRS or GZRS the secondary copy exists for durability but is inaccessible during normal operation; you cannot read or write it. If the primary region is lost, you trigger a customer-managed account failover, after which the secondary becomes the new primary and serves reads and writes. To read the secondary before any failover, you instead need the read-access variant.

Trap Expecting to read a plain GRS account's secondary copy during a primary outage. GRS gives no secondary read access; that requires RA-GRS, or an account failover first.

RA-GRS and RA-GZRS add read-only access to the secondary via the -secondary endpoint

The read-access variants RA-GRS and RA-GZRS let an application read the secondary copy at any time (including before a failover) through a read-only endpoint formed by appending -secondary to the account name (e.g. myaccount-secondary.blob.core.windows.net), using the same access keys. Choose RA- when the app must keep serving reads during a primary-region outage without waiting for failover.

4 questions test this

Azure Files can't use RA-GRS or RA-GZRS

Azure Files supports LRS, ZRS, and the geo options GRS and GZRS, but it does not support read access to the secondary region: there is no RA-GRS or RA-GZRS for file shares. If a requirement asks to read a file share's secondary copy before failover, it cannot be satisfied; plan failover-based recovery instead. (RA- read access applies to Blob, Queue, and Table.)

Trap Choosing RA-GRS for an Azure Files share to get secondary read access. Azure Files doesn't support the RA- variants, only LRS/ZRS/GRS/GZRS.

The archive blob tier needs LRS, GRS, or RA-GRS, never a ZRS-based option

The archive access tier for block blobs is supported only on LRS, GRS, and RA-GRS accounts. It is not supported on ZRS, GZRS, or RA-GZRS. So if a scenario both requires zone redundancy and uses the archive tier, those constraints conflict and you can't have both on the same account.

Trap Putting archive-tier blobs in a GZRS or ZRS account. The archive tier isn't supported on any zone-redundant option; use LRS, GRS, or RA-GRS.

3 questions test this

Object replication asynchronously copies block blobs from a source account to a destination account

Object replication is a blob feature, separate from account redundancy: it asynchronously copies block blobs from a source storage account to a destination account you can read and use directly, to cut read latency in a distant region, distribute compute, or stage results. It is one-directional, and the source and destination can be in the same or different regions, subscriptions, or even Microsoft Entra tenants.

Object replication requires versioning on both accounts and change feed on the source

Before object replication works, blob versioning must be enabled on both the source and destination accounts, and change feed must be enabled on the source (Azure reads the change feed to discover new writes to replicate). Both accounts must be general-purpose v2 or premium block blob. Miss any of these prerequisites and the policy won't replicate.

Trap Enabling object replication without turning on blob versioning on both accounts and change feed on the source. Those are hard prerequisites, not optional.

Object replication handles block blobs only, not append or page blobs

Object replication supports block blobs exclusively; append blobs and page blobs are not replicated, and accounts with a hierarchical namespace (Data Lake Storage) aren't supported. If a workload needs to replicate page or append blobs, object replication is the wrong tool. By default a rule copies only new block blobs written after the rule is created, though you can opt to also copy existing blobs.

Trap Expecting object replication to copy page or append blobs. It copies block blobs only; the others are unsupported.

The object replication destination container is read-only while the policy is active

Object replication is one-directional: once a policy is active, the destination container rejects writes with HTTP 409 (Conflict). Reads and deletes are allowed, but to write to the destination you must first remove the rule or the whole policy. You create the policy on the destination account (Azure assigns a policy ID), then apply that same policy ID on the source so both ends match.

Encryption at rest is always on (256-bit AES) and cannot be disabled

Every storage account encrypts all data at rest automatically with 256-bit AES service-side encryption, which is FIPS 140-2 compliant and covers blobs, files, queues, and tables (including metadata, every access tier, and both primary and secondary regions). There is no option and no cost to turn it off: the only thing you configure is who controls the key.

Trap Treating storage encryption at rest as an optional setting you enable. It is always on and can't be disabled; only key management is configurable.

Microsoft-managed keys are the default; customer-managed keys give you control

By default a storage account encrypts with a Microsoft-managed key (Microsoft stores and rotates it, zero config). Switch to a customer-managed key (CMK) when you must control rotation, auditing, or revocation. You can switch between Microsoft-managed and customer-managed keys at any time, and applying a CMK to an existing account takes effect immediately without re-encrypting your data.

A customer-managed key lives in Key Vault or Managed HSM, reached via a managed identity

A customer-managed key must be stored in Azure Key Vault or Azure Key Vault Managed HSM, and that vault must have both soft delete and purge protection enabled. The storage account accesses the key through a managed identity (system-assigned or user-assigned) that holds get, wrapKey, and unwrapKey permissions on the key. The CMK wraps the account's root encryption key rather than encrypting data directly, so disabling the key in the vault revokes access (operations then fail 403) without re-encrypting anything.

Trap Configuring a CMK on a key vault without soft delete and purge protection enabled. Both are required, or the configuration is rejected.

1 question tests this

You have an Azure subscription that contains an Azure Key Vault named KV1 and a storage account named Storage1. You plan to configure…

Infrastructure encryption double-encrypts, but only if enabled at account creation

Infrastructure encryption adds a second layer: data is encrypted twice, once at the service level and once at the infrastructure level, with two different 256-bit AES keys and algorithms, so a single compromised key or algorithm still leaves data protected. The infrastructure layer always uses a separate Microsoft-managed key even if the service layer uses your CMK. The catch: it can only be enabled when the account is created, you can't add it to an existing account.

Trap Planning to enable infrastructure (double) encryption on an existing account. It's a create-time-only option; you'd have to make a new account and copy the data.

AzCopy is the CLI for scripted, high-throughput transfers; Storage Explorer is the GUI for ad hoc work

AzCopy is a cross-platform command-line utility (Windows, Linux, macOS) for copying data to, from, or between storage accounts, the right tool for scripted, repeatable, or bulk transfers. Azure Storage Explorer is a free desktop GUI for point-and-click browsing and management, ideal for occasional interactive work; it uses AzCopy under the hood for its bulk transfers. Choose AzCopy when a scenario says 'script', 'automate', or 'large/efficient'; choose Storage Explorer for an occasional manual upload.

Trap Reaching for Storage Explorer's GUI to move terabytes in a repeatable script. That's AzCopy's job; Storage Explorer is for interactive, ad hoc use.

7 questions test this

azcopy copy moves data; azcopy sync makes the destination match the source

AzCopy's two core commands: azcopy copy copies source data to a destination (local-to-Azure, Azure-to-local, or account-to-account server-to-server), and azcopy sync performs one-directional synchronization so the destination ends up matching the source, transferring only what changed on re-runs. Use sync when you must keep a destination continuously aligned with a source rather than copying everything each time.

AzCopy authenticates with Microsoft Entra ID (azcopy login) or a SAS token on the URL

AzCopy supports two authorization methods: Microsoft Entra ID (run azcopy login once and reuse the credential across commands) or a shared access signature (SAS) token appended to each source or destination URL. Owning the storage account does not by itself grant data access, so you must provide one of these. Entra ID suits interactive or managed-identity use; a SAS token suits handing scoped, time-limited access to a script without sign-in.

A key expiration policy is a rotation reminder, and you must rotate each key once before setting it

A key expiration policy sets an interval and surfaces a reminder in the portal when the access keys haven't been rotated in time. It does not rotate keys automatically. You cannot create the policy until each access key has been rotated at least once; if keyCreationTime is null the Set rotation reminder option is greyed out. The built-in Azure Policy 'Storage account keys should not be expired' then reports which accounts are out of compliance.

7 questions test this

Also tested in

AZ-900 Microsoft Azure Fundamentals

Account kinds, performance tiers, and what you fix at creation

Account kinds

Performance tier

Naming and endpoints

Redundancy: LRS, ZRS, GRS, GZRS and the read-access variants

Question 1: within the primary region

Question 2: adding a second region

Read access to the secondary (RA-)

Object replication for block blobs

Prerequisites

Policies and rules

Encryption: Microsoft-managed, customer-managed, and infrastructure

Microsoft-managed vs customer-managed keys

Infrastructure (double) encryption

Encryption scopes

Managing data with Storage Explorer and AzCopy

Azure Storage Explorer

AzCopy

Exam-pattern recognition

Azure Storage redundancy options at a glance

Decision tree

Cheat sheet

Also tested in

References