Bird
Raised Fist0
GCPcloud~3 mins

Access control (IAM vs ACLs) in GCP - When to Use Which

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
The Big Idea

What if one wrong key could unlock your entire cloud system? Learn how IAM and ACLs prevent that.

The Scenario

Imagine you have a big office building with many rooms. You want to decide who can enter each room. If you write down on paper who can enter each door and hand out keys manually, it quickly becomes confusing and hard to manage.

The Problem

Manually tracking who has access to each room means you can easily lose track, give wrong permissions, or forget to update when someone leaves. It's slow, mistakes happen, and security risks grow.

The Solution

Access control systems like IAM and ACLs let you manage permissions centrally and clearly. IAM lets you assign roles to people or groups, controlling what they can do across many resources. ACLs let you set specific permissions on individual items. Together, they make access safe, simple, and scalable.

Before vs After
Before
Give key to Alice for Room A
Give key to Bob for Room B
Write down permissions on paper
After
IAM: Assign 'Viewer' role to Alice
ACL: Set read permission for Bob on File X
What It Enables

With IAM and ACLs, you can easily control who can see or change your cloud resources, keeping your data safe and your team productive.

Real Life Example

A company uses IAM to let developers deploy apps but only lets finance team view billing info. ACLs control who can read or write specific files in cloud storage.

Key Takeaways

Manual access control is confusing and risky.

IAM and ACLs provide clear, centralized permission management.

They help keep cloud resources secure and easy to manage.

Practice

(1/5)
1. What is the main difference between IAM and ACLs in Google Cloud Platform?
easy
A. IAM and ACLs are exactly the same in functionality.
B. IAM controls network traffic, and ACLs control user passwords.
C. IAM is only for virtual machines, ACLs are for storage only.
D. IAM manages access at resource levels using roles, while ACLs manage access at object or bucket levels.

Solution

  1. Step 1: Understand IAM scope

    IAM controls access broadly by assigning roles to users or groups at resource levels like projects or services.
  2. Step 2: Understand ACL scope

    ACLs control access more narrowly, typically at the object or bucket level in storage services.
  3. Final Answer:

    IAM manages access at resource levels using roles, while ACLs manage access at object or bucket levels. -> Option D
  4. Quick Check:

    IAM = broad roles, ACLs = fine-grained object permissions [OK]
Hint: IAM is broad roles; ACLs are fine-grained permissions [OK]
Common Mistakes:
  • Confusing IAM with network controls
  • Thinking ACLs control passwords
  • Assuming IAM and ACLs are identical
2. Which of the following is the correct way to grant a user the role of 'Storage Object Viewer' using IAM in GCP?
easy
A. Edit the user's password in the IAM console.
B. Add the user to the ACL of the bucket with read permission.
C. Use the command: gcloud projects add-iam-policy-binding my-project --member='user:email@example.com' --role='roles/storage.objectViewer'
D. Create a firewall rule allowing the user access.

Solution

  1. Step 1: Identify IAM command syntax

    The correct gcloud command to grant IAM roles uses 'add-iam-policy-binding' with member and role flags.
  2. Step 2: Verify role and member format

    The role 'roles/storage.objectViewer' and member format 'user:email@example.com' are correct for granting read access to storage objects.
  3. Final Answer:

    Use the command: gcloud projects add-iam-policy-binding my-project --member='user:email@example.com' --role='roles/storage.objectViewer' -> Option C
  4. Quick Check:

    IAM role grant uses gcloud add-iam-policy-binding [OK]
Hint: Use gcloud add-iam-policy-binding with correct role and member [OK]
Common Mistakes:
  • Confusing ACL changes with IAM commands
  • Editing passwords instead of roles
  • Using firewall rules for access control
3. Given the following IAM policy snippet for a bucket, what access does the user 'user:alice@example.com' have?
{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": ["user:alice@example.com"]
    }
  ]
}
medium
A. Alice can only read objects in the bucket.
B. Alice can create, delete, and update objects in the bucket.
C. Alice has no access to the bucket.
D. Alice can manage IAM policies but not objects.

Solution

  1. Step 1: Identify the role assigned

    The role 'roles/storage.objectAdmin' allows full control over objects in the bucket, including create, delete, and update.
  2. Step 2: Confirm member access

    The member 'user:alice@example.com' is assigned this role, so Alice has these permissions.
  3. Final Answer:

    Alice can create, delete, and update objects in the bucket. -> Option B
  4. Quick Check:

    roles/storage.objectAdmin = full object control [OK]
Hint: objectAdmin role means full object permissions [OK]
Common Mistakes:
  • Confusing objectAdmin with read-only roles
  • Assuming no access without explicit bucket ACL
  • Mixing IAM roles with IAM policy management
4. You tried to grant a user access to a Cloud Storage bucket by adding them to the bucket's ACL, but they still cannot access the objects. What is the likely issue?
medium
A. The bucket has uniform bucket-level access enabled, which disables ACLs.
B. The user needs to restart their computer.
C. The user's email address was misspelled in the ACL.
D. The user was not granted an IAM role at the project level.

Solution

  1. Step 1: Understand uniform bucket-level access

    When uniform bucket-level access is enabled, ACLs are disabled and only IAM controls access.
  2. Step 2: Check ACL effect

    Adding users to ACLs has no effect if uniform bucket-level access is on, so the user cannot access objects despite ACL changes.
  3. Final Answer:

    The bucket has uniform bucket-level access enabled, which disables ACLs. -> Option A
  4. Quick Check:

    Uniform bucket-level access disables ACLs [OK]
Hint: Uniform bucket-level access disables ACLs [OK]
Common Mistakes:
  • Assuming ACLs always work regardless of bucket settings
  • Blaming user typos without verification
  • Thinking user restart affects cloud permissions
5. You want to allow a third-party service to read specific objects in your Cloud Storage bucket without giving it full project access. Which approach is best?
hard
A. Add the service account to the bucket's ACL with READER permission on specific objects.
B. Enable uniform bucket-level access and grant the service account the storage.admin role.
C. Grant the service an IAM role at the project level with storage.objectViewer permission.
D. Create a firewall rule to allow the service IP to access the bucket.

Solution

  1. Step 1: Understand access scope needs

    The third-party service needs access only to specific objects, not the whole project.
  2. Step 2: Choose fine-grained control method

    ACLs allow granting permissions on specific objects or buckets, ideal for limited access.
  3. Step 3: Evaluate other options

    IAM roles at project level are too broad; storage.admin is too powerful; firewall rules do not control storage access.
  4. Final Answer:

    Add the service account to the bucket's ACL with READER permission on specific objects. -> Option A
  5. Quick Check:

    Use ACLs for fine-grained object access [OK]
Hint: Use ACLs for specific object access, IAM for broad access [OK]
Common Mistakes:
  • Granting overly broad IAM roles
  • Confusing firewall rules with access control
  • Using storage.admin role unnecessarily