How to share a Cosmos DB session token between App1 nodes?

AZ-204 By islever Editorial Last updated

Develop solutions that use Azure Cosmos DB

Short answer

B RequestOptions is the object to set the session token for reads and writes so multiple App1 nodes share the same Cosmos DB session.

Question

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?
  1. Document response
  2. Request options Correct Answer
  3. Feed options
  4. Connection policy

Key Takeaways

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.

Common mistake: 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.

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

These links open the official vendor documentation in a new tab.

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.

More AZ-204 FAQ →

Community Votes

B
78%
A
22%

78% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 6 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 6

  1. examtopicsLogin123 👍 3 Answered B
    In .NET SDK V2 it is: RequestOptions.SessionToken in .NET SDK V3 it is: ItemRequestOptions.SessionToken "If you wanted these nodes to participate in the same session ... you would have to send the SessionToken from FeedResponse<T> of the write action to the end-user ... to the CosmosClient for subsequent reads." "To manage session tokens manually, get the session token from the response and set them per request." https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/how-to-manage-consistency#utilize-session-tokens FeedOptions also have the SessionToken property https://learn.microsoft.com/en-us/dotnet/api/microsoft.azure.documents.client.feedoptions.sessiontoken
  2. overhill 👍 3
    For me it is Request Options the object we have to set with the session token example here: https://learn.microsoft.com/en-us/dotnet/api/microsoft.azure.documents.client.requestoptions.sessiontoken?view=azure-dotnet
  3. czegi90 👍 2 Answered B
    https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/how-to-manage-consistency?tabs=portal%2Cdotnetv2%2Capi-async#utilize-session-tokens
  4. passme847 👍 2 Answered A
    https://learn.microsoft.com/en-us/dotnet/api/microsoft.azure.documents.client.requestoptions.sessiontoken?view=azure-dotnet
  5. Vichu_1607 👍 1 Answered B
    B. Request options: The RequestOptions object allows you to specify options for individual requests, including the session token. By setting the session token in the RequestOptions, you can ensure that multiple nodes in your application share the same session token, thereby maintaining session consistency across those nodes.
Show 1 more comment
  1. Mattt 👍 1 Answered B
    B. Request option

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

How Do You Mitigate Azure Cache for Redis Maintenance Performance Issues?

S-grade

Azure Service Bus FIFO Processing Order

S-grade

How Do You Increase Read Cache in Azure Cache for Redis?

S-grade

Which Cosmos DB consistency level avoids out-of-order writes in multi-region reads?

S-grade

← Back to AZ-204 Study Guide