---
cuppy_hub: gcp
cuppy_path: reference/overview/projects-and-resource-hierarchy.md
cuppy_section: docs
cuppy_doc: Z6KA-5JJ1
cuppy_doc_uuid: 4f896323-a8ae-4e3b-9583-20496d05a283
cuppy_permalink: https://cuppy.io/gcp/d/Z6KA-5JJ1
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/overview/projects-and-resource-hierarchy
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 0fc5525f485e22699a3ba4443654e268c417fc52ea4451060d39d5776f8bdc67
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Projects and the resource hierarchy

## 1. The levels

```
organization  (root)
  folders     (optional)
    projects
      service resources
```

Two facts the page states and that an estimate depends on:

- **"An organization resource is required to use folders."** No organization, no folders, and therefore no
  intermediate scope between the top and a project.
- An organization is **not** itself required: free-trial users can create standalone projects without one.

So a Google Cloud estate can be a flat set of projects with nothing above them. That is a legitimate shape, and
it is the shape most proofs of concept are in. A migration that assumes an organization exists will fail at
the first folder-scoped grant.

## 2. The project's three identifiers, and which one you cannot change

| Identifier | Mutable? | What it is for |
|---|---|---|
| **project ID** | chosen by you; the page describes the project's **display name** as the mutable part | what almost every API, URL and resource name uses |
| **project number** | **auto-assigned and read-only** | what IAM and some APIs resolve to internally |
| **labels** | mutable | filtering, cost attribution, grouping |

The one that catches agents: **workload identity federation and several IAM resource names take the project
*number*, not the project ID** (`reference/identity/workload-identity-federation.md` §2). A binding written
with the ID is accepted and never matches.

## 3. What inherits, and in which direction

Only downward. An allow policy applied at the organization is, verbatim, "inherited by every resource in the
organization"; the same holds for a folder over its projects and a project over its resources.

| Inherits down | Does not |
|---|---|
| IAM allow policies | a grant's **removal** — see below |
| organization policies (constraints) | region or zone choices |
| labels, for the purposes of hierarchy reporting | quota, which is per-project (and sometimes per-region) |

**Nothing at a child level withdraws a parent's grant.** Removing a binding from a project does not remove the
same binding held at the folder above it. The only narrowing instruments are a deny policy and a Principal
Access Boundary policy (`reference/identity/iam-model.md` §1).

## 4. The hub's reading, for migration work

The resource-hierarchy page **states no hard limits**, which is worth recording as an absence rather than as a
reassurance: projects-per-organization and similar bounds live on each service's own quotas page, not here.

Shape-wise this is a **three-level tree with an optional middle**, against AWS Organizations
(root → organizational unit → account) and Azure (management group → subscription → resource group). The
closest analogy for sizing is:

| Google Cloud | AWS | Azure |
|---|---|---|
| project | account | subscription **or** resource group, depending on what you are counting |
| folder | organizational unit | management group |
| organization | organization root | tenant (directory) |

**The project/account/subscription row is the one that breaks a naive count.** A Google Cloud project is a
cheap, routinely-created unit; an AWS account is heavier; an Azure subscription is heavier still *and* Azure
adds the resource group, which has no Google Cloud equivalent — a Google Cloud project often maps to one Azure
resource group rather than to a subscription. Decide which it is **before** counting anything, because the
quota and RBAC ceilings attach to different levels in each cloud. The arithmetic is in
`guides/parity-and-migration-method.md`.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->