Scoping IAM roles and org policies so access matches need

Cloud IAM controls who (identity) can do what (role) on which Google Cloud resource, using a resource hierarchy of Organization > Folder > Project > Resource where permissions are inherited downward and policies are additive. Organization Policies complement IAM by restricting *how* resources can be configured (e.g., allowed locations, disabling external IPs) regardless of a user's IAM permissions, enforcing governance guardrails across the hierarchy. For the exam, know how to apply least-privilege using predefined vs. custom roles and when to use org policy constraints versus IAM bindings for data governance scenarios.

1 · Learn the must-know

• 1IAM answers 'who can do what on which resource' via bindings of members to roles (basic, predefined, or custom), while Organization Policies answer 'what configurations are allowed' via constraints, and the two are independent layers, an org policy can block an action even if IAM allows it.
• 2IAM policies are inherited down the resource hierarchy (Organization → Folder → Project → Resource) and are strictly additive, you cannot deny a permission at a lower level that was granted higher up; use deny policies or org policy constraints for restrictions instead.
• 3Basic roles (Owner, Editor, Viewer) are broad and generally discouraged for production/data resources; prefer predefined roles like roles/bigquery.dataViewer, roles/bigquery.jobUser, or roles/storage.objectViewer for least-privilege access to data services.
• 4BigQuery has fine-grained access controls beyond project-level IAM, including dataset-level access, table/view-level IAM, row-level security (row access policies), and column-level security via policy tags in a taxonomy, which are exam favorites for 'restrict access to sensitive columns/rows' scenarios.
• 5Service accounts (not end-user credentials) are the standard identity for data pipelines (Dataflow, Dataproc, Cloud Functions, Cloud Composer) to access other GCP services, and should be scoped with minimal roles and, where possible, impersonated rather than key-downloaded to avoid long-lived credential risk.
• 6Organization Policy constraints commonly tested include restricting resource locations (data residency, e.g., constraints/gcp.resourceLocations), requiring OS Login, disabling service account key creation, and restricting public/external access to storage or VMs, these enforce compliance independent of any single user's IAM grants.

2 · Check your understanding