A peat-bog research kiosk writes a sample id to Cosmos DB and must immediately read that same committed value from another region for a printed label. Which consistency level should the developer choose?

A peat-bog research kiosk that writes a sample id to Cosmos DB and must immediately read that same committed value from another region for a printed label needs Strong consistency. Strong provides linearizability: after a write commits, a subsequent read configured under Strong returns that latest committed value rather than a stale replica view. That is the guarantee when a printed label must match what just landed in the write path across the regions that participate in the Strong configuration.

Eventual consistency can lag arbitrarily; choosing it because cross-region reads might cost fewer RUs trades correctness for cheapness and can print yesterday’s sample id. Consistent prefix focuses on ordered visibility of writes (especially transactional batches), not on guaranteeing that every single-item write is immediately visible across regions the way Strong does. Session consistency depends on presenting a session token for read-your-writes within one client session; claiming every region shares one automatic token without carrying session state is incorrect and will not deliver Strong-like cross-region immediacy.

Exam caveat: Strong consistency is incompatible with multi-region write accounts. If the peat-bog account enables multiple write regions, you cannot keep Strong; redesign for a single write region or accept a weaker level.

Operational check: after setting Strong, run a write in the write region and an immediate read from the remote region used by the label printer, assert the ids match, and verify the account is not configured for multi-region writes while Strong remains selected.