Domain 3 of the official DP-900 skills outline includes "Describe the capabilities of Azure storage," with Blob Storage, Azure Files, and Table Storage listed under it. The questions do not stop at names such as "images go in Blob." They often go one level deeper, asking about minimum retention periods for each tier, lifecycle policies, PartitionKey and RowKey, and file share protocols.
This post is a supplementary entry to Non-relational Data Fundamentals in our DP-900 study series. Building on the basics of blob types, access tiers, and redundancy covered there, it walks through the detailed rules the exam asks about: storage account structure, Blob lifecycle management, the hierarchical namespace of Data Lake Storage Gen2, the protocols and capacity of Azure Files, and key design in Table Storage.
---
Storage Accounts: Where Every Azure Storage Service Starts
Picture an apartment complex. Inside one complex there is a storage building for keeping belongings, a shared office that several households use, and a ledger in the management office. In Azure Storage, the storage account plays the role of the complex, and blob containers, file shares, tables, and queues live inside it.
| Service | Hierarchy | How it is accessed | |------|------|------| | Blob Storage | Storage account → container → blob | HTTP(S)-based Blob API | | Data Lake Storage Gen2 | Storage account (hierarchical namespace on) → file system → directory → file | Blob API plus a file system driver for analytics | | Azure Files | Storage account → file share → directory → file | SMB and NFS mounts | | Table Storage | Storage account → table → entity | Key-based REST API |
Redundancy, which defines how data is replicated, is set per storage account. LRS keeps three copies in a single datacenter, and ZRS keeps copies across three availability zones in the same region. GRS and GZRS replicate asynchronously to a secondary region hundreds of miles away, and choosing RA-GRS or RA-GZRS (with RA for read access) lets you read from the secondary region even before a failover. Azure Files, however, does not support reading from the secondary region.
Exam tip: "Protect against a regional outage and read from the secondary region even before failover" → RA-GRS or RA-GZRS. "Data must stay writable even if one datacenter in the region goes down" → ZRS.
---
Blob Storage: Access Tiers and Lifecycle Management
Blob Types and Maximum Sizes
Blobs are stored in containers, and access is controlled at the container level. Folders inside a container are virtual folders made from "/" characters in blob names, so you cannot set permissions or run bulk operations at the folder level.
| Type | Structure | Maximum size | Use | |------|------|------|------| | Block blob | Up to 50,000 blocks of up to 4,000 MiB each | About 190.7 TiB | Large files that rarely change, such as images, videos, and documents | | Page blob | Fixed 512-byte pages | 8 TiB | Virtual machine disks, random reads and writes | | Append blob | Blocks can only be added to the end | About 195 GiB | Data that keeps growing at the end, such as logs |
Access Tiers and Early Deletion Charges
The four tiers, Hot, Cool, Cold, and Archive, strike different balances between storage cost and access cost. Hot is the default, and the further down you go, the cheaper storage becomes and the more expensive it is to read the data. Data must stay at least 30 days in Cool, 90 days in Cold, and 180 days in Archive. If you delete it or move it to another tier before then, an early deletion charge for the remaining days is applied on a prorated basis. Delete a blob 21 days after moving it to Cool, for example, and you pay for the remaining nine days of storage.
!Blob access tiers and lifecycle management
Archive is an offline tier, so you cannot read or modify a blob there directly. You first have to rehydrate it by changing its tier to Hot, Cool, or Cold. Standard priority can take up to 15 hours for objects under 10 GB, while the more expensive high priority may finish in under an hour and is meant for emergency restores.
Lifecycle Management Policies
Newly created data is used often and then, over time, hardly at all. A lifecycle management policy uses rules written in JSON to move blobs to cheaper tiers or delete them automatically.
Conditions: days since creation, last modification, or last access (when access tracking is enabled) Actions: change the tier to Cool, Cold, or Archive; delete current versions, previous versions, or snapshots Filters: target blobs by name prefix or blob index tags Cost: the policy itself is free and you pay only for the tier-change operations. After you change rules, it can take up to 24 hours for them to take effect.
Exam tip: "Automatically move blobs to Cool 30 days after upload, to Archive after 180 days, and delete them after seven years" → lifecycle management policy. "A blob in Archive cannot be read right away" → it must be rehydrated first.
---
Data Lake Storage Gen2: What the Hierarchical Namespace Changes
Data Lake Storage Gen2 is not a separate service. It is Blob Storage with the hierarchical namespace setting turned on for the storage account. You can enable it when you create the account or upgrade an existing account, but the upgrade is one-way: you cannot go back to a flat namespace afterward.
When folders that were only imitated with "/" in names become real directories, two things change.
Atomic directory operations: renaming, moving, or deleting a directory becomes a single update to the parent directory entry. With a flat namespace, millions of individual blobs had to be processed one by one. Spark and Hive rename temporary output folders at the end of a job, so analytics jobs finish much faster. POSIX-compliant ACLs: separately from Azure RBAC, you can set fine-grained read, write, and execute permissions on individual files and folders.
| Aspect | Blob Storage (flat namespace) | Data Lake Storage Gen2 (hierarchical namespace) | |------|------|------| | Folders | Virtual folders made from "/" in names | Real directories | | Renaming a directory | Blobs processed one by one | One atomic operation | | Fine-grained permissions | Mainly at the container level | POSIX ACLs per file and folder | | Main use | Object storage that apps read and write | Large-scale analytics with Databricks, Spark, and similar tools |
Blob access tiers and lifecycle management still apply, and Microsoft Fabric's OneLake is itself built on Data Lake Storage Gen2.
Exam tip: "Big data analytics storage that needs folder-level permissions and directory operations" → Data Lake Storage Gen2 with the hierarchical namespace enabled.
---
Azure Files: File Shares in the Cloud
Azure Files is an office file server moved to the cloud. Several computers mount the same share as a network drive and work with it together.
| Protocol | Supported clients | Requirements | |------|------|------| | SMB | Windows, Linux, macOS | Available on both HDD and SSD | | NFS | Linux | SSD media tier only, accessed through a private endpoint or service endpoint in a virtual network |
There are two media tiers, SSD and HDD. Use SSD when you need single-digit-millisecond latency and HDD when cost matters more. Pay-as-you-go HDD file shares are further divided into three access tiers, transaction optimized, hot, and cool; the cooler the tier, the lower the storage price and the higher the transaction price.
Capacity: a single file can be up to 4 TiB, and a pay-as-you-go file share can grow to 100 TiB. Azure File Sync: caches frequently used files on an on-premises Windows Server and synchronizes them with the Azure file share, giving branch offices fast local access while the data lives in the cloud. Snapshots: you can create up to 200 read-only, point-in-time copies per share.
Exam tip: "A share that Linux servers mount over NFS" → Azure Files on the SSD tier. "Keep frequently used files local on a branch-office file server while the master copy lives in Azure" → Azure File Sync.
---
Table Storage: PartitionKey and RowKey
A table in Table Storage shares only its name with a relational table. It is a schemaless key-value store where each row (entity) can have different columns, and it has no foreign keys, relationships, stored procedures, or views. Data is therefore often stored denormalized, with all of a customer's phone numbers and addresses in a single row.
An entity can hold up to 255 properties, including the three system properties (PartitionKey, RowKey, and Timestamp), and up to 1 MiB of data in total. Timestamp records the last modification time; the server manages it and users cannot change it.
Key Design and Query Performance
PartitionKey groups related rows into the same partition, and RowKey uniquely identifies a row within its partition. Together they form the unique key for the whole table, and rows within a partition are stored in RowKey order.
| Query type | Condition | Speed | |------|------|------| | Point query | Both PartitionKey and RowKey specified | Fastest; a single row | | Range query | PartitionKey plus a RowKey range | Fast; contiguous rows in one partition | | Partition scan | PartitionKey plus conditions on other properties | Scans one partition | | Table scan | No PartitionKey | Slowest; scans every partition |
For sensor data, for example, putting the sensor ID in PartitionKey and the reading time in RowKey lets you fetch "today's readings for sensor A" quickly with a range query. If you often need to search on other properties or distribute data globally, Cosmos DB for Table, which indexes every property automatically, is the alternative.
Exam tip: "What uniquely identifies an entity in Table Storage?" → the combination of PartitionKey and RowKey. "Rows in the same partition are sorted by what?" → RowKey.
---
Practice with Scenarios
Decide on your answer first, then check the columns on the right.
| Situa