IAM: policies, inheritance, and roles

IAM controls who can do what on which resource. To give access, you grant a role to a principal on a resource. Permissions are never granted directly: they always come inside roles.

Allow policies

An allow policy (formerly "IAM policy") is a JSON or YAML object attached to a resource with a list of role bindings: each one ties a role to the principals who hold it.

{
  "bindings": [
    { "role": "roles/storage.objectViewer",
      "members": ["group:analysts@example.com"] },
    { "role": "roles/compute.instanceAdmin.v1",
      "members": ["user:ana@example.com"],
      "condition": { "title": "until-dec",
        "expression": "request.time < timestamp('2026-12-31T00:00:00Z')" } }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

• Up to 1,500 principals per policy.
• The etag provides concurrency control: it stops two simultaneous changes from overwriting each other.
• Version: 1 doesn't support conditions; 3 adds the condition field (2 is internal).
• Changes usually take effect within about 2 minutes, but sometimes take 7 minutes or more.

Inheritance and the effective policy

An allow policy on a container applies to that container and everything below it: organization → folders → projects → resources. A resource's effective policy is the union of its own policy and those of all its ancestors: a binding at any level is enough to grant access.

• A permission granted higher up can't be removed with an allow policy lower down. To restrict it you need a deny policy.
• Resources that don't accept their own allow policy (for example, log buckets) inherit from their ancestors: grant the role on the project.
• Google best practices: grant roles to groups instead of individual users; few teams with roles on the organization (security, network); folders that mirror the company structure.

Creating and managing custom roles

• Created in an organization or project, never a folder (to use one in a folder, create it in the organization). They can only be granted within that organization or project.
• Limit: 300 per organization and 300 per project.
• A project role can't include permissions that only work at the folder or organization level.
• Not every permission is supported: each has a SUPPORTED, TESTING, or NOT_SUPPORTED level.
• Some permissions only work together: updating a policy needs getIamPolicy as well as setIamPolicy. Starting from a predefined role helps.
• Informational launch stage: ALPHA, BETA, GA, DEPRECATED. With DISABLED the role stays in policies but has no effect.
• You can't change the role ID. A deleted role can be undeleted for 7 days, and its ID can't be reused until 44 days have passed.
• Anyone who can edit custom roles can add any permission to them: limit that power to very few people.

gcloud iam roles create vmOperator --project=my-project \
  --title="VM Operator" --description="Start and stop VMs" \
  --permissions="compute.instances.get,compute.instances.list,compute.instances.start,compute.instances.stop" \
  --stage=GA

gcloud iam roles create orgAuditor --organization=123456789012 --file=role.yaml
gcloud iam roles update vmOperator --project=my-project --stage=DISABLED
gcloud iam roles delete vmOperator --project=my-project
gcloud iam roles undelete vmOperator --project=my-project

Viewing, granting, and revoking access

# Grant or remove a role (one-off change)
gcloud projects add-iam-policy-binding my-project \
  --member=group:devs@example.com --role=roles/compute.viewer
gcloud projects remove-iam-policy-binding my-project \
  --member=group:devs@example.com --role=roles/compute.viewer

# Bulk changes: read, modify, write
gcloud projects get-iam-policy my-project --format=json > policy.json
gcloud projects set-iam-policy my-project policy.json

• Principal formats: user:, group:, serviceAccount:, domain:.
• set-iam-policy overwrites the whole policy. Always follow the read-modify-write pattern so you don't drop bindings by accident; the etag rejects the write if someone else changed it in between.
• The same commands exist for folders (gcloud resource-manager folders), organizations, and individual resources.

IAM Conditions

Attribute-based access control: the binding only grants the role if the expression, written in a subset of CEL (Common Expression Language), is true. Useful, for example, for temporary access or access limited to resources with a certain name. They're also used in deny rules and Principal Access Boundary.

request.time < timestamp('2026-12-31T00:00:00Z')
resource.name.startsWith('projects/_/buckets/exampleco-site-assets/')

• Not allowed with legacy basic roles (Owner, Editor, Viewer) or with allUsers or allAuthenticatedUsers.
• A conditional binding doesn't override an unconditional one: if the principal already has the role without a condition, they always have it.
• On a Cloud Storage bucket they require uniform bucket-level access.
• Google recommends no more than 100 conditional bindings per policy.

Deny policies and Principal Access Boundary

Privileged Access Manager (PAM) lets principals request temporary, auditable access, with justification or approval, instead of holding a role permanently.

Exam scenarios

Common exam traps