IAM policy binding in GCP - Step-by-Step Execution

Process Flow - IAM policy binding

Start: Define IAM Policy

↓

Add Binding: Role + Member

↓

Attach Policy to Resource

↓

Resource Enforces Permissions

↓

User Access Granted or Denied

This flow shows how an IAM policy is created, a role and member are bound, the policy is attached to a resource, and then permissions are enforced.

Execution Sample

GCP

resource = "projects/my-project"
policy = getIamPolicy(resource)
policy.bindings.append({"role": "roles/viewer", "members": ["user:[e-mail]"]})
setIamPolicy(resource, policy)

This code gets the current IAM policy for a project, adds a binding for a viewer role to a user, and updates the policy.

Process Table

Step	Action	Policy Bindings Before	Policy Bindings After	Result
1	Get current IAM policy	[]	[]	Policy fetched with no bindings
2	Add binding: roles/viewer to user:[e-mail]	[]	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]	Binding added to policy
3	Set updated IAM policy on resource	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]	Policy updated on resource
4	User alice tries to access resource	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]	Access granted based on binding
5	User bob tries to access resource	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]	Access denied, no binding for bob

💡 Execution stops after policy is updated and access is enforced based on bindings.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
policy.bindings	[]	[]	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]	[{"role": "roles/viewer", "members": ["user:[e-mail]"]}]

Key Moments - 3 Insights

Why does user bob get denied access even though the policy has a binding?

Because the binding only includes user [e-mail] as a member for the viewer role. Bob is not listed in any binding (see execution_table step 5).

What happens if you add the same role with the same member twice?

The policy bindings list will have duplicate entries, but GCP treats them as one effective permission. However, best practice is to avoid duplicates (see execution_table step 2).

Why do we need to fetch the current policy before adding a binding?

Because IAM policies are full sets of bindings. You must get the current policy, modify it, then set it back to avoid overwriting existing bindings (see execution_table step 1 and 3).

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what is the policy.bindings after adding the binding?

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

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

C []

D null

💡 Hint

Check the 'Policy Bindings After' column at step 2 in the execution_table.

At which step does the user alice get access granted?

A Step 1

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Result' column for user alice's access in the execution_table.

If we add user bob to the same role binding at step 2, how would the policy.bindings change?

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

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

C []

D null

💡 Hint

Consider how members list inside a binding updates when adding another user.

Concept Snapshot

IAM Policy Binding Quick Reference:
- IAM policy is a set of bindings.
- Each binding links a role to one or more members.
- To add a binding: fetch policy, add binding, update policy.
- Permissions are granted if user is in a binding for a role.
- Always avoid overwriting existing bindings unintentionally.

Full Transcript

IAM policy binding in Google Cloud means connecting a role to users or groups so they get permissions. The process starts by getting the current policy of a resource. Then you add a binding that says, for example, 'user [e-mail] has viewer role.' After updating the policy on the resource, when alice tries to access, she is allowed because of the binding. Others not listed, like bob, are denied. It's important to fetch the current policy before adding bindings to avoid losing existing permissions. Bindings are lists of roles and members. Adding the same member twice is redundant but allowed. This visual trace shows each step and how the policy changes, helping beginners understand how access control works in GCP.

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