In IAM, access changes, such as granting a role or denying a permission, are eventually consistent. This means that it takes time for access changes through the system. In the meantime, recent access changes might not be effective everywhere. For example, principals might still be able to use a recently revoked role or a recently denied permission. Alternatively, they might not be able to use a recently granted role or a permission they were, until recently, denied from using.
The amount of time it takes for an access change to propagate depends on how you make the access change:
Method | Examples | Propagation time |
---|---|---|
Change a policy Change a principal's access by editing an allow or deny policy. When making policy changes, you can't exceed the limits on the number of principals allowed in a policy. |
|
Typically 2 minutes, potentially 7 minutes or longer |
Change a group's membership Change a principal's access by adding or removing them from a Google group that's included in an allow or deny policy. |
|
Typically several minutes, potentially hours or longer |
Change a nested group's membership Change a principal's access by adding or removing them from a nested group whose parent group is included in an allow or deny policy. |
|
Typically several minutes, potentially hours or longer |
Also keep in mind the following details for how group membership changes propagate:
- In general, adding a principal to a group propagates faster than removing a principal from a group.
- In general, group membership changes propagate faster than nested group membership changes.
You can use these propagation time estimates to inform the way you modify your principals' access.