Resource Hierarchy: Organizations, Folders and Projects Study Notes

The resource hierarchy is how Google Cloud organizes everything you own, from the organization at the top down to individual resources inside projects. It controls where Identity and Access Management policies and organization policies apply, and how access is inherited. Understanding this structure is foundational for the Associate Cloud Engineer exam and for day-to-day administration.

Key facts

• The hierarchy has four main levels from top to bottom: organization, folders, projects, and then resources such as virtual machines, buckets, and databases inside those projects.
• The organization node represents your company and is tied to a Google Workspace or Cloud Identity account, and it is the root where organization-wide policies and ownership are defined.
• Folders are optional grouping nodes that can contain other folders or projects, and they are commonly used to model departments, teams, environments, or business units.
• A project is the fundamental billing, quota, and API boundary, and every billable resource must belong to exactly one project at any given time.
• Each project has a unique project ID that you choose or accept at creation, a changeable display name, and an immutable project number assigned automatically by Google Cloud.
• IAM policies set on a parent node are inherited by all child folders, projects, and resources below it, and inherited permissions cannot be removed at a lower level.
• Organization policies are guardrails that constrain how resources can be configured, such as restricting external IP addresses or allowed regions, and they also inherit down the hierarchy.
• Labels are key-value pairs you attach to projects and resources for organization, filtering, and cost reporting, but labels do not affect IAM or policy inheritance in any way.
• You can move a project between folders within the same organization if you have the right permissions, but you cannot move a project between different organizations without a migration process.

What the exam expects you to know

• The exam tests whether you know that IAM granted at the folder or organization level automatically applies to every project underneath, creating a common least-privilege risk.
• Expect questions asking which node to use for grouping by department or environment, where the correct answer is usually folders rather than creating extra organizations.
• You should be able to identify the project ID versus the project number and know which one gcloud commands and APIs typically require in scripts and support cases.
• Scenarios often ask where to apply an organization policy so it affects production projects only, which means targeting the specific folder rather than the organization root.
• The exam checks that a resource can only live in one project, so sharing across projects requires networking or IAM sharing rather than moving the resource itself.
• Questions may describe billing confusion and expect you to know that billing is linked per project to a billing account, not inherited from the folder hierarchy.

Resource Hierarchy: Organizations, Folders and Projects vs Labels: when to use which

Use folders when you need real policy control, because IAM roles and organization policies inherit through folders and can enforce access and guardrails for a whole team or environment. Use labels when you only need to sort, filter, search, or break down costs, for example by cost center, owner, or application, without changing permissions. A typical design uses both together: folders define the security and policy boundary, while labels provide flexible reporting across projects that may sit in different folders. If an exam scenario mentions inheritance or enforcement, choose folders; if it mentions reporting or billing breakdown only, choose labels. See also the Labels notes.

Useful gcloud commands

gcloud organizations list
gcloud resource-manager folders list --organization=ORGANIZATION_ID
gcloud projects list
gcloud projects describe PROJECT_ID

Common exam traps

• Trap: Thinking you can deny or remove an inherited IAM permission at the project level. You cannot subtract inherited access; you must change the policy at the parent or restructure the hierarchy.
• Trap: Confusing the project ID with the project number. The project ID is unique, user-facing, and used in most commands, while the number is numeric and used internally and in some APIs.
• Trap: Assuming every Google Cloud account has an organization. Individual accounts without Workspace or Cloud Identity may have no organization node, and projects sit directly at the top.
• Trap: Believing labels enforce security. Labels are metadata only and never grant, deny, or restrict access, no matter how consistently you apply them across resources.

Frequently asked questions

Can a project belong to more than one folder?

No. A project has exactly one parent, which is either a folder or the organization itself. It cannot sit in two folders at once. If teams need shared access, grant IAM roles to both groups on that project or use Shared VPC and cross-project networking instead of trying to place the project in multiple locations.

What happens when you move a project to another folder?

The project immediately inherits IAM policies and organization policies from its new parent folder and stops inheriting from the old parent. Direct policies on the project itself stay unchanged. This can widen or narrow access instantly, so the exam expects you to check inherited permissions before and after any folder move.

Do I need an organization to create projects?

No, you can create projects without an organization, but an organization is strongly recommended for companies. It gives you central ownership, organization policies, and folder structure. Without it, there is no central admin who automatically owns all projects, which creates risk if an individual employee who created a critical project leaves the company.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.