docs: document entitlement lifecycle for role-scope bindings

product/admin/cloud-infrastructure-access.mdx

@@ -11,7 +11,7 @@
 
 ## The problem with flat access models in cloud environments
 
 In a SaaS app, access is a finite list: "Salesforce Admin," "Jira Reporter on Project X." You can sync every entitlement upfront and review them all in a campaign.
 
 Consider two real requests: a developer who needs Contributor access on one resource group for a four-hour deploy, and an AI agent that needs read access to a single Key Vault for one pipeline run. In a governance tool that flattens cloud entitlements into a list of identical-looking rows, neither request can be expressed precisely. The tool grants Contributor on the subscription, Reader on the management group. The blast radius of every grant grows because the tool can't express anything narrower.
 
@@ -20,7 +20,7 @@
 Representing this as a flat list causes real problems:
 
 - **Sync failures and database bloat** from trying to materialize every combination
 - **Unusable UIs** where end users and reviewers face thousands of identical-looking entries with no hierarchy context
 - **Rubber-stamp access reviews** where reviewers bulk-approve because the volume is unmanageable
 - **Governance blind spots** from workarounds that restrict which resources get synced
 
@@ -50,4 +50,18 @@
 
 **Provisioning** — C1 grants and revokes access at the specific scope it was requested or assigned, not at a flat entitlement level.
 
+## Entitlements come and go with grants
+
+A role-scope binding only exists as an entitlement while it has at least one active grant. Cloud infrastructure connectors like Azure only report role-scope combinations that currently have someone assigned, so C1 doesn't sync a role-scope pair that no one holds. When the last grant on a binding is removed, the entitlement disappears; when someone is granted that same role at that same scope again, C1 creates it again.
+
+This has two practical implications:
+
+1. **Don't set a maximum grant duration directly on one of these entitlements.** If it gets deleted and recreated while no one holds it, a duration set on the old row doesn't carry over. Use [entitlement configuration rules](/product/admin/entitlement-config-rules) instead: a rule that matches on role and scope applies its maximum duration to every matching entitlement, including ones created after you save the rule.
+
+2. **Be cautious referencing one of these entitlements by ID** — for example, from an access profile or from Terraform.
+
+   <Note>
+   Whether a recreated entitlement gets its original ID back depends on a tenant setting called entitlement resurrection, which is on by default for new C1 tenants. If your tenant predates that default, or you're not sure, ask C1 Support to confirm it's enabled.
+   </Note>
+