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.