Organization (Google Cloud)

The top-level resource in the Google Cloud resource hierarchy that typically corresponds to a company or domain and contains all folders and projects.

An optional grouping node between the organization and projects, used to organize resources by departments, environments, or other structures and to apply IAM and policies to groups of projects.

The fundamental unit of organization in Google Cloud that contains resources, defines IAM and quota boundaries, and links to a billing account. Every resource belongs to exactly one project.

Project ID vs Project Name

Project name is human-friendly and changeable. Project ID is globally unique, used in APIs and URLs, chosen at creation and typically not reusable after deletion.

A resource that represents how you pay for Google Cloud usage. One billing account can fund multiple projects, and each project must be linked to a billing account to incur charges.

A key-value pair attached to projects or resources, used for filtering, cost allocation, and automation (for example, env=prod, team=web).

An optional grouping node between the organization and projects, used to organize resources by departments, environments, or other structures and to apply IAM and policies to groups of projects.

The fundamental unit of organization in Google Cloud that contains resources, defines IAM and quota boundaries, and links to a billing account. Every resource belongs to exactly one project.

Google Cloud Resource Hierarchy, Projects, and Accounts — Google Cloud Associate Cloud Engineer: Complete Exam-Ready Masterclass

Why Resource Hierarchy Matters for an Associate Cloud Engineer

Why Hierarchy First?

Before you launch any VM or database, you need a clean structure to put it in. In Google Cloud, that structure is the resource hierarchy: organizations, folders, and projects.

Exam Relevance

This topic underpins Setting up a cloud solution environment and Configuring access and security. You will see questions about organizations, folders, projects, and how they relate.

Your Target Role

An Associate Cloud Engineer deploys and secures applications, services, and infrastructure, monitors operations of multiple projects, and maintains enterprise solutions to meet target performance metrics.

What You Will Learn

You will learn the hierarchy model, how to create and configure projects for dev/stage/prod, how naming and labels support governance and billing, and how project boundaries affect IAM and billing.

The Google Cloud Resource Hierarchy: Organizations, Folders, Projects

Hierarchy Overview

Google Cloud uses a tree-like hierarchy: organization → folders → projects → resources. Every VM, bucket, or dataset lives inside exactly one project.

Organization Node

The organization is the top-level container for a company or school. It usually maps to a Google Workspace or Cloud Identity domain and owns all folders and projects.

Folders

Folders are optional grouping layers under the organization. Use them to mirror departments or environments and to apply IAM and policies to groups of projects.

Projects

Projects are the main boundary for IAM, quotas, APIs, and billing alignment. Each has a human name, a globally unique project ID, and a numeric project number.

Designing a Resource Hierarchy for a Sample Company

Acme Retail Scenario

Acme Retail has teams for Web, Data & Analytics, and Mobile Apps, each with dev, staging, and prod. Production must be tightly controlled, and billing should be trackable.

Hierarchy Choice

Organization: `acme-retail.com`. Folders: `Environments/Production`, `Environments/Staging`, `Environments/Development`. Projects live under each environment folder.

Example Projects

Under Production: `web-prod-core`, `mobile-prod-api`, `data-prod-warehouse`. Under Staging: `web-stg-core`, `mobile-stg-api`, `data-stg-warehouse`, and similar for dev.

IAM Effects

Prod folder: SRE gets read-only. Devs get editor on dev/stage projects only. Analytics gets BigQuery access on `data-prod-warehouse` but no rights to `web-prod-core`.

Projects in Depth: Identity, APIs, Billing, and Lifecycle

Project Identity

Each project has a human-friendly name, a globally unique project ID, and a numeric project number. APIs and URLs usually use the project ID.

APIs and Quotas

APIs are enabled per project. Enabling them may create defaults like networks. Quotas such as vCPUs are typically enforced per project per region.

Billing Linkage

Every project links to a billing account. One billing account can fund many projects. If billing is disabled, resources may stop or be removed after a grace period.

Project Lifecycle

Creating a project sets its ID and number and inherits policies from its parent. Deleting a project soft-deletes it for a limited time before permanent deletion.

Creating and Configuring Projects for Dev, Staging, and Prod

Creating a Project

Use the project selector → New Project, set a name, choose the parent org/folder, optionally edit the project ID, and link a billing account.

Dev Project Settings

Dev projects often give developers broader IAM, use smaller/cheaper resources, and are more flexible for experimentation.

Staging Project Settings

Staging mirrors production architecture and regions but allows some flexibility. It is used for realistic pre-production testing.

Production Project Settings

Production projects have strict IAM, enforced organization policies, and standardized logging, monitoring, and backup configurations.

Thought Exercise: Map Your Own Hierarchy

Apply what you have learned by designing a simple hierarchy for a hypothetical or real scenario.

Your scenario

Imagine you are helping a university IT team move to Google Cloud. They have:

A public website (`www.university.example`)
A student portal (login required)
A data analytics team that needs access to anonymized student performance data
Separate dev, test, and prod environments

Task 1: Sketch the hierarchy

On paper or in a notes app, write down:

The organization name you would expect (hint: based on the university domain).
Whether you will use folders for departments, environments, or both.
A list of projects you would create (at least 4–6), including which folder they belong to.

Task 2: Decide IAM at each level

For each of these roles, decide where you would primarily grant access: organization, folder, or project.

Central security team
Web development team
Student portal team
Data analytics team

Write your answers, then check yourself:

Did you keep production workloads in separate projects from dev/test?
Did you give the analytics team data access without unnecessary access to web servers?
Did you use folders where policies naturally apply to a group of projects?

This type of reasoning mirrors exam scenarios, where you must choose the right level (org vs folder vs project) to meet requirements.

Naming Conventions and Labels for Governance and Automation

Naming Conventions

Use patterns like `team-env-app`: `web-prod-core`, `web-stg-core`. Keep names short, meaningful, and include the environment.

Project IDs

Project IDs must be globally unique, lowercase, and usually cannot be reused. Choose IDs that align with your naming scheme from the start.

Labels Basics

Labels are key-value pairs like `env=prod`, `team=data`. They support filtering, billing, and automation across projects and resources.

Best Practices

Define a small standard set of labels, apply them consistently, and use them in cost reports and scripts (for example, stop all `env=dev` VMs at night).

Managing Multiple Projects: IAM, Networking, and Billing

Multi-Project Reality

In practice you will manage many projects: web, data, shared networking, etc. You must understand how IAM, networking, and billing behave across them.

IAM Across Projects

IAM can be set at org, folder, project, or resource. You can give SREs org-level log viewing, while devs only get viewer on specific staging projects.

Shared VPC

Use a host project like `shared-network-prod` that owns the VPC. Attach service projects such as `web-prod-core` so they share networks but keep separate IAM and billing.

Billing and Labels

Link multiple projects to one billing account and use labels like `env=prod`, `team=web` so you can break down costs per team and environment.

Quick Check: Resource Hierarchy Basics

Test your understanding of organizations, folders, and projects.

You need to apply a security policy to all current and future production projects, without affecting development projects. Where is the BEST place to attach this policy?

At the organization node
At the Production folder that contains all production projects
Individually on each production project
On a single production project and rely on inheritance

Show Answer

Answer: B) At the Production folder that contains all production projects

Attaching the policy at the Production folder ensures it applies to all projects inside that folder, now and in the future, without impacting non-production folders. Organization-level would affect all projects, and per-project configuration does not scale.

Quick Check: Projects, IDs, and Billing

Confirm you understand project identity and billing behavior.

Which statement about Google Cloud projects is MOST accurate?

A project name must be globally unique and cannot be changed after creation.
A project ID must be unique within an organization but can be reused after deletion.
Every resource belongs to exactly one project, which links to a billing account.
Quotas and APIs are configured at the organization level, not per project.