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.