IAM Policy Troubleshooter
IAM Policy Troubleshooter
IAM Policy Troubleshooter answers one specific question: can this principal use this permission on this resource, and why. Rather than making you manually trace through every allow and deny policy attached to a resource and everything it inherits from its project, folder, and organization above it, the tool walks that entire chain for you and shows exactly which policy, at which level, produced the final answer.
This covers running a check, then what to actually do with a result that does not match what you expected.
Complete Process of IAM Policy Troubleshooter
Step One: Open Policy Troubleshooter
Open the console, then
Open Menu > IAM & Admin > Troubleshooter
Step 2: Enter the Principal, Resource, and Permission
Enter the email address of the principal you want to check, select the resource, and select the permission. Click Check Access.
Step 3: Review the Result
The tool shows whether that principal can use that permission on that resource, and which specific policy is responsible for the result.
Why the Result Might Surprise You: Deny Policies and Inheritance
Two things explain most results that do not match what you expected from looking at a role assignment alone.
- Inheritance, since an allow policy granted at the organization or folder level applies to every resource underneath it, not only the one it was set on directly. A principal can have access to a resource without any policy existing on that specific resource at all, because a parent level grant already covers it.
- Deny policies, which work the same way through inheritance, but always win over an allow policy. If a deny policy anywhere above a resource blocks a permission, a principal cannot use that permission on that resource, even if they hold a role that would otherwise grant it directly. This is by design, deny policies exist specifically to set a hard limit that an allow grant elsewhere cannot override.
When a result does not match what you expected, the troubleshooter’s explanation will point to the specific policy and the specific level in the hierarchy responsible, which is usually faster than guessing.
What You Need to See the Full Picture
Seeing every allow and deny policy that affects a result, including ones inherited from a parent organization or folder you do not have direct visibility into, generally requires the Security Reviewer role at the organization level. Without it, you may only see part of the picture for a resource whose access is partly controlled higher up the hierarchy than your own permissions reach.
Common Mistakes to Avoid
- Assuming a denied result means the role assignment itself is wrong. Check for an inherited deny policy first, since that overrides an allow grant regardless of how correctly the role was assigned.
- Checking a permission without the visibility to see policies inherited from a parent folder or organization. Request the Security Reviewer role if the result seems incomplete.
- Only checking the resource itself and ignoring that access can come from, or be blocked by, a policy set well above it in the hierarchy.
That covers using IAM Policy Troubleshooter properly, including the deny policies and inheritance behavior the original page never mentioned. To go further, explore Prwatech’s Google Cloud training program, which includes placement assistance.
