Bootstrapping and maintaining a Google Cloud organization · Topic 1 of 6
Resource Hierarchy, IAM, Organization Policies and Service Accounts
Design a Google Cloud resource hierarchy with folders and projects, IAM and organization policies, service accounts and data residency rules.
- 5 min
- Organization, folders, projects, resources; policies flow down.
- One project per application per environment; shared services in their own projects.
- Allow policies are additive; use deny policies to block inherited access.
What it is
The resource hierarchy is the tree every Google Cloud resource lives in: the organization at the top, folders below it, projects inside folders, and resources inside projects. IAM allow policies and organization policies set high in the tree flow down to everything below.
A good hierarchy lets a DevOps team grant access, apply guardrails and see costs by team or environment without touching each project.
How it works
Organizing resources
The project is the basic unit: it holds resources, enabled APIs, quotas and billing, and it is the usual IAM boundary. Folders group projects so policy can be set once.
| Layout | Folders under the organization | Good when |
|---|---|---|
| Environment first | prod, nonprod, then teams | Strong separation of production policy |
| Business unit first | retail, payments, then prod and nonprod | Teams own their budgets and access |
| Application-centric | One folder or App Hub application per application | Operating and monitoring by application, not by project |
Use one project per application per environment (for example shop-web-prod and shop-web-dev). Shared services such as the Shared VPC host, the CI/CD tooling and central logging get their own projects.
App Hub groups services and workloads from several projects into an application, so monitoring and ownership can follow the application rather than the project list.
IAM roles and inheritance
IAM allow policies are additive down the tree: a role granted on a folder applies to every project in it, and a lower level cannot remove it. To block access that is inherited, use an IAM deny policy.
| Role type | Example | Use |
|---|---|---|
| Basic | Owner, Editor, Viewer | Avoid in production; far too broad |
| Predefined | roles/container.developer, roles/run.admin | The default choice |
| Custom | Your own list of permissions | When no predefined role is narrow enough |
Grant roles to groups, not individuals, and grant at the lowest level that works.
Organization policies
The Organization Policy Service sets constraints on what can be configured, whoever asks. A policy set on a folder is inherited by its projects unless a lower level overrides it, so a constraint can apply to just one part of the tree.
| Constraint | Effect |
|---|---|
gcp.resourceLocations | Limits the regions where resources can be created |
iam.allowedPolicyMemberDomains | Only identities from your domains can be granted roles |
iam.disableServiceAccountKeyCreation | Blocks downloadable service account keys |
compute.vmExternalIpAccess | Limits which VMs can have external IP addresses |
iam.automaticIamGrantsForDefaultServiceAccounts | Stops default service accounts getting Editor |
Custom organization policies use CEL conditions for rules no built-in constraint covers.
Service accounts
A service account is the identity of a workload. Create a dedicated, user-managed account per workload, grant it only the roles it needs, and attach it to the VM, Cloud Run service or GKE workload.
gcloud iam service-accounts create web-runtime --project=shop-web-prod
gcloud projects add-iam-policy-binding shop-web-prod \
--member="serviceAccount:web-runtime@shop-web-prod.iam.gserviceaccount.com" \
--role="roles/cloudsql.client"| Who acts | How |
|---|---|
| Deployer attaches the account to a service | Service Account User on that account |
| Pipeline or admin impersonates the account | Service Account Token Creator on that account |
| CI outside Google Cloud | Workload Identity Federation, no key file |
Prefer attached accounts and impersonation over keys, which are long-lived and easy to leak.
Data residency
Data residency means data must stay in named locations. Enforce it with gcp.resourceLocations on the folder that holds regulated projects, using value groups such as in:eu-locations.
Remember the non-obvious copies: choose the region of log buckets, Artifact Registry repositories, backups and BigQuery datasets too. Assured Workloads adds controls for regulated regimes on top of location policies.
A worked example
A retailer has 60 projects created by hand, Editor granted widely, and EU customer data that must stay in the EU. The engineer creates prod and nonprod folders per business unit and moves projects into them.
Groups receive predefined roles on folders, and Editor is removed. On the EU folder, gcp.resourceLocations is set to in:eu-locations, and iam.disableServiceAccountKeyCreation is enforced at the organization.
How the exam asks about this
- "All projects for a business unit must inherit the same access and restrictions, including projects created next year." Put them in a folder and set IAM and organization policies on the folder.
- "Resources for EU customers must never be created outside the EU." Set
gcp.resourceLocationswith an EU value group on the folder. - "A Cloud Build pipeline needs to deploy as a runtime service account without anyone holding a key." Grant the build's service account Service Account User on the runtime account.
What to remember for the exam
- Organization, folders, projects, resources; policies flow down.
- One project per application per environment; shared services in their own projects.
- Allow policies are additive; use deny policies to block inherited access.
- Organization policies restrict configuration; IAM decides who can act.
- One dedicated service account per workload, attached rather than keyed.
Granting a role at the organization or folder level gives it on every project below, including future ones. Check the scope before using a broad role high in the tree.
Common mistakes
Using one project for all environments. Production and test then share IAM, quotas and blast radius. Split them into separate projects under environment folders.
Expecting a project to remove an inherited role. A lower allow policy cannot take away a role granted on a folder. Change the folder grant or use a deny policy.
Forgetting data that is not in the main database. Logs, images and backups also hold data. Set their locations and enforce gcp.resourceLocations.
Check yourself
Why use folders rather than setting IAM on each project?
Policies set on a folder are inherited by every project in it, including new ones, so access and guardrails stay consistent with one change.
Which organization policy enforces data residency?
gcp.resourceLocations, which limits the locations where resources can be created, often with a value group such as in:eu-locations.
What lets a pipeline act as a runtime service account without a key?
Granting the pipeline's identity Service Account User, or Token Creator for impersonation, on that specific service account.
Topic 1 of 6 in Bootstrapping and maintaining a Google Cloud organization
Test yourself on Bootstrapping and maintaining a Google Cloud organization
The full Google Cloud Professional Cloud DevOps Engineer question bank has 751 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.