How to share a Cosmos DB session token between App1 nodes?
You manage an Azure Cosmos DB for a NoSQL API account named account1. The account contains a database named db1, which contains a container named container1. You configure account1 with a session consistency level. You plan to develop an application named App1 that will access container1. Individual instances of App1 must perform reads and writes. App1 must allow multiple nodes to participate in the same session. You need to configure an object to share the session token between the nodes. Which object should you use?
Community Votes
78% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests manual session token management for multi-node session consistency; the trap is confusing the response that contains the token (Document response) with the request object that carries it to subsequent operations (RequestOptions).
Azure Cosmos DB session consistency requires propagating the session token between client nodes when multiple instances must participate in the same session. This page establishes that RequestOptions is the correct object for sharing the session token during point reads and writes in App1.
Many learners choose Document response (A) because it is the source from which the session token is read after a write, but it is a read-only response object, not the configuration object used to pass the token on later requests.
Community Discussion (6 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Azure Cosmos DB session consistency guarantees read-your-writes and monotonic reads within a single session. To let multiple nodes in App1 participate in the same session, the session token returned by a write must be passed to subsequent read and write operations. In the.NET SDK, RequestOptions (v2) or ItemRequestOptions (v3) exposes a SessionToken property that allows the client to send the token with each request. Because App1 instances perform individual reads and writes, RequestOptions is the object that carries the session token for those point operations. Thus configuring RequestOptions.SessionToken on each node is how you share session state across nodes.Why the Other Options Are Wrong
Document response (A) is the response object that contains the session token from a completed operation; it is where you obtain the token, not where you set it to share. Feed options (C) is used for queries rather than individual reads and writes, and while it also has a SessionToken property, it does not serve point reads/writes required by App1. Connection policy (D) configures low-level connection behavior such as connection mode and retry options; it has no SessionToken property for propagating session state.Community Comment Notes
As examtopicsLogin123 noted, in.NET SDK v2 it is "RequestOptions.SessionToken" and in v3 it is "ItemRequestOptions.SessionToken", and you must send the session token from the write response to other nodes. overhill agreed it is Request Options and linked the RequestOptions.SessionToken API page. czegi90 provided the Microsoft how-to-manage-consistency link, which includes the "utilize session tokens" section confirming this pattern. passme847 voted A but linked the same RequestOptions.SessionToken page, which actually supports B, indicating a misread.Official Reference
Exam Strategy
For session token questions, focus on the object that sends the token on subsequent requests, not the response that receives it. Remember RequestOptions (or ItemRequestOptions in v3) for point operations and FeedOptions for queries; ConnectionPolicy never carries session state.
Frequently Asked Questions
Why is FeedOptions not the answer for App1's reads and writes?
FeedOptions is used for queries (e.g., CreateDocumentQuery) and also exposes SessionToken, but App1 requires point reads and writes, which use RequestOptions.
Can ConnectionPolicy be used to share a Cosmos DB session token?
No. ConnectionPolicy configures connection mode, retry, and timeout settings; it has no SessionToken property for session consistency.