Describe considerations for working with non-relational data on Azure →mediumMultiple ChoiceObjective-mapped
DP-900 Practice Question: Describe considerations for working with non-relational data on Azure
A global social media platform allows users to like posts. The platform is designed to prioritize availability and partition tolerance over strong consistency across its globally distributed Azure Cosmos DB instance. When a user likes a post, the like count may not be immediately visible to all users, but it will eventually become consistent across all regions. Which consistency model does this application follow?
⚠ Common exam trap
It's easy for candidates to confuse 'eventual consistency' with 'session consistency' because both involve delays, but session consistency is scoped to a single client session and provides stronger guarantees like monotonic reads, whereas eventual consistency has no such session-level guarantees and is the weakest model in Cosmos DB.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Eventual consistency
Eventual consistency is the correct choice because the platform prioritizes availability and partition tolerance (AP from the CAP theorem) over strong consistency. In Azure Cosmos DB, eventual consistency guarantees that all replicas will converge to the same value over time without any ordering guarantees, which matches the scenario where like counts are not immediately visible but become consistent eventually.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Strong consistency
Why it's wrong here
Strong consistency ensures that any read always returns the most recent write, regardless of region. This would make the like count immediately visible to all users, but it reduces availability and increases latency, which the platform explicitly wants to avoid.
When this WOULD be correct
A financial trading application requires that all users see the exact same account balance immediately after a transaction, even if it means lower availability during a partition. Strong consistency would be the correct choice.
- ✗
Bounded staleness consistency
Why it's wrong here
Bounded staleness consistency is a tunable consistency level, available in Azure Cosmos DB, that permits reads to lag behind writes by a defined time interval or a specified number of versions, after which reads are guaranteed to reflect the latest write. Unlike eventual consistency, it imposes a strict upper bound on how stale a read can be, requiring replicas to synchronize within that bound. The scenario describes a platform prioritizing low latency and high availability without any such bound, making this model unnecessarily restrictive and incorrect.
When this WOULD be correct
An application requires that all reads are within a configurable staleness window (e.g., 5 seconds or 10 updates) from the latest write, but can tolerate some delay. For example, a stock ticker showing prices that must be no older than 1 second.
- ✗
Session consistency
Why it's wrong here
Session consistency is scoped to a single client connection or session, offering guarantees such as read-your-writes, monotonic reads, and monotonic writes within that session. It ensures that a user immediately sees their own writes and that subsequent reads in the same session never regress to older versions. However, it provides no cross-session or cross-user guarantee, so other users' like counts can remain arbitrarily stale. The platform's requirement is global eventual convergence across all users and regions, not just a single user's session experience, making this option incorrect.
When this WOULD be correct
Session consistency would be correct for an application where a user updates their profile and expects to see their own changes immediately across devices, but other users may see stale data temporarily. For example, a user changes their display name and wants to see the update on their phone and laptop right away, while friends see the old name until the change propagates.
- ✓
Eventual consistency
Why this is correct
Eventual consistency is the weakest consistency level, prioritizing availability and low latency. It guarantees that if no new writes are made, all replicas will converge to the same state over time. This aligns with the platform's design goals.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The DP-900 exam frequently reuses these exact scenarios with slightly different constraints.
✓Eventual consistencyCorrect answer▾
Why this is correct
Eventual consistency is the weakest consistency level, prioritizing availability and low latency. It guarantees that if no new writes are made, all replicas will converge to the same state over time. This aligns with the platform's design goals.
✗Strong consistencyWrong answer — click to see why▾
Why this is wrong here
Strong consistency ensures that all reads reflect the most recent write, which contradicts the requirement for high availability and partition tolerance with eventual visibility of likes across regions.
★ When this WOULD be the correct answer
A financial trading application requires that all users see the exact same account balance immediately after a transaction, even if it means lower availability during a partition. Strong consistency would be the correct choice.
Why candidates choose this
Candidates may assume that any database operation should be strongly consistent by default, not realizing that Cosmos DB offers multiple consistency levels to balance consistency, availability, and performance.
✗Bounded staleness consistencyWrong answer — click to see why▾
Why this is wrong here
Bounded staleness guarantees that reads lag behind writes by at most a fixed number of versions or time interval, but the question explicitly states 'eventually become consistent' with no bounded lag, which is the definition of eventual consistency.
★ When this WOULD be the correct answer
An application requires that all reads are within a configurable staleness window (e.g., 5 seconds or 10 updates) from the latest write, but can tolerate some delay. For example, a stock ticker showing prices that must be no older than 1 second.
Why candidates choose this
Candidates may confuse 'bounded staleness' with 'eventual consistency' because both allow stale reads, but they overlook the 'bounded' constraint that limits the staleness, which is not present in eventual consistency.
✗Session consistencyWrong answer — click to see why▾
Why this is wrong here
Session consistency provides monotonic reads, writes, and read-your-writes guarantees within a single client session, but the question describes a scenario where consistency is relaxed across all users globally, not just within a session. The platform prioritizes availability and partition tolerance over strong consistency, which aligns with eventual consistency, not session consistency.
★ When this WOULD be the correct answer
Session consistency would be correct for an application where a user updates their profile and expects to see their own changes immediately across devices, but other users may see stale data temporarily. For example, a user changes their display name and wants to see the update on their phone and laptop right away, while friends see the old name until the change propagates.
Why candidates choose this
Candidates may confuse session consistency with eventual consistency because both allow temporary inconsistencies, but session consistency provides stronger guarantees within a session, which might seem like a middle ground. The phrase 'eventually become consistent' might be misinterpreted as session-based guarantees.
Analysis generated from the official DP-900blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
Courseiva writes every DP-900 question from scratch — 820 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DP-900 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-900 exam.