Resource Hierarchy & Inheritance
In Google Cloud, the resource hierarchy is the backbone of how you manage access, organize services, and control billing. It follows a strictly hierarchical structure where policies applied at higher levels are inherited by all child resources.
Core Concepts
1. The Organization Node
The root of the hierarchy. It represents your company and is linked to a Google Workspace or Cloud Identity domain. It provides central visibility and control over all resources in the company.
2. Folders
Folders allow you to group projects and other folders. This is where you map your GCP environment to your organizational structure (e.g., Departmental, Regional, or Environment-based like Prod/Dev).
3. Projects
The base level for enabling APIs, managing billing, and adding services. Every resource must belong to exactly one project. Projects are the “trust boundary” for most services.
4. Resources
The actual services: Compute Engine instances, Cloud Storage buckets, BigQuery datasets, etc.
Policy Inheritance (The “Why”)
GCP uses a Union policy model. If a user is granted “Storage Admin” at the Folder level and “Compute Admin” at the Project level, their effective permissions on that project are both roles. You cannot “strip away” a permission inherited from a parent using an IAM Allow policy.
Scenario-Based Usage
- Compliance: Apply a “Deny” policy at the Org level to prevent any project from creating external IP addresses.
- Billing: Link multiple projects to a single Billing Account, but group them under folders to track costs by department.
- Mergers: Move an entire folder from one Org to another (requires specific Resource Manager permissions).
| Feature | Google Cloud (GCP) | AWS Equivalent |
|---|---|---|
| Root Container | Organization | AWS Organizations (Root) |
| Grouping Mechanism | Folders | Organizational Units (OUs) |
| Resource Container | Project | AWS Account |
| Service Policies | Organization Policy Service | Service Control Policies (SCPs) |
- The “Union” Rule: IAM permissions are additive. You cannot revoke a permission at a child level if it was granted at a parent level.
- Project Deletion: When you delete a project, it enters a 30-day “soft delete” state before permanent removal.
- Folder Nesting: Folders can be nested up to 10 levels deep (but 3-4 is usually the architectural sweet spot).
- Organization Policy vs. IAM: IAM defines who can do what. Organization Policies define what can be done with a resource (e.g., restricting locations).
Common Interview Questions
They are an Editor. Permissions are the union of all policies.
Use Organization Policies to restrict specific resource types or VM machine types at the Org or Folder level.
Yes (as a “No Organization” project), but this is not recommended for enterprises as it lacks central management.
10 levels.
30 days.
Visualizing GCP Resource Hierarchy
Flow: Policies flow DOWN. Visibility flows UP.
IAM: Role assignments at any level inherit downwards.
Cloud Billing: Linked at the Project level, but can be managed at Org level.
Resource Manager API: The engine that handles moves, deletes, and tags.
Quotas: Most quotas are enforced at the Project level.
Limits: 10 levels of folders; 30 projects per Org by default (adjustable via request).
Speed: Hierarchy changes (IAM) propagate in seconds.
Billing Export: Always export billing data to BigQuery at the Billing Account level.
Labels vs Tags: Use Labels for cost filtering and Tags for conditional IAM/Org policies.
Production Use Case: Multi-Tenant SaaS
A SaaS provider uses Folders for each client. Each client folder contains a Project for “Data Ingestion” and “Reporting.” By applying IAM roles at the Client Folder level, the provider ensures client isolation while maintaining global admin access from the Organization level.