Google Cloud Resource Hierarchy

Introduction to the GCP Resource Hierarchy

The GCP Resource Hierarchy is the essential structure that determines how you organize your Google Cloud resources. For anyone preparing for the Associate Cloud Engineer (ACE) exam, understanding the GCP Resource Hierarchy is non-negotiable. It is not merely a way to group items; it is the fundamental mechanism for managing access control (IAM), applying organization policies, and handling billing across your entire cloud footprint.

Think of the GCP Resource Hierarchy as the "spine" of your cloud environment. Every resource you create, from a simple Compute Engine VM to a complex BigQuery dataset, must be attached to this hierarchy. By understanding the GCP Resource Hierarchy, you can ensure that your organization remains secure, compliant, and cost-efficient.

白話文解釋（Plain English Explanation）

To help you internalize the concept of the GCP Resource Hierarchy, let's look at three different analogies that represent how structure and inheritance work in Google Cloud.

1. The Corporate Headquarters (Physical Structure)

Imagine a massive international corporation:

• The Organization is the entire Corporation itself. It represents the legal entity and the root of all operations.
• Folders are the different Business Units or Departments, such as "Finance," "Engineering," or "Marketing." Some floors might have sub-departments (nested folders).
• Projects are the specific Teams or Offices within those departments. This is where the actual work happens.
• Resources are the Desks, Computers, and Files inside those offices.

If you have a badge that grants you entry to the "Engineering Floor" (Folder), you automatically have access to all the "Engineering Offices" (Projects) on that floor. You don't need a separate badge for every office. This is how the GCP Resource Hierarchy handles inheritance.

2. The File System (Digital Structure)

Think about the file system on your computer:

• The Organization is the Root Directory (e.g., C:\ or /).
• Folders are the Sub-folders you create to organize your files (e.g., /Users/Work/2024/).
• Projects are the specific Workspaces or Application Folders.
• Resources are the individual Documents, Images, and Code Files.

If you set a folder to be "Read Only," every file inside that folder inherits that property. In the GCP Resource Hierarchy, policies and permissions behave exactly like these file system attributes—they flow from the top down.

3. The Family Tree (Biological Structure)

Consider how traits and rules are passed down in a family:

• The Organization represents the Great-Grandparents.
• Folders represent the Parents.
• Projects represent the Children.
• Resources represent the individual Traits or Possessions.

In this GCP Resource Hierarchy analogy, if the "Great-Grandparent" establishes a rule (a Policy), that rule is inherited by the parents, and then by the children. You cannot simply "opt-out" of a family rule at the child level if it was set at the top. This illustrates the "additive" and "non-restrictive" nature of IAM in the GCP Resource Hierarchy.

The Four Pillars of the Hierarchy

The GCP Resource Hierarchy consists of four distinct levels, each serving a specific purpose in the management lifecycle.

The Organization Node

The Organization resource is the root node of the GCP Resource Hierarchy. It is the top-level container for all other resources in your company. An Organization is created automatically when a Google Workspace or Cloud Identity customer creates their first project.

Folders: The Grouping Layer

Folders provide an additional grouping mechanism and an isolation layer between projects. They allow you to model your GCP Resource Hierarchy after your organization's internal structure. You can nest folders up to 10 levels deep.

Projects: The Service Container

The Project is the primary level at which you enable APIs, manage billing, and add/remove collaborators. Every resource in Google Cloud MUST belong to exactly one project. Projects are the "working units" of the GCP Resource Hierarchy.

Resources: The Leaf Nodes

Resources are the service-level components that do the actual work. Examples include Compute Engine VMs, Cloud Storage buckets, and App Engine instances. These are the "leaves" of the GCP Resource Hierarchy tree.

Understanding Policy Inheritance

The most critical concept within the GCP Resource Hierarchy is how policies and permissions are inherited. Policies flow from the top (Organization) down to the bottom (Resources).

How Permissions Flow

When you grant a role to a user at a higher level in the GCP Resource Hierarchy, that user automatically receives those same permissions for all child resources. For example, if you grant "Storage Object Viewer" at the Folder level, the user can view objects in every bucket in every project inside that folder.

The Additive Nature of IAM

IAM permissions in the GCP Resource Hierarchy are additive. This means that if a user has a role at the Project level and a different role at the Resource level, their total permissions are the sum of both.

Overriding vs. Complementing Policies

While you can add permissions as you move down the GCP Resource Hierarchy, you generally cannot "remove" an inherited permission at a lower level using standard IAM. If a user is an "Editor" at the Folder level, they will be an "Editor" on all projects within that folder, even if you try to make them only a "Viewer" at the project level.

Managing Organizations

The Organization node is the gateway to centralized management within the GCP Resource Hierarchy.

Creating the Organization Node

Most companies acquire an Organization node by signing up for Google Workspace or Cloud Identity. Once the domain is verified, the Organization resource is provisioned.

Organization Admins

The roles/resourcemanager.organizationAdmin role is the most powerful role in the GCP Resource Hierarchy. This person can define the structure of the hierarchy and delegate administrative tasks to others.

Linking with Cloud Identity

The GCP Resource Hierarchy relies on Cloud Identity (or Google Workspace) for user authentication. The Organization node acts as the bridge between your corporate directory and your cloud resources.

Working with Folders

Folders are the most flexible part of the GCP Resource Hierarchy, allowing for complex organizational designs.

Folder Hierarchies

You can use folders to separate production environments from development environments. This is a common pattern in the GCP Resource Hierarchy to ensure that "dev" experiments don't accidentally affect "prod" stability.

Folder-Level IAM Roles

By applying roles at the folder level, you can manage access for entire teams across multiple projects simultaneously, simplifying the management of the GCP Resource Hierarchy.

Nesting Limits and Best Practices

While you can nest folders 10 levels deep, best practices for the GCP Resource Hierarchy suggest keeping it as flat as possible (usually 2-3 levels) to avoid complexity and "permission sprawl."

Project Management Essentials

Projects are where the "rubber meets the road" in the GCP Resource Hierarchy.

Project IDs vs. Project Names

• Project Name: A human-readable name you choose. It doesn't have to be unique.
• Project ID: A globally unique string used to identify the project in APIs and the CLI. It cannot be changed after creation.
• Project Number: A unique number assigned by Google Cloud.

Project Quotas

Every Organization has a "Project Quota," which limits how many projects can be created. If you hit this limit while building out your GCP Resource Hierarchy, you must request an increase from Google.

Moving Projects Between Folders

Moving a project between folders in the GCP Resource Hierarchy requires specific permissions: resourcemanager.projects.update on the project and the target folder.

Resource Manager Roles

To manage the GCP Resource Hierarchy effectively, you must know these key Resource Manager roles:

Organization Admin Role

roles/resourcemanager.organizationAdmin: Full control over the entire GCP Resource Hierarchy.

Folder Admin Role

roles/resourcemanager.folderAdmin: Can create, edit, and delete folders within their scope of the GCP Resource Hierarchy.

Project Creator Role

roles/resourcemanager.projectCreator: Allows a user to create new projects within an organization or folder in the GCP Resource Hierarchy.

Governance and Organization Policies

The GCP Resource Hierarchy is also the foundation for Organization Policies, which are different from IAM.

Setting Constraints at Scale

Organization Policies allow you to set "constraints" across your GCP Resource Hierarchy. For example, you can forbid the creation of external IP addresses for all projects in a specific folder.

Boolean vs. List Constraints

• Boolean Constraints: On or Off (e.g., "Disable Serial Port Access").
• List Constraints: A list of allowed/denied values (e.g., "Allowed Locations" for resources).

Dry Run Mode for Policies

You can test policies in the GCP Resource Hierarchy using "Dry Run" mode to see what would be blocked without actually breaking existing workflows.

Billing and the Hierarchy

Billing is inextricably linked to the GCP Resource Hierarchy.

Billing Account Association

While projects reside in the GCP Resource Hierarchy, they must also be linked to a Billing Account. A single billing account can pay for many projects.

Cost Tracking by Folder

By organizing your GCP Resource Hierarchy using folders, you can more easily track and export billing data based on business units.

Hierarchical Firewalls

The GCP Resource Hierarchy allows you to define firewall rules at the Folder or Organization level, ensuring that security policies are enforced across all projects automatically.

Best Practices for Hierarchy Design

Designing a robust GCP Resource Hierarchy requires careful planning.

Mirroring Business Units

Align the top levels of your GCP Resource Hierarchy with your company's stable business units (e.g., HR, Engineering, Sales).

Environment-Based Isolation

Create "Prod," "Stage," and "Dev" folders. This allows you to apply strict organization policies to production while being more lenient in development within the GCP Resource Hierarchy.

Security Perimeter Definition

Use the GCP Resource Hierarchy to define clear security perimeters using VPC Service Controls, which often align with folder boundaries.

Troubleshooting Hierarchy Issues

When things go wrong in the GCP Resource Hierarchy, look at these areas:

Missing Permissions

Users often lose access because a project was moved to a new folder in the GCP Resource Hierarchy where they don't have inherited permissions.

Policy Conflict Resolution

If an Organization Policy is set at the Org level and a different one at the Folder level, the folder-level policy (being more specific) often takes precedence, but this depends on the constraint type.

Audit Logs and Hierarchy Changes

Use Cloud Audit Logs to track who moved a project or changed a folder's IAM policy within the GCP Resource Hierarchy.

Common Exam Scenarios for ACE

Expect these types of questions regarding the GCP Resource Hierarchy:

Moving a Project

"You need to move a project from the 'Marketing' folder to the 'Sales' folder. What roles do you need?"

Inherited Role Issues

"A user is an Editor at the Folder level but only a Viewer at the Project level. What can they do?" (Answer: They are still an Editor due to inheritance in the GCP Resource Hierarchy).

Organization Policy Conflicts

"You have a policy at the Org level forbidding external IPs, but one project needs one. How do you fix this?" (Answer: Override the policy at the project level if allowed).

FAQ

Q1: Can a Project belong to multiple Folders in the GCP Resource Hierarchy? A1: No. A project must have exactly one parent, which can be either a Folder or the Organization node.

Q2: Is the Project ID the same as the Project Name? A2: No. The Project ID must be globally unique and is immutable. The Project Name is just a display name and can be changed.

Q3: How many levels of folders can I have in the GCP Resource Hierarchy? A3: You can nest folders up to 10 levels deep, though keeping it simpler is usually better for management.

Q4: Does deleting a Folder delete the Projects inside it? A4: You cannot delete a folder if it contains projects or other folders. You must move or delete the children first to maintain the integrity of the GCP Resource Hierarchy.

Q5: What is the difference between IAM and Organization Policies in the GCP Resource Hierarchy? A5: IAM focuses on "Who" can do "What." Organization Policies focus on "What" can be done with "Resources" (e.g., forbidding specific configurations), regardless of who the user is.

Summary Checklist for ACE

• Understand the 4 layers of the GCP Resource Hierarchy.
• Remember that IAM permissions are additive and flow downwards.
• Know that the Organization node is the root and requires Cloud Identity.
• Distinguish between Project ID, Project Name, and Project Number.
• Understand how Folders can be used for environment and department isolation.
• Be ready to identify the roles needed to manage the GCP Resource Hierarchy.