Understanding the GCP Resource Hierarchy

Overview and What You Will Learn

In this lab, you will create a Project with a deliberately chosen Project ID, understand exactly what that ID controls, and see how permissions applied at a Folder level automatically flow down to every Project inside it.

Why This Matters in Production

A team creates a project named test-proj-1 intending to rename it once it moves to production, only to discover the Project ID itself can never be changed - the display name can be updated, but the ID that appears in every resource URL, every billing export, and every API call stays fixed forever. Six months later, production infrastructure is still running under a Project ID that clearly signals "temporary test project" to anyone who looks.

Core Principles

GCP organizes every resource inside a strict four-level hierarchy, and policies set at a higher level automatically apply to everything beneath it.

A Project ID is globally unique across all of Google Cloud, chosen once at creation, and never changeable - unlike the Project's display name, which can be updated freely at any time.

Detailed Step-by-Step Practical Lab

1. Create a Folder to represent a specific environment or team:

2. Create a Project inside that Folder, with a deliberate, production-appropriate Project ID:

3. Confirm the Project was created and check both its ID and display name:

4. Grant a role at the Folder level, so it automatically applies to every current and future Project inside that Folder:

5. Confirm the inherited permission actually applies at the Project level, even though it was never granted directly there:

Note

The output here will show the Viewer role inherited from the Folder, not directly listed as a Project-level binding - this is exactly how policy inheritance works, and it's a common point of confusion when auditing "who has access to this project" without checking the Folder and Organization levels above it too.

6. List every Project inside the Folder to confirm the hierarchy is organizing things as expected:

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Choosing a casual or placeholder Project ID like test-123 intending to rename it later. The Project ID is permanent - if a project ends up being promoted to production, the only way to get a proper ID is creating an entirely new project and migrating every resource into it.

Tip

Use Folders to mirror your organization's actual structure - by team, by environment, or both - so IAM permissions and Organization Policies can be applied once at the right level rather than repeated individually across dozens of projects.

• A Project belongs to exactly one Folder (or directly to the Organization), never multiple. If a project's IAM needs differ meaningfully from its current Folder's inherited policies, that's often a signal it belongs in a different Folder, not that it needs individual overrides layered on top.
• Auditing "who has access" requires checking every level of the hierarchy, not just the Project itself - a permission granted at the Organization or Folder level is invisible if you only look at the Project's own IAM policy.

Quick Reference & Troubleshooting Commands