Design Data Storage for Semi-Structured and Unstructured Data — Topic Lesson

This lesson integrates the four learning objectives under Topic 2 of Unit 2: recommending a solution for semi-structured data (LO16), recommending a solution for unstructured data (LO17), balancing storage performance, cost, and access patterns (LO18), and designing for durability of unstructured data (LO19). Together these objectives cover Azure Cosmos DB, Azure Blob Storage, Azure Data Lake Storage Gen2, Azure Files, access tiers, lifecycle management, and redundancy options. Mastering this topic prepares you for roughly 15%–20% of AZ-305 exam questions.

Reference: Ch. 2, §2.2, p. 62–73 of the AZ-305 exam book.

Why This Matters

Modern cloud applications generate enormous volumes of data that doesn't fit neatly into relational tables. A social-media platform stores user profiles as JSON documents, a healthcare system ingests millions of medical images daily, and an IoT fleet streams telemetry in Avro format. Choosing the wrong storage service — or the wrong tier within a service — can mean the difference between a $$500$/month bill and a $$50{,}000$/month bill, or between sub-millisecond reads and multi-second latency.

As an Azure Solutions Architect, you'll be the person stakeholders turn to when they ask: "Where should this data live?" The AZ-305 exam tests your ability to make that call under realistic constraints — budget caps, SLA requirements, compliance mandates, and performance targets. This topic lesson gives you the integrated mental model to reason across all four LOs so the individual pieces click together.

Prerequisites

• Azure Resource Manager (ARM) fundamentals — Can you explain the relationship between a subscription, a resource group, and a resource?
• Basic networking concepts (endpoints, firewalls) — Could you sketch how a virtual network restricts access to a storage account?
• Familiarity with JSON and key-value data models — Can you describe the difference between a document store and a key-value store?
• Azure Storage account basics — Do you know the four services bundled inside a single storage account (Blob, File, Queue, Table)?
• Cost Management fundamentals — Can you read an Azure pricing calculator estimate and identify the dominant cost driver?

Learning Objectives

By the end of this lesson you will be able to:

1. Evaluate Azure Cosmos DB APIs, consistency levels, and partitioning strategies to recommend a semi-structured data solution that meets latency, throughput, and global-distribution requirements.
2. Design an Azure Blob Storage or Azure Data Lake Storage Gen2 architecture for unstructured data, selecting the correct account type, access tier, and namespace configuration.
3. Analyse the trade-offs among Hot, Cool, Cold, and Archive access tiers and recommend lifecycle-management policies that balance cost against access-pattern requirements.
4. Recommend a redundancy strategy (LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS) that satisfies RPO, RTO, and durability targets for unstructured workloads.

Building Blocks

Semi-structured data — Think of a filing cabinet where every folder has a slightly different set of documents inside. → Formally, data that has a schema-on-read model: it carries metadata tags or a self-describing structure (JSON, XML, Avro, Parquet) but does not require a fixed relational schema. → It matters because most modern application state — user profiles, product catalogs, IoT telemetry — is semi-structured, and forcing it into rigid tables creates impedance mismatch.

Unstructured data — Imagine a warehouse of shipping containers: you know each container exists, but you can't query the contents without opening it. → Any data that has no predefined data model — images, videos, logs, backups, office documents. → It matters because unstructured data is typically the largest volume category in any enterprise, so storage-cost optimisation here yields the biggest savings.

Consistency level — Picture a chain of coffee shops that all share one menu. "Strong consistency" means every shop updates the menu simultaneously before serving anyone; "eventual consistency" means each shop updates at its own pace. → In distributed databases, the consistency level governs the trade-off between how fresh a read is and how fast that read completes. → It matters because Azure Cosmos DB exposes five levels (Strong, Bounded Staleness, Session, Consistent Prefix, Eventual), and choosing the wrong one either wastes throughput or violates correctness.

Request Unit (RU) — Think of an RU as a "currency unit" for database work: a 1-KB point-read costs 1 RU, and everything else is priced relative to that. → A Request Unit is a performance abstraction in Cosmos DB that normalises CPU, IOPS, and memory into a single metric. → It matters because you provision or autoscale RUs, and under-provisioning triggers 429 Too Many Requests errors.

Access tier — Imagine a library with a front desk (Hot), a back room (Cool), and a deep archive vault (Archive). Retrieving from the vault is cheap to store but slow and expensive to fetch. → Azure Blob Storage assigns each blob an access tier that determines per-GB storage cost and per-operation retrieval cost. → It matters because the exam tests your ability to map access patterns to tiers and automate transitions with lifecycle rules.

Data redundancy — Think of making photocopies: LRS keeps 3 copies in one building, ZRS spreads 3 copies across 3 buildings in the same city, and GRS sends an extra 3 copies to a building in another city. → Azure replicates storage-account data according to a redundancy option that determines how many copies exist and where they sit. → It matters because durability (11 nines for LRS vs. 16 nines for GZRS) directly maps to RPO and RTO commitments.

Partition key — Think of sorting mail into P.O. boxes: a good partition key fills boxes evenly, a bad one stuffs everything into Box 1. → In Cosmos DB, the partition key is the JSON property that determines how documents are distributed across physical partitions. → It matters because a hot partition caps your throughput at $10{,}000$ RU/s regardless of how much you provision.

Lifecycle management — Imagine an office where a clerk automatically moves ageing paper files from the desk drawer (fast access) to the filing cabinet (slower) to the offsite warehouse (very slow). → In Azure Blob Storage, a lifecycle management policy is a set of rules that automatically transition blobs between access tiers or delete them based on last-modified time or creation time. → It matters because manual tiering at scale is impractical; lifecycle rules enforce your cost-optimisation strategy without human intervention.

Hierarchical namespace (HNS) — Think of the difference between a flat pile of labelled photos and a structured photo album with chapters and pages. → HNS adds true directory and subdirectory support to Azure Blob Storage, turning it into Azure Data Lake Storage Gen2. Operations like directory rename are atomic and $O(1)$ rather than $O(n)$. → It matters because big-data engines like Apache Spark perform metadata-heavy operations (listing, renaming output folders) that are orders of magnitude faster with HNS.

Rehydration — Think of retrieving a document from a deep-freeze archive: you submit a request, and hours later the document arrives at your desk. → In Azure Blob Storage, rehydration is the process of copying or moving a blob from Archive tier back to Hot or Cool so it can be read. Standard priority takes up to 15 hours; high priority typically completes within 1 hour for blobs under 10 GB. → It matters because Archive tier is effectively offline storage; failing to account for rehydration time in your design can lead to SLA violations.

Deep Dive

LO16 — Recommend a Solution for Semi-Structured Data

Azure Cosmos DB is Microsoft's flagship globally-distributed, multi-model database. It supports five APIs, each targeting a different developer ecosystem:

[!TIP] Choose the NoSQL (SQL) API for new projects unless you have an existing codebase on MongoDB or Cassandra. The SQL API gets first-party features earliest and offers the richest query surface.

Consistency levels are a spectrum. From strongest to weakest:

[!WARNING] Strong consistency is unavailable for multi-region write accounts. If the exam scenario requires multi-region writes, the strongest option is Bounded Staleness.

Partitioning strategy — every Cosmos DB container requires a partition key. The ideal key has high cardinality, even distribution, and appears in most query WHERE clauses. Common patterns:

If queries always filter by customerId, use /customerId. If a single customer generates vastly more orders than others, consider a synthetic partition key like /customerId-yearMonth to spread the load.

Throughput models — Provisioned throughput locks in a set RU/s budget (minimum 400 RU/s per container); Autoscale lets you set a maximum and scales between 10% and 100% of that max. Serverless bills per-request with no minimum but caps at $5{,}000$ RU/s and 1 TB.

Global distribution — Cosmos DB supports turnkey multi-region replication. You can add or remove regions at any time without downtime. With multi-region writes, each region accepts writes locally and conflicts are resolved using Last Writer Wins (LWW) by default or custom conflict-resolution policies. This is the only Azure-native database that offers single-digit-millisecond writes across continents with guaranteed SLAs — 99.999% availability for multi-region accounts.

A common exam pattern presents a scenario where an application requires low write latency in both East US and West Europe. The correct answer is Cosmos DB with multi-region writes — not Azure SQL with geo-replication (which provides a single writable primary) and not traffic manager in front of separate databases (which creates consistency headaches).

See the LO16-level lesson for a deeper walkthrough of partition-key design patterns and cross-partition query costs.

LO17 — Recommend a Solution for Unstructured Data

Unstructured data in Azure lands in one of three primary services:

Azure Blob Storage is the workhorse. It offers three blob types:

• Block blobs — optimised for sequential read/write (documents, images, video). Maximum size $190.7 TiB.
• Append blobs — optimised for append operations (log files, audit trails).
• Page blobs — optimised for random read/write (VM disks — most architects use Managed Disks instead).

Azure Data Lake Storage Gen2 (ADLS Gen2) layers a hierarchical namespace (HNS) on top of Blob Storage. It adds true directory semantics, POSIX-like ACLs, and atomic rename — critical for big-data engines like Apache Spark and Azure Synapse.

Azure Files provides fully managed SMB / NFS file shares. Use it when workloads need a mounted file system — legacy lift-and-shift apps, shared config, or home directories.

[!IMPORTANT] You cannot enable HNS on an existing storage account retroactively in all cases — plan this at creation time. Enabling HNS converts the account and may affect features like blob versioning and change feed.

Choosing between Blob Storage and ADLS Gen2 — If your workload is simple object storage (web content, backups, media), standard Blob Storage is sufficient and slightly simpler to manage. If your workload involves big-data analytics, data engineering pipelines (ETL/ELT), or any scenario where you run Spark, Databricks, or Synapse over the data, enable HNS and use ADLS Gen2. The storage costs are identical — the only difference is the HNS feature toggle and its implications for API compatibility.

Azure Table Storage vs. Cosmos DB Table API — Azure Storage accounts include a Table service for simple key-value lookups. For new projects, prefer Cosmos DB Table API which offers global distribution, automatic indexing, and guaranteed single-digit-millisecond latency. The Cosmos DB Table API is wire-compatible with the Azure Table Storage SDK, so migration requires only a connection string change. The exam often tests whether candidates recognise that Cosmos DB Table API supersedes Azure Table Storage for all but the most budget-constrained, low-scale scenarios.

See the LO17-level lesson for a detailed comparison of Blob Storage vs. ADLS Gen2 vs. Azure Files with decision trees.

LO18 — Balance Storage Cost, Performance, and Access Patterns

Azure Blob Storage provides four access tiers. The fundamental trade-off: the colder the tier, the cheaper the storage-per-GB but the more expensive (and slower) data retrieval.

[!NOTE] The minimum retention means early deletion incurs a penalty equal to the remaining days' storage cost. A blob deleted from Cool after 10 days is billed for 20 extra days.

Lifecycle management policies automate tier transitions. A policy is a JSON array of rules:

Design heuristic: map each data category to its access pattern, then set lifecycle rules:

• Active operational data → Hot
• Compliance data accessed monthly → Cool
• Quarterly audit data → Cold
• Legal hold / 7-year retention → Archive

Premium block-blob accounts (BlockBlobStorage kind with Premium_LRS) deliver consistent low-latency I/O for workloads like real-time analytics or media transcoding. They do not support tiering — all data is effectively Hot.

Account-level vs. blob-level tiering — The default access tier is set at the storage account level (Hot or Cool). Individual blobs can override this setting. Account-level default applies to new blobs that don't specify a tier. For ADLS Gen2 accounts, blob-level tiering is supported but lifecycle management is the recommended approach rather than per-blob manual overrides.

Premium block-blob storage uses solid-state drives and delivers consistent low-latency I/O. It is ideal for interactive workloads such as real-time media editing, AI inference pipelines serving models from storage, and IoT near-real-time analytics. Premium accounts only support LRS and ZRS redundancy — no geo-redundancy options. The exam may present a scenario requiring both premium performance and geo-redundancy; the correct answer is that this combination is not available, and you must architect a replication layer (e.g., AzCopy scheduled jobs or Azure Data Factory pipelines) to a secondary region.

See the LO18-level lesson for a worked cost-comparison calculator across tiers and access patterns.

LO19 — Design for Durability of Unstructured Data

Azure replicates every storage account; the redundancy option you choose at creation time determines where and how many copies exist:

Key design decisions:

• RPO — GRS/GZRS replication is asynchronous; typical RPO is under 15 minutes but not guaranteed.
• RTO — Manual failover can take up to 1 hour. RA-GRS/RA-GZRS allows read access during outage, giving an effective read-RTO of zero.
• Soft delete and versioning add a layer of protection against accidental deletion. Soft delete keeps blobs recoverable for a configurable retention window (up to 365 days). Versioning preserves every overwrite.
• Immutable storage (legal hold, time-based retention) makes blobs WORM-compliant for regulatory requirements.

Object replication — For scenarios where you need a copy of specific blobs in a second region (rather than the entire account), Azure offers object replication. It asynchronously copies block blobs from a source container to a destination container in a different storage account (which can be in a different region). This is useful when you need fine-grained control over what data is replicated and where, for example, replicating only a critical-data/ prefix to a secondary region while leaving temporary processing blobs local.

Azure Backup for Blob Storage — In addition to native redundancy, you can configure operational backup for Azure Blob Storage. This provides point-in-time restore (PITR) for up to 365 days, protecting against accidental overwrites and deletions at the blob level. Combined with soft delete (365-day max), versioning, and immutable storage, you can build defence-in-depth protection that satisfies even the most stringent compliance frameworks.

The Well-Architected Framework's Reliability pillar recommends layering these protections: redundancy (infrastructure-level), soft delete and versioning (data-level), immutable storage (compliance-level), and Azure Backup (operational-level). Each layer addresses a different failure mode — hardware failure, user error, ransomware, and regulatory hold respectively.

See the LO19-level lesson for detailed RPO/RTO matrices and failover simulation walkthroughs.

Worked Examples

Easy — Contoso E-Commerce Product Catalog

Problem: Contoso stores $500{,}000$ product listings as JSON documents. Queries filter by categoryId and return results in under 10 ms. Traffic is steady at $2{,}000$ reads/s. Budget: minimise cost.

Step-by-step solution:

1. Data is semi-structured (JSON) → Cosmos DB NoSQL API.
2. Partition key: /categoryId — high cardinality (200 categories), aligns with query filter.
3. Throughput: steady traffic → Provisioned throughput. Estimate: $2{,}000$ reads/s × 1 RU per 1-KB point-read ≈ $2{,}000`RU/s. Provision`2{,}400$ RU/s for headroom.
4. Consistency: Session (default) — users always see their own edits, and stale reads across sessions are acceptable for a catalog.
5. Single region (no global distribution requirement stated).

[!NOTE] At $2{,}400`RU/s provisioned, the monthly cost is approximately`$2{,}400 \times 0.008 \times 730 \approx$$140$ (varies by region). Autoscale would cost more during steady load because it charges the peak.

Medium — Woodgrove Bank Document Archive

Problem: Woodgrove Bank must retain 50 TB of scanned loan documents for 7 years. Documents are accessed fewer than 5 times per year after the first 90 days. Regulatory requirement: data must survive a full regional outage.

Step-by-step solution:

1. Data is unstructured (scanned images) → Azure Blob Storage (block blobs).
2. Access pattern: active for 90 days, then rarely accessed → lifecycle policy: Hot → Cool at day 30, Cool → Archive at day 90.
3. Durability: must survive regional outage → GRS or RA-GRS. Read access to the secondary is useful for audit queries during outage → choose RA-GRS.
4. Retention: 7-year regulatory hold → configure time-based immutability policy with $2{,}555$-day (7-year) retention.
5. Soft delete: enable with 30-day retention as a safety net against accidental deletion during the active phase.

[!NOTE] Archive tier for 50 TB ≈ 50,000 × $0.00099 = $49.50/month. The same data on Hot would cost ≈ $1,040/month — a 95% saving.

Hard — Fabrikam Global IoT Telemetry Platform

Problem: Fabrikam deploys 1 million IoT sensors across 5 regions. Each sensor emits a 2-KB JSON event every 10 seconds. The analytics team runs Apache Spark jobs on raw telemetry. Requirements: sub-10-ms ingestion latency at each region, 99.999% read availability, 7-day hot window for dashboards, 1-year warm window for ad-hoc analytics, then archive for 5 more years.

Step-by-step solution:

1. Ingestion: $1{,}000{,}000$ sensors × 1 event / 10 s = $100{,}000$ events/s. Each event is 2 KB → $200{,}000$ RU/s globally. Use Cosmos DB with multi-region writes and Autoscale (max $250{,}000$ RU/s).
2. Partition key: /deviceId — $1{,}000{,}000$ unique values, excellent cardinality.
3. Consistency: Session (each device reads its own writes; cross-device ordering not required). Note: Strong is unavailable with multi-region writes.
4. Change feed: enable Cosmos DB change feed to stream events to Azure Data Lake Storage Gen2 for Spark processing.
5. ADLS Gen2 tiering:
   • Days 0–7: Hot tier (dashboards query raw data).
   • Days 7–365: Cool tier (ad-hoc analytics).
   • Day 365+: Archive tier (5-year retention).
6. ADLS Gen2 redundancy: RA-GZRS for 99.99999999999999% (16 nines) durability and read access during regional outage.
7. Spark accesses ADLS Gen2 via the abfss:// driver; HNS enabled at account creation.

[!NOTE] Multi-region write Cosmos DB with Autoscale at $250{,}000$ RU/s across 5 regions is expensive. Encourage the team to evaluate whether Azure Event Hubs can buffer ingestion and batch-write to Cosmos DB to lower sustained RU consumption.

Visual Explanations

Storage Service Decision Tree

This decision tree guides you from the data category (semi-structured vs. unstructured) through the key architectural forks to the target Azure service.

Access Tier Cost-Latency Trade-Off

Each rightward step lowers storage cost but increases retrieval cost and latency. Lifecycle rules automate these transitions.

Redundancy Scope Comparison

LRS replicates within a single data centre and pairs with GRS for cross-region protection. ZRS replicates across zones and pairs with GZRS for the highest durability.

Azure Storage Redundancy — Zone and Region Layout

This diagram shows the physical layout of RA-GZRS replication: three copies spread across three availability zones in the primary region, asynchronously replicated to three more copies in the paired region.

Cosmos DB API Comparison

Common Mistakes

❌ Myth: "Cosmos DB Strong consistency works with multi-region writes." ✅ Reality: Strong consistency is not available when multi-region writes are enabled. The strongest option is Bounded Staleness. Why it's tricky: The portal lets you select multi-region writes and shows all five consistency levels in settings, but Strong is silently downgraded — the exam expects you to catch this.

❌ Myth: "Archive tier blobs can be read immediately like Cool or Hot blobs." ✅ Reality: Archive blobs must be rehydrated to Hot or Cool before they can be read. Standard rehydration takes up to 15 hours; high-priority rehydration completes in under 1 hour for objects under 10 GB. Why it's tricky: The access tiers look like a simple drop-down, but Archive behaves fundamentally differently — it's offline storage.

❌ Myth: "GRS gives you instant read access to the secondary region during an outage." ✅ Reality: Plain GRS replicates to the secondary but does not expose a read endpoint. You need RA-GRS or RA-GZRS for read access to the secondary. Why it's tricky: The names are similar, and the exam often pairs "read access during outage" with a GRS option to see if you catch the missing RA- prefix.

❌ Myth: "Enabling hierarchical namespace (ADLS Gen2) can be done anytime after creating a storage account." ✅ Reality: HNS must be enabled at account creation time in most scenarios. While Azure introduced a migration path, it has limitations and may disable certain Blob features. Why it's tricky: Because HNS is a property of the storage account, not a separate service, candidates assume it's a toggle.

Practice Exercises

🟢 Easy — Tier Selection A marketing team uploads campaign images (500 GB). Images are accessed daily for the first 2 weeks, then almost never. Which access tier should you set at upload, and what lifecycle rule should you create?

▶💡 Hint

Compare the early-deletion penalty of Cool (30-day minimum) against the storage savings.

▶✅ Solution

Upload to Hot tier. Create a lifecycle rule to move to Cool after 14 days and to Archive after 90 days. Hot avoids the Cool-tier early-deletion penalty during the 14-day active window.

🟢 Easy — Cosmos DB API Choice A team has an existing Node.js application that uses MongoDB Atlas. They want to migrate to Azure with minimal code changes. Which Cosmos DB API should they choose?

▶💡 Hint

Think about wire-protocol compatibility.

▶✅ Solution

Use the MongoDB API for Cosmos DB. It is wire-protocol compatible with MongoDB $4.2+, so the application can connect by changing the connection string without rewriting queries.

🟡 Medium — Redundancy for Compliance A healthcare company stores patient records (10 TB) in Azure Blob Storage. Regulation requires: data must survive a complete regional outage, and the application must be able to read data within 1 minute of a primary-region failure. Which redundancy option meets these requirements?

▶💡 Hint

Consider the difference between GRS and RA-GRS, and what "read within 1 minute" implies.

▶✅ Solution

Choose RA-GRS (or RA-GZRS for zone protection as well). RA-GRS provides a read-only endpoint in the paired region that is available immediately — no failover needed. Plain GRS requires a manual failover (up to 1 hour), which violates the 1-minute read requirement.

🟡 Medium — Partition Key Design Fabrikam's order-management system stores 10 million orders in Cosmos DB. 80% of orders belong to 50 enterprise customers. The team chose /customerId as the partition key. What problem will they encounter, and how should they fix it?

▶💡 Hint

Think about partition throughput limits and data skew.

▶✅ Solution

Hot partitions — the 50 enterprise customers will concentrate most data and RU consumption onto a few physical partitions, each capped at $10{,}000$ RU/s and 20 GB. Fix: use a synthetic partition key like /customerId-orderMonth to spread large customers across multiple logical partitions.

🔴 Hard — Multi-Tier Architecture Contoso runs a media platform. Video files (\sim$$$2 TB/day) must be available for streaming within 100 ms for 30 days, then available for on-demand viewing (retrieval within 1 hour acceptable) for 2 years, then deleted. Metadata per video (\sim5$ KB JSON) must be queryable at all times. Design the storage architecture.

▶💡 Hint

Consider two separate storage services for video files vs. metadata, and lifecycle policies for the video files.

▶✅ Solution

Video files: Azure Blob Storage (block blobs). Upload to Hot tier. Lifecycle rule: move to Cool at day 30, move to Archive at day 365 (Archive rehydration meets the 1-hour on-demand requirement using high-priority rehydration), delete at day 760 (2 years + 30 days).

Metadata: Cosmos DB NoSQL API. Partition key /videoId. Session consistency. Autoscale (traffic varies with uploads). This keeps metadata always queryable even when the video itself is in Archive.

Redundancy: RA-GZRS for the Blob account (highest durability for large media assets). Cosmos DB multi-region for metadata availability.

🔴 Hard — Cost Optimisation Across Tiers Woodgrove Bank stores 200 TB of data. Access analysis shows: 20 TB accessed daily, 80 TB accessed monthly, 60 TB accessed quarterly, 40 TB never accessed after initial upload. Currently all data sits on Hot. Estimate the monthly cost reduction from tiering correctly. (Use approximate per-GB rates: Hot = $$0.0208$, Cool = $$0.0115$, Cold = $$0.0072$, Archive = $$0.00099$.)

▶💡 Hint

Multiply each segment's volume by the appropriate tier rate and compare against the current all-Hot cost.

▶✅ Solution

Current cost (all Hot): $$200{,}000 \times$$0.0208 = $4{,}160$/month.

Optimised: 20{,}000 \times$ $0.0208$ (Hot) + 80{,}000 \times$$0.0115$ (Cool) + 60{,}000 \times$ $0.0072$ (Cold) + 40{,}000 \times$$0.00099$ (Archive) $= $416 + $920 + $432 + $39.60 = $1{,}807.60$/month.

Saving: $$4{,}160 - $1{,}807.60 = $2{,}352.40$/month ($$\sim$$$56%$ reduction).

Summary & Concept Map

• Semi-structured data belongs in Azure Cosmos DB — pick the API that matches your existing ecosystem, choose the lightest consistency level that meets correctness needs, and design a high-cardinality partition key.
• Unstructured data lands in Azure Blob Storage (general purpose), ADLS Gen2 (big-data analytics with HNS), or Azure Files (file-share mounts).
• Access tiers (Hot, Cool, Cold, Archive) trade storage cost against retrieval cost; lifecycle management policies automate transitions based on age.
• Redundancy options range from LRS (11 nines, single data centre) to RA-GZRS (16 nines, cross-zone + cross-region + read access) — choose based on RPO, RTO, and compliance requirements.
• Soft delete, versioning, and immutable storage add protection layers against accidental or malicious data loss.
• Cost optimisation is a first-class design concern: the right combination of tier, throughput model, and redundancy can reduce costs by 50%+ without sacrificing SLA commitments.
• Across all four LOs, the unifying principle is matching the data's access pattern to the storage service's strengths — latency-sensitive queries need Cosmos DB or Hot-tier Blob, rarely-accessed compliance data belongs in Archive, and analytics pipelines need ADLS Gen2's hierarchical namespace.

Connections & Next Steps

This topic's four learning objectives form a natural reading sequence:

1. LO16 — Semi-structured storage (Cosmos DB deep dive): start here to master document/graph/key-value design decisions.
2. LO17 — Unstructured storage (Blob, ADLS Gen2, Files): builds on LO16 by contrasting object storage with document storage.
3. LO18 — Storage balance (tiers, lifecycle, cost): applies to the Blob and ADLS services from LO17.
4. LO19 — Unstructured durability (redundancy, soft delete, immutability): caps the topic with data-protection design.

After completing this topic, move to Topic U2/T1 — Relational Data to compare how Azure SQL, PostgreSQL, and MySQL handle structured data. The redundancy and tiering concepts you learned here will resurface in Unit 3 — Business Continuity where you'll design end-to-end DR strategies that span both storage and compute.

For a broader view of how all four Topics in Unit 2 connect, revisit the Unit 2 survey lesson.