IAM policy binding in GCP - Commands & Configuration

Introduction

Sometimes you want to give someone or something permission to use your cloud resources. IAM policy binding lets you connect a user, group, or service to a specific role that defines what they can do.

When you want to let a teammate read data from a storage bucket without changing it

When you need to allow a service account to deploy applications on your cloud project

When you want to give a group of users admin access to a specific resource

When you want to remove access for a user who no longer needs it

When you want to audit who has what permissions on your cloud resources

Commands

This command adds a policy binding to the project 'example-project' giving the user [e-mail] the role to view storage objects. It connects the user to the permission role.

Terminal

gcloud projects add-iam-policy-binding example-project --member='user:[e-mail]' --role='roles/storage.objectViewer'

Expected Output

Updated IAM policy for project [example-project].

→

--member - Specifies the user, group, or service account to grant the role

→

--role - Specifies the role that defines the permissions

This command shows the current IAM policy for the project, so you can verify the binding was added.

Terminal

gcloud projects get-iam-policy example-project

Expected Output

bindings:

- members:

  - user:[e-mail]

  role: roles/storage.objectViewer

etag: BwWWja0YfJA=

version: 1

This command removes the policy binding, taking away the permissions from the user.

Terminal

gcloud projects remove-iam-policy-binding example-project --member='user:[e-mail]' --role='roles/storage.objectViewer'

Expected Output

Updated IAM policy for project [example-project].

→

--member - Specifies the user or entity to remove from the role

→

--role - Specifies the role to remove from the member

Key Concept

If you remember nothing else from this pattern, remember: IAM policy binding connects a user or service to a role that grants specific permissions on cloud resources.

Common Mistakes

Using the wrong member format like just the email without 'user:' prefix

The command expects the member type prefix (user:, group:, serviceAccount:) to identify the entity correctly.

Always include the member type prefix, for example 'user:[e-mail]'.

Trying to add a role that does not exist or is misspelled

The command will fail because the role must be a valid predefined or custom role in GCP.

Check the exact role name in GCP documentation or use 'gcloud iam roles list' to find valid roles.

Not verifying the policy after adding or removing bindings

You might think the change worked but it did not apply, leading to unexpected access issues.

Always run 'gcloud projects get-iam-policy' to confirm your changes.

Summary

Use 'gcloud projects add-iam-policy-binding' to grant permissions by connecting members to roles.

Verify changes with 'gcloud projects get-iam-policy' to see current bindings.

Remove permissions with 'gcloud projects remove-iam-policy-binding' when access is no longer needed.

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