DP-900 Practice Question: Describe considerations for working with non-relational data on Azure

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Switch to the Cassandra API

  Why it's wrong here

  Switching to the Cassandra API merely changes the wire protocol used to communicate with Azure Cosmos DB; the underlying engine and its Request Unit (RU) cost model remain unchanged. Every operation that is translated from Cassandra syntax into a Cosmos DB request still consumes RUs, and the protocol translation can even add slight overhead. Therefore, this change would not reduce RU consumption for a read-heavy product catalog, and it would require a costly application rewrite without solving the intended cost issue.

• ✗

  Create a composite index on frequently queried fields

  Why it's wrong here

  While a composite index on frequently queried fields can lower the RU cost of specific read queries by improving lookup efficiency, it introduces a hidden cost: every new index must be updated on every insert, update, or delete, which increases write RU consumption. In a product catalog with ongoing price or inventory updates, the added write overhead can offset any read savings, and it does not address the dominant cost of repeated reads. Increasing index coverage is not a direct way to reduce overall RU consumption, especially when the same query is run many times.

• ✓

  Enable the Azure Cosmos DB integrated cache

  Why this is correct

  Enabling the Azure Cosmos DB integrated cache allows repeated point-reads and queries to be served directly from an in-memory cache inside the dedicated gateway, completely bypassing the backend engine. Because cached responses return data without touching the storage engine, they consume 0 RUs, directly reducing RU consumption for repeated reads of product catalog items. The cache is fully managed, has a default 5-minute TTL, and requires no application code changes—only enabling the dedicated gateway. This is precisely the right approach for read-heavy workloads where the same data is frequently accessed.

• ✗

  Increase the provisioned RU/s

  Why it's wrong here

  Increasing the provisioned RU/s only raises the throughput ceiling of the container, meaning you pay for more RU capacity per second, regardless of whether it is actually used. It does not change the number of RUs consumed by each individual request—it merely allows more requests to pass without being throttled. If the goal is to reduce RU consumption, adding capacity increases costs and fails to optimize the root cause; you would still be paying for every read, whereas caching or query optimization can lower per-request RU usage.

Go deeper

Related to this question