The GCP resource hierarchy shows up across the Professional Cloud Architect exam, often as a setup for IAM, billing, or policy questions. If you don't have a clean mental model of how organizations, folders, and projects relate to each other, those questions get harder than they need to be. This article walks through the hierarchy and ends with the project name vs ID vs number distinction that the exam likes to test.
A project is the fundamental, lowest-level unit of organization in Google Cloud. Every resource you create, whether that's a Compute Engine VM, a Cloud Storage bucket, a BigQuery dataset, or a Dataproc cluster, lives inside a project. The project is the container that holds everything you build or deploy.
Projects also act as the boundary for billing, access management, and API settings. A project gets its own bill. A project has its own IAM policy. A project has its own enabled APIs. This separation is what lets you isolate workloads, charge different teams for their own usage, and grant access to one workload without leaking access to another.
The rule that catches people new to GCP is that you have to be in a project at all times. There is no "outside a project" mode. When you run a gcloud command, you specify a project (or it picks up your default). When you spin up a VM, it goes into a project. When you query a table, the query runs against a project's resources and is billed to that project. Everything in GCP is project-scoped.
An organization is the top-level container in the GCP resource hierarchy. It represents your entire company, business unit, or division. The organization is what lets you centralize management across many projects.
Two things are worth knowing about organizations for the exam. First, they are optional. You can use GCP with just standalone projects and never create an organization, which is what happens when you sign up with a personal Gmail account. Second, an organization is tied to a Cloud Identity or Google Workspace account. That's the link between your company's users and groups and your GCP resources. Without that identity layer, there's nothing to anchor an organization to.
Once you have an organization, you can manage all your resources, policies, and billing from one place. You can grant roles at the organization level that cascade down to every project underneath. That cascading behavior is the reason organizations matter for the Professional Cloud Architect exam: they are where you set the policies that you want every project in the company to inherit.
Folders sit between the organization and projects. They are an optional intermediate container used to group projects logically. You can have an organization with no folders at all, and you can also nest folders inside other folders for deeper structure.
The thing to internalize is that folders don't hold cloud services directly. You don't put a VM in a folder. Folders exist purely to organize and to be a target for policies and IAM bindings. A common pattern is one folder per department (Marketing, Engineering, Finance), or one folder per environment (Production, Staging, Development), with the actual projects sitting inside.
Like projects, folders inherit policies from above. A policy set on the organization flows down to every folder, and a policy set on a folder flows down to every project inside it. This inheritance is what makes folders useful. You set guardrails once at the folder level and they apply to every project that team owns, without having to repeat yourself.
A complete hierarchy looks like this. At the top, you have the organization, representing the whole company. Underneath, you have folders grouping projects by department or environment. You can nest folders if you want a deeper structure, for example a Production folder inside an Engineering folder. At the bottom, you have projects, and inside the projects sit the actual resources like VMs, storage buckets, databases, and pipelines.
For exam questions, the pattern to recognize is that policies and IAM roles flow downward. If you grant someone a role at the organization level, they get it on every folder and project beneath. If you grant it at a folder, they get it on every project in that folder. If you grant it at a project, it stays scoped to that project. When a question asks where to apply a policy, the answer is usually "at the lowest level that covers everything you need to cover," because that limits blast radius.
Every GCP project has three identifiers, and the Professional Cloud Architect exam likes to test whether you know the difference.
The project name is human-readable. Something like "Analytics Project." It exists for your convenience, you can edit it anytime, and it doesn't have to be unique. Two different projects, in your organization or someone else's, can share a name.
The project ID is a globally unique alphanumeric identifier. Something like "analytics-project-prod-4912." It's all lowercase, no spaces, often with a numeric suffix to make it globally unique. Once you set the project ID, it's immutable. You can never change it. This is the identifier you use with gcloud commands, with API calls, and in any automation you write. When you see a question that asks which identifier to use in a script or an API call, the answer is the project ID.
The project number is a globally unique numerical identifier, something like "847193562410." Google Cloud assigns it automatically when the project is created. You can't choose it, you can't modify it, and it's mostly used internally by GCP itself. You'll see it pop up in service account email addresses, in IAM audit logs, and in some lower-level API responses, but you'll rarely type it yourself.
The shorthand: name is for humans, ID is for you when you call gcloud or the API, number is for GCP's internal plumbing.
My Professional Cloud Architect course covers the GCP resource hierarchy alongside the rest of the IAM and governance material.
