Governance in Google Cloud is built on the resource hierarchy, the layered structure that holds every resource you create. The hierarchy has three levels. The organization is the top-level container, folders are an optional middle layer, and projects are the lowest-level unit where resources actually live. Policies and permissions set at a higher level flow down to the levels beneath them, which is the property that makes the hierarchy a governance tool and not just a way of organizing things. The Professional Cloud Database Engineer exam expects you to know what sits at each level and how that downward flow works, because most administrative and access questions trace back to it.
The project is the fundamental, lowest-level unit of organization in Google Cloud. It is the container that holds the resources and services you build or deploy, including virtual machines, pipelines, and databases. A single project can contain a mix of services such as Compute Engine, Cloud Storage, and BigQuery, all grouped together as one unit.
Beyond holding resources, a project is the distinct entity for billing, access management, and API settings. Costs are tracked per project, access is granted per project, and the APIs you enable are enabled within a project. This keeps spending accounted for and resources managed securely inside their own boundary.
The point to carry into the exam is that you are always operating within a project. To use Google Cloud at all, you have to be in a project. Every action, from spinning up a virtual machine to querying a database, is tied to a specific project. Nothing exists outside of one.
The organization is the top-level container in the resource hierarchy. It represents an entire company, organization, or division. Below it sit the projects, and optionally folders, that belong to it.
Organizations are optional. Projects can exist and be used without an organization above them, so the absence of an organization does not stop you from working in Google Cloud. The organization becomes useful when you need to centralize the management of multiple projects. A large company with many departments might give each department its own projects while keeping all of them under the umbrella of a single organization.
An organization is tied to a Cloud Identity or Google Workspace account. That link matters for governance because the identity and access management policies from your organization flow through to Google Cloud. From the organization level you manage resources, policies, billing, and other settings in one central place. You can also grant roles and permissions here, including ones that cascade down to the projects below. That makes the organization level the natural place to define high-level administrative roles that need to manage many projects at once.
Folders are an optional intermediate container that sits between the organization and its projects. You can run an organization without any folders, so they are there when you want them rather than required.
Their purpose is to organize projects into logical groups. Unlike projects, folders do not have any actual cloud services associated with them. They hold no virtual machines or databases of their own. They exist purely for organization and management, which is worth keeping straight, because a folder is a grouping mechanism and not a place where resources run.
Folders earn their place when you have many projects and need a way to group them by function, department, or environment. You might gather all development projects under one folder, or all marketing projects under another. They also inherit policies and permissions from their parent organization, so any policy applied at the organization level flows down to the folders and the projects inside them. Folders can be nested inside one another as well, which lets you build deeper levels of organization and apply finer-grained control over permissions and policies.
It helps to picture a worked example. At the top is an organization, call it My Organization, which represents the entire company. Every resource in Google Cloud exists under it. Inside the organization is Folder 1, which groups projects together and in this case contains Project A and Project B, perhaps belonging to two different teams. Nested inside Folder 1 is a second folder, Folder 2, which holds Project C. That nesting shows how folders inside folders create multiple levels of structure.
Each of those projects contains the real resources, the virtual machines, databases, and other services. The projects are where the work actually lives, while the folders and the organization above them let you manage everything from the top down. You can apply roles and policies at whatever level fits the need, across an entire folder, or just for one specific project. This is what centralizes governance. You set a control once at the right level, and it reaches everything beneath it.
For the Professional Cloud Database Engineer exam, a few distinctions are worth holding onto. Projects are the only level where resources, including your databases, actually reside, and you are always inside one. Organizations and folders are both optional, and folders never hold services of their own. Inheritance runs downward, so a role or policy granted at the organization or folder level cascades to the projects under it. When a question asks where to apply a control so that it covers a group of projects with the least repeated effort, the answer usually comes from choosing the right level in the hierarchy rather than touching each project one at a time.
Our Professional Cloud Database Engineer course covers the resource hierarchy alongside identity and access management and policy inheritance, with practice questions that drill these distinctions.
