Design data storage solutions
NoSQL, Object, File, and Data-Lake Storage Design
CoreChoose NoSQL, object, file, and data-lake storage from access model, consistency, scale, durability, lifecycle, and cost requirements.
Aligned to the current AZ-305 study guide, skills measured as of April 17, 2026, verified August 25, 2026.
Why this matters
Semi-structured and unstructured workloads differ more by access and query patterns than by file extension, and each durability choice has region and failover consequences.
Must Know
- Start with the required access and query model when choosing among Cosmos DB, Blob Storage, Azure Files, and Data Lake Storage.
- Balance storage tier savings against retrieval price and latency, including archive rehydration.
- Select LRS, ZRS, GRS, GZRS, or a read-access variant by the fault scope and secondary-read behavior the workload requires.
- Design partitioning, consistency, lifecycle, and data-protection controls as explicit parts of the storage architecture.
Compare and Distinguish
- Azure Cosmos DB provides globally distributed NoSQL models; Blob Storage provides object storage; Azure Files provides managed file shares; Data Lake Storage adds hierarchical namespace semantics for analytics.
- Hot, cool, cold, and archive choices trade access cost and latency against storage cost; archive requires rehydration.
- LRS, ZRS, GRS, GZRS and read-access variants protect against different fault scopes and expose different secondary access behavior.
Scenario examples
- Scenario: Globally distributed user profiles need predictable low-latency key access. Think: Cosmos DB with a durable partition strategy.
- Scenario: Analytics engines need directory-like operations over object data. Think: hierarchical namespace in Data Lake Storage.
- Scenario: Compliance records must be retained against modification. Think: immutable blob storage plus the required retention policy.
Exam traps
- GRS does not automatically make the secondary endpoint readable.
- Archive is not appropriate for immediate interactive retrieval.
- A poor partition key cannot be fixed merely by adding throughput.
Key takeaways
- Choose by access and consistency model before choosing a product.
- Match redundancy to fault scope and failover expectations.
- Design lifecycle and protection controls around how data can be lost or changed.
How it works
- Azure Storage acknowledges a write after synchronously replicating it within the primary region; geo-redundant options then copy the change asynchronously to the paired secondary region.
- Azure Cosmos DB uses the partition-key value to place items into logical partitions that are distributed across physical partitions, so request routing and scale behavior follow the chosen key.
- Blob lifecycle management periodically evaluates rule filters and blob age, then applies supported tiering or deletion actions; archived blobs must be rehydrated before their data can be read.
Objects and administrative surfaces
- Storage account kind, namespace choice, region pairing, redundancy, lifecycle rules, and private connectivity shape the design.
- Cosmos DB partition key and consistency choices affect scale, latency, availability, and request cost.
- Immutability, soft delete, versioning, and backup address different deletion or alteration risks.
When to use it
- Use Cosmos DB for distributed NoSQL access with a deliberate partition and consistency model.
- Use Blob Storage for objects, Azure Files for SMB or NFS shares, and Data Lake Storage for analytical object data with hierarchical namespace semantics.
- Use hot or cooler online tiers from access frequency, and immutability plus versioning when fixed retention and prior-state recovery are required.
Security and governance implications
- Separate storage account management, data-plane roles, network paths, encryption keys, and immutable-retention administration.
- Keep regulated copies and failover destinations within allowed regions and prevent privileged deletion where retention demands it.
How to validate and revise the design
- For Cosmos DB hot partitions, inspect the partition key, request distribution, item growth, and region or consistency pattern.
- For missing or inaccessible objects, trace lifecycle tier, rehydration state, version or delete behavior, endpoint authorization, and redundancy status.
More detail
- A read-access geo-redundant account exposes a secondary read endpoint, but the secondary is not a second writable region; asynchronous replication means the newest writes can be absent during a primary-region failure.
- A hierarchical namespace improves directory-oriented analytics operations but also changes feature and protocol compatibility, so it should be selected from workload requirements rather than added merely because the data is called a lake.
- Lifecycle tiering reduces storage price only when minimum-retention, retrieval, transaction, and rehydration consequences fit the access pattern; it does not substitute for backup, versioning, or immutability.
Ready for the quiz?
- Does the workload require key-based NoSQL access, object APIs, mounted file shares, or analytical directory semantics?
- Which partition, consistency, tier, lifecycle, and immutability decisions follow from the access and retention pattern?
- What zone or regional fault must the redundancy option survive, and may clients read the secondary?
Related objectives
- D2.2.S1 — Recommend a solution for storing semi-structured data
- D2.2.S2 — Recommend a solution for storing unstructured data
- D2.2.S3 — Recommend a data storage solution to balance features, performance, and costs
- D2.2.S4 — Recommend a data solution for protection and durability