SkarpSkarp

Chapter 23 of 27

Configuring IAM Policies, basic roles, and Resource-Level Permissions

Misconfigured permissions are a top cause of incidents; practice granting and restricting access with the precision the exam expects.

27 min readen

IAM Policies in Context: From Fundamentals to Configuration

From IAM Theory to Practice

You already know the core idea: IAM lets you manage access control by defining who (identity) has what access (role) for which resource. Now we focus on configuring it correctly.

Why This Matters for the Exam

IAM appears heavily in Configuring access and security, and also when you set up environments and keep solutions running. Misconfigurations are common exam traps.

Module Focus Areas

We will practice using basic, predefined, and custom roles; choosing project vs folder vs resource scopes; enforcing least privilege; fixing permission errors; and designing low-blast-radius IAM.

Current IAM Landscape

As of 2026, IAM still uses the same core model, but with many granular predefined roles and tools like Policy Analyzer and Recommender. You must reason about scope more than memorize role lists.

Basic Roles: Powerful, Convenient, and Dangerous

The Three Basic Roles

Basic roles are: `roles/viewer`, `roles/editor`, and `roles/owner`. They are legacy, broad roles that apply across almost all services in a project.

What They Do

`Viewer` is read-only. `Editor` can modify most resources and data. `Owner` can do everything `Editor` can plus manage IAM and project-level administration.

Why They Are Risky

Basic roles include permissions for many services. Giving someone `Editor` for Compute also grants broad access to Storage, BigQuery, and more.

Exam Pattern

If a question offers `roles/editor` vs a specific predefined role, the safer, least-privilege answer is almost always the predefined role, unless broad admin access is clearly required.

Predefined Roles: Service-Specific and Granular

What Are Predefined Roles?

Predefined roles are Google-managed roles for specific services and job functions. They bundle many fine-grained permissions into a single, service-focused role.

Naming Patterns

Common patterns: `roles/compute.instanceAdmin`, `roles/storage.objectViewer`, `roles/bigquery.dataOwner`. The service name appears in the middle.

Common Suffixes

`Admin` can create and modify resources. `Viewer` is read-only. `User` can use existing resources. `Owner` or `*Editor` is broader within that service.

Exam Strategy

When a question asks for a role for a specific task and a predefined role fits, pick it instead of basic roles or building a custom role from scratch.

Custom Roles: When Predefined Is Not Enough

What Are Custom Roles?

Custom roles are roles you define yourself by selecting specific permissions. They help when predefined roles are too broad or do not match your exact needs.

Scope and Limits

Custom roles are defined at the project or organization level. You can only add permissions that Google allows for custom roles.

Creating a Custom Role

In the Console: IAM & Admin → Roles → Create role → choose scope and stage → search and add permissions → save and assign via IAM.

Exam Clues

If a scenario stresses strict least privilege and no predefined role fits, a custom role is appropriate. Otherwise, prefer predefined roles for simplicity and maintainability.

IAM Hierarchy: Organization, Folder, Project, Resource

The Resource Hierarchy

From top to bottom: Organization → Folder → Project → Resource (like a bucket or VM). IAM policies can be attached at any of these levels.

Inheritance

Permissions granted at a higher level are inherited by all children. An org-level role flows down to folders, projects, and resources under it.

Project vs Resource-Level

A role at the project level applies to all resources in that project. A role at a specific resource (like a bucket) limits access to that resource only.

Design Principle

Give broad, low-risk visibility higher in the tree, and grant powerful, sensitive roles at the lowest level that still meets requirements.

Project vs Resource-Level IAM: Concrete Scenarios

Scenario 1: Read-Only to a Project

Support needs to view logs, VMs, and buckets in `prod-app` but not modify them. Grant their group `roles/viewer` at the project level.

Scenario 2: Only One Bucket

Marketing should see only `gs://marketing-assets`. Grant `roles/storage.objectViewer` on that specific bucket, not on the project.

Scenario 3: Org-Wide Auditors

Security auditors must see all projects. Grant them `roles/viewer` or other read-only roles at the organization level.

Exam Reading Tip

Look for phrases like "only this resource" or "across all projects". They indicate whether to grant at resource, project, folder, or organization level.

Least Privilege and Access Reviews in Practice

Least Privilege Defined

Least privilege means each identity has only the permissions it truly needs, nothing extra. This limits damage if credentials are misused.

Applying Least Privilege

Use predefined roles over basic roles, grant at the lowest suitable level, and avoid `roles/owner` except for narrow admin groups.

Service Accounts

Use a service account for applications and workloads, with only the roles required for their tasks, not human-level admin roles.

Reviewing Access

Regularly inspect IAM policies for broad roles, powerful service accounts, and external users. Use IAM Recommender to spot unused access.

Designing IAM for Separation of Duties

Work through this thought exercise to practice designing IAM that separates duties and minimizes blast radius.

Scenario:

You manage a production project `prod-payments`. The organization requires:

  • Network engineers can manage VPCs and firewalls but must not read or write application data.
  • Database administrators (DBAs) can manage Cloud SQL and BigQuery schemas but must not deploy code or modify networking.
  • Application operators can deploy new versions of services and restart VMs but cannot change IAM or networking.

Task 1: Identify the main identity groups

Think: Which Google Groups would you create? For example:

  • `net-eng@example.com`
  • `dba@example.com`
  • `app-ops@example.com`

Task 2: Choose suitable predefined roles

Without worrying about exact names, sketch which types of roles each group needs:

  • Network engineers: network admin roles (for example `roles/compute.networkAdmin`).
  • DBAs: database and data admin roles (for example `roles/cloudsql.admin`, `roles/bigquery.dataOwner` on specific datasets).
  • App operators: deployment and instance management roles (for example `roles/compute.instanceAdmin.v1`, `roles/clouddeploy.operator`).

Task 3: Decide scopes

For each group, decide whether to grant roles at project or resource level:

  • Network engineers: likely project-level for networking.
  • DBAs: dataset-level in BigQuery, instance-level or project-level for Cloud SQL.
  • App operators: project-level for Compute Engine instances, but not org-level.

Write down or say out loud your design. Then compare it to the explanation in the next mental check:

  • Did any group accidentally get `roles/owner` or `roles/editor`? If yes, how could you replace that with more specific roles?
  • Did you ensure no single group can both deploy code and change IAM or networking?

Troubleshooting Permission Denied: Compute, Storage, BigQuery

General Debug Pattern

1) Read the error. 2) Identify the identity. 3) Check IAM bindings. 4) Map missing permission to a predefined role. 5) Grant the least-privilege role at the right scope.

Compute Engine Example

If a user sees `compute.instances.start` denied, they likely need a Compute admin-type role like `roles/compute.instanceAdmin.v1` for that project or instance.

Cloud Storage Example

If a service account cannot read from a bucket and `storage.objects.get` is denied, grant `roles/storage.objectViewer` on that specific bucket.

BigQuery Example

If a user gets `Access Denied` querying a table, assign `roles/bigquery.dataViewer` at the dataset or project level, not a broad editor role.

Quiz 1: Basic vs Predefined Roles and Scope

Test your understanding of role types and IAM scope.

A team of data analysts needs to run queries on several BigQuery datasets in project `analytics-prod`. They must not modify any other resources in the project. What is the best IAM configuration?

  1. Grant the group `roles/editor` on project `analytics-prod`.
  2. Grant the group `roles/bigquery.dataViewer` on the required datasets.
  3. Grant the group `roles/viewer` on project `analytics-prod`.
  4. Grant the group `roles/owner` on the required datasets.
Show Answer

Answer: B) Grant the group `roles/bigquery.dataViewer` on the required datasets.

They only need to read BigQuery data. Granting `roles/bigquery.dataViewer` on specific datasets follows least privilege and resource-level scoping. `roles/editor` and `roles/owner` are overly broad; project-level `roles/viewer` gives read access to many services they do not need.

Quiz 2: Custom Roles and Least Privilege

Check your understanding of when to use custom roles.

You are asked to allow a CI/CD service account to only create and delete Cloud Storage objects in a single bucket. No predefined role exactly matches this combination. What is the best approach?

  1. Grant the service account `roles/storage.admin` on the project.
  2. Grant the service account `roles/editor` on the project.
  3. Create a custom role with only the required Storage object permissions and bind it to the service account on that bucket.
  4. Grant the service account `roles/storage.objectViewer` on the bucket.
Show Answer

Answer: C) Create a custom role with only the required Storage object permissions and bind it to the service account on that bucket.

The requirement is very specific and no predefined role matches it exactly. Creating a custom role with just the needed Storage object permissions and assigning it at the bucket level enforces strict least privilege. `storage.admin` and `editor` are too broad. `objectViewer` is read-only and does not allow creating or deleting objects.

Key IAM Terms and Patterns

Use these flashcards to reinforce terminology and core patterns before moving on.

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.
Three IAM role types
The IAM role types are: basic, predefined, custom.
Basic roles
Legacy, broad roles: `roles/viewer`, `roles/editor`, `roles/owner`. They apply across most services in a project and should be used carefully due to over-privilege.
Predefined roles
Google-managed roles tailored to specific services and job functions, such as `roles/compute.instanceAdmin` or `roles/storage.objectViewer`. Preferred for least privilege when they fit.
Custom roles
User-defined roles at the project or organization level that bundle selected permissions when predefined roles do not meet exact 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.
Resource hierarchy order
Organization → Folder → Project → Resource. IAM policies at higher levels are inherited by lower levels.
Least privilege
A security principle where each identity is granted only the minimum permissions necessary to perform its tasks, reducing potential damage from misuse.
Project-level vs resource-level IAM
Project-level roles apply to all resources in the project. Resource-level roles apply only to a specific resource (like one bucket or one dataset) for tighter control.
Typical exam trap with IAM
Offering `roles/editor` or another basic role as an easy fix. The better answer is usually a more specific predefined role at the narrowest appropriate scope.

Key Terms

basic roles
Legacy, broad IAM roles: `roles/viewer`, `roles/editor`, and `roles/owner`, which grant wide access across many Google Cloud services.
custom roles
User-defined IAM roles at the project or organization level that combine selected permissions when predefined roles do not meet exact requirements.
least privilege
The security principle of giving identities only the minimum permissions they need to perform their tasks, reducing risk if credentials are compromised.
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 that bundle fine-grained permissions for specific services and job functions, designed to support least privilege.
resource hierarchy
The structure of Google Cloud resources: Organization → Folder → Project → Resource, which determines how IAM policies are inherited.
resource-level IAM
IAM policy bindings applied directly to a single resource (such as one bucket or dataset), limiting the scope of granted permissions.
separation of duties
An IAM design approach where different teams or roles are given distinct responsibilities (for example networking vs database vs deployment) to reduce the chance of abuse or mistakes.
permission denied error
An error that occurs when an identity attempts an operation without the required IAM permission, often indicating missing or mis-scoped roles.
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