Examkin

Question

Difficulty: MediumAzure Cosmos DB and NoSQL Solutions

An organization is designing a fleet management system using Azure Cosmos DB for NoSQL to store telemetry data from 2,000,0002,000,000 active delivery vehicles. Each vehicle uploads a status message containing `VehicleId`, `CurrentStatus` (which can be 'Active', 'Idle', or 'Maintenance'), and `Timestamp` every 6060 seconds. The database must sustain high-throughput write operations and handle queries that retrieve the telemetry history for a specific vehicle. Additionally, the database must remain available for reads even during a regional outage. Which design configuration should you recommend?

  1. Configure the container with VehicleId as the partition key and add a secondary region to the Azure Cosmos DB account.Answer
  2. B
    Configure the container with CurrentStatus as the partition key and add a secondary region to the Azure Cosmos DB account.
  3. C
    Configure the container with VehicleId as the partition key and configure the account to use locally redundant storage (LRS) as the primary mechanism for surviving regional failures.
  4. D
    Configure the container with VehicleId as the partition key and distribute a Shared Access Signature (SAS) token with a 5-year expiration directly to all vehicles to perform database writes.

Answer

Configure the container with VehicleId as the partition key and add a secondary region to the Azure Cosmos DB account.
The correct design uses VehicleId as the partition key because it has high cardinality (2,000,0002,000,000 unique values) and aligns with the query pattern, which distributes throughput evenly. Adding a secondary region ensures that the database remains available for reads if the primary region experiences an outage.

Step-by-Step Solution

1
Analyze partition key requirements for high-throughput writes and specific query patterns.
VehicleId is selected as the partition key because it has high cardinality (2 million unique values) and aligns with the query pattern of retrieving history for a specific vehicle.
Choosing a high-cardinality key like VehicleId ensures write and read operations are distributed evenly across physical partitions, avoiding hot partitions.
2
Evaluate high availability and disaster recovery requirements.
Adding a secondary region to the Azure Cosmos DB account ensures high availability and read availability in the event of a primary region outage.
Locally redundant storage (LRS) only replicates data within a single region and cannot protect against a regional outage.
3
Evaluate the security configuration for client writes.
Avoid distributing long-lived credentials (like a 5-year SAS token) directly on the vehicle devices.
Long-lived credentials without stored access policies are difficult to revoke and expose the database to unauthorized access if a device is compromised.

Key Concept

Azure Cosmos DB Partition Key Selection and High Availability
Rate this question

Topics

Azure Cosmos DB and NoSQL Solutions

More questions from this topic