D2 · Data Storage

Storage Accounts Design

The storage design decisions on AZ-305: which meets the durability and DR requirements, which access tier minimizes cost for the access pattern, and which authorization mechanism is the most secure.

Icon-storage-86

Redundancy: from LRS to GZRS

OptionCopiesSurvives...Durability
LRS3 in one datacenterDisk/rack failure11 nines
ZRS3 across 3 An entire datacenter/zone going down12 nines
GRSLRS + 3 async copies in the paired regionRegional disaster (failover)16 nines
GZRSZRS + 3 async copies in the paired regionZone down AND regional disaster16 nines
RA-GRS / RA-GZRSSame + read access to the secondaryLets you READ from the secondary without failing over16 nines

Design keys

  • • Geo replication is asynchronous — typical RPO < 15 min (possible loss of the last few minutes on failover)
  • • Account failover: client-initiated (or by Microsoft in a declared disaster); after failover the account becomes LRS and must be reconfigured
  • • RA-GRS: apps can read from the secondary (-secondary endpoint) for read HA without failing over

How to choose

  • • Recreatable / dev-test data → LRS
  • • Intra-region HA (zonal) → ZRS
  • • Regional DR requirement → GRS/GZRS
  • • Maximum resilience (zonal + regional) → GZRS
  • • Premium (SSD) only supports LRS and ZRS
Icon-storage-86

Access tiers and lifecycle management

TierStorage / access costMinimum retentionUse
HotExpensive storage / cheap access—Frequently accessed data
CoolCheaper / more expensive access30 daysInfrequent access: recent backups, 30-90 day-old data
ColdEven cheaper / expensive access90 daysRarely accessed but instantly available online
ArchiveMinimal / rehydration required (hours)180 daysCompliance, years of retention. OFFLINE: rehydrate to Hot/Cool to read (1-15h, or High Priority <1h)

Lifecycle management policies

Automatic rules based on age/last access: move to Cool after 30 days without access → Archive after 180 → delete after 7 years. If the scenario asks to "automatically optimize blob costs based on usage", the answer is lifecycle management — not scripts or Azure Functions.

Icon-storage-86

Standard vs Premium and Data Lake Gen2

Account types

  • • Standard general-purpose v2: the default — blobs, files, queues, tables, all tiers and redundancies
  • • Premium block blobs: SSD, low and consistent latency — interactive workloads, high-frequency IoT
  • • Premium file shares: high-performance SMB/NFS
  • • Premium page blobs: unmanaged disks (legacy)

Data Lake Storage Gen2

  • • + hierarchical namespace (real directories)
  • • POSIX ACLs per directory/file (in addition to RBAC)
  • • The foundation for data lakes feeding Synapse, Databricks, Fabric
  • • Exam signal: "big data analytics" + "folder-level permissions" → ADLS Gen2

Azure Files and NetApp Files

ServiceProtocolWhen
Azure Files Standard/PremiumSMB, NFS (premium), RESTManaged file shares: lift-and-shift of apps that use shares, AVD FSLogix profiles. Kerberos auth with Entra DS/AD DS
Azure File SyncSMB (agent on Windows Server)Local cache on on-prem servers with cloud tiering — branch offices with fast access and the cloud as the source of truth
Azure NetApp FilesNFSv3/v4.1, SMB, dualDemanding enterprise workloads: SAP HANA, HPC, databases over NFS — <1ms latency and extreme throughput
Blob NFS 3.0NFS over blobAnalytics/HPC reading objects via NFS, cheaper than NetApp
Icon-storage-86

Access: keys, SAS and Entra ID

MechanismRiskWhen
Entra ID + RBAC (DataActions)Minimal — no secrets, with CA and auditingALWAYS the first option: managed identity + Storage Blob Data Contributor/Reader
User delegation SASLow — signed with Entra credentials, not the account keyTemporary delegated access for external clients (the best kind of SAS)
Service/Account SASMedium — signed with the account key; revoking = rotating the keyTemporary granular access when there is no Entra identity. Restrict with stored access policies
Account keysHigh — full account accessAvoid in apps. Disable shared key if policy allows
Anonymous public accessCriticalOnly deliberately public content ( origin). Disabled by default

Network

Private Endpoints for VNet-only traffic (remember the privatelink private DNS zone), account firewall with allowed IPs/VNets, and "Allow trusted Microsoft services" so Backup/Defender can access the account despite the firewall.

Decision table

RequirementDesign
Critical data that must survive a zone AND a regional outageGZRS (or RA-GZRS if they need to read during DR)
Reports read from the secondary without failing overRA-GRS / RA-GZRS (-secondary endpoint)
10-year retention at the lowest cost, almost never accessedArchive tier + lifecycle policy
Automatically move blobs to colder tiers based on last accessLifecycle management policy
Data lake with per-directory permissions for SynapseADLS Gen2 (hierarchical namespace + ACLs)
Low, consistent blob latency for an interactive workloadPremium block blob (LRS/ZRS)
Share SMB files with caching in branch officesAzure Files + Azure File Sync (cloud tiering)
SAP HANA over NFS with <1ms latencyAzure NetApp Files
An app accesses blobs with no secretsManaged identity + RBAC data plane
External partner uploads files for 48hUser delegation SAS with expiration

Did you get this topic?

Test what you just learned

An insurance company stores scanned records: they're queried frequently in the first 60 days, almost never after, and regulation requires keeping them for 10 years and being able to retrieve them within 24 hours. They want the lowest possible cost with minimal administration. What do you design?

Ready to test "Storage Accounts Design"?

Put what you learned to the test with original AZ-305 exam questions.

Start AZ-305 mock exam

Unlimited mock exams with the Pro plan

Log in to track your progress.