AZ-204 · Question #205
Drag and Drop Question You are developing a solution for a hospital to support the following use cases: - The most recent patient status details must be retrieved even if multiple users in different…
The correct answer is Strong; Bounded Staleness; Eventual. Azure Cosmos DB Consistency Levels - Exam Explanation Background: The Five Levels (Strongest -> Weakest) | Level | Guarantee | |---|---| | Strong | Always reads the most recent committed write (linearizable) | | Bounded Staleness | Reads lag writes by at most K versions or T…
Question
Exhibit
Answer Area
Drag items
Correct arrangement
- Strong
- Bounded Staleness
- Eventual
Explanation
Azure Cosmos DB Consistency Levels - Exam Explanation
Background: The Five Levels (Strongest -> Weakest)
| Level | Guarantee |
|---|---|
| Strong | Always reads the most recent committed write (linearizable) |
| Bounded Staleness | Reads lag writes by at most K versions or T seconds |
| Session | Consistent within a single client session |
| Consistent Prefix | Reads never see out-of-order writes, but can lag arbitrarily |
| Eventual | No ordering guarantee; eventually converges to latest |
The account default is Strong, but the task is to override per query using the weakest level that still satisfies each requirement - because the question explicitly asks to minimize latency and availability impact.
Placement Explanations
1. Most recent patient status - multiple users, different locations -> Strong
This is the only level that guarantees linearizability - every read reflects the most recently committed write, regardless of which region performed the update. No weaker level can promise "most recent" in a multi-writer distributed scenario. This matches the account default, so no override is technically needed, but it is the correct answer.
2. Health monitoring data - current or prior version -> Bounded Staleness
"Current or prior version" signals you can tolerate being slightly behind, but not arbitrarily stale. Bounded Staleness lets you configure a maximum staleness window (e.g., K=1 version behind). This directly maps to "current or the prior version" while still providing a defined bound. Consistent Prefix is a common wrong answer here - it also prevents out-of-order reads but places no bound on how far behind the data can be, which is weaker than required.
3. Final billing record after discharge -> Eventual
Once a patient is discharged and all charges are assessed, the record is frozen - no further writes occur. Because the data is static, even the weakest consistency level will eventually return the correct final record. Eventual consistency provides the lowest latency and highest availability, directly satisfying the "minimize latency and availability impact" constraint. Using anything stronger here wastes resources unnecessarily.
Common Mistakes
- Using Strong for everything - satisfies correctness but violates the "minimize latency/availability impact" requirement.
- Choosing Consistent Prefix for use case 2 - it prevents out-of-order reads but doesn't bound staleness, so "prior version" could be arbitrarily old.
- Choosing Session for use case 1 - Session only guarantees consistency within one client session, not across multiple users in different locations.
- Not recognizing the "frozen data" signal - when a record is finalized and immutable, Eventual is always the right answer for latency optimization.
Topics
Community Discussion
No community discussion yet for this question.