Every resource in Google Cloud lives within a project. Every project can belong to a folder. Every folder can belong to an organization. This hierarchy is not just an organizational convenience. It is the structure through which IAM permissions and organizational policies cascade downward, and it is a topic the Associate Cloud Engineer exam tests directly.
A project is the lowest level of the hierarchy and the primary boundary for GCP resources. Every virtual machine, every database, every storage bucket, every API enablement belongs to exactly one project.
Projects are also the boundary for billing, API access control, and IAM policies. Billing is tracked at the project level, meaning each project has a billing account associated with it. APIs are enabled per project, so enabling the Cloud Run API in one project does not enable it in another. IAM policies applied at the project level affect all resources within that project.
To use any GCP service, you must be working within a project. There is no way to create a resource outside of a project context. This is worth knowing for the exam because it explains why the first step in any GCP environment setup is always creating or selecting a project.
An organization is the top-level node in the hierarchy. It represents the entire company, organization, or division. An organization is associated with a Cloud Identity or Google Workspace account, meaning the domain used for those accounts becomes the organization's domain in GCP.
The organization level is where centralized management begins. IAM roles granted at the organization level apply to every folder, project, and resource within the organization. An organization administrator has visibility and control over all resources in the organization. Organizational policies, which are constraints that enforce governance rules, can be applied at the organization level and cascade to everything below.
Examples of organizational policies include restricting resource creation to specific regions, requiring all VMs to use shielded instance features, or preventing users from creating external IP addresses. These constraints apply automatically to all projects in the organization without requiring individual project configuration.
Not every GCP account has an organization. Individual developers using personal accounts may only have projects with no organization above them. Enterprise accounts using Google Workspace or Cloud Identity will have an organization node.
Folders are optional intermediate containers between the organization and projects. They do not have GCP resources directly associated with them, but they serve as logical grouping mechanisms and as additional policy attachment points.
A common pattern is organizing folders by department, team, or environment. A large company might have a folder for the engineering department, a folder for finance, and a folder for marketing. Within engineering, there might be sub-folders for different product teams. Each project then lives within the appropriate folder.
Folders inherit policies from the organization above them and pass those policies down to the projects and resources below them. You can also apply additional policies at the folder level that affect only the projects in that folder. This layering allows you to enforce organization-wide constraints while adding folder-specific rules for teams with different requirements.
The exam tests folder usage in scenarios involving centralized policy management for multi-team environments. When a question describes an organization that wants to apply a specific rule to all projects belonging to a particular team without affecting other teams' projects, the answer involves folders.
IAM policies in GCP are additive and inherit downward. If you grant a user the Viewer role at the organization level, they can view resources in every folder and project within that organization. If you grant the same role at a specific folder, they can view resources in every project within that folder but not in other folders. Granting at the project level restricts the access to that project only.
This means the most permissive level at which you grant a role determines the scope of access. There is no way to deny access at a lower level that overrides a grant at a higher level. If you want to restrict access, you need to grant at the most restrictive level that still meets the requirement. This is the principle of least privilege applied to the hierarchy.
The Associate Cloud Engineer exam tests the hierarchy in multiple ways. It tests whether you know the components and their relationships. It tests where to apply IAM roles for a given access scope. It tests how organizational policies work and at which level to apply them. It also tests the relationship between projects and billing accounts.
Common exam scenarios include: an administrator needs to grant a team access to all projects in a specific department (apply the role at the folder level), a company wants to prevent any project from creating public IP addresses (apply an org policy at the organization level), a developer needs access to only one specific project (grant the role at the project level).
My Associate Cloud Engineer course covers the resource hierarchy in detail, including the IAM inheritance patterns and organizational policy scenarios that appear most frequently on the exam.
Projects can be moved between organizations or from no organization to an organization. This operation requires specific IAM roles: the Project Mover role on the project being moved, and the Project Creator role or Organization Admin role on the destination organization.
Migrating a project between organizations does not affect the resources within the project. Virtual machines keep running, databases remain intact, and APIs stay enabled. What changes is the organizational policy context. After the migration, the project inherits the organizational policies of the new parent organization, which may be more or less restrictive than the previous context. This is a point the exam occasionally raises in scenarios about mergers, acquisitions, and organizational restructuring where projects need to move between GCP organizations.
