Size a Google Cloud allow policy against the 1500-principal cap, the 250-group sub-limit and 300 custom roles per project.
Google Cloud caps the total principals in one allow policy at 1500, and separately caps how many of those may be groups at 250. Because policies inherit downward and cannot deny, the access that applies to a project is the union of its own policy with every ancestor policy. Hitting the principal cap breaks setIamPolicy for the whole resource, so a single over-populated project policy blocks every subsequent access change until someone refactors it into groups.
GCP IAM
utilisation = principals in the allow policy ÷ 1500, with a nested cap of 250 Google groups among those principals.
Inherited access
effective principals = principals bound here + principals inherited from ancestor folders and the organisation.
utilisation = principals in the allow policy ÷ 1500, with a nested cap of 250 Google groups among those principals. Google Cloud caps the total principals in one allow policy at 1500, and separately caps how many of those may be groups at 250. Because policies inherit downward and cannot deny, the access that applies to a project is the union of its own policy with every ancestor policy.
Hitting the principal cap breaks setIamPolicy for the whole resource, so a single over-populated project policy blocks every subsequent access change until someone refactors it into groups.
This calculator takes 5 inputs: Principals in the project allow policy, Of those, Google groups, Role bindings in the policy, Custom roles in the project, Principals inherited from folder and organisation. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Replace individual user bindings with Google group bindings, bind at folder or organisation level where the access is genuinely broad, remove bindings for deleted principals (they linger as deleted: entries), and use IAM Conditions so one binding covers cases that previously needed several.
Not with allow policies — they are purely additive, so a project cannot revoke what a folder granted. Restricting inherited access requires deny policies, which are evaluated before allow policies, or organisation policy constraints.