Managing Cloud IAM: Roles, Policies, and Inheritance

Cloud IAM answers one question — who can do what on which resource — with three building blocks. A principal (also called a member) is the identity requesting access: a Google Account (user:alice@example.com), a service account (serviceAccount:app@project.iam.gserviceaccount.com), a Google group (group:devs@example.com), a whole domain (domain:example.com), or the special principals allAuthenticatedUsers and allUsers. A role is a named bundle of permissions, where each permission is a verb on a service resource such as compute.instances.start or storage.objects.get. You never grant a permission directly to a principal — permissions travel only inside roles.

A role binding ties one role to a list of principals, and an IAM policy (also called an allow policy) is the set of bindings attached to a single resource. Policies can attach at any level of the hierarchy: the organization, a folder, a project, or an individual resource that supports its own policy, such as a Cloud Storage bucket, a Pub/Sub topic, or a service account. A binding can also carry an optional IAM condition — a logical expression that limits when the grant applies, for example only until an expiry date or only to resources whose name matches a prefix.

Two consequences of this model come up constantly in questions. First, because permissions only travel inside roles, the fix for a missing single permission is finding (or building) a role that carries it — not granting the permission by itself. Second, because the policy lives on the resource rather than on the user, auditing what a person can do means examining policies across the hierarchy, which is why the effective-policy and inheritance rules in the next sections matter so much.

You view a project's policy with gcloud projects get-iam-policy PROJECT_ID, which prints every binding — role, principals, and any conditions — plus an etag used for optimistic concurrency when you write the policy back. The equivalent exists at each level: gcloud organizations get-iam-policy ORG_ID, gcloud resource-manager folders get-iam-policy FOLDER_ID, and per-resource commands such as gcloud storage buckets get-iam-policy gs://my-bucket. In the Console, the IAM page shows the same data with inherited grants labelled by the level they come from.

To grant a role, add a binding: gcloud projects add-iam-policy-binding PROJECT_ID --member=group:devs@example.com --role=roles/compute.instanceAdmin.v1. To revoke, use remove-iam-policy-binding with the same flags. These two commands are read-modify-write helpers — they fetch the current policy, edit one binding, and write it back — and they are the day-to-day way to manage access. For bulk changes you can dump the policy to a file, edit it, and apply the whole document with gcloud projects set-iam-policy PROJECT_ID policy.json; the etag in the file protects you from silently overwriting someone else's concurrent change.

Editing a policy is itself a privileged operation: it requires the setIamPolicy permission on that resource, carried by roles like Owner or the resource-specific admin roles. Two supporting tools are worth knowing by name: Policy Troubleshooter answers why a specific principal does or does not have a specific permission on a resource, and IAM Recommender analyzes actual permission usage and suggests replacing over-broad grants with tighter roles — Google's own tooling for enforcing least privilege over time.

The three role types differ in who defines them, how broad they are, and when you should reach for each.

The basic roles predate the modern IAM system, and their reach is wider than people expect: Editor grants modify access to nearly all services in the project, and Owner adds the ability to manage IAM itself and grant roles to others. Billing management is handled separately through billing account roles rather than by project ownership alone. Any exam option that hands a human or a service account Editor to solve a narrow task is nearly always the wrong answer when a predefined role is on the list.

Predefined roles carry a maintenance advantage custom roles never get: when a service launches new features and permissions, Google updates its predefined roles so holders keep working. A custom role is frozen at the permissions you listed — you own its upkeep forever. That trade-off is exactly how the exam frames the choice: reach for custom roles only when least privilege genuinely demands a combination no predefined role offers.

IAM policies inherit down the resource hierarchy: a binding on the organization applies to every folder, project, and resource beneath it; a binding on a folder applies to all projects inside it; a binding on a project applies to every resource in the project. The effective policy on any resource is the union of the policy set directly on it and every policy inherited from its ancestors.

The rule with teeth is that inheritance is additive and allow-only. Standard IAM policies only ever grant — there is no subtract-a-role binding — so a lower level can never narrow what an ancestor granted. If devs@example.com holds roles/editor on the folder, granting the same group roles/viewer on one project inside it changes nothing: the group still holds Editor there through inheritance. The only fix is to remove or tighten the grant where it was made, at the folder. (Google Cloud does offer separate deny policies as an advanced guardrail mechanism, but the default IAM model the exam tests is the additive allow model — assume no denies unless a question says otherwise.)

Inheritance is also why grant placement is a design decision. Grant at the highest level whose entire subtree genuinely needs the access — an organization-wide security team might hold roles/iam.securityReviewer on the organization — and at the lowest level otherwise: a contractor auditing one bucket gets roles/storage.objectViewer on that bucket, not on the project. When a scenario asks how to give a team the same access across the twelve projects in one department, the answer is one binding on the department's folder, not twelve project-level bindings you must keep synchronized by hand.

A custom role is a permission bundle you define when least privilege requires a combination no predefined role offers — for example, operators who may start and stop VMs but never create or delete them. Custom roles can be created at the project level or the organization level, and that choice matters: a project-level custom role can only be used in bindings within that project, while an organization-level role can be used in any project in the organization. Notably, custom roles cannot be created at the folder level — a recurring trick option. If several projects need the same custom role, define it once at the organization level rather than cloning it per project.

Create one with gcloud by listing permissions inline: gcloud iam roles create vmOperator --project=PROJECT_ID --title=VM-Operator --permissions=compute.instances.start,compute.instances.stop --stage=GA, or from a YAML definition file with --file. Swap --project for --organization=ORG_ID for an org-level role. Useful companions: gcloud iam list-testable-permissions RESOURCE shows which permissions can be granted on a resource type, gcloud iam roles describe roles/storage.objectViewer reveals a predefined role's exact permission list to use as a starting point, and gcloud iam roles copy clones a role you can then trim. Not every permission is supported in custom roles — some are grantable only through predefined roles — so build from the testable-permissions list rather than guessing.

Every custom role carries a launch stage — ALPHA, BETA, or GA while it is live, plus DEPRECATED and DISABLED for retirement. The stage is metadata that signals maturity to your own admins; it does not change enforcement. Lifecycle management is on you: update a role with gcloud iam roles update, mark it deprecated to warn admins off new bindings, and disable it to inactivate its bindings. Remember the standing trade-off — Google never updates your custom roles, so when a service adds new permissions your role stays frozen until you edit it.

Scenario: your company has an organization with a retail folder containing the projects retail-prod, retail-staging, and retail-dev. The deployment team must manage Compute Engine instances in all three projects; the data science group needs read-only access to one Cloud Storage bucket in retail-prod; and a new platform admin must be able to grant roles across the whole retail estate. How do you set this up without touching basic roles?

Work each requirement from the model. The deployment team needs the same service-specific power in every project under the folder, so bind once at the folder: gcloud resource-manager folders add-iam-policy-binding FOLDER_ID --member=group:deploy@example.com --role=roles/compute.instanceAdmin.v1. Inheritance carries it into all three projects, and any future project created in the folder is covered automatically. The data science group's need is the narrowest, so bind at the resource itself: roles/storage.objectViewer on the single bucket, not on retail-prod — a project-level grant would expose every bucket in the project. The platform admin needs to manage IAM but should not inherit Owner's full powers, so grant roles/resourcemanager.folderIamAdmin on the folder, which permits editing folder and project policies beneath it without granting resource access.

Note the habits embedded here, because the exam tests them as reflexes: every grant went to a group rather than a named user, so team changes are a group-membership edit rather than an IAM edit; every grant used a predefined role scoped to one job; and every grant landed at the lowest level that satisfies the whole requirement — folder for the folder-wide need, bucket for the bucket-wide need. If the deployment team later needed start/stop only, that is the trigger to define an organization-level custom role and swap the folder binding to it.

Use this reference to compress the lesson into the facts questions actually turn on.

When you hit an IAM question, run this triage: identify the principal (prefer a group), identify the narrowest role that carries the needed permissions (predefined before custom, custom before basic), then identify the lowest attachment point whose subtree matches the requirement (resource, then project, then folder, then organization). If the question involves someone having more access than a project-level policy suggests, the answer is inheritance from a folder or organization binding. If it involves needing a role in many projects at once, the answer is a single higher-level binding — or, for a custom role, defining it at the organization level so all projects can use it.