A user is an individual person’s account. A group is a Google Group that contains multiple users; you assign IAM roles to the group email so membership changes automatically update access.

The broad, legacy roles `roles/viewer`, `roles/editor`, and `roles/owner`. They apply across most services in a project and are not aligned with least privilege.

Google-managed roles tailored to specific services or job functions (for example, `roles/storage.objectViewer`). Preferred for most use cases because they are maintained and updated by Google.

An individual person’s Google account, used to sign in to the console, Cloud Shell, or CLI. Users are typically granted access via groups rather than direct bindings in production.

A Google Group that aggregates multiple user accounts. IAM roles can be granted to the group email so that membership changes automatically update who has access.

An entry in an IAM policy that assigns a role to one or more members (identities), such as granting `roles/storage.objectViewer` to a group on a bucket.

IAM Deep Dive: Identities, basic roles, and Least Privilege — Google Cloud Associate Cloud Engineer: Complete Exam-Ready Masterclass

Big Picture: What IAM Is and Why It Matters

IAM in One Sentence

Identity and Access Management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource. This is the core idea you must remember.

Why IAM Matters

IAM controls who can start or stop VMs, read or write storage, access databases, and more. As an Associate Cloud Engineer, you configure IAM so systems are secure but still usable.

What You Will Learn

You will learn identity types, role types, how IAM policies attach to the hierarchy, how inheritance works, and how to apply least privilege in realistic exam-style scenarios.

IAM Identities: Users, Groups, and Service Accounts

Users

Users are real people with Google accounts like `alice@example.com`. They log into the console or use `gcloud`. In production, you usually give users access via groups, not direct bindings.

Groups

Groups are Google Groups that contain multiple users. You grant IAM roles to the group email. Adding or removing members from the group automatically updates who has access.

Service Accounts

A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.

Exam Tip on Identities

If a scenario describes an app or job needing access, think service account. If it says "all developers" or easy onboarding/offboarding, think group. Individual humans are users.

IAM Roles: Basic vs Predefined vs Custom

Roles Bundle Permissions

Roles are collections of low-level permissions like `compute.instances.start`. You almost never assign permissions directly; you assign roles that group them.

Basic Roles

Basic roles are `Viewer`, `Editor`, and `Owner`. They are very broad and affect almost all services in a project. Still supported but not recommended for least-privilege setups.

Predefined Roles

Predefined roles are created and maintained by Google for specific services or job functions, like `storage.objectViewer` or `logging.logWriter`. They are the default choice for most scenarios.

Custom Roles

Custom roles are created by you at project or org level. You pick exact permissions when no single predefined role fits. They give flexibility but require maintenance.

Least Privilege: Reasoning About the Minimum Required Role

Least Privilege Defined

Least privilege means each identity gets only the permissions needed to do its job, and no more. The exam often asks you to pick the smallest role that still works.

4-Step Reasoning

1) Identify resource type. 2) Identify actions needed. 3) Match to the narrowest role that supports those actions. 4) Scope it to the smallest resource that still works.

Storage Example

Analyst needs to read objects in one bucket only. Choose `roles/storage.objectViewer` on that bucket, not on the entire project, and not `Editor`.

Logging Example & Trap

CI/CD needs to write logs: give its service account `roles/logging.logWriter` on the project. Avoid picking `Editor` or `Owner` when "security best practice" is mentioned.

Resource Hierarchy and Policy Inheritance

Resource Hierarchy

Hierarchy from top: Organization → Folders → Projects → Resources. Most IAM questions are at project or resource level, but higher levels can grant broader access.

IAM Policies and Bindings

An IAM policy attaches to a resource and contains bindings. Each binding maps a role to one or more members (identities).

Inheritance is Additive

Permissions granted at org or folder level flow down to projects and resources. Child policies can add more permissions, but cannot remove inherited ones via IAM alone.

Example

If a group has `Viewer` at org level, its members can view everything. If a user has `Editor` on one project, that access applies only within that project.

Worked Scenario: Predicting Effective Permissions

Scenario Setup

Org `example.com` → Folder `Production` → Project `prod-app-1` → Bucket `gs://prod-app-logs`. Different groups and a service account have roles at different levels.

Support Group on Bucket

Group `support@example.com` has `roles/storage.objectViewer` on the bucket. They can read and list objects, but not delete or upload new ones.

CI/CD Service Account

Service account `ci-cd@...` has `roles/storage.objectAdmin` on the project. It can read, write, and delete objects in buckets within that project, including `prod-app-logs`.

Org Auditors

Group `org-auditors@example.com` has `roles/viewer` at org level, so they can view resources and metadata, including listing objects in `prod-app-logs`, but not modify them.

Thought Exercise: Choosing Identities and Roles

Work through this mentally. Do not worry about being perfect; focus on your reasoning.

Scenario A: New Developer Joins

A new backend developer, Priya, joins the team.
She needs to deploy new versions of a microservice to a single project `dev-app-1`, and read logs for that service.

Questions:

Should you grant IAM directly to Priya’s user account, or to a group?
Which identity type should own the runtime permissions for the microservice (for example, reading from Pub/Sub, writing to Cloud Storage): Priya’s user, a group, or a service account?
What kind of roles should you prefer: basic, predefined, or custom?

Scenario B: Batch Job Processing

You have a nightly batch job running on a Compute Engine VM.
It reads files from `gs://incoming-data` and writes results to `gs://processed-data`.

Questions:

Where do you attach the identity for this job: to the VM’s service account or to a user account?
What roles does that identity need on each bucket?
At what scope should you grant those roles: bucket, project, or organization?

Reflect

Write down your answers in your notes, then compare with this reasoning:

Prefer groups for people, service accounts for workloads.
Prefer predefined roles at the narrowest scope that works.
Only consider custom roles when no predefined role matches the required permission set.

Quiz 1: Identities and Least Privilege

Check your understanding of IAM identities and least privilege.

A team runs a web app on Cloud Run in project `web-prod`. The app needs to read from one specific Cloud Storage bucket `gs://web-assets` in the same project. Following least privilege, what is the BEST setup?

Grant `roles/storage.objectAdmin` on the project to all developers' user accounts.
Create a service account for the Cloud Run service and grant it `roles/storage.objectViewer` on the `web-assets` bucket.
Grant `roles/storage.admin` at the organization level to the Cloud Run service account.
Create a custom role with all storage permissions and assign it to the Cloud Run service account on the project.

Show Answer

Answer: B) Create a service account for the Cloud Run service and grant it `roles/storage.objectViewer` on the `web-assets` bucket.

The app is a workload, so it should use a service account identity. It only needs to READ objects from a single bucket, so `roles/storage.objectViewer` scoped to that bucket is the least-privilege choice. Granting objectAdmin, storage.admin, or a custom role with all permissions is unnecessarily broad.

Quiz 2: Policy Inheritance and Effective Access

Test how well you can reason about IAM inheritance.

User `alex@example.com` is in group `devs@example.com`. IAM bindings: - Organization: `devs@example.com` → `roles/viewer` - Project `test-1`: `alex@example.com` → `roles/storage.objectAdmin` There is a bucket `gs://test-bucket` in project `test-1`. What can Alex do with objects in `gs://test-bucket`?

View metadata only, because viewer at org level overrides project-level roles.
Nothing, because Alex has no direct role on the bucket.
Read, create, update, and delete objects in `gs://test-bucket`.
Only list objects, because viewer at org level limits Alex to listing resources.

Show Answer

Answer: C) Read, create, update, and delete objects in `gs://test-bucket`.

IAM is additive. Alex gets `roles/viewer` via the group at org level and `roles/storage.objectAdmin` directly on the project. ObjectAdmin on the project grants full object management in that bucket, so Alex can read, create, update, and delete objects.

Common IAM Misconfigurations and Exam Traps

Trap: Basic Roles

Overusing `Viewer`, `Editor`, `Owner` is a classic mistake. When the question stresses security or least privilege, these broad roles are usually wrong.

Trap: Wrong Identity Type

Do not give runtime permissions to human users if a workload is doing the work. Use service accounts for applications, users/groups for people.

Trap: Too-Broad Scope

Avoid project-wide roles when access is needed only to a single bucket, topic, or database. Grant roles at the smallest resource scope that works.

Trap: Misunderstanding Inheritance

IAM is additive. Lower-level policies cannot remove inherited permissions. Also, prefer predefined roles over custom ones unless you truly need a custom set.

Key IAM Concepts Review

Flip through these flashcards to reinforce key IAM terms and ideas.

Identity and Access Management (IAM): Identity and Access Management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource.
User vs Group: A user is an individual person’s account. A group is a Google Group that contains multiple users; you assign IAM roles to the group email so membership changes automatically update access.
service account: A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.
Basic roles: The broad, legacy roles `roles/viewer`, `roles/editor`, and `roles/owner`. They apply across most services in a project and are not aligned with least privilege.
Predefined roles: Google-managed roles tailored to specific services or job functions (for example, `roles/storage.objectViewer`). Preferred for most use cases because they are maintained and updated by Google.
Custom roles: Roles you create at the project or organization level by choosing specific permissions. Used when no single predefined role matches the required permission set.
Least privilege: The principle of granting identities only the minimum permissions they need to perform their tasks, at the narrowest resource scope that works.
Resource hierarchy: The structure Organization → Folders → Projects → Resources. IAM policies attach at any level and permissions are inherited downward.
IAM inheritance: Permissions granted at a higher level (organization, folder, project) apply to all child resources. IAM is additive; lower-level policies cannot remove inherited permissions.
Role binding: A mapping in an IAM policy that connects a role to one or more members (identities), such as granting `roles/storage.objectViewer` to a group on a bucket.

Apply It: Mini Design Task for an Associate Cloud Engineer

Imagine you are working as an Associate Cloud Engineer in a small startup. You need to design IAM for a new analytics project.

Context

Project: `analytics-prod`
Team:
3 data engineers (build pipelines)
5 data analysts (query data, build dashboards)
Resources:
BigQuery datasets
A Cloud Storage bucket `gs://analytics-import` for raw CSV imports
A daily Dataflow job that reads from `analytics-import` and writes to BigQuery

Your task (think and sketch notes):

Which identity types do you use for:

Data engineers
Data analysts
Dataflow job

Which kinds of roles (basic, predefined, custom) do you aim to use for each?
At what scope do you grant each role (project, dataset, bucket)?

Hints to guide your design

Group humans into Google Groups like `data-engineers@example.com`, `data-analysts@example.com`.
Use a service account for the Dataflow job and attach it as the job’s runtime identity.
Prefer predefined roles like BigQuery data owner/viewer and storage object roles.
Scope analysts’ roles to datasets and engineers’ roles to project or specific resources as needed.

After you sketch your design, compare it to what you’ve learned:

Are you using least privilege?
Are workloads using service accounts?
Are roles scoped as narrowly as practical?

Key Terms

user: An individual person’s Google account, used to sign in to the console, Cloud Shell, or CLI. Users are typically granted access via groups rather than direct bindings in production.
group: A Google Group that aggregates multiple user accounts. IAM roles can be granted to the group email so that membership changes automatically update who has access.
binding: An entry in an IAM policy that assigns a role to one or more members (identities), such as granting `roles/storage.objectViewer` to a group on a bucket.
IAM policy: A document attached to a Google Cloud resource that contains role bindings defining which identities have which roles on that resource.
basic roles: The broad, legacy roles `roles/viewer`, `roles/editor`, and `roles/owner` that apply to most services in a project and are generally not aligned with least-privilege best practices.
custom roles: IAM roles created by customers at the project or organization level by selecting specific permissions, used when no single predefined role matches the required permission set.
least privilege: A security principle where each identity is granted only the minimum permissions necessary to perform its tasks, at the narrowest resource scope that still meets requirements.
service account: A service account is a special kind of account used by an application or compute workload, not a person, to make authorized API calls and access Google Cloud resources.
predefined roles: Google-managed IAM roles tailored to specific services or job functions, such as `roles/storage.objectViewer` or `roles/logging.logWriter`, updated automatically as services evolve.
policy inheritance: The behavior where IAM permissions granted at higher levels in the resource hierarchy (organization, folder, project) apply to all child resources.
resource hierarchy: The Google Cloud structure of Organization → Folders → Projects → Resources, which determines how IAM policies are inherited.
effective permissions: The sum of all permissions an identity has on a resource, considering all IAM roles granted at that resource and at higher levels in the hierarchy.
Identity and Access Management (IAM): Identity and Access Management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource.