Partitioning by /sensorId ensures all readings for a specific device are collocated in the same logical partition. This is optimal because the query pattern targets a single sensor’s data over a time range. Partitioning by timestamp would scatter a single sensor’s data across all partitions, requiring a costly cross-partition query. Region or sensorType would group unrelated sensors together, not aligning with the access pattern.

The root cause is that consumption (9,800 RU/s) is too close to the provisioned limit (10,000 RU/s), causing throttling. Manually increasing throughput provides immediate headroom. Enabling autoscale (A) is a good medium-term solution but may not react instantly to a sustained spike already happening. Adding an index (C) reduces RU cost per operation but doesn’t address an immediate throughput ceiling. Changing consistency (D) lowers RU cost but can introduce side effects and is not the most direct fix for a throughput limit issue.

All three queries include an equality filter on the partition key (`c.category = ‘Electronics’`). This allows the query engine to route the request to the specific logical partition holding all ‘Electronics’ items. The presence of additional filters (like `c.price > 100`) or aggregation functions (like `COUNT`) does not change this routing logic as long as the partition key is specified with an equality filter.

Using Change Feed with an Azure Function is the standard pattern for online, live migration of partition keys. The function reads the existing container’s change feed, transforms documents (assigning the new partition key value), and writes them to a new container. This allows the source container to remain fully operational. Data Factory (A) is for bulk, one-time copies, not continuous sync. The Live Data Migrator (B) is a specific tool for this purpose, but it’s not a core Azure service listed in the exam scope like Azure Functions are. DMS (D) is for migrating from other database systems to Azure, not for restructuring within Cosmos DB.

Strong consistency requires reads to be quorum-acknowledged across more replicas to guarantee the most recent committed write is returned. This increased coordination and latency results in a higher RU (Request Unit) cost compared to weaker consistency levels like Session or Eventual. Session consistency, which is the default, provides a good balance of performance, cost, and intuitive programming model for single-session guarantees.

Cosmos DB’s Time to Live (TTL) feature allows automatic deletion of items after a specified number of seconds. Setting TTL to 7 years (2555 days) meets the compliance requirement for retention. Crucially, TTL-deleted items are not charged, which minimizes cost for the online transactional store. The analytical store (B) is for analytical workloads, not for compliance archiving. Archiving to Blob (C) adds complexity and is not an automatic, native feature. Partition-level TTL (D) is not a standard Cosmos DB feature; TTL is set at the container or item level.

Multi-region writes are needed for low-latency writes from any region. Bounded Staleness (with a defined lag like 5 seconds) guarantees that reads are no more out-of-date than the configured lag period. This balances the requirement for low-latency, globally readable writes with the acceptance of brief staleness, avoiding the performance penalty of Strong consistency. Option A (Session) does not guarantee cross-region read-your-writes. Option B (Single write region) creates a write latency bottleneck. Option D (Eventual) offers no staleness guarantee.

A unique key constraint in the Core (SQL) API guarantees the uniqueness of the *combination* of values for the specified paths *across the entire container*, scoped within the partition key value. This is different from a partition key, which enforces uniqueness only within a logical partition. It is a powerful feature for enforcing data integrity, such as preventing duplicate user emails within a SaaS application’s tenant.

Azure Synapse Link provides a hybrid transactional/analytical processing (HTAP) architecture. It automatically syncs data from the Cosmos DB transactional store to a columnar analytical store. Querying this analytical store via Synapse Analytics (Spark or SQL) is highly performant for complex aggregations and does not consume any RUs from the operational container, making it very cost-effective. Running aggregations on the transactional store (A) is expensive in RUs. A materialized view (C) adds complexity and RU cost for maintenance. A nightly ETL to SQL DB (D) introduces latency and management overhead.

Partitioning by /sensorId ensures all readings for a specific device are collocated in the same logical partition. This is optimal because the query pattern targets a single sensor’s data over a time range. Partitioning by timestamp would scatter a single sensor’s data across all partitions, requiring a costly cross-partition query. Region or sensorType would group unrelated sensors together, not aligning with the access pattern.0