IAM policy binding in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

What happens when you bind a role to a user in an IAM policy?

You add a binding in an IAM policy that assigns the role roles/storage.objectViewer to a user. What is the immediate effect on that user's permissions?

A The user can read objects in the specified Cloud Storage bucket immediately.

B The user can create new buckets in the project immediately.

C The user can delete any object in the project immediately.

D The user can modify IAM policies on the project immediately.

💡 Hint

Think about what the roles/storage.objectViewer role allows.

The roles/storage.objectViewer role grants read access to objects in Cloud Storage buckets. It does not allow creating buckets, deleting objects, or modifying IAM policies.

🧠 Conceptual

intermediate

Which statement about IAM policy bindings is true?

Consider the following statements about IAM policy bindings. Which one is correct?

A A binding can assign multiple roles to a single member in one entry.

B A binding can assign roles only at the project level, not at resource level.

C A binding can only assign roles to service accounts, not users.

D A binding assigns one role to one or more members in one entry.

💡 Hint

Think about the structure of an IAM policy binding.

Each binding assigns exactly one role to one or more members. Multiple roles require multiple bindings. Bindings can assign roles to users, groups, service accounts, and can be applied at various resource levels.

❓ security

advanced

What is the security risk of granting the role roles/owner in an IAM policy binding?

You bind the role roles/owner to a user on a project. What is the main security risk of this action?

A The user can only modify billing settings but not access resources.

B The user can only view resources but cannot make changes.

C The user can delete the entire project and all its resources.

D The user can only create new resources but cannot delete existing ones.

💡 Hint

Consider the permissions included in the roles/owner role.

The roles/owner role grants full control over all resources in the project, including deleting the project and all resources, which is a significant security risk if misused.

❓ Configuration

advanced

Which IAM policy binding JSON snippet correctly grants the role roles/editor to a group?

Identify the correct JSON snippet that binds the role roles/editor to the group [e-mail] on a project.

A

{
  "bindings": [
    {
      "role": "roles/editor",
      "members": ["group:[e-mail]"]
    }
  ]
}

B

{
  "bindings": [
    {
      "role": "roles/editor",
      "members": ["user:[e-mail]"]
    }
  ]
}

C

}
]  
}    
]"moc.elpmaxe@maet-ved:puorg"[ :"srebmem"      
,"rotide/selor" :"elor"      
{    
[ :"sgnidnib"  
{

D

{
  "bindings": [
    {
      "role": "roles/editor",
      "members": ["group:dev-team@example"]
    }
  ]
}

💡 Hint

Check the member type prefix and email spelling.

The correct member prefix for a group is group:. The email must be spelled correctly. Option A uses the correct prefix and email.

❓ Architecture

expert

How does IAM policy binding inheritance work across GCP resource hierarchy?

Given a role binding at the organization level, which statement best describes how it affects projects and resources below it?

A The binding applies only to the organization resource and not to any projects or resources below it.

B The binding applies to all projects and resources under the organization unless overridden by a deny policy.

C The binding applies only to projects explicitly listed in the binding.

D The binding applies only to resources created after the binding was set.

💡 Hint

Think about how IAM policies propagate in GCP's resource hierarchy.

IAM policies set at higher levels like organization or folder automatically apply to all child resources unless explicitly denied or overridden.

Practice

1. What does an IAM policy binding do in Google Cloud?

easy

A. It connects a role to one or more members to grant permissions.

B. It creates a new Google Cloud project.

C. It deletes user accounts from the organization.

D. It monitors network traffic between services.

Solution

1. Step 1: Understand IAM policy binding purpose

   An IAM policy binding links a role, which defines permissions, to members like users or service accounts.

2. Step 2: Identify correct function

   Only It connects a role to one or more members to grant permissions. describes this connection; other options describe unrelated actions.

3. Final Answer:

   It connects a role to one or more members to grant permissions. -> Option A

4. Quick Check:

   IAM binding = role + members [OK]

Hint: IAM binding links roles to members for permissions [OK]

Common Mistakes:

• Confusing IAM binding with project creation
• Thinking IAM binding deletes users
• Mixing IAM with network monitoring

2. Which of the following is the correct syntax snippet to bind a role to a user in a GCP IAM policy JSON?

easy

A. {"roles": "roles/viewer", "members": ["user:[e-mail]"]}

B. {"role": "roles/viewer", "member": "user:[e-mail]"}

C. {"role": "roles/viewer", "members": "user:[e-mail]"}

D. {"role": "roles/viewer", "members": ["user:[e-mail]"]}

Solution

1. Step 1: Check JSON key names

   The correct keys are 'role' and 'members'. 'members' must be a list even if one member.

2. Step 2: Validate member format

   Member must be inside a list with correct prefix like 'user:'. {"role": "roles/viewer", "members": ["user:[e-mail]"]} matches this exactly.

3. Final Answer:

   {"role": "roles/viewer", "members": ["user:[e-mail]"]} -> Option D

4. Quick Check:

   Role + members list = correct syntax [OK]

Hint: Members must be a list, even for one user [OK]

Common Mistakes:

• Using 'member' instead of 'members'
• Not using a list for members
• Swapping 'role' and 'roles' keys

3. Given this IAM policy snippet, which member has the 'roles/editor' role?

{
  "bindings": [
    {
      "role": "roles/viewer",
      "members": ["user:[e-mail]"]
    },
    {
      "role": "roles/editor",
      "members": ["serviceAccount:[e-mail]"]
    }
  ]
}

medium

A. user:[e-mail]

B. user:[e-mail]

C. serviceAccount:[e-mail]

D. group:[e-mail]

Solution

1. Step 1: Locate 'roles/editor' binding

   Look for the binding with role 'roles/editor' in the JSON; it has members list with one service account.

2. Step 2: Identify member with 'roles/editor'

   The member is 'serviceAccount:[e-mail]'. Other members have different roles.

3. Final Answer:

   serviceAccount:[e-mail] -> Option C

4. Quick Check:

   Editor role assigned to service account [OK]

Hint: Match role key to find correct member [OK]

Common Mistakes:

• Confusing roles/viewer with roles/editor
• Picking a member not listed under the role
• Ignoring service account prefix

4. You have this IAM policy JSON snippet:

{
  "bindings": [
    {
      "role": "roles/storage.admin",
      "members": "user:[e-mail]"
    }
  ]
}

What is wrong with this policy binding?

medium

A. The policy is missing a 'version' field.

B. The 'members' field should be a list, not a string.

C. The user email format is incorrect.

D. The 'role' field is misspelled.

Solution

1. Step 1: Check 'members' field type

   The 'members' field must be a list of strings, not a single string.

2. Step 2: Verify other fields

   'role' is correctly spelled, user email format is valid, and 'version' is optional.

3. Final Answer:

   The 'members' field should be a list, not a string. -> Option B

4. Quick Check:

   Members must be a list [OK]

Hint: Members always need square brackets [] [OK]

Common Mistakes:

• Using string instead of list for members
• Assuming 'version' is mandatory
• Mistaking email format as error

5. You want to grant the 'roles/logging.logWriter' role to all users in your organization except external users. Which IAM policy binding approach is best?

hard

A. Bind 'roles/logging.logWriter' to 'domain:yourcompany.com' member.

B. Bind 'roles/logging.logWriter' to 'allAuthenticatedUsers' member.

C. Bind 'roles/logging.logWriter' to 'allUsers' member.

D. Bind 'roles/logging.logWriter' to 'user:[e-mail]' member.

Solution

1. Step 1: Understand member types

   'allUsers' includes everyone, including external; 'allAuthenticatedUsers' includes any signed-in Google user; 'domain:' restricts to your company domain.

2. Step 2: Choose member to exclude external users

   Using 'domain:yourcompany.com' grants access only to users in your company domain, excluding external users.

3. Final Answer:

   Bind 'roles/logging.logWriter' to 'domain:yourcompany.com' member. -> Option A

4. Quick Check:

   Domain member limits to internal users [OK]

Hint: Use domain: to restrict to company users [OK]

Common Mistakes:

• Using allUsers exposes to everyone
• Using allAuthenticatedUsers includes external Google accounts
• Binding to single external user misses others