2.2 Organization Policies & Granting IAM Roles

Why This Topic Matters

Domain 1 of the exam guide pairs two closely related but frequently confused controls: applying organizational policies to the resource hierarchy and granting members IAM roles within a project. Exam writers love scenarios that require you to pick the right tool — Organization Policy Service or IAM — because using the wrong one either doesn't work or is far more brittle to maintain. Get this distinction wrong on the exam and you'll misdiagnose half the "why can't this resource be created" scenario questions.

Quick Answer: IAM answers "who can do what" — it grants roles (bundles of permissions) to principals (users, groups, service accounts, domains) on a resource. Organization Policy Service answers "what configurations are allowed at all, regardless of who is asking" — it restricts things like external IPs on VMs or which regions resources can be created in, and it applies even to project Owners.

Organization Policies: Constraints, Not Permissions

An organization policy is built from a constraint — a predefined restriction you can enforce on a node in the resource hierarchy. Google Cloud has three constraint categories:

Constraints come in two shapes:

• Boolean constraints — simple on/off enforcement (e.g., disable serial port access entirely).
• List constraints — allow or deny specific values, using hierarchy-aware prefixes like under: (include an entire subtree) or in: (match a specific value or group), e.g. restricting constraints/gcp.resourceLocations to in:us-locations.

Inheritance Rule (frequently tested)

When you set an organization policy on a node, every descendant folder and project inherits it by default. Critically, inherited managed-constraint values are not merged with a child's own policy — a child either takes the parent's policy as-is, or fully overrides it with its own configuration for that constraint. This is different from IAM, where permissions genuinely accumulate down the tree. Setting or changing org policies requires the Organization Policy Administrator role (roles/orgpolicy.policyAdmin).

Common Constraints to Know

• constraints/compute.vmExternalIpAccess — block VMs from getting public IPs org-wide.
• constraints/gcp.resourceLocations — restrict which regions/zones new resources can be created in (data residency).
• constraints/iam.allowedPolicyMemberDomains — Domain Restricted Sharing, preventing IAM grants to identities outside approved domains (stops someone from adding a personal Gmail account as a project Viewer).

Granting IAM Roles Within a Project

Once you know whether a rule belongs in org policy vs. IAM, granting the actual roles is straightforward. IAM roles bind to a principal — user:name@example.com, group:team@example.com, serviceAccount:sa-name@project.iam.gserviceaccount.com, or domain:example.com — and to a role on a resource (organization, folder, or project).

Basic (Legacy) Roles — Know Them, Avoid Them in Production

These basic roles carry thousands of permissions across every Google Cloud service and are a common exam trap: a scenario describing "over-permissioned" access, or asking for the least-privilege fix, is almost always steering you away from Editor/Owner and toward a scoped predefined or custom role (the full predefined/custom role taxonomy is covered in Chapter 14).

Granting a Role with gcloud

gcloud projects add-iam-policy-binding retail-data-prod \
    --member="group:data-analysts@example.com" \
    --role="roles/storage.objectViewer"

add-iam-policy-binding appends one binding without disturbing any existing ones — the safe, everyday command. Its counterpart, remove-iam-policy-binding, revokes a single binding the same way. For bulk edits, use the read-modify-write pattern: gcloud projects get-iam-policy PROJECT_ID --format=json > policy.json, edit the file, then gcloud projects set-iam-policy PROJECT_ID policy.json — but this replaces the entire policy, so it's riskier for a single-binding change than add-iam-policy-binding.

Granting or revoking roles yourself requires resourcemanager.projects.setIamPolicy (or the folder/organization equivalent), which is bundled into roles like Project IAM Admin, Folder Admin, and Organization Administrator — you do not need the basic Owner role just to manage access.

Console Path

IAM & Admin → IAM → Grant Access → enter the principal → search for and select one or more roles (searchable by name, product, or job function) → optionally attach an IAM Condition (e.g., time-bound access) → Save.

Exam Scenario

A security team wants to guarantee that no user, service account, or future automation — no matter what IAM role it holds — can ever launch a Compute Engine VM with a public IP address, across every project in the company. Granting a narrower IAM role won't achieve this, because IAM only controls who has which permissions; it can't structurally forbid a resource shape for everyone including Owners. The correct fix is an organization policy using constraints/compute.vmExternalIpAccess applied at the organization node, so it cascades to every folder and project beneath it regardless of any individual's IAM grants.

Takeaways for the Exam

• IAM = who can do what (identity-based, additive allow policies). Organization Policy = what configurations are allowed (resource-based, applies to everyone including Owners).
• Org policies cascade down the hierarchy; a child either inherits the parent's value as-is or fully overrides it — values are never merged.
• add-iam-policy-binding / remove-iam-policy-binding are the safe, single-change commands; set-iam-policy replaces the whole policy and is reserved for bulk edits.
• Avoid granting basic roles (Owner/Editor/Viewer) in production scenarios on the exam — they are the "wrong answer" whenever a question asks for least privilege.