AI-200 practice: Optimize query performance and Request Units (RUs) consumption by using indexing policies and consistency levels

Question 1

A Cosmos DB for NoSQL container storing chat-session documents uses sessionId as the partition key. As the app scales, most reads and writes concentrate on a small number of very active sessions, creating hot partitions, while an indexing policy that indexes every property is also driving up write RU cost.

What should you do to address both issues?

Accepted Answer

Use a higher-cardinality synthetic partition key for even access distribution, and narrow the indexing policy to only paths used by actual queries

Answer

Increase provisioned throughput (RU/s) on the container until hot-partition throttling stops, leaving partition key and indexing unchanged

Answer

Collapse all session documents into a single logical partition so query patterns stay simple, then scale compute on the application tier

Answer

Enable a short TTL on every item so older session data expires quickly, assuming reduced item count alone will eliminate hot partitions

Question 2

A globally distributed Cosmos DB account, replicated across three regions, backs an AI recommendation service. The team wants reads within a single client session to always reflect that client's own most recent writes, while keeping cross-region read latency low. They accept that a read from a different session might briefly lag behind a very recent write made by another session.

Which consistency level best fits this requirement?

Accepted Answer

Session consistency, which guarantees read-your-own-writes within a client session at low latency while other sessions may briefly see stale data

Answer

Strong consistency, which guarantees every read in every region always reflects the most recent committed write across the entire account

Answer

Eventual consistency, which allows reads to return any previously written value with no session affinity or ordering guarantees for client sessions

Answer

Consistent prefix, which ensures clients never observe out-of-order writes but does not guarantee a session always sees its own latest writes

Question 3

You provision a Cosmos DB container for a RAG application using the Python SDK:
```python
from azure.cosmos import CosmosClient, PartitionKey

client = CosmosClient(url, credential=key)
database = client.create_database_if_not_exists(id="ragdb")
container = database.create_container_if_not_exists(
    id="documents",
    partition_key=PartitionKey(path="/tenantId"),
    offer_throughput=400
)
```
Six months later, a single large tenant accounts for 90% of all reads and writes, and RU consumption spikes cause 429 errors only for that tenant's operations. What is the underlying issue and best long-term fix?

Accepted Answer

The container has a hot partition because /tenantId concentrates that tenant's data and RU load on a single logical partition; introduce a synthetic partition key (e.g., /tenantId_documentType) or hierarchical partition key.

Answer

Increase offer_throughput to a very high fixed RU/s value; this alone permanently fixes hot partition issues regardless of key design.

Answer

Switch the container to serverless mode, which automatically eliminates hot partitions.

Answer

The issue is unrelated to partitioning; it is caused by the SDK not using connection pooling.

Question 4

You define an indexing policy to optimize RU cost for a container where most queries filter on `/status` and `/category`, but the application never queries on the large `/rawPayload` field:
```json
{
  "indexingMode": "consistent",
  "automatic": true,
  "includedPaths": [
    { "path": "/*" }
  ],
  "excludedPaths": [
    { "path": "/_etag/?" }
  ]
}
```
RU cost for writes is unexpectedly high. What change best reduces write RU cost while preserving query performance on `/status` and `/category`?

Accepted Answer

Add /rawPayload/* to excludedPaths while keeping /* included (or explicitly include only /status/? and /category/? in includedPaths and exclude /*).

Answer

Set indexingMode to "none" to disable indexing entirely, then manually re-enable it before each query.

Answer

Change indexingMode to "lazy" so indexing happens in the background.

Answer

Add a composite index on (/status, /category, /rawPayload).

Question 5

Your application frequently runs this query and needs it to be RU-efficient:
```sql
SELECT c.orderId, c.total
FROM c
WHERE c.status = "shipped"
ORDER BY c.shippedDate DESC
```
The query works but consumes far more RU than expected, and diagnostics show it is doing a full scan with in-memory sort. What indexing policy addition resolves this?

Accepted Answer

Add a composite index covering (/status ASC, /shippedDate DESC) so the engine can filter and sort using a single index without an in-memory sort.

Answer

Add a range index on /shippedDate/?; range indexes alone are sufficient for any ORDER BY.

Answer

Add a spatial index on /shippedDate/?.

Answer

Add /status/? and /shippedDate/? as two separate single-property range indexes; Cosmos DB automatically combines any two range indexes to satisfy filter+sort queries.

Question 6

A Cosmos DB for NoSQL container is consuming far more RUs than expected for point reads on a well-chosen partition key. What is the most likely cause?

Accepted Answer

Indexing unused properties, raising RU cost

Answer

Partition key that is overly selective

Answer

Default consistency set to Strong level

Answer

Account using NoSQL instead of Table API

Question 7

Your globally distributed AI application reads from Cosmos DB for NoSQL and can tolerate slightly stale data in exchange for the lowest possible read latency and highest availability. Which consistency level should you choose?

Accepted Answer

Eventual or Session consistency level

Answer

Strong consistency across all regions

Answer

Bounded Staleness with zero staleness

Answer

No latency trade-off exists in Cosmos DB

Question 8

Your application performs frequent single-item lookups by a known 'userId' in Cosmos DB for NoSQL. To minimize RU cost, what should the partition key be?

Accepted Answer

userId matching the dominant lookup pattern

Answer

Constant fixed value shared by every document

Answer

Random GUID unrelated to any query pattern

Answer

Creation date alone as the sole partition key

Question 9

Which statement about Request Units (RUs) in Azure Cosmos DB for NoSQL is correct?

Accepted Answer

RU cost varies with size, indexing, query, consistency

Answer

RU cost is fixed regardless of size or complexity

Answer

RUs apply only to writes and never to any reads

Answer

RUs matter only when using the Table API alone

Question 10

An AI application must guarantee that within a single client session, a user always sees their own writes to Cosmos DB for NoSQL immediately, while allowing other users to see slightly stale data for lower latency. Which consistency level fits best?

Accepted Answer

Session consistency

Answer

Eventual consistency

Answer

Strong consistency

Answer

Consistent Prefix

11 questions