Prepare and test your skills
Prepare and test your skills
Designing a secure and compliant resource hierarchy means organizing Google Cloud workloads into a multi-level tree that supports governance, isolation, and auditability. The tree starts at a single organization (opens in a new tab) node as the root, branches into folders (opens in a new tab) that group related work, and ends in projects (opens in a new tab) that host resources such as virtual machines, storage buckets, and networking. Folders act as policy attach points and isolation boundaries, while projects act as the core billing and trust boundary for resources.
How folders, projects, and inheritance enforce governance is through a single inheritance path that carries guardrails from parents to children. Every folder or project has exactly one parent, so policy always flows from the organization through folders to the project. Organization policies are inherited by descendants but can be superseded by a policy defined at a lower level, which allows central guardrails with targeted exceptions.
Identity and Access Management (IAM) allow policies are also inherited and are additive, so a grant on a folder applies to all projects in that folder. IAM deny policies are evaluated before allow policies and can supersede allows at the project, folder, and organization level. For example, a grant of Compute Instance Admin on a folder gives that role on all contained projects, while a deny placed higher in the tree can still block the action even when a lower-level allow grants it.
Exam tip: Allow policies inherit and add together down the hierarchy, but deny policies are applied first and can override an allow; organization policies inherit down but can be overridden by a lower-level organization policy.
Folder limits and project moves determine whether a hierarchy can grow without breaking access. A parent folder can contain up to 300 direct child folders, folders can be nested up to 10 levels deep, and folder display names must be unique within the same level of the hierarchy. When tenant count exceeds 300, tenants must be arranged into nested hierarchies to stay within the direct-child limit.
Projects can be created at any level, and creating a project in a folder requires the Project Creator role on that folder. Moving a project into or out of a folder does not move inherited permissions with it, because directly attached IAM and organization policies move with the project while inherited policies stay with the source parent. If a service account receives Storage Object Creator from Folder A, moving a project from Folder A to Folder B removes that inherited access unless Folder B grants the same permission, which can cause an outage.
How to choose a hierarchy model is to follow business and security needs rather than copying the corporate organization chart. Key design factors are who is responsible for cloud resources, what compliance needs apply, and whether mergers, acquisitions, or spin-offs are expected. Most organizations use a hybrid approach at different levels, starting with the grouping that most affects policies and access.
The documented decision flow evaluates requirements in order. First, if subsidiaries, regional groups, or business units have very different policy requirements, use a region or subsidiary design. If not, evaluate team autonomy next: if workload or product teams require strong autonomy without a central security team setting policy, use an accountability-framework design, while central control favors an application-environment design.
The three hierarchy models are different ways to group top-level folders, and they trade central consistency for team autonomy. Centralized models standardize guardrails from the top down, while decentralized models push ownership to product teams. The choice controls who sets policy, how compliance is enforced, and how much coordination is required.
| Hierarchy model | Top-level grouping | Control model and tradeoff |
|---|---|---|
| Based on application environments | Development, testing, and production folders | Centralized; central security team enforces consistent production controls and separate IAM per environment, but teams have less policy autonomy |
| Based on regions or subsidiaries | Subsidiary and regional folders such as APAC, EMEA, and Americas | Federated; each region or subsidiary keeps independent processes and regulatory controls, but cross-region consistency requires more coordination |
| Based on accountability framework | Product or module folders such as Ecommerce Modules and Reconciliation and Billing | Decentralized; product owners control lifecycle, security, and access for independent workloads, but organization-wide guardrails are uncommon and harder to enforce |
Choose the environment model when development, testing, and production need different policies, audit rules, and access, such as stricter Payment Card Industry Data Security Standard (PCI DSS) controls and hardware security module use only in production. Choose the region or subsidiary model when regions operate independently with different operational backbones and regulatory standards. Choose the accountability model when products are independent, share few common policies, and are delivered as service or product offerings.
Enterprise separation of duties uses dedicated folder branches so each operational owner controls only its own scope. In the documented enterprise pattern, three top-level folders divide ownership: a Network Team folder hosts virtual private clouds (VPCs), a Cluster Team folder hosts platform clusters (opens in a new tab), and a Tenants folder hosts tenant non-cluster resources. The Network Team branch uses subfolders for tenant and cluster networks with one project per environment, while the Tenants branch uses one subfolder per tenant with one or more projects per tenant.
The Cluster Team branch uses per-environment folders that each group multiple projects, which supports both isolation and shared governance. Placing clusters in dedicated projects improves isolation for three related reasons:
Per-environment folders above those projects still allow low-risk policies and aggregated log sinks to apply to all production clusters at once. Best practices reduce overhead while preserving visibility: use a single organization node whenever possible, use standardized naming, and start with a sandbox folder to validate the hierarchy. Keep the bootstrap (opens in a new tab) folder with infrastructure-as-code resources directly below the organization node, place common shared infrastructure directly below the organization when monitoring is shared, and place environment-specific shared services lower so production and non-production secrets carry different allow policies.
Configuring and auditing access controls across the hierarchy means attaching IAM allow and deny policies at the organization, folder, and project levels and monitoring how those policies inherit. The Organization resource (opens in a new tab) is the apex node that provides central visibility and control over every folder, project, and service resource below it. Folders (opens in a new tab) group projects that share common policies, while projects contain service resources such as Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints.
IAM identities, roles, and policies define who can act, what they can do, and where that permission applies in Google Cloud. A principal is an identity that can receive access, a role is a collection of permissions, a permission allows a specific operation, and an IAM allow policy binds principals to a role on a specific resource. When an allow policy is attached to an organization, folder, or project, every principal in that binding gains all permissions in the role for that resource and its descendants unless blocked by a deny.
IAM recognizes four principal types that cover people and workloads:
How allow and deny policies combine determines the effective access for every resource below the attachment point. Organization policies are inherited by all descendants but can be superseded by a policy defined at a lower folder or project level. IAM allow policies are also inherited and are additive, so permissions granted at the organization plus permissions granted at a folder and project all combine for a principal.
IAM deny policies restrict permissions at the organization, folder, and project level and are evaluated before allow policies, so a deny overrides additive allow inheritance. Hierarchical firewall policies follow a similar implicit inheritance model where traffic can be allowed or denied at any level or the decision can be delegated to a lower level. This order means broad allows at the top remain manageable because a targeted deny can still block sensitive actions.
Exam tip: Allow policies add together down the hierarchy, but deny policies are applied before allow policies, so a deny at any level blocks access even when an allow is inherited from above.
Where a role is attached controls the blast radius of access because folder-level policies control all resources the folder contains. If a user is granted the Compute Instance Admin role on a folder, that user has that role for all projects in that folder. A given folder or project has exactly one parent, so inheritance flows through a single path from organization to folder to project to resource.
| Level | Scope of attachment | Inheritance and audit effect |
|---|---|---|
| Organization resource | Entire company hierarchy under one root node | Central visibility and control; policies and aggregated sinks here apply to all descendants |
| Folder | Department, environment, team, or tenant branch | Policies cascade to all child folders and projects; enables delegation and per-branch auditing |
| Project | Workload, environment instance, or cluster boundary | Strongest isolation for IAM, quota, and workload security; misconfiguration affects only that project |
Choose the organization level for central guardrails and visibility, the folder level for shared team or environment controls, and the project level for strict workload isolation and least privilege.
Scaling access depends on separating human access from workload access and delegating administration at folder branches. The scalable pattern is to first identify the groups needed and their scope of operations, then assign the appropriate IAM role to the group rather than to individual users. Cloud Identity centrally manages those users and groups and enables single sign-on, while service accounts give applications and Google Cloud products their own principals that cannot perform any action they are not permitted to do.
Delegation scales administration because folders act as isolation boundaries and attach points for access and configuration policies. Grant the entire domain the Organization Viewer and Folder Viewer roles at the organization resource when broad visibility of structure is needed, and grant Folder Viewer only on specific folders to restrict visibility to branches. To manage folders for the entire organization, a principal needs the Folder Admin role, which grants permission to create, edit, delete, move, and change IAM permissions on folders and to move projects between folders, and initially only the Organization Administrator can assign that role.
Auditing policy changes at scale requires collecting evidence at the folder or organization level instead of checking each project individually. The resource hierarchy (opens in a new tab) supports Cloud Logging aggregated sinks that collect logs at the folder or organization level, which allows a per-environment folder to export all of its projects logs together for monitoring policy changes and access activity. Because billing is assigned at the project level, costs can still be analyzed by project hierarchy in billing reports to detect unexpected resource creation tied to access changes.
Consistency is required for auditing to remain trustworthy when frequent changes occur across many teams and projects. An infrastructure as code approach with standardized naming and consistent folder, project, and label assignment prevents drift that would hide resources from folder-level sinks and reports. The enterprise pattern with top-level folders for network, clusters (opens in a new tab), and tenants shows this balance: per-environment folders apply low-risk policies and host aggregated sinks, while separate projects isolate configuration, workload security, and quota. This combination lets central security enforce consistent production controls, delegate day-to-day administration at folder branches, and still retain organization-wide detection of violations in the foundation (opens in a new tab).
Implementing and managing organizational policies at scale means using guardrails that enforce security, compliance, and cost controls across the Google Cloud resource hierarchy. The hierarchy flows from the organization resource (opens in a new tab) at the root to folders (opens in a new tab) in the middle to projects (opens in a new tab) that hold workloads such as Compute Engine virtual machines, Cloud Storage buckets, Pub/Sub topics, and Cloud VPN endpoints. Policies attached high in the hierarchy cascade downward, while folders provide the attachment points to standardize controls for departments, environments, and regulated workloads without managing every project individually.
How organization policy constraints inherit is through rules based on constraints that flow to all descendants but allow controlled exceptions. A constraint set at the organization resource flows to every folder and project below it, while a folder-level policy replaces the inherited result for that folder subtree. This model lets a central team set organization-wide guidelines and still permit exceptions for specific folders or projects.
A common compliance use is resource location constraints, which restrict where workloads can be deployed to pre-approved regions. That control supports data residency and regulatory needs such as General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), and Payment Card Industry Data Security Standard (PCI DSS) requirements. The exception path matters because a regulated production branch can keep strict location limits while a sandbox branch allows broader testing.
The interaction of allow and deny policies determines effective access after inheritance and project moves. Identity and Access Management (IAM) allow policies grant roles to principals and are inherited by descendants, with grants at lower levels being additive to grants from above. A user granted the Compute Instance Admin role on a folder holds that role for all projects in that folder, plus any additional roles granted directly on a child project.
IAM deny policies restrict permissions at the organization, folder, and project level and are evaluated before allow policies, so a deny can supersede an otherwise additive allow. Moving a project breaks inheritance from its old parent, because directly attached allow policies and organization policies move with the project while inherited permissions do not. If a service account holds Storage Object Creator on Folder A, workloads in Folder A projects can upload to Cloud Storage, but moving one project to Folder B without the same grant removes upload ability and the workload can fail.
Exam tip: IAM allow policies combine additively down the hierarchy, but IAM deny policies are applied before allow policies and can block an inherited allow.
Folders as policy attachment points group projects and other folders that share common allow, deny, or organization policies. Each folder or project has exactly one parent, so policy inheritance follows a single path from the organization resource through nested folders to the project. Folders enable delegated administration, environment separation such as production versus staging, and policy-centric splits such as Standard Workloads, Regulated Workloads, Non-Prod Environment, Production Environment, Customer-Facing (Restricted), and Internal-Only (Standard).
Folder scale and structure follow strict limits that shape enterprise design:
A per-environment folder can carry low-risk policies for all production clusters (opens in a new tab) and host aggregated log sinks even when clusters are isolated in separate per-environment projects for configuration, workload, and quota isolation.
The four policy types enforce different layers of control through the same hierarchy. Organization policies constrain what configurations are permitted, IAM policies control who can act, and network policies control what traffic is permitted. The comparison preserves their inheritance and enforcement differences.
| Policy type | Inheritance behavior | Enforcement effect |
|---|---|---|
| Organization policies | Inherited by descendants, superseded by lower-level policy | Constraint sets guidelines for the organization or subtree while allowing exceptions |
| IAM allow policies | Inherited by descendants, lower-level grants are additive | Binds principals to roles; folder grant applies to all contained projects |
| IAM deny policies | Applies at organization, folder, and project level, evaluated before allows | Restricts permissions even when an allow policy would otherwise grant them |
| Hierarchical firewall policies | Implicit inheritance through organization or folders | Allows or denies traffic at any level or delegates the decision to a lower level |
Project moves illustrate why this precedence matters at scale. Organization policies behave like IAM inheritance, so source and destination folders must have consistent constraints before a move. Otherwise a workload that was compliant under Folder A can violate Folder B controls or lose access it inherited from Folder A.
Extending hierarchy enforcement connects organization and IAM controls to observability, cost analysis, and networking. Cloud Logging supports aggregated sinks that collect logs at the folder or organization level, so a production folder can export all child-project logs to one destination. Log flow therefore runs from child projects upward to the folder or organization sink that central security monitors.
Billing is assigned at the project level and is not directly linked to the hierarchy, but billing reports can analyze costs by project hierarchy to give folder-level spend for business units or applications. Hierarchical firewall policies apply consistent network controls through the organization or selected folders, where traffic control flows from the higher-level policy to child folders and projects unless the decision is delegated downward. This structure is maintained in the documented foundation (opens in a new tab) approach with a bootstrap folder directly below the organization and shared-services placement chosen by whether services are common across environments or specific to one environment.
Identity and Access Management (IAM) allow policies are inherited down the hierarchy and combine additively, while Identity and Access Management (IAM) deny policies are evaluated before allow policies and can block an inherited allow. For example, a Compute Instance Admin grant on a folder applies to all projects in that folder, but a deny placed higher in the tree can still block the action even when a lower-level allow grants it.
Moving a project does not move inherited permissions with it because directly attached Identity and Access Management (IAM) and organization policies move with the project while inherited policies stay with the source parent. If a service account received Storage Object Creator from Folder A, moving its project to Folder B removes that inherited access unless Folder B grants the same permission.
A parent folder can contain up to 300 direct child folders, folders can be nested up to 10 levels deep, and folder display names must be unique within the same level of the hierarchy. Every folder or project has exactly one parent, so tenants beyond 300 must be arranged into nested hierarchies and inheritance always follows a single path from the organization through folders to the project.
An enterprise is establishing a multi-tier Google Cloud resource hierarchy to support several business units with strict regulatory requirements across Development, Staging, and Production environments. The security architecture must satisfy the following constraints:
Which resource hierarchy and access governance architecture should the organization deploy?
Last updated