Designing for security and compliance · Topic 1 of 5
IAM, Resource Hierarchy and Separation of Duties
Designing IAM with least privilege, the organization, folder and project hierarchy, organization policies, separation of duties and just-in-time access.
- 3 min
- Organization, folders, projects, resources; policies inherit downward.
- Predefined roles to groups; avoid basic roles; custom roles when needed.
- Organization policies are guardrails that IAM cannot override.
What it is
Identity and Access Management decides who can do what on which resource. The resource hierarchy decides where policies apply and how they are inherited. Together they let an architect give each person and workload exactly the access it needs, separate powerful duties and enforce rules across the whole organization.
How it works
The resource hierarchy
| Level | Typical use |
|---|---|
| Organization | Company-wide policies, central security and billing roles |
| Folders | Environments (prod, non-prod), business units or regulated workloads |
| Projects | Units of isolation, billing and quota for one application or team |
| Resources | Buckets, datasets, VMs with their own policies where needed |
Allow policies inherit downward: a role granted on a folder applies to every project below it. Design folders so the right controls attach at the right level, for example a production folder with stricter policies.
IAM roles and principals
| Role type | Use |
|---|---|
| Basic (Owner, Editor, Viewer) | Avoid in production; far too broad |
| Predefined | Most cases; maintained by Google per service |
| Custom | When predefined roles grant too much |
Grant roles to groups, not individuals, so joiners and leavers are handled in the identity system. Use IAM Conditions to limit by resource name, tag or time. Use deny policies to block specific permissions regardless of grants.
Identities
- Cloud Identity or Google Workspace for staff, often synced from Active Directory with Google Cloud Directory Sync and signed in through SAML or OIDC single sign-on.
- Workforce Identity Federation lets users from an external identity provider access Google Cloud without Google accounts; each user still appears in audit logs.
- Service accounts for workloads, one per application, with no downloadable keys where possible.
Organization policies
Organization policies are guardrails that apply regardless of IAM, for example:
| Constraint (example) | Effect |
|---|---|
| Resource locations | Resources may be created only in allowed regions |
| Disable service account key creation | No long-lived keys |
| Restrict public IP on Cloud SQL | No public database endpoints |
| Domain restricted sharing | Only identities from allowed domains can receive roles |
| Require OS Login | SSH access tied to IAM identities |
Separation of duties
Split powerful duties so no single person can both change and approve, or both hold keys and read data:
- Key administrators in a separate project from data owners.
- Billing, network and security administration held by different groups.
- Deployment through pipelines whose service accounts hold production rights, rather than people.
Just-in-time privileged access
Privileged Access Manager grants elevated roles temporarily: a user requests an entitlement with a justification, an approver accepts, and access expires automatically after the set duration. This replaces standing administrator access.
"No standing access, justification, approval, expires in four hours" is the Privileged Access Manager pattern.
How the exam asks about this
- "Freelancers sign in only to their studio's SAML provider; no Google accounts; individually visible in audit logs." Workforce Identity Federation.
- "Engineers must not create buckets outside the EU, even by mistake." Resource locations organization policy.
- "Each pipeline may deploy only to its team's projects." A service account per team with roles only on those projects.
What to remember for the exam
- Organization, folders, projects, resources; policies inherit downward.
- Predefined roles to groups; avoid basic roles; custom roles when needed.
- Organization policies are guardrails that IAM cannot override.
- Separate key management, deployment and data access duties.
- Privileged Access Manager for just-in-time elevated access.
Granting a role at the organization or folder level gives it on every project below. Grant at the lowest level that works.
Common mistakes
Editor for everyone. Basic roles break least privilege.
One shared service account for all pipelines or apps.
Relying on training where an organization policy can enforce the rule.
Check yourself
Where should roles usually be granted: to individuals or groups?
To groups, managed in the identity system.
Which service gives time-limited, approved elevation of roles with a justification?
Privileged Access Manager.
Which control stops resources being created outside approved regions?
The resource locations organization policy constraint.
Topic 1 of 5 in Designing for security and compliance
Test yourself on Designing for security and compliance
The full Google Cloud Professional Cloud Architect question bank has 877 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.