This chapter dives deep into the Google Cloud Platform (GCP) resource hierarchy, covering Organizations, Folders, and Projects. Understanding this hierarchy is fundamental for the ACE exam because it underpins IAM policy inheritance, resource organization, and billing management. Approximately 10-15% of ACE exam questions touch on topics related to resource hierarchy, IAM policy inheritance, and project organization. This chapter will equip you with the precise knowledge needed to design and manage multi-project environments in GCP.
Jump to a section
Imagine a large multinational corporation called ‘CloudCorp’. The CEO and board of directors sit at the top and set company-wide policies, budgets, and security rules – this is the Organization node. Under the CEO, there are regional divisions like ‘Americas’, ‘Europe’, and ‘Asia-Pacific’. Each division has its own VP who enforces divisional policies, manages budgets, and can delegate authority to local departments. These divisions are Folders. Within a division, say ‘Americas’, there are departments like ‘Engineering’, ‘Marketing’, and ‘Sales’. Each department has a manager who controls projects and resources. These departments are Projects. Finally, individual employees (e.g., a developer named Alice) use company resources like laptops, servers, and databases – these are Resources (Compute Engine VMs, Cloud Storage buckets, etc.). The hierarchy ensures that policies set at the top (e.g., ‘All data must be encrypted at rest’) flow down and cannot be bypassed by lower levels. IAM roles can be assigned at any level: a VP can grant access to their entire division, a manager to their project, or a team lead to specific resources. Billing also flows down: the CEO sees the total cost, the VP sees their division’s cost, and the manager sees their project’s cost. This hierarchy mirrors GCP’s resource hierarchy: Organization → Folders → Projects → Resources.
What is the GCP Resource Hierarchy?
The GCP resource hierarchy is a tree structure that organizes cloud resources into four levels: Organization, Folders, Projects, and Resources. This hierarchy is central to how IAM policies are inherited, how resources are grouped, and how billing is aggregated. The hierarchy is defined as: Organization (root) → Folders (optional, one or more levels) → Projects (leaf nodes) → Resources (individual services like VMs, buckets, etc.).
Why Does It Exist?
Without a hierarchy, managing IAM permissions across hundreds of projects would be cumbersome. The hierarchy allows you to set policies at a high level (e.g., Organization) and have them automatically apply to all descendant resources. This is similar to how Active Directory or LDAP directories use OUs to apply Group Policy. The hierarchy also enables billing aggregation: you can view costs at the Organization, Folder, or Project level.
Organization Node
The Organization node is the root of the hierarchy. It represents your company or enterprise. You must have a Google Workspace or Cloud Identity account to create an Organization. The Organization node is automatically created when you associate a GCP project with a Google Workspace or Cloud Identity account. The Organization node has an IAM policy that governs all resources under it. The Organization Admin role (roles/resourcemanager.organizationAdmin) and Organization Viewer role (roles/resourcemanager.organizationViewer) are critical for managing the organization.
Key properties:
- Only one Organization per Google Workspace or Cloud Identity account.
- The Organization node’s ID is a numeric ID (e.g., 123456789012).
- To use Organization-level IAM, you must have the resourcemanager.organizations.get permission.
Folders
Folders are optional intermediate nodes between the Organization and Projects. They allow you to group projects based on departments, environments (e.g., dev, test, prod), or any other logical grouping. Folders can be nested up to 10 levels deep (Organization + Folders + Project). Each folder can have its own IAM policy, which is inherited by all projects and resources within that folder.
Key properties:
- Folder names must be unique within the same parent (Organization or parent folder).
- Folder display names are not unique; they are just labels.
- Folder IDs are numeric and auto-generated.
- You need the resourcemanager.folders.create permission at the parent level to create a folder.
- Folders can be deleted only if they are empty (no child folders or projects).
Projects
Projects are the base level of the hierarchy. All GCP resources (Compute Engine instances, Cloud Storage buckets, etc.) belong to exactly one project. Projects are the primary unit of resource isolation, billing, and IAM. Each project has:
A unique project ID (globally unique, user-specified, e.g., my-project-123)
A project name (not unique, for display)
A project number (auto-generated, globally unique numeric ID)
Projects can be created via the Console, gcloud CLI, or API. The roles/resourcemanager.projectCreator role is required to create projects. Projects can be moved between folders or the Organization, but with some restrictions.
IAM Policy Inheritance
IAM policies are inherited from parent to child. A policy set at the Organization automatically applies to all folders, projects, and resources under it. A policy set at a folder applies to all projects and resources in that folder. A policy set at a project applies to all resources in that project. However, policies are NOT transitive across folders in the sense that a policy on a folder does not affect sibling folders; it only affects descendants.
Important nuance: IAM policies are additive. If a user has a role at the Organization level and a different role at the Project level, they get the union of permissions. There is no deny by default; all policies are allow-only. However, there are Organization Policies (not IAM) that can impose constraints (e.g., restrict VM external IPs).
Example:
- Organization: User A has roles/viewer.
- Folder dev: User A has roles/editor.
- Project my-project: User A has roles/owner.
- Result: User A has all permissions from all three roles (union).
Billing Hierarchy
Billing accounts are linked at the Organization, Folder, or Project level. You can associate a billing account with an Organization, and then all projects under that Organization will use that billing account unless overridden at a lower level. This allows centralized billing management.
Resource Manager API
The Resource Manager API (cloudresourcemanager.googleapis.com) is used to manage the hierarchy. Key methods:
- organizations.get()
- folders.create(), folders.get(), folders.list()
- projects.create(), projects.get(), projects.list()
- projects.update() (to move projects)
Common CLI Commands
List organizations:
gcloud organizations listList folders under an organization:
gcloud resource-manager folders list --organization=123456789012Create a folder:
gcloud resource-manager folders create --display-name="Production" --organization=123456789012Get folder IAM policy:
gcloud resource-manager folders get-iam-policy FOLDER_IDList projects:
gcloud projects listCreate a project:
gcloud projects create PROJECT_ID --name="My Project" --folder=FOLDER_IDMove a project to a folder:
gcloud projects move PROJECT_ID --folder=FOLDER_IDInteraction with Other Services
IAM: IAM policies are evaluated based on the hierarchy. The effective policy on a resource is the union of policies from the resource, its project, its folders, and the organization.
Cloud Audit Logs: Admin Activity logs track changes to the hierarchy (e.g., creating folders, moving projects).
Organization Policies: Can be set at the Organization or Folder level to enforce constraints like restricting resource locations.
Billing: Billing accounts can be linked at any level, but typically at Organization.
Defaults and Quotas
Maximum folders per organization: 3,000 (soft limit, can be increased).
Maximum projects per organization: 10,000 (soft limit).
Maximum folder nesting depth: 10 (Organization + 9 levels of folders + project).
Maximum IAM roles per policy: 1,500.
Maximum members per role: 1,500.
Common Pitfalls
Deleting a folder with projects: You must first delete or move all projects and child folders.
Moving a project between folders: The project must be in the active state. Moving can cause temporary IAM policy changes as inheritance updates.
Organization not set up: If you don't have a Google Workspace or Cloud Identity account, you cannot use Organization-level features; you can only work with projects.
Set up Organization Node
To use the full hierarchy, you must have a Google Workspace or Cloud Identity account. When you create a GCP project under such an account, the Organization node is automatically created. You can verify it by running `gcloud organizations list`. The Organization node will have a numeric ID. The super admin of the Google Workspace account automatically gets the Organization Admin role. If you don't have an organization, you can only work with projects and folders are not available.
Create Folder Structure
Plan your folder hierarchy based on your company structure (e.g., departments like Engineering, Finance) or environments (Dev, QA, Prod). Use `gcloud resource-manager folders create` to create folders. For example, create a top-level folder for each department. Folders can be nested. Note that folder display names are not unique, but folder IDs are. Always use folder IDs in scripts. You can also set IAM policies on folders to give department-level access.
Create Projects
Create projects within the appropriate folder using `gcloud projects create`. Specify the `--folder` flag to place the project directly under a folder. If you omit the flag, the project is created under the Organization (if it exists) or as an orphan project. Project IDs must be globally unique. After creation, you can move the project using `gcloud projects move`. Projects are the containers for all resources.
Assign IAM Policies at Each Level
Set IAM policies at the Organization, Folder, and Project levels as needed. Use `gcloud organizations add-iam-policy-binding`, `gcloud resource-manager folders add-iam-policy-binding`, and `gcloud projects add-iam-policy-binding`. Remember that policies are inherited downward. For example, granting `roles/compute.admin` at the Organization level will give compute admin access to all projects. Use least privilege: grant roles at the lowest possible level.
Move a Project Between Folders
To move a project from one folder to another, use `gcloud projects move PROJECT_ID --folder=DESTINATION_FOLDER_ID`. The project must be in active state. Moving a project triggers a change in IAM policy inheritance; the project will lose policies inherited from the old folder and gain policies from the new folder. This can cause temporary access changes. Ensure users have necessary permissions in the new folder before moving. Also, any resources in the project remain unchanged.
Enterprise Scenario 1: Multi-Department Organization
A large enterprise with 10,000 employees uses GCP. They have departments: Engineering, Data Science, Marketing, and Finance. Each department has multiple teams. They set up an Organization node tied to their Google Workspace account. Under the Organization, they create a folder for each department. Within each department folder, they create subfolders for environments: Dev, Staging, Prod. Each team has its own project under the appropriate environment folder. IAM policies are set at the folder level: e.g., the Engineering folder grants roles/editor to the Engineering team. This avoids managing IAM per project. Billing is aggregated at the Organization level, but each department sees its own costs via folder-level billing. The challenge is managing folder limits: 3,000 folders max; they stay well under that. Misconfiguration: If a folder is accidentally deleted, all projects under it are orphaned (they move to the Organization root). To recover, you must move them back. They use a script to backup folder structure daily.
Enterprise Scenario 2: Isolated Environments for PCI Compliance
A fintech company must comply with PCI DSS. They have a strict separation between development and production environments. They create a Folder called 'Production' with an Organization Policy that restricts external IPs and requires CMEK encryption. The Production folder has IAM policies that only allow a small number of operations staff. The Development folder has more permissive policies. Projects for each application are created under the appropriate folder. This ensures that no developer can accidentally create a VM with an external IP in production. The Organization Policy at the folder level prevents any project under Production from using external IPs, even if the project-level IAM allows it. Common mistake: Not all Organization Policies apply to folders; some only apply to projects. They test policies before enforcement.
Enterprise Scenario 3: Merger and Acquisition
Company A acquires Company B. Company B has its own GCP Organization. To consolidate, Company A creates a folder under its Organization for Company B's projects. They use gcloud projects move to move each project from Company B's Organization to the new folder. However, moving projects across organizations is not supported directly. Instead, they must export resources and recreate projects. This is a painful manual process. They learn that it's better to have a single Organization from the start. They also face issues with IAM: roles from the old Organization are lost. They script the recreation of IAM bindings.
ACE Exam Focus: Resource Hierarchy (Objective 1.1)
The ACE exam tests your understanding of the GCP resource hierarchy in several ways:
1. IAM Policy Inheritance: You must know that IAM policies are inherited from parent to child. A policy at the Organization applies to all folders and projects. A policy at a folder applies to all projects and resources in that folder. A common exam question: 'If a user has role A at the Organization and role B at the Project, what permissions do they have?' Answer: union of A and B.
2. Organization Node Requirements: You need to know that an Organization node is automatically created when you have a Google Workspace or Cloud Identity account. If you don't have one, you cannot create folders. A common wrong answer is that you need a separate GCP subscription or that the Organization is optional. Reality: Without an Organization, folders are not available.
3. Folder vs. Project Permissions: The exam tests the difference between resourcemanager.folders.create and resourcemanager.projects.create. You need resourcemanager.folders.create at the parent level to create a folder. For projects, you need resourcemanager.projects.create at the organization or folder level. A trap: 'Can a Project Creator create folders?' No, they need separate folder creation permission.
4. Moving Projects: The exam may ask: 'What happens when you move a project from one folder to another?' Answer: IAM policies from the old folder no longer apply, and policies from the new folder take effect. Resources remain unchanged. A wrong answer: 'Resources are automatically migrated.' No, resources stay.
5. Organization Policies vs. IAM: The exam distinguishes between IAM policies (who can do what) and Organization Policies (constraints on resources). Organization Policies can be set at the Organization or Folder level. A common wrong answer: 'Organization Policies are set at the Project level.' They can be, but they are typically set higher.
6. Numeric IDs: The exam expects you to know that organizations, folders, and projects have numeric IDs (auto-generated) and that project IDs are user-specified and globally unique. A trap: 'Project number and project ID are the same.' No, project number is numeric, project ID is a string.
7. Hierarchy Limits: Know the limits: 10 levels of nesting (including Organization), 3,000 folders per organization, 10,000 projects per organization. A question might ask: 'What is the maximum depth of the resource hierarchy?' Answer: 10 (Organization + 9 folders + project).
8. Deleting Resources: To delete a folder, it must be empty (no projects or child folders). To delete a project, you must first shut it down. A common wrong answer: 'You can delete a folder with projects by using force flag.' No force flag exists.
9. Billing Account Association: The exam may ask: 'Can you associate a billing account with a folder?' Yes, but it's more common at the Organization level. If no billing account is set at the project level, it inherits from the folder or organization.
10. Common Exam Scenarios: Questions often present a scenario where a company wants to delegate control to department heads. The correct solution is to create folders for each department and assign IAM roles on those folders. A wrong answer might suggest using projects as the grouping mechanism, but projects are not hierarchical in the same way.
Elimination Strategy: When in doubt, remember that the hierarchy is a tree. Policies flow downward. If a question involves permissions, think about where the policy is set and who the user is. Use the concept of inheritance to eliminate answers that contradict it.
The GCP resource hierarchy is: Organization → Folders (optional, up to 10 levels deep) → Projects → Resources.
IAM policies are inherited downward: Organization → Folder → Project → Resource. Policies are additive (union of all).
To use folders and Organization-level features, you must have a Google Workspace or Cloud Identity account.
Project IDs are globally unique strings; project numbers are auto-generated numeric IDs.
Maximum folder nesting depth is 10 (including Organization). Maximum folders per organization: 3,000. Maximum projects per organization: 10,000.
Moving a project between folders changes IAM policy inheritance but does not affect resources.
Organization Policies (constraints) are set at Organization or Folder level and can restrict resource configurations (e.g., external IPs).
The `gcloud resource-manager folders create` command requires the `resourcemanager.folders.create` permission at the parent.
To delete a folder, it must be empty (no child folders or projects).
Billing accounts can be linked at Organization, Folder, or Project level; typically set at Organization for centralized billing.
These come up on the exam all the time. Here's how to tell them apart.
Organization Node
Root of the hierarchy; only one per Google Workspace/Cloud Identity account.
Represents the entire company or enterprise.
Cannot be deleted; it is automatically created.
IAM roles: Organization Admin, Organization Viewer.
Billing account can be linked at this level.
Folder Node
Intermediate node between Organization and Projects; multiple can exist.
Used to group projects by department, environment, etc.
Can be deleted if empty (no child folders or projects).
IAM roles: Folder Admin, Folder Viewer, Folder Creator.
Billing account can be linked, but typically inherited from Organization.
Mistake
You can create an Organization node without a Google Workspace or Cloud Identity account.
Correct
You cannot. The Organization node is automatically created when you associate a project with a Google Workspace or Cloud Identity account. Without such an account, you can only work with projects; folders are not available.
Mistake
Folders are required to use GCP; you must create at least one folder.
Correct
Folders are optional. You can place projects directly under the Organization node. Folders are used for grouping and policy inheritance, but they are not mandatory.
Mistake
IAM policies set at a folder apply to sibling folders.
Correct
IAM policies are inherited only by descendants (children, grandchildren, etc.). They do not affect sibling folders. Each folder's policy is independent.
Mistake
When you move a project to a different folder, its resources are automatically moved to the new folder's region.
Correct
Moving a project does not move any resources. Resources remain in their original locations. Only the project's position in the hierarchy changes, affecting IAM policy inheritance.
Mistake
Project ID and project number are interchangeable and both are globally unique.
Correct
Project ID is a user-specified string that is globally unique. Project number is an auto-generated numeric ID that is also globally unique. They are different values and cannot be used interchangeably in all APIs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A project ID is a user-specified, globally unique string (e.g., 'my-project-123') that you choose when creating the project. A project number is an auto-generated numeric ID (e.g., 123456789012) that is also globally unique. The project number is used in some APIs and for billing. They are not interchangeable; some APIs require one or the other.
No, you can have only one Organization node per Google Workspace or Cloud Identity account. If you have multiple Google Workspace accounts, each will have its own Organization. You cannot merge organizations.
The project loses IAM policies inherited from the old folder and gains policies from the new folder. Any IAM policies set directly on the project remain. The effective permissions on the project become the union of the new folder's policies, the Organization's policies, and the project's own policies.
Yes, Organization Policies can be set at the Organization, Folder, or Project level. However, they are typically set at higher levels to enforce consistency. If a policy is set at the Organization level, it applies to all descendants unless overridden at a lower level (if the policy allows overrides).
A folder must be empty (no child folders or projects) to be deleted. Use `gcloud resource-manager folders delete FOLDER_ID`. If the folder contains projects, you must move or delete them first. There is no force delete option.
You need the `resourcemanager.projects.create` permission at the parent level (Organization or folder). This is included in roles like `roles/resourcemanager.projectCreator` (at the Organization level) or `roles/resourcemanager.folderAdmin` (at the folder level).
No, moving a project from one Organization to another is not supported. You would need to recreate the project and resources in the destination organization. This is a common challenge in mergers and acquisitions.
You've just covered GCP Projects, Folders, and Organizations — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?