Examkin

Question

Difficulty: Very hardAzure Cosmos DB and NoSQL Solutions

An architect is designing a globally distributed telemetry ingestion system for a fleet of 100,000100,000 autonomous transport vehicles. The solution uses Azure Cosmos DB for NoSQL and replicates data across East US, West Europe, and East Asia to support local writes (multi-region writes enabled). The workload consists of 80%80\% writes and 20%20\% reads, aiming for a 99.999%99.999\% availability SLA for both reads and writes. Large diagnostic payloads must be archived to Azure Blob Storage. You must select a design that:

1. Avoids hot partitions in the Cosmos DB container during high-concurrency periods.
2. Ensures the archived payloads in Blob Storage survive a regional disaster.
3. Provides a secure method to generate SAS tokens for accessing the archives, ensuring they can be revoked instantly if compromised.

Which design configuration should you recommend?

  1. A
    Partition the Azure Cosmos DB container using the vehicle manufacturing year as the partition key; configure the Azure Blob Storage account to use Geo-redundant storage (GRS) and generate SAS tokens using a stored access policy.
  2. B
    Partition the Azure Cosmos DB container using a synthetic partition key that combines the vehicle ID and the date (vehicleId_date); configure the Azure Blob Storage account to use Locally redundant storage (LRS) and generate SAS tokens using a stored access policy.
  3. Partition the Azure Cosmos DB container using a synthetic partition key that combines the vehicle ID and the date (vehicleId_date); configure the Azure Blob Storage account to use Geo-redundant storage (GRS) and generate SAS tokens using a stored access policy.Answer
  4. D
    Partition the Azure Cosmos DB container using a synthetic partition key that combines the vehicle ID and the date (vehicleId_date); configure the Azure Blob Storage account to use Geo-redundant storage (GRS) and generate ad-hoc SAS tokens with a 55-year validity period.

Answer

Partition the Azure Cosmos DB container using a synthetic partition key that combines the vehicle ID and the date (vehicleId_date); configure the Azure Blob Storage account to use Geo-redundant storage (GRS) and generate SAS tokens using a stored access policy.
The correct configuration uses a high-cardinality synthetic partition key (vehicleId_date) to ensure even distribution of Request Units (RUs) across physical partitions, preventing hot partitions. To survive regional disaster, the storage account must be configured with Geo-redundant storage (GRS). To ensure immediate revocation of SAS tokens, the tokens must be generated using a stored access policy, allowing the policy to be modified or deleted without rotating the master storage account keys.

Step-by-Step Solution

1
Analyze partition key requirements for Azure Cosmos DB.
Identify that using a low-cardinality key like manufacturing year results in hot partitions. A synthetic key combining vehicle ID and date provides high cardinality and even write distribution.
To satisfy the requirement of avoiding hot partitions under a write-heavy workload.
2
Determine the appropriate Azure Storage redundancy tier.
Eliminate Locally Redundant Storage (LRS) as it cannot survive regional outages. Select Geo-redundant storage (GRS) to replicate data to a secondary region.
To satisfy the requirement that archived payloads must survive a regional disaster.
3
Design the SAS token lifecycle management policy.
Reject long-lived ad-hoc SAS tokens. Select SAS tokens bound to a stored access policy.
To ensure that SAS tokens can be revoked immediately (by deleting or modifying the stored access policy) without rotating the account keys.

Key Concept

Designing a resilient, secure NoSQL and storage architecture using synthetic partition keys, geo-redundant storage tiers, and stored access policies for access token management.
Rate this question

Topics

Azure Cosmos DB and NoSQL Solutions

More questions from this topic