A brine-works municipal payroll replica may lag behind the write region, but never by more than two minutes or five versions. Which Cosmos consistency level matches that requirement?
Select an answer to reveal the explanation.
Short Explanation
Lag is fine—unbounded lag is not. Bounded staleness is the “never more than K versions or T time” dial. That matches a two-minute / five-version payroll replica ceiling.
Full Explanation
A brine-works municipal payroll replica that may lag the write region but never by more than two minutes or five versions maps directly to Bounded staleness. That level’s contract is an upper bound on lag expressed as at most K versions or T time. Here K=5 and T=two minutes give operations a concrete staleness ceiling while still allowing asynchronous replication within that window.
Eventual accepts unbounded lag, so “any lag is fine” fails a requirement that hard-caps staleness. Session consistency scopes guarantees to a client session via session tokens; those tokens do not enforce a global two-minute window for all readers of the payroll replica. Consistent prefix preserves order for transactional batch visibility but does not define the K-or-T lag budget described in the stem, and it does not wait for Strong quorum on every read.
Exam caveat: Bounded staleness still sits below Strong on the consistency ladder. Within the allowed K/T window, readers can see slightly older data; if the payroll printout must never miss the latest committed write across regions, Strong (with its multi-region-write restriction) is the different skill.
Operational check: set the account (or request) to Bounded staleness with K=5 and T=120 seconds, generate a burst of payroll writes, and measure remote-region read lag to confirm it stays inside the configured bound under load.