Prepare and test your skills
Prepare and test your skills
Applying and enforcing organization policies means using central guardrails to control what resources can be deployed and how they can be configured. The Organization Policy Service (opens in a new tab) is the centralized control plane for these guardrails. An organization policy administrator defines a policy as a set of restrictions called constraints, and Google Cloud enforces those constraints on the target node and on all descendants below it. Policies can be attached at the organization, folder, or project level, so a central team can set a secure baseline while delegating exceptions lower in the hierarchy.
Organization policy constraints are the rules that define allowed behavior for Google Cloud resources throughout the hierarchy. The Organization Policy Service provides built-in managed constraints for many services, and custom constraints provide granular control over specific fields when built-in constraints are not precise enough. A custom constraint restricts a specific operation on a specific resource type and is then used inside an organization policy like any managed constraint.
Constraints establish guardrails for deployment decisions without configuring each project individually. Common guardrails include resource location constraints that limit deployment to pre-approved regions for data residency and compliance, network configuration rules that control connectivity patterns, and controls on which services can be enabled or which virtual machine shapes can be provisioned. Because the policy attaches to a node in the hierarchy, the same definition protects every project beneath that node.
Organization policy inheritance means a policy attached to a parent is enforced on all child folders and projects below it. When a policy is enforced on a folder, Google Cloud enforces it on all projects in that folder and on all folders nested beneath it, through as many as 10 levels of folder nesting. A policy defined at a lower level can supersede the inherited policy from above, so teams use broad constraints at the top for organization-wide guidelines and narrower policies below for controlled exceptions.
This replacement behavior is different from Identity and Access Management (IAM) inheritance:
Exam tip: A lower-level organization policy supersedes an inherited organization policy, while a lower-level IAM allow policy adds to an inherited allow policy — only an IAM deny policy overrides an allow policy.
Policy placement determines the blast radius and purpose of an organization policy. The Organization resource (opens in a new tab) is the apex of the hierarchy and provides central visibility and control over every folder, project, and service resource beneath it. Folders group related projects so different teams can set policies that cascade across multiple projects, while projects contain service resources such as Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints.
The following table compares where to attach a guardrail:
| Hierarchy level | Scope of enforcement | Use for guardrails when |
|---|---|---|
| Organization | Every folder and project in the organization | The control must apply everywhere, such as data residency or baseline security |
| Folder | All projects and nested folders beneath that folder | The control varies by environment, team, region, or subsidiary |
| Project | Only resources inside that project | A workload needs an exception or tighter control than its parent |
A parent folder can contain up to 300 child folders, and folders can be nested up to 10 levels deep. If tenancy exceeds 300 tenants under one parent, tenants can be arranged into nested hierarchies to stay within the limit. Use a single organization node whenever possible to avoid management overhead, and use separate organization nodes only for specific isolation needs:
Keep a Bootstrap folder directly below the organization node for infrastructure-as-code and deployment foundations, and keep common services such as monitoring in a separate shared infrastructure location. When environments share monitoring and other global services, place shared infrastructure directly below the organization; when services differ by environment, place a separate shared folder inside each environment folder so production and non-production secrets, policies, and allow rules remain distinct.
Hierarchical controls beyond organization policies also follow the resource hierarchy to constrain behavior and preserve visibility. Hierarchical firewall policies implement consistent network controls throughout the organization or in specific folders with implicit inheritance, where a higher level can allow traffic, deny traffic, or delegate the decision to a lower level. This lets central networking teams enforce a baseline while folder owners refine rules for their own projects.
Cloud Logging (opens in a new tab) supports aggregated sinks that collect logs at the folder or organization level, so a per-environment folder can export all of its projects' logs together for audit and security analysis. Billing is assigned at the project level rather than directly to the hierarchy, but costs can be analyzed by project hierarchy in billing reports to show folder-level aggregates. Together, organization policies constrain what can be deployed, IAM controls who can act, firewall policies constrain network traffic, aggregated sinks preserve visibility, and billing reports preserve accountability across the same folder and project structure.
Designing resource hierarchies for separation of duties and security is the practice of arranging Organization, folders, and projects so environments, applications, and teams are isolated by enforceable boundaries. Resource Manager (opens in a new tab) provides the hierarchy, while Identity and Access Management (IAM) and organization policies provide the access and guardrail controls that flow through it. A well-designed hierarchy limits the blast radius of a compromise and lets different duties be assigned to different groups without overlap.
The Google Cloud resource hierarchy is a tree with the Organization resource as the root node, folders in the middle, and projects as the leaves that hold actual resources. Folders can contain both projects and other folders, and they are used to group similar projects and to apply folder-level IAM permissions that are inherited by everything below them. A Project is both a trust boundary for resources and an IAM enforcement point, so compromise of one project does not automatically grant access to a sibling project.
IAM and organization policies inherit downward, which makes level selection a security decision. A policy set at the Organization node applies globally across the cloud estate, while the same policy set at a folder or project applies selectively to only that branch. To implement defense in depth, document the security requirements of each component and then apply guardrails such as:
These guardrails reduce attack surface and help contain the impact when a lower-level identity or workload is compromised.
Separation of environments in the hierarchy means placing development, non-production or staging, and production workloads in distinct folders so testing activity cannot affect production. A common pattern places Development environment and Production environment folders on the first level below the Organization, then places an App 1 and App 2 folder inside each environment, then places separate projects inside each application folder for independent modules. This structure lets IAM allow policies and organizational constraints be attached at the environment level for broad isolation and at the application or project level for fine-grained team access.
Application identity reinforces the same separation by representing each deployment environment as a distinct application, such as my-app-dev, my-app-staging, and my-app-prod. Separating environments into distinct applications creates precise limits for access control, policy enforcement, and monitoring, and the Environment attribute provides metadata for filtering, reporting, and resource-specific control. Application management boundaries should then be aligned with team structures through a dedicated management project, so the ownership model mirrors how duties are divided between development, security, and operations teams.
Bootstrap and shared infrastructure folders isolate the tooling that builds and observes the cloud from the applications that run in it. The Bootstrap folder contains the infrastructure-as-code, pipelines, and common resources required to deploy Google Cloud infrastructure, and it is placed directly below the Organization node so its highly privileged deployer identities are separated from every environment. Shared services folders hold resources used by multiple applications or environments, such as monitoring, and their level depends on their sharing scope.
| Placement | Choose when | Example contents |
|---|---|---|
| Shared infrastructure folder below Organization | The hierarchy uses application environments at the highest level and services such as monitoring are common between environments | Central monitoring, organization-wide logging, cross-environment observability |
| Shared folder below each environment or application | Services are shared between applications but a separate instance is deployed for each environment | Folder-level secrets project with different allow policies for production secrets and non-production secrets |
Placing a shared service too high grants it broader inheritance than needed, while placing it too low duplicates management effort. Choose top-level placement when one instance serves all environments, and choose environment-level placement when each environment needs an independent, differently permissioned instance.
Exam tip: The Bootstrap folder always sits directly below the Organization node, while a common services folder sits below the Organization only when the service is shared across environments.
Separation of duties in a resource hierarchy means no single user or service can abuse authorized privileges without collusion, which is achieved by splitting roles across groups and hierarchy levels. Access controls follow the principle of least privilege, where groups receive only the predefined or custom roles they need on only the Organization, folder, or project where they need them. Effective enforcement requires defining a separation-of-duties policy, creating groups, granting roles to those groups rather than to individuals, and regularly analyzing and adjusting assignments with policy analysis tools.
Hierarchy level is itself a least-privilege control. Broad roles assigned at the Organization or folder level are overly broad when the duty is project-scoped, so Memorystore for Redis roles such as roles/redis.admin, roles/redis.editor, and roles/redis.viewer must be assigned at the project level rather than at the Organization or folder level. Similarly, placing secrets in a folder-level secrets project lets administrators apply different allow policies to production and non-production secrets, so developers with non-production access cannot read production credentials even when the application code is similar.
Regulated workloads require logical segmentation that can prove an out-of-scope system could be compromised without impacting the security of the in-scope system. In a Payment Card Industry Data Security Standard design, the cardholder data environment (CDE) includes the people, processes, and technology that store, process, or transmit cardholder data, plus the IAM systems, segmentation systems such as projects, folders, firewalls, virtual private clouds (VPCs), and subnets, and the application pods and clusters that handle that data. Without adequate segmentation through the resource hierarchy and network, the entire cloud footprint falls into audit scope, so cardholder data is consolidated into as few projects and folders as possible.
VPC Service Controls (opens in a new tab) extends hierarchy isolation with security perimeters that isolate services and resources through authorization, access controls, and secure data exchange. A data ingestion perimeter accepts incoming batch or streaming data and de-identifies it in a landing zone that protects other workloads, while a confidential data or data perimeter isolates re-identified or encrypted data from other workloads. A separate governance perimeter stores encryption keys and defines data classification, catalog management, and logging, which separates governance duties and key custody from the teams that use the data in the warehouse.
Managing projects as resource containers and billing units means treating the Google Cloud project as the primary unit for deployment, cost, and capacity. A Google Cloud project (opens in a new tab) sits below the Organization resource and folders in the resource hierarchy, so folders group projects for policy and visibility while the project itself controls isolation, cost attribution, and capacity. Every service resource lives inside a project, every project links to a billing account for charges, and quotas are measured and enforced per project.
A Google Cloud project is the container that holds service resources such as Compute Engine (opens in a new tab) virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints. Resources are created in a project through the Google Cloud console, Cloud Shell, or Cloud APIs, and teams that expect frequent changes use infrastructure as code (IaC) such as Terraform or Deployment Manager to keep creation repeatable. The hierarchy flows from the Organization resource at the root to folders that group related projects, then to projects that directly contain the workload resources.
Projects are the primary method for segregating resources because three controls stop at the project boundary. First, configuration such as Identity and Access Management (IAM) is per project, so a misconfiguration in one project does not automatically affect workloads in another project. Second, workload security is stronger across projects by default, so a compromised or misbehaving workload in one project has limited impact on workloads in other projects. Third, resource quota is established and enforced per project, so spreading clusters or applications across projects prevents one autoscaled workload from exhausting the limits for an entire environment.
This isolation creates a tradeoff for application-centric and team-based ownership. A platform team can place only one cluster in each project and group those projects in a per-environment folder to progressively roll out IAM changes and apply low-risk production policies and aggregated log sinks at the folder level. A smaller organization with looser service objectives can keep all per-environment clusters in a single project to reduce management overhead, but then it loses the blast-radius protection for configuration, security, and quota.
Projects as billing and quota units means the project determines who pays and how much capacity is available. Billing in Google Cloud is assigned at the project level, not directly to the folder hierarchy. Each project links to a billing account, usage from all resources in that project flows to that billing account, and costs can then be aggregated upward for reporting by project hierarchy at the folder or organization level. This design means folder structure shapes visibility and governance, while the project remains the unit that determines who pays.
Quotas follow the same project boundary and directly affect the ability to create resources. Because limits are enforced per project, a single project that hosts many teams or clusters can run out of capacity even when the organization has capacity elsewhere. Design choices that split production, staging, and development into separate projects, or that split tenants and clusters into dedicated projects, limit the impact of quota exhaustion to one environment or team. Planning must therefore consider how many projects are needed, how workloads are distributed across them, and how project quotas will scale with growth and with multiple teams working simultaneously.
Fine-grained cost visibility below the project level depends on labels. Labels are key-value pairs assigned to cloud resources that identify assets more specifically than folders and projects allow. Label data flows from resources into Cloud Billing reports and Cloud Billing export to BigQuery, where costs can be filtered by labels for chargeback and analysis. Consistent labeling is required for this flow to work, so deployment processes must create project, folder, and label assignments the same way across the organization.
Project creation establishes the parent, name, and billing link that define the project's lifecycle. A new project is created under a selected Organization resource or folder parent, and creating the first project provisions the organization resource automatically. Independent test or proof-of-concept projects that were created outside the organization can later be migrated into the organization to bring them under central visibility and control.
Creating a project in the console follows an ordered workflow:
Billing selection depends on IAM roles on the organization or billing account. The combination of Project Creator and Billing Account User allows creation of new projects linked to that billing account, while the combination of Project Billing Manager and Billing Account User allows linking and unlinking existing projects. For frequent hierarchy changes, automated provisioning through IaC replaces manual console steps and keeps folder, project, and bootstrap resources consistent. Bootstrap resources for deploying infrastructure and common shared services are kept in separate folders directly below the organization node so lifecycle tooling does not mix with application workloads.
Exam tip: Billing attaches to the project, not the folder — folders only aggregate project costs in reports, while quotas are also enforced per project.
Standardized naming and governed labeling let projects support application-centric and team-based ownership at scale. A standardized naming convention is applied throughout the organization so projects, folders, and resources can be identified and automated without ambiguity. Labels extend that identification to individual resources when folder and project structure alone is not specific enough.
Labels are used for peer purposes that folders cannot express alone:
Google-managed assets carry Google-assigned labels prefixed with goog-, such as labels for Google Kubernetes Engine, Compute Engine, Managed Service for Apache Spark, and Gemini Enterprise Agent Platform Workbench. These labels identify resources that Google services manage inside a customer virtual private cloud (VPC) and should not be deep-inspected or overwritten by customer automation. Governance for customer-assigned labels, combined with IaC-based provisioning, prevents inconsistent infrastructure that makes asset inventories and compliance reporting unsupportable.
Ownership models build on this foundation through the application management boundary. The resource hierarchy provides the base grouping, and a management project defines the application management boundary on top of it through Application Hub. Choosing a single project, a folder, or a set of projects as that boundary shapes governance, policy enforcement, and resource discovery, and product support varies by pattern. A parent folder can contain up to 300 folders with nesting up to 10 levels deep, so tenants can be arranged into nested hierarchies when scale requires it, while designs are regularly refined to keep applications aligned with business functions and team structures.
Organization policies flow from parent to child and a policy defined at a lower level supersedes the inherited policy from above for that branch, while Identity and Access Management allow policies also flow from parent to child but child allow policies are additive with parent allow policies. Only Identity and Access Management deny policies, which are evaluated before allow policies, can supersede allow policies.
Attach the policy at the Organization resource when the control must apply everywhere such as data residency or baseline security, at a folder when the control varies by environment, team, region, or subsidiary, and at a project when a workload needs an exception or tighter control than its parent. A policy attached to a node is enforced on all child folders and projects below it.
The Bootstrap folder sits directly below the Organization node so its highly privileged deployment identities are separated from every environment workload. A shared infrastructure folder sits below the Organization when services such as monitoring are common between environments, while a separate shared folder inside each environment folder is used when each environment needs an independent, differently permissioned instance.
Billing in Google Cloud is assigned at the project level where each project links to a billing account, and quotas are also enforced per project rather than per folder. Folders only aggregate project costs in billing reports by project hierarchy, so splitting workloads across projects limits the impact of quota exhaustion and preserves cost attribution for each environment or team.
An enterprise is designing its Google Cloud resource hierarchy to support multiple development teams while meeting strict security, compliance, and operational governance requirements:
Development environments to rapidly iterate, but must have strictly restricted, read-only permissions in Production where changes are deployed exclusively through CI/CD service accounts.Which resource hierarchy and access architecture should the team implement?
Last updated