---
name: Microsoft Graph CA policy reads are eventually consistent (~5s)
description: After PATCHing a CA policy (204 No Content), an immediate GET may return stale state. Wait ~5 seconds before verifying.
type: feedback
---

When PATCHing `/identity/conditionalAccess/policies/{id}` and immediately re-reading via GET, the read may return pre-PATCH state for a few seconds even though the PATCH was accepted (204).

Observed 2026-04-29 during the Cascades admin@ exclusion backfill: 7 of 8 PATCHes returned 204, but immediate verify GETs showed the old `excludeUsers` list. Re-query after `sleep 5` showed all 8 had landed correctly. No retries were needed — the PATCH had succeeded; only the read lagged.

**Why:** Microsoft Graph fronts CA policy reads through a regional cache that doesn't immediately reflect writes. Writes hit the authoritative store and return 204 right away. Reads converge after a short propagation window.

**How to apply:**
- After a CA policy PATCH that returns 204, do not treat an immediate "verify mismatch" as failure.
- Insert `sleep 3-5` (or a poll loop with a few seconds of backoff) before the verify GET.
- If verifying many policies in a batch, the simplest pattern is: do all PATCHes, sleep 5, then re-query everything once at the end.
- This applies to CA policies specifically. Other Graph endpoints (e.g., users, groups) have their own consistency characteristics — don't generalize.