SkarpSkarp

Chapter 22 of 27

Identity and Access Management Fundamentals and IAM Role Types

Access control is at the heart of security; build a clear mental model of IAM identities, roles, and policies as tested on the exam.

27 min readen

Big Picture: Why IAM Matters (and Exam Context)

IAM Is Everywhere

In Google Cloud, almost every action is checked by Identity and Access Management (IAM). If you understand IAM, you can both secure environments and answer many exam questions confidently.

Core Definition

Identity and Access Management (IAM) lets you manage access control by defining who (identity) has what access (role) for which resource. This 3-part idea is the core of this module.

Three Parts of IAM

  • Who: the identity (user, group, service account)
  • What access: the role (set of permissions)
  • Which resource: the project, bucket, VM, dataset, etc.

Exam-Oriented Thinking

For a scenario like "developer needs read-only access to Cloud Storage", think: identity type, role type (basic, predefined, custom), and resource level (project vs bucket).

Connection to Observability

Earlier, you saw logging and monitoring roles such as `logs.viewer`. These are IAM roles. Misconfigured IAM is a common reason logs or metrics seem to "disappear".

Principals, Identities, and Resources

Principals vs Resources

IAM connects principals (identities) to resources. Principals are who acts; resources are what they act on (projects, buckets, VMs, etc.).

Common Identity Types

  • Google account (user)
  • Google group
  • service account
  • Domain (all users in `@company.com`)
  • Special: `allUsers`, `allAuthenticatedUsers`

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.

Resource Hierarchy

Resources form a tree: Organization → Folder(s) → Project → child resources (buckets, VMs, datasets, etc.). IAM policies can attach at each level.

IAM Binding Example

Example binding: give `devs@example.com` the `roles/storage.objectViewer` role on project `analytics-prod`. Principal = group, Role = viewer, Resource = project.

IAM Roles and Permissions: The Building Blocks

Permissions vs Roles

Permissions are low-level abilities like `storage.objects.get`. Roles are named collections of permissions, such as `roles/storage.objectViewer`.

How IAM Grants Access

IAM does not grant permissions directly. It grants roles to principals on resources. The role determines which permissions they effectively get.

Multiple Roles and Union

A principal can have several roles on a resource. Their effective permissions are the union of all permissions from all those roles (including inherited ones).

Role Naming Patterns

Common pattern: `roles/product.roleName`, like `roles/logging.viewer` or `roles/compute.admin`. Some cross-product roles exist, like `roles/viewer`.

Exam Expectations

You should match English descriptions ("view logs only") to appropriate roles, and prefer roles that give only the needed permissions.

IAM Role Types: basic, predefined, custom

Three IAM Role Types

Google Cloud defines three IAM role types: basic, predefined, custom. Knowing when to use each is critical for both security and the exam.

Basic Roles

Basic roles: `roles/viewer`, `roles/editor`, `roles/owner`. They span almost all services in a project and are very broad, often too permissive.

Predefined Roles

Predefined roles are created by Google for specific products and tasks, like `roles/storage.objectViewer` or `roles/logging.logWriter`. They are the usual choice for least privilege.

Custom Roles

Custom roles are built by your org from individual permissions when predefined roles are not precise enough. They can be defined at org or project level.

Exam-Friendly Rule of Thumb

Default to predefined roles for real workloads, avoid basic roles in production, and reach for custom roles only when predefined options cannot meet strict requirements.

Choosing Role Types: Practical Scenarios

Scenario 1: Intern Read-Only

Need: intern can view all resources in one project, no changes. A single basic `roles/viewer` on that project is simple and acceptable in non-production.

Scenario 2: Cloud Run + Logs + Bucket

Need: a Cloud Run service account writes logs and reads one bucket. Use predefined roles: `roles/logging.logWriter` on project and `roles/storage.objectViewer` on that bucket.

Avoid Overly Broad Roles

Do not give `roles/editor` to that service account. It would grant many write permissions across services, violating least privilege.

Scenario 3: Start/Stop Only

Need: a team can only start/stop Compute Engine VMs. Predefined instance admin roles allow too much. Build a custom role with just start/stop permissions.

Pattern to Remember

Pattern: basic roles for broad, low-risk read-only; predefined roles for most real workloads; custom roles for strict, unusual requirements.

IAM Policies, Bindings, and Evaluation

What Is an IAM Policy?

An IAM policy is attached to a resource and contains bindings. Each binding pairs a role with a list of member identities.

Binding Structure

Binding: `{ role: roles/storage.objectViewer, members: [user:alice@example.com, group:devs@example.com] }`.

Evaluation Steps

On access: find the resource, gather its policy and ancestor policies, expand groups, union all permissions from roles, then check if the requested permission is present.

Deny-by-Default

If no binding grants the needed permission, the request is denied. There is no simple "deny overrides allow" feature in standard IAM for this exam.

Union of Roles

A principal may get roles from multiple bindings and levels. Their effective permissions are the union, which explains why removing one role may not remove access.

Resource Hierarchy and Policy Inheritance

Hierarchy Overview

Hierarchy: Organization → Folder(s) → Project → child resources (buckets, VMs, datasets, etc.). IAM policies can attach at any level.

Inheritance Rule

A role granted at a higher level (org, folder, project) is inherited by all descendant resources unless you change the higher-level policy.

Org-Level Example

Grant `roles/logging.viewer` to `security-team` at the organization. They can view logs in all projects in that org automatically.

Project-Level Example

Give `roles/bigquery.dataViewer` to `data-analysts` at a project. They can read datasets and tables in that project without per-dataset IAM.

Design Implications

Higher-level bindings are powerful but risky. For least privilege, bind roles as close as practical to the resource, and always consider inheritance.

Thought Exercise: Tracing Effective Permissions

Use this exercise to practice mentally evaluating IAM.

Scenario

Hierarchy:

  • Organization: `example.com`
  • Folder: `Prod`
  • Project: `analytics-prod`
  • Resource: Cloud Storage bucket `gs://customer-data`

Bindings:

  1. Organization level: `group:sec-team@example.com` → `roles/logging.viewer`
  2. Folder `Prod`: `group:devs@example.com` → `roles/viewer`
  3. Project `analytics-prod`: `group:analysts@example.com` → `roles/bigquery.dataViewer`
  4. Bucket `customer-data`: `group:marketing@example.com` → `roles/storage.objectViewer`

Groups:

  • Alice is in `devs@example.com` and `analysts@example.com`.
  • Bob is in `marketing@example.com` only.
  • Carol is in `sec-team@example.com` only.

Questions (think before checking explanations below):

  1. Can Alice list objects in `gs://customer-data`? Why or why not?
  2. Can Bob query BigQuery datasets in `analytics-prod`?
  3. Can Carol view logs for `analytics-prod` resources?
  4. If you remove binding (4) at the bucket, does Bob still have any access to that bucket?

Suggested answers (do not peek until you reason it out):

  1. Alice has `roles/viewer` at the folder level, inherited down to the project and bucket. Basic `viewer` includes read access to most resources, including listing bucket contents. So yes, she can list objects, even without a bucket-level role.
  2. Bob only has `roles/storage.objectViewer` on the bucket. That does not include BigQuery permissions. So no, he cannot query datasets.
  3. Carol has `roles/logging.viewer` at the organization level, inherited to all projects including `analytics-prod`. She can view logs for that project.
  4. After removing binding (4), Bob has no roles on the bucket from any ancestor, so he loses access. This shows how a resource-level role can be the only grant for a user.

Quiz 1: IAM Basics and Role Types

Check your understanding of IAM fundamentals and role types.

A team runs a production app on Google Cloud. Developers need to read logs and view metrics for their project, but must not modify resources. Which option best follows least privilege?

  1. Grant the developers the basic role roles/viewer on the project.
  2. Grant the developers predefined roles like roles/logging.viewer and roles/monitoring.viewer on the project.
  3. Grant the developers the basic role roles/editor on the project.
  4. Create a custom role with all permissions from roles/editor except delete permissions, and grant it to the developers.
Show Answer

Answer: B) Grant the developers predefined roles like roles/logging.viewer and roles/monitoring.viewer on the project.

Predefined roles like roles/logging.viewer and roles/monitoring.viewer grant exactly the needed read-only permissions for logs and metrics without broader access. Basic roles such as roles/viewer or roles/editor are much broader; roles/viewer may still be acceptable in some cases, but the more precise predefined roles better match the requirement. A custom role duplicating editor minus delete is still overly broad and hard to maintain.

Quiz 2: Inheritance and Effective Access

Test your understanding of IAM inheritance and evaluation.

You removed roles/storage.objectViewer from a user on a specific Cloud Storage bucket, but they can still list objects in that bucket. What is the most likely explanation?

  1. Cloud Storage caches IAM decisions for several hours, so the change has not taken effect.
  2. The user has roles/storage.objectViewer on the project, and that permission is inherited by the bucket.
  3. The user has a custom role on the bucket that explicitly denies access, but denies are ignored.
  4. The user is using a different Google account that still has access.
Show Answer

Answer: B) The user has roles/storage.objectViewer on the project, and that permission is inherited by the bucket.

If a user still has access after removing a bucket-level role, the most common reason is that they have a broader role (such as roles/storage.objectViewer or roles/viewer) at a higher level like the project, which is inherited by the bucket. IAM is deny-by-default and grant-based; there is no simple deny override in standard IAM, so option 3 is incorrect. Caching and multiple accounts are possible in real life but are not the primary exam concept being tested.

Key IAM Terms and Role Types

Use these flashcards to reinforce key IAM concepts and definitions.

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.
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.
Principal (identity)
An entity that can be granted access in IAM, such as a user, group, service account, domain, or special identities like allUsers.
Resource hierarchy (top to bottom)
Organization → Folder(s) → Project → Child resources (e.g., buckets, VMs, datasets). IAM policies can attach at each level and inherit downwards.
IAM role types (list them)
Three IAM role types: basic, predefined, custom.
basic roles
roles/viewer, roles/editor, roles/owner. Very broad, span many services in a project. Historically called primitive roles; now referred to as basic roles.
predefined roles
Roles created and maintained by Google for specific products and tasks (e.g., roles/storage.objectViewer). Recommended starting point for least privilege.
custom roles
Roles created by your organization from individual permissions when predefined roles are not precise enough. Defined at org or project level.
IAM binding
A mapping in a policy that associates one role with a list of members (principals), for example role: roles/storage.objectViewer, members: [user:alice@example.com].
Deny-by-default behavior
If no IAM binding grants the required permission for an action, access is denied. Standard IAM does not rely on explicit denies overriding allows for the exam.

Putting It All Together: Exam Patterns and Next Steps

Core IAM Recap

IAM defines who (identity) has what access (role) for which resource. Principals get roles on resources; policies live on resources and inherit down the hierarchy.

Role Types Recap

Three IAM role types: basic, predefined, custom. Prefer predefined for least privilege, use basic sparingly, and custom only when necessary.

Troubleshooting Mindset

If access is surprising, check ancestor policies and group memberships. Remember deny-by-default and union of all granted roles.

Exam Patterns

Watch for questions that overuse roles/editor or roles/owner, or that hide higher-level grants. Always pick the least-privilege role that satisfies the requirement.

Your Next Moves

Continue with Skarp’s IAM diagnostic and mock exams. Missed items will appear in your spaced review queue so IAM reasoning becomes automatic.

Key Terms

binding
A part of an IAM policy that associates a single role with a list of members (principals).
principal
An identity that can be granted access in IAM, such as a user, group, service account, domain, or special identities like allUsers.
IAM policy
A document attached to a resource that contains bindings, each mapping a role to one or more members (principals).
basic roles
The broad roles roles/viewer, roles/editor, and roles/owner that apply across many Google Cloud services in a project.
custom roles
Organization- or project-level IAM roles created by customers from individual permissions when predefined roles are not suitable.
least privilege
A security principle where identities are granted only the minimum permissions necessary to perform their required tasks.
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
Roles created and maintained by Google Cloud for specific products and tasks, typically offering finer-grained least-privilege access.
resource hierarchy
The structure Organization → Folder(s) → Project → child resources, which determines how IAM policies inherit.
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.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself