4.1 Azure Storage Account and Services
Key Takeaways
- A single Azure Storage account is the container for four data services: Blob (objects), File (SMB/NFS shares), Queue (messages), and Table (key-value NoSQL).
- Storage account types include general-purpose v2 (the default, all services), premium block blob, premium file shares, and premium page blobs; legacy general-purpose v1 and BlobStorage accounts still appear on the exam.
- Replication options are LRS, ZRS, GRS, RA-GRS, GZRS, and RA-GZRS, trading cost against how many copies and regions protect the data.
- Access is secured with access keys, shared access signatures (SAS), Microsoft Entra ID RBAC, and network rules such as firewalls and private endpoints.
- Each account exposes service-specific endpoints (blob, file, queue, table) under a globally unique account name in the form https://<account>.<service>.core.windows.net.
Azure Storage Account and Services
Quick Answer: An Azure Storage account is the top-level resource that hosts four data services in one place: Blob storage (unstructured objects), Azure Files (SMB/NFS file shares), Queue storage (messages for async workflows), and Table storage (a key-value NoSQL store). You pick an account kind, a performance tier (standard or premium), and a replication option, and Azure gives you globally unique endpoints for each service.
Non-relational data on Azure starts with the storage account. On the DP-900 exam, the first job is to recognize which of the four services a scenario describes, then layer on durability and access decisions.
The Four Services in One Account
| Service | Data shape | Typical workload | Endpoint suffix |
|---|---|---|---|
| Blob | Unstructured objects (files, images, video, backups, logs) | Data lake landing zone, media, backups | blob.core.windows.net |
| Azure Files | Fully managed file shares | Lift-and-shift file servers, shared app config | file.core.windows.net |
| Queue | Small text messages (up to 64 KB) | Decoupling app tiers, async task buffering | queue.core.windows.net |
| Table | Key-value / wide-column rows | Flexible-schema structured data, device data | table.core.windows.net |
Each service is reached through a service-specific endpoint under one globally unique account name: https://contosodata.blob.core.windows.net, https://contosodata.table.core.windows.net, and so on. Because the account name is part of a public DNS name, it must be globally unique across all of Azure.
Account Kinds
The account kind controls which services and tiers are available.
| Kind | Services supported | Notes |
|---|---|---|
| General-purpose v2 (GPv2) | Blob, File, Queue, Table | The recommended default; supports all access tiers |
| Premium block blob | Blob only | Low-latency, high-transaction object storage on SSD |
| Premium file shares | Azure Files only | High-performance SMB/NFS shares on SSD |
| Premium page blobs | Page blobs only | Backing store for unmanaged VM disks |
| General-purpose v1 (legacy) | Blob, File, Queue, Table | Older billing model; Microsoft recommends upgrading to v2 |
For the exam, treat general-purpose v2 as the default answer unless a scenario specifically needs the consistent low latency of a premium tier.
Redundancy and Replication
Every storage account keeps multiple copies of your data. The replication option you choose sets how many copies and how far apart they sit — a direct trade between cost and durability.
| Option | Copies | Scope | Protects against |
|---|---|---|---|
| LRS (Locally redundant) | 3 | One datacenter | Disk and server failure |
| ZRS (Zone redundant) | 3 | Three availability zones in one region | Datacenter/zone failure |
| GRS (Geo-redundant) | 6 | Primary region + paired region | Regional outage |
| RA-GRS (Read-access GRS) | 6 | Same as GRS, secondary is readable | Regional outage, with read failover |
| GZRS (Geo-zone-redundant) | 6 | Zones in primary + paired region | Zone and regional failure |
| RA-GZRS | 6 | Same as GZRS, secondary is readable | Highest durability + read failover |
All options provide at least eleven nines (99.999999999%) of durability over a year. The decision pattern: use LRS for cheap, easily reproducible data; ZRS when you need resilience to a datacenter failure inside one region; and a geo option (GRS/GZRS) when the data must survive an entire region going offline.
Securing a Storage Account
Four mechanisms control access, and the exam expects you to recognize each:
- Access keys. Two 512-bit account keys grant full control. Powerful but coarse — rotate them and avoid embedding them in code.
- Shared access signature (SAS). A signed URL granting scoped, time-limited access to specific services, containers, or objects, with chosen permissions (read, write, delete, list).
- Microsoft Entra ID + Azure RBAC. The recommended option: assign roles such as Storage Blob Data Reader to users, groups, or managed identities. No secrets to leak.
- Network rules. Firewalls restrict access to selected virtual networks or IP ranges, and private endpoints give the account a private IP inside your VNet.
Data is always encrypted at rest with Storage Service Encryption (256-bit AES, on by default) and in transit with HTTPS/TLS.
Putting It Together
A typical analytics solution uses one storage account for several jobs at once: Blob containers hold raw landing files, an Azure Files share serves shared configuration to compute, a Queue buffers ingestion tasks, and a Table records lightweight processing metadata. Recognizing that all four can live in a single account — and which one fits a described need — is exactly the skill the non-relational domain tests.
Data File Formats You Will Meet
The core-concepts domain expects you to recognize common data file formats, and storage accounts are where these files live. Know the families and their trade-offs.
| Format | Type | Notes |
|---|---|---|
| CSV / TSV | Delimited text, row-based | Human-readable, no types, no compression |
| JSON | Semi-structured text | Self-describing, nested, schema per document |
| XML | Semi-structured text | Tag-based, verbose, schema in tags |
| Avro | Row-based binary | Embedded schema; good for write-heavy streaming |
| ORC | Columnar binary | Optimized for Hive/analytics reads |
| Parquet | Columnar binary | Compressed, typed; the analytics default on Azure |
| Delta | Parquet + transaction log | Adds ACID, time travel; the lakehouse standard |
The exam tell: row-based formats (CSV, Avro) suit writes and full-row reads; columnar formats (Parquet, ORC) suit analytical reads that scan a few columns over many rows, because they compress better and skip unneeded columns. Delta is Parquet with reliability features and underpins Fabric and Databricks.
Storage Account Limits and Naming
A storage account name must be 3 to 24 characters, lowercase letters and numbers only, and globally unique — because it forms part of a public DNS endpoint. A single account scales to 5 PiB of capacity (higher with a quota increase) and high request rates, but very large or very high-throughput workloads may spread data across multiple accounts. Recognizing the naming rule and the one-account-many-services model is enough for DP-900.
How the Pieces Fit a Solution
Picture a retail analytics platform on one general-purpose v2 account with GZRS replication. Nightly sales files land as block blobs in an ADLS Gen2 container (hierarchical namespace on). A Queue receives a message per file so a function knows to process it. An Azure Files share holds shared lookup spreadsheets that several VMs mount, and a Table records lightweight job status.
Each service is secured with Microsoft Entra RBAC rather than shared keys, and a private endpoint keeps traffic off the public internet. Being able to assign each requirement to the correct service is precisely the non-relational skill the exam measures.
A company needs its storage account to survive the complete loss of an Azure region while keeping three synchronized copies across availability zones in the primary region. Which replication option meets this requirement at the lowest scope that still satisfies it?
An application must grant a third-party service read-only access to a single blob container for 24 hours, without sharing the account keys. Which Azure Storage feature is the best fit?