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 social networking application uses Azure Cosmos DB to store user posts. When a user publishes a new post, they immediately refresh their feed and expect to see their own post. However, the application can tolerate temporary staleness for posts from other users (e.g., a few seconds delay). Which Azure Cosmos DB consistency level should the application use for read operations that display the feed?
⚠ Common exam trap
A common mix-up: candidates confuse 'session' with 'eventual' because both allow staleness, but session guarantees per-user write-read consistency, which eventual does not, and they overlook that bounded staleness applies globally, not per-user.
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
✓
Session
Session consistency is the correct choice because it guarantees that the user who writes a post will read their own write within the same session, while allowing other users to see slightly stale data. This matches the requirement: the author immediately sees their new post, but the application can tolerate a few seconds of staleness for other users' posts. Session consistency uses a session token to ensure monotonic reads and writes for the same client, making it ideal for per-user feed scenarios.
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
Why it's wrong here
Strong consistency in Azure Cosmos DB provides linearizable reads by ensuring every read returns the most recently committed write across all regions, which requires synchronization with the write quorum before acknowledging a read. This guarantees absolute freshness but incurs significantly higher latency and RU/s costs because each read must wait for the latest commit timestamp. For a social networking scenario where only the user who posted needs to see their own post immediately, Strong is over-provisioned: it applies global ordering to all readers, not just the session owner, and sacrifices performance and availability unnecessarily. The requirement is specifically about satisfying the writer's read-your-writes expectation, not about enforcing a total order on every read, so Strong's strictness is more than what the application logically needs.
When this WOULD be correct
A banking application that processes financial transactions (e.g., account balance updates) where any read must reflect the latest write to prevent overdrafts or double-spending. The question would specify zero tolerance for staleness and require linearizability.
- ✗
Bounded staleness
Why it's wrong here
Bounded staleness allows reads to lag behind writes by a configurable time interval or number of versions. While it could work, it is a stricter guarantee than needed (the application only needs session-level consistency) and may have higher latency than session consistency.
When this WOULD be correct
An application requires that all reads see the same latest write within a defined time window (e.g., 5 seconds) or after a certain number of operations, but does not need immediate consistency for any specific user. For example, a stock ticker that must show prices updated within 2 seconds across all clients.
- ✓
Session
Why this is correct
Session consistency uses a session token to ensure that within the same client session, reads reflect the writes made by that client. This satisfies the requirement that the user sees their own post immediately, while other reads may see slightly stale data.
- ✗
Eventual
Why it's wrong here
Eventual consistency does not guarantee that a user will read their own write immediately. There could be a delay, so the user might not see their own post right after publishing, which breaks the requirement.
When this WOULD be correct
Eventual consistency would be correct for a scenario where the application can tolerate temporary staleness for all reads, including the user's own writes, and high availability and low latency are prioritized over immediate consistency, such as in a global leaderboard that updates periodically.
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.
✓SessionCorrect answer▾
Why this is correct
Session consistency uses a session token to ensure that within the same client session, reads reflect the writes made by that client. This satisfies the requirement that the user sees their own post immediately, while other reads may see slightly stale data.
✗StrongWrong answer — click to see why▾
Why this is wrong here
Strong consistency would enforce immediate visibility for all users, but the application only needs the posting user to see their own post immediately. Strong consistency is overkill and would increase latency and reduce availability unnecessarily.
★ When this WOULD be the correct answer
A banking application that processes financial transactions (e.g., account balance updates) where any read must reflect the latest write to prevent overdrafts or double-spending. The question would specify zero tolerance for staleness and require linearizability.
Why candidates choose this
Candidates may think 'strong' is always the safest choice for consistency, overlooking that the application explicitly tolerates temporary staleness for other users' posts, making a weaker level sufficient.
✗Bounded stalenessWrong answer — click to see why▾
Why this is wrong here
Bounded staleness allows a configurable lag (time or operations), but the application requires that the user's own post is immediately visible after refresh. Session consistency guarantees monotonic reads for the same session, which matches the requirement of seeing one's own post immediately while tolerating staleness for others.
★ When this WOULD be the correct answer
An application requires that all reads see the same latest write within a defined time window (e.g., 5 seconds) or after a certain number of operations, but does not need immediate consistency for any specific user. For example, a stock ticker that must show prices updated within 2 seconds across all clients.
Why candidates choose this
Candidates may think 'bounded staleness' is a middle ground that offers some freshness guarantee, but they overlook that session consistency is specifically designed for per-user write-read consistency, which is the exact need here.
✗EventualWrong answer — click to see why▾
Why this is wrong here
Eventual consistency allows stale reads for any user, including the one who just posted, so the user might not see their own post immediately after refresh, which violates the requirement that the user must see their own post right away.
★ When this WOULD be the correct answer
Eventual consistency would be correct for a scenario where the application can tolerate temporary staleness for all reads, including the user's own writes, and high availability and low latency are prioritized over immediate consistency, such as in a global leaderboard that updates periodically.
Why candidates choose this
Candidates may choose Eventual because the question mentions tolerance for temporary staleness for other users' posts, but they overlook the critical requirement that the user must immediately see their own post, which Session consistency guarantees via read-your-writes.
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
Learn chapter
Data Roles and Core Concepts
Key term
Data
Data is raw, unprocessed information, like numbers, words, or measurements, that can be stored, processed, and analyzed by computers.
Key term
Consistency level
Consistency level is a setting in Azure data services that determines how quickly and accurately data is synchronized across multiple copies in a distributed system.
About these practice questions
One of 820 original DP-900 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.