In Google Cloud IAM, what happens when a deny policy explicitly denies a permission that a user is also granted by an allow policy?
Think about which policy type has higher priority in IAM.
In Google Cloud IAM, deny policies always take precedence over allow policies. If a permission is denied explicitly, the user cannot perform that action even if an allow policy grants it.
Which of the following JSON snippets correctly defines an IAM deny policy that denies the permission storage.buckets.delete for all users on a Cloud Storage bucket?
Check that both deniedPermissions and deniedPrincipals are specified.
A valid deny rule must specify both the permissions to deny and the principals to deny them for. Option C correctly includes both.
You want to prevent all users except a specific admin group from deleting Compute Engine instances in a project. Which deny policy configuration achieves this?
Consider how to exclude a principal from a deny policy.
Deny policies support exceptions via exceptionPrincipals. Option D correctly denies the permission for all users except the admin group.
If a deny policy is set on a folder denying resourcemanager.projects.delete, what happens when a user tries to delete a project inside that folder, even if the project’s IAM policy allows it?
Think about how deny policies propagate in resource hierarchy.
Deny policies set on parent resources apply to all child resources. So denying a permission on a folder denies it on projects inside it regardless of project-level policies.
A user is a member of two groups: Group A and Group B. Group A’s allow policy grants storage.objects.create on a bucket. Group B’s deny policy denies storage.objects.create on the same bucket. What is the user’s effective permission?
Consider how deny policies affect users with multiple group memberships.
In IAM, deny policies always take precedence regardless of other allow policies, even if the user is granted permission by another group.