Resource hierarchy (organizations, folders, and projects)

Organization Policy Enforcement and Guardrails

Centralized Control with Constraints

The Google Cloud resource hierarchy provides a structured way to manage everything, starting with an organization at the top. This organization contains folders and projects, which hold service resources like virtual machines. The Organization Policy Service uses this structure to apply security guardrails. It enforces rules called constraints to restrict how Google Cloud services can be used, helping to prevent misconfiguration and control costs across the entire company.

Policy Inheritance and Management

A key feature is policy inheritance. When a policy is set at a high level, like the organization or a folder, it automatically applies to all the projects and resources below it. This creates a consistent security baseline. Administrators can also set policies directly on a project, and the effective policy for any resource is a combination of its own settings and all the rules it inherits from above. To create and manage these policies, especially custom ones, a user needs the Organization Policy Administrator role.

Creating Security Guardrails

These policies act as protective guardrails. For example, a constraint can restrict where resources are physically located for legal reasons, limit the types or sizes of virtual machines to manage spending, or enforce naming patterns for projects to keep things organized. Custom constraints are written using a language called Common Expression Language (CEL) for very specific control. It's important to check that existing resources follow the new rules before enforcing a policy, as policies are not retroactive.

Hierarchical Structure and IAM Inheritance

The Hierarchy of Ownership

The resource hierarchy is a tree-like structure for organizing and owning everything in Google Cloud. The Organization is the root and represents your entire company. Below it, optional Folders can group projects by department, team, or environment (like production vs. development). At the bottom, Projects are the essential containers where you actually create resources like Compute Engine VMs or Cloud Storage buckets. The lifecycle of a resource is tied to its parent project or folder.

How IAM Permissions Flow

Identity and Access Management (IAM) policies follow this hierarchy through inheritance. If you grant a user a role at the organization level, that permission flows down and applies to every folder and project inside it. The effective policy for a specific resource is the combination of all permissions granted directly to it and all permissions inherited from its ancestors. This system allows for centralized security management. You can also use Deny policies to block specific permissions at a lower level, even if they were allowed from above, which helps enforce the principle of least privilege.

Designing an Effective Hierarchy

Good hierarchy design focuses on business needs rather than just copying a company's org chart. Best practices include using a single organization node for central visibility and control. It's also recommended to create separate "bootstrap" folders for infrastructure management tools, keeping them isolated from actual workloads. The core security principle is to grant IAM roles at the lowest possible level (e.g., on a specific project instead of the whole organization) to limit users' access only to what they absolutely need.

Administrative Isolation and Resource Grouping

Using Folders for Logical Separation

Folders are the primary tool for creating administrative isolation and logical boundaries within an organization. You can use them to separate distinct business units, like "Finance" and "Engineering," or different environments, like "Production," "Staging," and "Development." This separation allows you to delegate administrative control to different teams for their own folder without giving them access to other parts of the company's cloud resources. It also helps apply specific security policies and quotas to each logical group.

Projects as the Operational Unit

While folders provide grouping, Projects are the operational unit where services are enabled and resources are created. Each project has its own unique identifiers and, by default, its resources are isolated from those in other projects. Billing is also managed at the project level by linking each project to a Cloud Billing account. This makes projects ideal for separating workloads with different cost centers or for isolating different application environments.

Managing Costs and Ownership

Although billing is assigned per project, you can use Labels (key-value pairs) on resources to track costs with more granularity across departments or teams, regardless of which project they are in. Effective resource grouping through folders and projects ensures billing responsibilities are clear. A key best practice is to establish standardized naming conventions for all folders and projects. This, combined with keeping foundational "bootstrap" resources (like those for infrastructure-as-code tools) in their own isolated folder, creates a clean, scalable, and well-managed hierarchy.