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.

• ✗

  Embed all fields in a single document and rely on automatic indexing

  Why it's wrong here

  Embedding all fields in a single document does not address the core problem: the `locale` field exists in only 30% of documents, so automatic indexing still indexes every document, including the 70% lacking that field, wasting throughput on irrelevant scans. This approach is tempting because denormalisation reduces joins and works well when most documents share the same fields, but here the sparse, optional nature of `locale` demands a filtered index or a partial index strategy to avoid indexing empty values.

• ✗

  Normalize the data by storing locale in a separate container and use cross-container queries

  Why it's wrong here

  Cross-container queries in Azure Cosmos DB require either writing multiple queries or using the change feed to replicate the locale into the main container, which increases RU costs, network latency, and operational complexity. Since Cosmos DB does not support native server-side joins across containers, this approach forces a client-side merge that defeats the purpose of an indexed seek and can result in full-partition scans on every container. This is an architecturally anti-pattern for a single-field filter that can be served by an index on the existing player container.

• ✗

  Define a fixed schema for all documents to ensure every document has the locale field

  Why it's wrong here

  Forcing a fixed schema by adding a nullable locale field to every document does not improve indexing performance, because Cosmos DB automatically indexes all fields by default, and null-valued fields are still stored in the index as 'undefined' entries (depending on the indexing path). This increases index size and write RU costs without making the existing 70% of documents any more selective for a `WHERE locale = 'cn'` query. The correct way to avoid indexing irrelevant values is to customize the indexing policy (e.g., exclude the `locale` path for documents that don't need it), not to pad documents with empty fields.

• ✓

  Create a composite index that includes the locale field

  Why this is correct

  A composite index that includes `locale` as the leading field (and optionally another field like `region` or `level`) directly supports a query that filters on `locale` by enabling an index seek instead of a full container scan. Because the index only contains entries for documents that actually have a `locale` property, the 70% of profiles that omit the field are automatically excluded from the index scan, drastically lowering request units (RU) and improving latency. This is the recommended and simplest optimization within Cosmos DB's schema-agnostic indexing model, and it does not require schema changes or data duplication.

Go deeper

Related to this question