Cosmos DB and Blob Storage through SDKs
Where it sits in the route
This module follows the runtime path and introduces data-plane requests, partition/object boundaries, and data retention behavior before messaging and observability.
Prerequisites and outcomes
Know JSON, HTTP status codes, programming control flow, SDK clients, and token-based identity. You should be able to choose Cosmos DB for queryable distributed items or Blob Storage for object content, explain the request boundary, and predict how consistency, partitioning, metadata, and lifecycle rules affect a workload.
Concept sequence and relationships
The application authenticates, constructs an SDK request, and receives a data-plane response. Cosmos DB routes an item request through its container and partition key; its consistency choice trades freshness and latency. Blob Storage addresses an object and its properties or metadata; lifecycle management can transition or delete data later.
Cosmos DB is not Blob Storage: items are structured records accessed through a database/container model, while blobs are object content accessed through a storage account/container/blob path. SDK access is not AzCopy: application logic uses SDKs, while a transfer tool moves data operationally. A 404 can indicate the wrong container/blob path; a 403 can indicate authorization; unexpectedly expensive reads can expose a partition-key or query-design problem.
Worked scenario
Store a photo’s bytes in Blob Storage and its searchable metadata in Cosmos DB. Use the same request’s authenticated principal to obtain the least required data permissions. Set metadata for content type, choose a partition key that distributes customer traffic, and make a thumbnail handler idempotent when it reacts to a data change.
Conceptual checkpoint
For three requests, identify service, address boundary, credential/permission, expected status, and recovery: missing blob, stale Cosmos read, and unauthorized write. Explain which lifecycle action may happen later and why it is not a backup.
Hands-on / what to try
Read a sample SDK configuration and predict each request’s service, partition/object path, response, and required permission. Deliberately change one container name and one role in the exercise, record the expected diagnosis, restore the configuration, and remove test values. This procedure is static and not live-verified.
Sources and re-audit
- AZ-204 storage objectives, skills measured 2026-01-14; checked 2026-08-31.
- Cosmos DB SDK overview, checked 2026-08-31.
- Blob Storage overview, checked 2026-08-31.
Re-audit when SDK APIs, partition/consistency behavior, storage authorization, or lifecycle behavior changes.