Develop AI solutions by using Azure data management services practice questions

When both the id and the partition key are known, a point read is cheaper than any query.

read_item sends a direct request to the item's logical partition by id, so no query plan or index lookup is needed. Microsoft documents point reads as costing about 1 RU for a 1 KB item. A query with WHERE c.id = @id returns the same item but costs more because the query engine runs. A cross-partition query or a change feed read wastes even more RU.

1. Check what the app knows: the item id and the partition key value.
2. With both values, the item can be addressed directly without a query.
3. Choose the point read; reserve queries for lookups that need filters or several items.

Exam tip: Known id + partition key = read_item point read, the lowest-RU way to fetch one item.

query_items takes a parameters list of name/value dictionaries and a partition_key that scopes the query to one logical partition.

Two requirements decide the answer. Injection safety needs the value passed through parameters rather than concatenated into the SQL text. Single-partition execution needs partition_key set to the container's partition key value, here the user's ID. Only the keyed line does both: one distractor uses the wrong value for the partition key, one is unsafe, and one fans out across partitions.

1. Find the container's partition key path (/userId) and the value that matches it (user_id).
2. Pass request-supplied values through parameters, never string concatenation.
3. Set partition_key so the SDK sends the query to one logical partition.

Exam tip: Safe and cheap queries: bind values with parameters=[{name, value}] and scope with partition_key.

Index metrics (populate_index_metrics in Python) report utilised and potential indexed paths for a query.

In the Python SDK, passing populate_index_metrics=True to query_items makes the service return the x-ms-cosmos-index-utilization header, which lists utilised single and composite indexes and potential ones with an impact score. That is the input needed to change the indexing policy. Query metrics and the request charge describe cost and execution, not indexes, and request logs work at the operation level. Microsoft recommends enabling index metrics only while troubleshooting.

1. Identify the information needed: which indexes the query used and which could help.
2. Match it to the feature that reports utilised and potential indexes: index metrics.
3. Enable it on the query call and read the index utilisation header, then test the recommended paths.

Exam tip: Tuning an indexing policy for one query: enable index metrics and read the utilised and potential indexes.

By default every property is indexed, and each indexed property adds to the RU cost of every write.

The default policy includes /* so every path, including long text and nested objects, is indexed on each write. When the query patterns are known, include only the queried paths and exclude /* to cut write RU while keeping those queries indexed. Adding a composite index to the default policy adds index work on each write instead of removing it, consistency does not change write cost, and excluding the queried paths reverses the fix.

1. List the paths the queries filter and sort on.
2. Recognise that the default policy indexes every other path too, which raises write RU.
3. Include the queried paths and exclude the rest of the document.

Exam tip: Known query patterns: include only the paths you filter or sort on and exclude /* to cut write RU.

Vector indexes are defined separately from range indexing; the embedding path should be excluded from range indexing so writes don't index every array element.

With includedPaths /* the range index treats the embedding as an array and indexes every element, so each insert pays for 1,536 extra index entries. Microsoft's sample policies add the vector path (for example /embedding/*) to excludedPaths alongside the vectorIndexes entry. The diskANN index still serves VectorDistance queries. Changing the vector index type or data type leaves the range indexing in place, and removing the vector index makes queries expensive.

1. Notice that /* includes every path, including the embedding array.
2. Separate the two index structures: the range index (includedPaths) and the vector index (vectorIndexes).
3. Exclude the vector path from range indexing and keep the vector index for queries.

Exam tip: Always exclude the embedding path from includedPaths range indexing; the vector index is configured separately.

An ORDER BY on two or more properties needs a composite index whose path order and directions match the clause (or are its exact reverse).

Range indexes from /* can sort on one property, but a multi-property ORDER BY requires a composite index. The index must list the paths in the same order as the ORDER BY, and its directions must match the query or all be reversed. Only the keyed definition matches both the sequence (pinned, then updatedAt) and the directions (descending, descending).

1. Read the ORDER BY clause: pinned DESC, then updatedAt DESC.
2. Keep the path sequence identical in the composite index.
3. Match the directions, or reverse every one of them.

Exam tip: Composite index for ORDER BY: same path order, and same directions or all of them reversed.