IAM deny policies in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the effect of an IAM deny policy

In Google Cloud IAM, what happens when a deny policy explicitly denies a permission that a user is also granted by an allow policy?

A The deny policy overrides the allow policy, so the user is denied the permission.

B The allow policy overrides the deny policy, so the user is allowed the permission.

C The user is allowed the permission only if the deny policy is attached to a different resource.

D The deny policy and allow policy cancel each other out, so the user’s access depends on other policies.

💡 Hint

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.

❓ Configuration

intermediate

Identifying the correct deny policy syntax

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?

A

{
  "denyRules": [
    {
      "deniedPermissions": ["storage.buckets.delete"]
    }
  ]
}

B

{
  "bindings": [
    {
      "role": "roles/storage.admin",
      "members": ["allUsers"]
    }
  ]
}

C

{
  "denyRules": [
    {
      "deniedPermissions": ["storage.buckets.delete"],
      "deniedPrincipals": ["allUsers"]
    }
  ]
}

D

{
  "denyRules": [
    {
      "deniedPrincipals": ["allUsers"]
    }
  ]
}

💡 Hint

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.

❓ Architecture

advanced

Designing a deny policy for sensitive operations

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?

A Allow only the admin group the permission <code>compute.instances.delete</code> and do not create any deny policy.

B Deny all users the permission <code>compute.instances.delete</code> except the admin group by specifying <code>deniedPrincipals</code> as <code>allUsers</code> and excluding the admin group.

C Create a deny policy denying <code>compute.instances.delete</code> for <code>allUsers</code> and then create an allow policy granting the admin group the same permission.

D Create a deny policy denying <code>compute.instances.delete</code> for <code>allUsers</code> except the admin group by specifying <code>deniedPrincipals</code> as <code>allUsers</code> and adding the admin group to <code>exceptionPrincipals</code>.

💡 Hint

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.

❓ service_behavior

advanced

Effect of deny policies on inherited permissions

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?

A The user is denied deleting the project only if the deny policy is also set on the project itself.

B The user is denied deleting the project because deny policies on parent resources apply to child resources.

C The user can delete the project only if they have the Owner role on the project.

D The user can delete the project because the project’s IAM policy overrides the folder’s deny policy.

💡 Hint

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.

❓ security

expert

Analyzing a deny policy conflict scenario

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?

A The user is denied <code>storage.objects.create</code> because deny policies override allow policies.

B The user is allowed <code>storage.objects.create</code> because allow policies override deny policies.

C The user’s permission depends on which group’s policy was applied last.

D The user is allowed <code>storage.objects.create</code> only if they have an additional role granting it.

💡 Hint

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.

Practice

1. What is the main purpose of an IAM deny policy in Google Cloud?

easy

A. To monitor user activities without changing permissions

B. To grant additional permissions to users or groups

C. To explicitly block certain permissions even if other policies allow them

D. To automatically delete unused resources

Solution

1. Step 1: Understand IAM deny policy function and compare with other policy types

   An IAM deny policy explicitly blocks permissions, overriding any allow policies. Unlike allow policies that grant access, deny policies prevent actions even if allowed elsewhere.

2. Final Answer:

   To explicitly block certain permissions even if other policies allow them -> Option C

3. Quick Check:

   IAM deny policy blocks permissions [OK]

Hint: Deny policies block permissions regardless of other allows [OK]

Common Mistakes:

• Confusing deny policies with allow policies
• Thinking deny policies grant permissions
• Assuming deny policies only monitor actions

2. Which of the following is the correct way to specify a deny rule in an IAM policy JSON snippet?

easy

A. "denyRules": [{"deniedPermissions": ["storage.buckets.delete"]}]

B. "allowRules": [{"allowedPermissions": ["storage.buckets.delete"]}]

C. "denyRules": [{"allowedPermissions": ["storage.buckets.delete"]}]

D. "denyRules": [{"deniedPermissions": "storage.buckets.delete"}]

Solution

1. Step 1: Identify correct deny rule syntax and check each option

   Deny rules use "denyRules" with "deniedPermissions" as a list of strings. "denyRules": [{"deniedPermissions": ["storage.buckets.delete"]}] correctly uses a list for "deniedPermissions". "allowRules": [{"allowedPermissions": ["storage.buckets.delete"]}] uses allowRules, which is incorrect. "denyRules": [{"allowedPermissions": ["storage.buckets.delete"]}] mixes denyRules with allowedPermissions, which is invalid. "denyRules": [{"deniedPermissions": "storage.buckets.delete"}] uses a string instead of a list, which is invalid.

2. Final Answer:

   "denyRules": [{"deniedPermissions": ["storage.buckets.delete"]}] -> Option A

3. Quick Check:

   Deny rules need deniedPermissions as list [OK]

Hint: Deny permissions must be in a list under deniedPermissions [OK]

Common Mistakes:

• Using allowRules instead of denyRules
• Providing deniedPermissions as a string instead of list
• Mixing allowedPermissions inside denyRules

3. Given this deny policy snippet:

{"denyRules": [{"deniedPermissions": ["compute.instances.start"]}]}

What happens if a user has an allow policy for compute.instances.start but this deny policy is applied?

medium

A. The user can start instances because allow policies override deny policies

B. The deny policy has no effect unless combined with a condition

C. The user can start instances only during business hours

D. The user cannot start instances because deny policies block the permission

Solution

1. Step 1: Understand deny policy precedence and apply to the example

   Deny policies always override allow policies for the specified permissions. Even if the user has an allow for starting instances, the deny rule blocks it.

2. Final Answer:

   The user cannot start instances because deny policies block the permission -> Option D

3. Quick Check:

   Deny overrides allow for blocked permissions [OK]

Hint: Deny always beats allow for the same permission [OK]

Common Mistakes:

• Thinking allow policies override deny policies
• Assuming deny policies need conditions to work
• Believing deny policies only log actions

4. You wrote this deny policy JSON but it does not block the intended permission:

{"denyRules": [{"deniedPermissions": "storage.objects.delete"}]}

What is the error?

medium

A. denyRules should be named allowRules

B. deniedPermissions should be a list, not a string

C. storage.objects.delete is not a valid permission

D. The policy must include a condition to work

Solution

1. Step 1: Check deniedPermissions data type and identify the error in the JSON

   deniedPermissions must be a list of strings, not a single string. The policy uses a string instead of a list, so it is invalid and won't block the permission.

2. Final Answer:

   deniedPermissions should be a list, not a string -> Option B

3. Quick Check:

   deniedPermissions requires a list [OK]

Hint: Use brackets [] for deniedPermissions list [OK]

Common Mistakes:

• Using string instead of list for deniedPermissions
• Confusing denyRules with allowRules
• Thinking conditions are mandatory

5. You want to deny the permission storage.buckets.delete only for requests made after 2024-01-01T00:00:00Z. Which IAM deny policy condition should you use?

hard

A. Use a condition with request.time > '2024-01-01T00:00:00Z'

B. Use a condition with resource.name == 'storage.buckets.delete'

C. No condition is needed; deny applies to all users

D. Use a condition with request.ip != 'company-network-ip-range'

Solution

1. Step 1: Identify the condition to restrict by time and match condition syntax

   To deny only for requests after the date, use a condition checking request.time > '2024-01-01T00:00:00Z'. Use a condition with request.time > '2024-01-01T00:00:00Z' uses request.time with inequality to apply after the date, which is correct.

2. Final Answer:

   Use a condition with request.time > '2024-01-01T00:00:00Z' -> Option A

3. Quick Check:

   Condition on request.time restricts deny by time [OK]

Hint: Use request.time condition to limit deny by time [OK]

Common Mistakes:

• Using resource.name instead of request.time for time check
• Using IP condition unrelated to time
• Applying deny without condition blocks all users