A slate-quarry timesheet system has many small Cosmos containers that are idle most of the day and one occasionally busy container. Where can provisioned throughput be set so idle containers can share RU/s?
Select an answer to reveal the explanation.
Short Explanation
Lots of quiet containers? Park shared RU/s at the database so they carpool. One hot container can still get its own dedicated throughput when it needs the fast lane.
Full Explanation
Cosmos DB provisioned throughput can be set at database scope so many containers share a pool of RU/s, or dedicated on an individual container that needs isolation. For a slate-quarry timesheet system with many mostly idle containers and one occasionally busy container, shared database throughput lets quiet containers carpool RU/s, while the hot container can receive dedicated RU/s when it must not starve or be starved by siblings.
Claiming throughput can only be configured on Azure Blob containers denies Cosmos’s own RU model. Purchasing RU/s exclusively through Azure Kubernetes Service node pools confuses compute scaling with Cosmos throughput provisioning. Saying provisioned throughput is available only when using Azure Table Storage APIs against Cosmos incorrectly ties RU configuration to a legacy API surface; throughput is a Cosmos account/database/container setting independent of that claim.
Exam caveat: you generally do not mix shared database throughput with per-container provisioned throughput on the same containers without understanding migration constraints—plan whether a container shares or is dedicated. Autoscale RU/s settings change max throughput behavior and cost. Operational check: provision shared RU/s at the database for the idle containers, optionally move the busy container to dedicated RU/s, generate load on the hot path, and confirm 429 rates and metrics show the expected isolation versus shared-pool contention.