When I coach candidates through the Professional Data Engineer exam, the resource hierarchy is one of those topics that looks deceptively simple on a slide and then bites people on the test. The diagram with an organization, a few folders, and some projects feels obvious until a question asks where to apply a policy so that it cascades correctly, or which container actually holds the BigQuery dataset. So in this post I want to walk through the three levels of the Google Cloud resource hierarchy with the framing I use for the Professional Data Engineer exam.
The project is the fundamental, lowest level unit of organization in Google Cloud. Every resource you spin up, whether it is a Compute Engine VM, a Cloud Storage bucket, a BigQuery dataset, a Dataproc cluster, or a Dataflow pipeline, lives inside exactly one project. There is no way around this. You cannot use Google Cloud without being in a project at all times.
A few things make the project special compared to the higher levels:
For the exam, the mental model I want you to hold is that the project is the container, and everything you actually pay for and operate on sits inside it. When a question talks about isolating a team's data warehouse so that its costs are separate and its access is independent, the answer almost always lives at the project boundary.
One level above projects sits the organization. The organization is the top-level container in Google Cloud and represents an entire company, agency, or division. It is tied to a Cloud Identity or Google Workspace account, which is what gives Google Cloud a notion of who belongs to your company in the first place.
A subtle point that trips people up: organizations are optional. You can create and use projects without ever having an organization above them, which is what happens when an individual signs up with a personal Gmail account. The organization only enters the picture once a company connects a Cloud Identity or Workspace domain to Google Cloud.
Once you do have one, the organization becomes the place where you centralize control across many projects. You can:
For the Professional Data Engineer exam, the keyword to associate with organization is company-wide. If a scenario says something like "the security team needs to enforce a policy across every data pipeline the company owns," you are being pointed at the organization level.
Between organizations and projects sit folders. Folders are optional intermediate containers that exist purely to group projects into logical buckets. Unlike projects, folders do not have cloud services or resources directly inside them. You do not deploy a VM into a folder. You use folders to organize the projects that contain VMs.
Typical ways to use folders include grouping by department, by environment, or by business unit. A company might have a Marketing folder, a Finance folder, and a Data Platform folder, with each one containing the projects that team owns. Folders can also be nested inside other folders, which is how larger organizations build out a tree that mirrors their internal structure.
The behavior I always emphasize for the exam is inheritance. Folders inherit policies and permissions from the parent organization, and projects inside a folder inherit from that folder. So if you grant a role at the organization level, it flows down through every folder and into every project. If you grant a role on a single folder, it flows down to only the projects inside that folder. That cascading model is the reason folders exist in the first place.
Picture an organization called My Organization. Inside it, there is Folder 1, which contains Project A and Project B. Folder 1 also contains a nested Folder 2, which in turn holds Project C. Each project is where the actual data engineering work happens, things like BigQuery datasets, Pub/Sub topics, and Cloud Composer environments.
Now suppose you want to give a data governance team read access to every dataset in the company. You grant the relevant role at the organization level and it cascades down through Folder 1, through Folder 2, and into Projects A, B, and C. If instead you only want them to see datasets owned by the team behind Folder 2, you grant the role on Folder 2 and it only reaches Project C.
That single example is the kind of reasoning the Professional Data Engineer exam loves. The level you attach a policy to determines the blast radius. Higher means wider. Lower means narrower.
When you hit a hierarchy question on test day, the move is to identify the scope the scenario is describing, match it to one of these three levels, and pick the answer that places the policy or resource there.
My Professional Data Engineer course covers the resource hierarchy in detail along with the IAM patterns that build on top of it.
