Configuring IAM Roles and Custom Permissions

Overview and What You Will Learn

In this lab, you will grant the Editor basic role to see how broad it actually is, then replace it with a predefined role scoped to one specific service, and finally build a custom role from individual permissions when even that predefined role is too broad for the actual need.

Why This Matters in Production

A new team member is granted the Editor basic role "to keep things simple," and months later a routine access review discovers they've had the ability to modify nearly every resource type in the project the entire time - including services they've never once touched. A predefined or custom role scoped to their actual job would have made that exact access review a non-event.

Core Principles

GCP IAM roles come in three distinct types, and choosing the right type matters as much as choosing the right specific role.

Detailed Step-by-Step Practical Lab

1. Create a Project for this lab:

2. Grant the Editor basic role, and observe exactly how broad it actually is:

3. Remove that overly broad grant and replace it with a predefined role scoped to only Compute Engine:

4. Suppose the actual need is even narrower - this user should only be able to view VM details, never start, stop, or delete them. Define a custom role built from exactly the permissions needed:

5. Replace the predefined role with this custom role, matching the actual, narrower need:

6. Confirm the final IAM policy reflects only this narrow, custom role:

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Granting the Editor or Owner basic role by default because it "definitely won't cause a permissions error." These roles apply broadly across nearly every resource type in a project - a predefined role scoped to the specific service actually being used is almost always the more appropriate choice for day-to-day work.

Tip

Reach for a custom role only when a predefined role is genuinely too broad or too narrow for a real, specific need - not as a default starting point. Google's predefined roles already cover the large majority of common access patterns, and custom roles add ongoing maintenance overhead as GCP's own permission set evolves over time.

• Custom roles do not automatically stay current with new GCP permissions. As Google adds new features to a service, a custom role built from an explicit permission list does not automatically gain access to those new capabilities - predefined roles, by contrast, are maintained by Google to include newly relevant permissions.
• Test a new role assignment with the Policy Simulator (or a similar dry-run check) before applying it broadly, especially for a custom role, to confirm it grants exactly the intended access and nothing more.

Quick Reference & Troubleshooting Commands