Projects, hierarchy & billing

Projects, hierarchy & billing — the foundation everything sits on

Mental model: before you deploy anything on Google Cloud you need a place to put it (a project) and a way to pay for it (a billing account). Google Cloud arranges everything in a resource hierarchy, and where you attach an IAM policy in that hierarchy decides who can do what — so getting the structure right up front is what keeps a growing environment from turning into chaos.

The resource hierarchy (top to bottom)

    Organization        (the root node — your company)
      -> Folders         (optional — group projects by team, dept, or environment)
        -> Projects       (the BASE-LEVEL organizing entity)
          -> Resources    (VMs, buckets, databases — the things you actually build)

A project is the base-level organizing entity: individual resources always live inside a project, never loose. Folders are optional grouping in between.

Why the hierarchy exists — IAM inherits downward. An IAM policy you set at a higher level is inherited by everything below it. Grant a role on a folder and every project beneath that folder inherits the grant. That means you set broad access rules once at the right level instead of repeating them on every project.

    Grant on Folder  ->  inherited by every Project under it  ->  and their Resources

1 · A project's three identifiers (people trip on this)

    Project ID       globally unique, IMMUTABLE — you can never change it once set
    Project name     just a human-friendly label — editable anytime
    Project number    auto-generated by Google — you don't pick it

Create a project and set it as your working project:

    gcloud projects create sprkd-demo --name='Sprkd Demo'
    gcloud config set project sprkd-demo

    # `sprkd-demo` here is the Project ID (immutable). `Sprkd Demo` is the name (editable).
    # `gcloud config set project` just points your local CLI at that project for later commands.

2 · Pay for it — link a Cloud Billing account

A Cloud Billing account defines WHO pays. You link it to one or more projects; resource usage in those projects bills to that account. Set budgets and alerts on it so spending never surprises you.

    gcloud billing projects link sprkd-demo --billing-account=XXXXXX-XXXXXX-XXXXXX

    # --billing-account is the billing account ID, in the form XXXXXX-XXXXXX-XXXXXX.
    # This links the project to the account that pays for it — nothing more.

3 · The #1 gotcha — billing is NOT an IAM parent

A billing account is not part of the IAM resource hierarchy. A project does NOT inherit IAM permissions from the billing account it's linked to. Billing and access control are two separate concerns:

    Billing account  -> defines who PAYS (linked to projects, budgets + alerts)
    IAM hierarchy    -> defines who has ACCESS (Org -> Folders -> Projects, inherits down)

So linking a project to a billing account gives no one any access, and inheriting access from a folder has nothing to do with who pays. Keep the two mental models apart.

4 · How you interact with all of this

    Cloud Console         the web UI (console.cloud.google.com)
    Google Cloud CLI      the `gcloud` command — NOT "Cloud SDK" (that's the outdated name)
    Cloud Shell           a ready-to-go browser terminal with the Google Cloud CLI preinstalled

Notes:
- It's the "Google Cloud CLI" (the `gcloud` command). "Cloud SDK" is the old term — don't say it.
- Billing != IAM inheritance. A billing account says who pays; it does not grant permissions, and projects do not inherit IAM from it. IAM inherits down the Org -> Folders -> Projects hierarchy only.
- The Project ID is immutable. Choose it carefully at creation — you can rename the project name later, but never the ID.
- A project is the base-level organizing entity; resources live inside projects, and folders are optional grouping above them.

Verify:
    gcloud config get-value project          # confirm your active project is sprkd-demo
    gcloud billing projects describe sprkd-demo   # confirm it's linked and billing is enabled

Scope: the facts above are verified against official Google Cloud docs and the gcloud command shapes come from the docs — they were not run against a live Google Cloud project, so no output is captured here.