Examkin

Soru

Zorluk: ZorAzure Cosmos DB and NoSQL Solutions

An international healthcare organization is designing a telemonitoring platform to ingest telemetry data from 500,000500,000 wearable medical devices globally. The platform requires a globally distributed Azure Cosmos DB for NoSQL database. The workload is write-heavy, with a write-to-read ratio of 9:19:1, and requires a 99.999%99.999\% read and write availability SLA.

The design must meet the following requirements:
- Support multi-region writes to provide sub-1010 ms write latency for patients worldwide.
- Ensure the backup data can survive a regional primary datacenter outage.
- Prevent hot partitions under heavy write load.
- Authorize external research partners to access specific patient telemetry using temporary credentials that automatically expire after 2424 hours, without exposing the database's master keys.

Which two configuration options should you include in the storage design? (Select two.)

  1. Partition the Cosmos DB container using a high-cardinality composite key such as deviceId-YYYYMMDD and configure the database account with Session consistency.Cevap
  2. Deploy a custom token broker service to issue Azure Cosmos DB resource tokens with a maximum lifetime of 24 hours to the external research partners.Cevap
  3. C
    Partition the Cosmos DB container using deviceType as the partition key to group similar telemetry schemas into the same logical partition.
  4. D
    Configure the database backup redundancy to use Locally Redundant Storage (LRS) and enable manual failover to survive regional primary datacenter outages.

Cevap

Partition the Cosmos DB container using a high-cardinality composite key such as deviceId-YYYYMMDD, configure the database account with Session consistency, and deploy a custom token broker service to issue Azure Cosmos DB resource tokens with a maximum lifetime of 24 hours.
Partitioning the container using a high-cardinality composite key like deviceId-YYYYMMDD ensures that the write-heavy workload of 500,000 devices is evenly distributed across logical and physical partitions, avoiding hot partition bottlenecks. Implementing a custom token broker to issue 24-hour resource tokens satisfies the security requirement by providing temporary, fine-grained access to third-party integrations without exposing master keys.

Adım Adım Çözüm

1
Analyze partitioning requirements to prevent hot partitions.
Identify that deviceId-YYYYMMDD is a high-cardinality key that spreads the write load across partitions, whereas deviceType has low cardinality and would create hot partitions.
Choosing a high-cardinality partition key ensures high scalability and avoids RequestRateTooLarge errors in write-heavy workloads.
2
Analyze authorization requirements for external research partners.
Recommend using a custom token broker to generate short-lived (24-hour) resource tokens.
Resource tokens provide granular access permissions to specific containers or items and expire automatically without exposing the account master keys.
3
Evaluate backup redundancy and replication requirements.
Reject Locally Redundant Storage (LRS) for backups as it cannot survive regional outages.
LRS keeps three copies of data in a single datacenter, making it vulnerable to regional disaster, violating the RPO and survivability requirements.

Anahtar Kavram

Designing partition keys and security policies for Azure Cosmos DB in globally distributed scenarios.
Bu soruyu puanla

Konular

Azure Cosmos DB and NoSQL Solutions

Bu konudan daha fazla soru