Organization, Folders, and Projects
GCP resources are organized in a tree: an Organization node sits at the top (tied to a Google Workspace or Cloud Identity domain), Folders can group related Projects or other Folders beneath it (often mirroring departments or environments like 'Engineering' or 'Production'), and Projects are the actual unit of billing and resource isolation — every VM, bucket, or database belongs to exactly one Project. A Project has three identifiers: a Project ID (globally unique, human-readable, immutable), a Project Number (globally unique, auto-generated), and a Project Name (mutable, not unique, for display only). Small teams without a formal Organization can still use standalone Projects, but larger enterprises rely on the full hierarchy to apply policy consistently across many teams.
Cricket analogy: The Organization-Folder-Project hierarchy is like the BCCI at the top, State Cricket Associations as folders (Mumbai Cricket Association, Delhi and District Cricket Association), and individual clubs as projects — each club owns its own players and grounds, but policy flows down from the BCCI.
# View the resource hierarchy for a project
gcloud projects describe my-gcp-project-id
# Create a new project under a folder
gcloud projects create my-new-project --folder=123456789012
# List all projects in an organization
gcloud projects list --filter="parent.id=987654321098"IAM Policy Inheritance
IAM policies attached at the Organization or Folder level are inherited downward: a role granted at the Organization level (e.g., 'roles/viewer' for a security auditor) automatically applies to every Folder and Project beneath it, and this inheritance cannot be revoked at a lower level — you can only add more permissive roles, never subtract inherited ones at a child resource. This means policy design should generally follow the principle of least privilege: grant broad roles high in the hierarchy only when truly needed by every child, and grant narrower roles at the Project level for team-specific access.
Cricket analogy: IAM inheritance is like the BCCI mandating a dress code that applies to every state association and club below it — an individual club can add stricter rules but cannot override the BCCI's baseline requirement.
Use 'gcloud organizations get-iam-policy' and 'gcloud projects get-iam-policy' to inspect who has access at each level. Combining the Policy Analyzer in the Console with these commands helps audit effective permissions across the whole hierarchy.
Billing Accounts and Project Isolation
Every Project is linked to exactly one Billing Account, which can itself be shared across many Projects — a common pattern is one Billing Account per Organization, with individual Projects for each team or environment (dev, staging, prod) so costs and access can be isolated and tracked separately per Project while still consolidating payment centrally. Deleting a Project schedules it for deletion after a 30-day recovery window, during which most resources stop serving traffic but the Project ID remains reserved, preventing accidental permanent loss.
Cricket analogy: One billing account funding many projects is like the BCCI centrally funding each IPL franchise's operations while each franchise tracks its own separate budget for players, travel, and staff.
Deleting a Project is not instantaneous but is still dangerous — APIs stop responding almost immediately even though full deletion is delayed 30 days. Never delete a production Project without confirming with 'gcloud projects describe' and checking dependent resources first.
- GCP resources form a tree: Organization at the top, then Folders, then Projects, then individual resources.
- A Project has three identifiers: Project ID (immutable), Project Number (auto-generated), and Project Name (mutable).
- IAM policies granted at Organization or Folder level are inherited downward and cannot be revoked at a lower level.
- Least-privilege design means granting broad roles high in the hierarchy only when every child truly needs them.
- Every Project links to exactly one Billing Account, though a Billing Account can fund many Projects.
- Deleting a Project triggers a 30-day recovery window before permanent deletion, though APIs stop responding almost immediately.
- Use 'gcloud organizations/projects get-iam-policy' and Policy Analyzer to audit effective permissions.
Practice what you learned
1. What is the correct order of the GCP resource hierarchy from top to bottom?
2. Can an IAM role inherited from the Organization level be revoked at a child Project?
3. Which Project identifier is globally unique, human-readable, and immutable once set?
4. What happens immediately after you delete a GCP Project?
Was this page helpful?
You May Also Like
What Is Google Cloud Platform?
An introduction to Google Cloud Platform, its core service categories, and how it compares to running your own infrastructure.
The GCP Console and gcloud CLI
How to manage Google Cloud resources through the web-based Console, the gcloud command-line tool, and Cloud Shell.
GCP Billing and Free Tier
How GCP billing accounts, budgets, and the Free Tier work, and practical ways to avoid unexpected charges while learning.