Quick Note — Recommend a Solution for Storing Semi-Structured Data
AZ-305 › Unit 2 › Design data storage for semi-structured and unstructured data › Recommend a solution for storing semi-structured data
Quick Note — Recommend a Solution for Storing Semi-Structured Data
Semi-structured data is the lifeblood of modern cloud applications — JSON product catalogs, IoT telemetry, user profiles, social graphs, and event streams that don't fit neatly into rows and columns but aren't truly amorphous either. On the AZ-305 exam, candidates are asked to choose the right Azure data service for these workloads, configure it correctly, and reason about the cost and performance trade-offs.…
Retrieval target
- Recommend a Solution for Storing Semi-Structured Data
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Azure Cosmos DB | A globally distributed, multi-model, fully managed NoSQL database. 99.999% SLA for multi-region accounts, 99.99% for single region. Guarantees <10 ms p99 latency for reads and writes. Five data models exposed through five APIs (NoSQL/SQL, MongoDB, Cassandra, Gremlin, Table) — pick the one that matches your app or driver ecosystem. |
Cosmos DB API surface — what each is for | NoSQL (default) — document JSON store, native SDK + SQL-like query. MongoDB — wire-compatible with Mongo 3.x–6.x drivers. Cassandra — wire-compatible with Cassandra CQL drivers. Gremlin — graph traversal (vertices + edges). Table — wire-compatible with Azure Table Storage clients but with Cosmos guarantees (global dist, lower latency). The underlying engine is the same; APIs are facades over it. |
Partition key (Cosmos DB) | The property on a container's items used to distribute data across logical & physical partitions. Items with the same key live together; each logical partition has a 20 GB cap and shares an RU budget. Pick a key with high cardinality + even access pattern + no hot spot (e.g., tenantId+date, not region). Changing it later requires a copy. |
Request Unit per second (RU/s) | Cosmos DB's throughput currency. One RU is the cost of a 1 KB point-read of a single-property doc. Writes cost ~5 RU, complex queries far more. You provision RU/s at the container or database level (autoscale or manual) or pick Serverless (pay-per-RU consumed, capped throughput) for spiky / dev workloads. RU exhaustion → HTTP 429 with retry-after. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.