Lesson 06 — Storage Accounts: Configuration & Redundancy

Domain 2 — Storage AZ-104: 15–20% ~30 min Prereq: Lesson 05 — Locks, Tags & Cost

Why Storage Accounts Are Foundational

Nearly every Azure workload touches a storage account. VM boot diagnostics, Azure Function triggers, Log Analytics workspace exports, ARM template deployments, static web hosting, data lake analytics — all of these depend on storage accounts configured correctly. Getting the redundancy option wrong is the single most common storage mistake in enterprise Azure, and it surfaces only when there is a disaster.

The AZ-104 exam specifically tests the six redundancy tiers — their names, their protections, their RPOs, and what happens post-failover. Memorise the redundancy table in this lesson before your exam date.

Storage Account Types

Azure has four current storage account types. Choosing the wrong type is an irreversible decision — you cannot change a storage account type after creation.

TypeServicesRedundancyUse case
Standard GPv2 Blob, Files, Queues, Tables LRS, ZRS, GRS, GZRS, RA-GRS, RA-GZRS Default choice for almost all workloads
Premium Block Blob Block blobs only LRS, ZRS only High-throughput blob workloads, low-latency streaming
Premium File Shares Azure Files only LRS, ZRS only Enterprise file shares requiring low latency or NFS protocol
Premium Page Blobs Page blobs only LRS only Unmanaged VM disks (legacy — use Managed Disks instead)
Legacy account types: GPv1 and Blob Storage Standard GPv1 and the legacy Blob Storage account type are still supported but should not be used for new deployments. Microsoft recommends migrating both to GPv2 — you can upgrade GPv1 to GPv2 in-place (no data movement required) but you cannot downgrade. Blob Storage accounts can also be upgraded to GPv2.
Premium accounts cannot use geo-redundancy All three Premium account types support only LRS or ZRS — no geo-replication options. If your workload needs both low latency and geo-redundancy, you must architect around this: for example, use Azure Site Recovery or application-level replication rather than relying on storage account redundancy.

Redundancy Options — All Six

This is the most exam-dense section in the Storage domain. Understand the topology of each option — not just the name. Know exactly what failure scenario each one does and does not protect against.

── Single Region ───────────────────────────────────────────────── LRS │ 3 copies in ONE datacenter, ONE region. Cheapest. ZRS │ 3 copies across 3 Availability Zones in ONE region. ── Geo-Redundant (Two Regions) ─────────────────────────────────── GRS │ LRS primary + async replication → LRS secondary (not readable) GZRS │ ZRS primary + async replication → LRS secondary (not readable) RA-GRS │ GRS + secondary endpoint always readable RA-GZRS │ GZRS + secondary endpoint always readable ← Microsoft recommended
TierCopiesDatacenter failure?Region failure?Secondary readable?
LRS 3 (1 datacenter) ✗ Not protected ✗ Not protected N/A
ZRS 3 (3 AZs) ✓ Protected ✗ Not protected N/A
GRS 6 (3+3) ✗ Not protected (primary is LRS) ✓ After failover ✗ Only after failover
GZRS 6 (3+3) ✓ Protected ✓ After failover ✗ Only after failover
RA-GRS 6 (3+3) ✗ Not protected (primary is LRS) ✓ Anytime ✓ Always
RA-GZRS 6 (3+3) ✓ Protected ✓ Anytime ✓ Always

Reading from the Secondary Region

When read access (RA-GRS or RA-GZRS) is enabled, the secondary endpoint URL is:

https://<accountname>-secondary.blob.core.windows.net/<container>/<blob>

Data on the secondary is eventually consistent — the replication is asynchronous with a typical RPO under 15 minutes, but this is not guaranteed. Applications reading from the secondary must tolerate stale data and must handle 404 responses gracefully (objects may not yet have been replicated).

Manual Failover

For GRS, GZRS, RA-GRS, and RA-GZRS accounts, you can initiate a customer-managed failover via the portal or Azure CLI when the primary region is unavailable:

  • The secondary region becomes the new primary.
  • The account's redundancy downgrades to LRS immediately after failover — the former secondary only has LRS within itself.
  • Data loss is possible — any writes to the primary not yet replicated to the secondary are lost.
  • After the original primary region recovers, you must manually reconfigure geo-redundancy on the account. It does not restore automatically.
Post-failover state is LRS — not GRS This is a high-probability exam question. After a manual failover, the storage account is LRS — no geo-replication, no protection against the new primary region going down. You must re-enable geo-redundancy and wait for initial replication to complete before you are protected again.

Access Tiers

Access tiers apply to Standard GPv2 accounts and control the storage and access cost trade-off. The default tier can be set at the account level; individual blobs can override with blob-level tiering.

TierOptimised forStorage costAccess costMin storage duration
Hot Frequent access Highest Lowest None
Cool Infrequent access (monthly) Lower Higher 30 days
Cold Rarely accessed (quarterly) Lower still Higher still 90 days
Archive Long-term retention, rarely read Lowest Highest + rehydration time 180 days
Early deletion fees apply to Cool, Cold, and Archive If you store a blob in Cool tier and delete it after 5 days, you are still billed for 30 days. If you store in Archive and delete after 100 days, you are billed for 180 days. Hot tier has no minimum duration. This is a recurring billing gotcha in exam scenarios.

Hot and Cool tiers can be set as the account default. Cold and Archive are available only at the individual blob level — you cannot set Cold or Archive as the storage account default tier.

Configuration and Security Settings

Naming Constraints

Storage account names must be 3–24 lowercase alphanumeric characters, globally unique across all Azure. The name becomes part of the service endpoint URL (https://<name>.blob.core.windows.net), so name collisions are global.

Hierarchical Namespace (HNS)

Enabling Hierarchical Namespace at account creation converts the account into Azure Data Lake Storage Gen2. This adds:

  • Atomic directory rename and delete operations (critical for big data pipelines).
  • POSIX-compatible ACLs at file and directory level (in addition to RBAC).
  • Native integration with Spark (Azure Databricks, HDInsight, Synapse Analytics).
HNS cannot be enabled after account creation Hierarchical Namespace is set at provisioning time and cannot be changed later. If you need ADLS Gen2 capabilities, you must create a new storage account with HNS enabled. There is no in-place migration path — data must be moved. Plan this decision carefully before deployment.

Network Access Configuration

SettingWhat it does
Public access — All networks Anyone on the internet can reach the storage endpoint (subject to auth)
Public access — Selected networks Only specified VNet subnets (via service endpoints) and IP ranges can access
Public access — Disabled All public traffic denied; access only via private endpoints in your VNet

Authentication Options

Storage accounts support two authentication models for data-plane access:

  • Shared key (access keys): two 512-bit keys, full account access. Simple but high blast radius if leaked. Microsoft now recommends disabling shared key auth in production.
  • Microsoft Entra ID (OAuth + RBAC): assign storage data-plane roles (Storage Blob Data Reader, Storage Blob Data Contributor, etc.) to managed identities or service principals. No secret to rotate or leak.
Disabling shared key auth is a breaking change Before disabling shared key auth, audit all clients accessing the account. SAS tokens signed with storage account keys will also stop working — only User Delegation SAS (backed by Entra ID) will continue to function. Migrate applications to managed identity authentication before disabling.

Encryption Settings

  • Encryption at rest: all storage data is encrypted at rest by default with 256-bit AES using Microsoft-managed keys. No configuration needed.
  • Customer-Managed Keys (CMK): supply your own encryption key via Azure Key Vault or Managed HSM. Required for some compliance frameworks (PCI-DSS, HIPAA). Key rotation is your responsibility.
  • Infrastructure encryption: double encryption — Azure encrypts data twice at the hardware layer plus the software layer. For the most stringent compliance requirements.
  • Minimum TLS version: set to TLS 1.2 in production. TLS 1.0 and 1.1 are insecure and deprecated.
  • Secure transfer required: enforces HTTPS for all connections — should always be enabled. Rejects HTTP connections.

Key Service Limits

LimitValue
Max storage capacity5 PiB (petabytes)
Max storage accounts per subscription per region250
Max request rate per account20,000 requests/second
Max ingress (LRS/GRS)10 Gbps (US/Europe), varies by region

Check Your Understanding

Click any option to see immediate feedback. Answers represent correct behaviour in a real Azure environment.

1. A critical financial application must read data from the secondary region during a primary region outage without waiting for a Microsoft-initiated failover. Which redundancy should you choose?

RA-GZRS is the correct answer. "RA" means Read Access — the secondary endpoint is available for reads at all times, not just after failover. The "GZRS" component means the primary uses ZRS (3 availability zones), providing datacenter fault tolerance in addition to geo-replication. This is Microsoft's recommended option for maximum durability.

2. You create a GPv2 storage account with Cool as the account tier. A developer uploads a blob then deletes it 5 days later. What is the billing implication?

Cool tier has a 30-day minimum storage duration. If you delete a blob before 30 days, Azure charges as if it were stored for the full 30 days. This same principle applies to Cold (90-day minimum) and Archive (180-day minimum). Hot tier has no minimum duration. Always factor minimum retention periods into lifecycle management design.

3. An application uses shared key authentication for storage access. Your security team mandates migration to Entra ID authentication. What is the correct sequence?

The migration must be done in sequence to avoid an outage. First: ensure the identity (managed identity or service principal) has the correct data-plane role (e.g. Storage Blob Data Contributor). Second: update the application code to use DefaultAzureCredential or another Entra-aware credential. Third: only after the app is confirmed working with Entra ID, disable shared key auth — this is a breaking change for any remaining key-based clients.

4. A storage account must be inaccessible from the public internet — all access must go through a private network path. Which configuration achieves this?

Only a private endpoint truly removes the storage account from the public internet. A private endpoint injects a private IP from your VNet's address space directly to the storage service — DNS resolves to this private IP. Service endpoints (option D) still traverse the public IP space of the Azure Storage service and do not make the storage account private-only. Adding an IP range to the firewall (option B) still allows traffic from those addresses via public routing.

5. You need to store video files with low-latency access and run Spark analytics jobs using Azure Databricks with directory-level operations. Which configuration is required?

ADLS Gen2 (Standard GPv2 + HNS) is the correct answer. HNS enables atomic directory operations (rename, delete) which are essential for big data analytics where Spark commits results by renaming temporary directories. Azure Files (option D) is for SMB/NFS file shares, not blob analytics. Premium Block Blob (option B) does not support HNS. Remember: HNS must be set at account creation — it cannot be added later.

6. Your storage account currently uses GRS. You initiate a manual customer failover due to a regional outage. What is the state of the account immediately after failover completes?

After a manual customer failover, the storage account becomes LRS. The secondary region (which is now the primary) was originally using LRS as its local replication model. Azure does not automatically reconfigure geo-redundancy — you must change the replication setting back to GRS or GZRS manually after the original primary region recovers. Until you do this, your data has no geo-protection.
Primary source for this lesson Azure Storage redundancy (Microsoft Learn)

Also read: Storage account overview and Disaster recovery and storage account failover. The failover article explains post-failover LRS state in detail.

Questions for your teacher (the AI agent)
This lesson covered storage account types, redundancy, tiers, and security. Go deeper on:
  • Walk me through the exact CLI commands to initiate a storage account failover and then reconfigure GRS afterwards.
  • What is the difference between a service endpoint and a private endpoint for storage, architecturally?
  • How does ADLS Gen2 POSIX ACL interact with Azure RBAC — which takes precedence?
  • When would I use a customer-managed key versus Microsoft-managed key for storage encryption?
  • How do I migrate a production storage account from LRS to ZRS without downtime?
Coming up: Lesson 07 — Azure Blob Storage: Access, Lifecycle & Security With storage accounts understood, the next lesson goes one level deeper — into blob storage specifically. We cover the three blob types, SAS token architecture (including the all-important User Delegation SAS), lifecycle management policies for automated tiering, and the full suite of data protection features: soft delete, versioning, immutability policies, and point-in-time restore.