A healthcare organization is designing an Azure Cosmos DB Core (SQL) API container to stor… — Microsoft Azure Developer (AZ-204)

A healthcare organization is designing an Azure Cosmos DB Core (SQL) API container to store real-time telemetry from $100,000$ active medical wearables. The system ingests approximately $20,000$ write operations per second, with each document containing the fields `deviceId`, `patientId`, `timestamp` (ISO 8601 string format), `hospitalId`, and `vitalMetrics`.

The container must satisfy the following requirements:
- Ingestion & Storage: Prevent hot partitions. While overall writes are balanced, intensive care patients generate $10\times$ more telemetry packets than standard patients.
- Queries: Optimize read queries from clinicians retrieving a patient's telemetry for a single day (e.g., `SELECT * FROM c WHERE c.patientId = 'P-8802' AND c.timestamp STARTSWITH '2026-07-16'`).
- Transactional Scope: Stored procedures must execute transactional batches to atomically update a patient's daily summary document alongside new telemetry entries.

Which two design decisions should you implement to satisfy these requirements? (Select two.)

Configure the container with a synthetic partition key created by concatenating the patientId and the date portion of the timestamp (for example, patientId_YYYY-MM-DD).Answer
Store both the daily summary documents and the telemetry documents in the same container, using the synthetic partition key value to scope transactional batches.Answer
C
Configure hospitalId as the partition key to group all regional telemetry and summaries within the same logical partition.
D
Append a random suffix to the patientId (for example, patientId_N where N is a random integer from 1 to 5) to distribute writes, and configure the client to use Session consistency to execute transactional batches.

Answer

Configure the container with a synthetic partition key created by concatenating the patientId and the date portion of the timestamp (for example, patientId_YYYY-MM-DD), and store both the daily summary documents and the telemetry documents in the same container, using the synthetic partition key value to scope transactional batches.

The correct strategy combines a synthetic partition key with document co-location. Concatenating the patient identifier and the date ensures that all telemetry and summaries for a patient-day reside in the same logical partition. This satisfies the single logical partition requirement for transactional batches while maintaining high key cardinality and avoiding storage-bound hot partitions.

Step-by-Step Solution

Analyze the transactional boundary requirement.

Cosmos DB transactions (stored procedures and transactional batches) are strictly limited to a single logical partition.

This means all documents that need to be updated atomically (the telemetry records and the daily summary document) must share the same partition key value.

Evaluate candidate partition keys for cardinality and hot partition risk.

Using the hospital identifier leads to low cardinality and hot partitions. Using the patient identifier alone risks growing too large over time and causing hotspots for high-frequency (intensive care) patients.

Selecting a partition key with low cardinality or unbounded growth violates the physical partition constraints (

20\text{ GB}

storage limit and

10,000\text{ RU/s}

throughput limit).

Formulate a synthetic partition key strategy.

Combine the patientId and the date portion of the timestamp (e.g., `patientId_YYYY-MM-DD`).

This limits the data volume per logical partition to a single patient's daily activity, ensures high cardinality across the system, co-locates the daily transactions, and prevents write hotspots from persisting across multiple days.

Key Concept

Selecting a partition key in Azure Cosmos DB requires balancing transaction boundaries, query patterns, and write scalability. A synthetic partition key combining an entity identifier and a time-based window (like a date string) is a standard pattern to co-locate transactional scope without creating unbounded logical partitions or long-term hot partitions.

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic