AZ-305 Design data storage solutions Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Store large binary data (e.g., images) directly as documents

  Why it's wrong here

  Storing large binary data such as images directly as Azure Cosmos DB documents is a common anti-pattern because each document has a hard 2 MB size limit, and any binary payload inflates RU consumption during writes and queries. The recommended pattern is to store binaries in Azure Blob Storage and maintain only a reference URL or metadata in Cosmos DB, keeping documents small and operation costs predictable.

• ✓

  Use the appropriate consistency level based on application requirements

  Why this is correct

  Choosing the appropriate consistency level for each application requirement is a core Cosmos DB design practice because consistency directly impacts throughput and latency. Strong consistency requires more RUs and may have higher latency across regions, while session, eventual, or bounded staleness can reduce cost and improve performance. This decision must be made deliberately: banking transactions need strong consistency, while IoT telemetry or product catalog reads can tolerate eventual consistency to save resources.

• ✓

  Choose a partition key that evenly distributes request units (RU) across partitions

  Why this is correct

  Selecting a partition key that provides even RU distribution is essential to avoid hot partitions where one logical partition receives a disproportionate share of traffic. Each logical partition has a 20 GB storage cap and all requests for a partition are served by a single physical partition, so a skewed key like status or region can throttle workloads. A proper key such as device ID, customer ID, or order ID spreads reads and writes across many logical partitions and maximizes aggregate throughput.

• ✓

  Enable autoscale on containers with unpredictable traffic patterns

  Why this is correct

  Enabling autoscale on containers with unpredictable traffic patterns is a best practice because it allows Cosmos DB to automatically scale RU/s to the maximum required, avoiding manual provisioning errors and throttling (HTTP 429). Autoscale scales instantly within a range from 10% to 100% of the maximum RU/s, so you only pay for the capacity consumed intra-hour, making it cost-efficient for spiky workloads. For steady, predictable workloads manual throughput is often cheaper, but for variability autoscale prevents both over- and under-provisioning.

• ✗

  Use manual provisioned throughput for all containers to control costs

  Why it's wrong here

  Using manual provisioned throughput for all containers is not a best practice because it forces you to guess capacity: fixed RU/s causes throttling during spikes and wasted cost during idle periods. Manual throughput suits applications with stable, predictable demand, but for variable or unknown patterns autoscale automatically adjusts RU/s, maintains performance, and lowers overall cost. Additionally, manual provisioning across many containers requires continuous monitoring to update assigned RUs, which is operationally inefficient.

Go deeper

Related to this question