Question

Difficulty: MediumAzure Cosmos DB and NoSQL Solutions

An Azure Solutions Architect is designing the storage architecture for a global telehealth application. The application must ingest real-time patient health telemetry from 5 million wearable devices distributed globally, with a read/write ratio of 10%10\% reads to 90%90\% writes. The data storage solution must meet a 99.99%99.99\% availability SLA. Real-time metrics must be stored in Azure Cosmos DB (NoSQL API), while weekly diagnostic report files must be uploaded by the devices directly to Azure Blob Storage. The architecture must satisfy the following requirements:
- Prevent database hot partitions during high-frequency write operations.
- Ensure the weekly diagnostic reports survive a primary datacenter outage.
- Secure device access to the Blob Storage account while minimizing administrative overhead and enabling token revocation.

Which design configuration should you recommend?

  1. Partition the Cosmos DB container using the device ID, configure Geo-Redundant Storage (GRS) for the Blob Storage account, and issue short-lived Shared Access Signatures (SAS) generated dynamically via a user delegation key.Answer
  2. B
    Partition the Cosmos DB container using the patient's country code, configure Geo-Redundant Storage (GRS) for the Blob Storage account, and issue short-lived Shared Access Signatures (SAS) generated dynamically via a user delegation key.
  3. C
    Partition the Cosmos DB container using the device ID, configure Locally Redundant Storage (LRS) for the Blob Storage account, and issue short-lived Shared Access Signatures (SAS) generated dynamically via a user delegation key.
  4. D
    Partition the Cosmos DB container using the device ID, configure Geo-Redundant Storage (GRS) for the Blob Storage account, and embed a Shared Access Signature (SAS) token with a five-year lifetime directly in the device firmware.

Answer

Partition the Cosmos DB container using the device ID, configure Geo-Redundant Storage (GRS) for the Blob Storage account, and issue short-lived Shared Access Signatures (SAS) generated dynamically via a user delegation key.
The correct configuration uses the device ID as the partition key because it has high cardinality, which distributes the high write load evenly. Geo-Redundant Storage (GRS) is used to replicate weekly reports to a secondary region, providing protection against datacenter failures. Generating short-lived SAS tokens dynamically via user delegation keys ensures client access is temporary, secure, and easily managed via Entra ID.

Step-by-Step Solution

1
Select the partition key for Azure Cosmos DB.
Choose the device ID.
Since there are 5 million devices, device ID provides a high-cardinality key that distributes writes evenly across logical partitions, avoiding hot partitions.
2
Select the redundancy tier for Azure Blob Storage.
Choose Geo-Redundant Storage (GRS).
To survive a primary datacenter outage, GRS replicates data synchronously to a primary region and asynchronously to a secondary region.
3
Define the authentication and access method for Azure Blob Storage.
Generate short-lived SAS tokens dynamically using a user delegation key.
Using a user delegation key secured by Microsoft Entra ID credentials provides a secure, short-lived SAS token that avoids hardcoding storage account master keys and simplifies access revocation.

Key Concept

Selecting high-cardinality partition keys in Azure Cosmos DB to prevent hot partitions, combined with appropriate storage redundancy and secure, delegatable access policies.
Rate this question