Soru

Zorluk: OrtaAzure Cosmos DB and NoSQL Solutions

An energy utility company is designing a smart grid monitoring platform on Azure. The system will ingest real-time telemetry from 10 million smart meters globally. The architecture has the following requirements:

* Raw telemetry payloads must be stored in an Azure Storage account. The storage account must survive a regional outage.
* A third-party auditing application must be granted temporary read-only access to the raw payloads for a maximum of 2 hours, with the ability to revoke access immediately if credentials are leaked.
* Metadata and event indexing records must be stored in Azure Cosmos DB for NoSQL. The database must sustain a write-heavy ingestion rate (90% writes, 10% reads) and achieve 99.999%99.999\% write availability.
* Telemetry records in Cosmos DB contain `meterId` (unique per meter), `readingDate` (daily format), `postalCode` (geographic region), and `usageValue`. Queries typically filter by `meterId` and `readingDate`.

You need to recommend the partition key for Azure Cosmos DB, the redundancy configuration for the storage account, and the security configuration for the auditing application.

Which combination should you recommend?

  1. Partition key: meterId; Storage redundancy: Geo-redundant storage (GRS); Security: A Service Shared Access Signature (SAS) associated with a Stored Access Policy configured for a 2-hour duration.Cevap
  2. B
    Partition key: postalCode; Storage redundancy: Geo-redundant storage (GRS); Security: A Service Shared Access Signature (SAS) associated with a Stored Access Policy configured for a 2-hour duration.
  3. C
    Partition key: meterId; Storage redundancy: Locally redundant storage (LRS); Security: A Service Shared Access Signature (SAS) associated with a Stored Access Policy configured for a 2-hour duration.
  4. D
    Partition key: meterId; Storage redundancy: Geo-redundant storage (GRS); Security: An ad-hoc Shared Access Signature (SAS) token configured with a 1-year lifetime directly embedded in the connection string.

Cevap

Select meterId as the Cosmos DB partition key, configure the storage account with Geo-redundant storage (GRS), and use a Service Shared Access Signature (SAS) associated with a Stored Access Policy configured for 2 hours.
The correct recommendation is to use meterId as the Cosmos DB partition key, Geo-redundant storage (GRS) for storage account redundancy, and a Service SAS associated with a Stored Access Policy for temporary access. This combination successfully distributes Cosmos DB writes evenly across 10 million logical partitions, protects storage data against regional disaster, and provides revokable, limited-duration access to the auditing application.

Adım Adım Çözüm

1
Determine the Cosmos DB partition key to prevent hot partitions under heavy write ingestion.
Using meterId, which has high cardinality (10 million unique values), ensures even distribution of write and read requests across logical partitions.
Choosing low-cardinality keys like postalCode would group millions of devices into a small number of partitions, causing ingestion bottlenecks (hot partitions).
2
Select the storage redundancy tier that meets the regional resilience requirement.
Recommend Geo-redundant storage (GRS) or Read-access geo-redundant storage (RA-GRS).
Locally redundant storage (LRS) only replicates data within a single physical location and does not provide protection against regional outages.
3
Select the secure data access method for third-party auditing.
Recommend a Service SAS tied to a Stored Access Policy with a 2-hour validity window.
Tying the SAS to a Stored Access Policy allows revocation at any time by deleting or altering the policy. Using an ad-hoc SAS token with a long lifetime cannot be revoked without rotating storage account keys.

Anahtar Kavram

Azure Cosmos DB partition key selection, storage redundancy options for disaster recovery, and secure storage access management using SAS and Stored Access Policies.
Bu soruyu puanla