This chapter covers the GCP resource hierarchy — Organization, Folders, and Projects — the foundational structure for managing access control, cost allocation, and policy enforcement. Understanding this hierarchy is critical for the ACE exam, as approximately 15-20% of questions touch on resource hierarchy concepts, IAM inheritance, and organizational policies. You will learn how to design, implement, and troubleshoot the hierarchy to ensure secure, scalable cloud governance.
Jump to a section
Imagine a global corporation with a headquarters (HQ), several divisions (e.g., Sales, Engineering, Finance), and local offices within each division. The HQ (Organization node) owns all resources and sets company-wide policies, like security rules and budget limits. Divisions (Folders) group related offices and can apply their own policies, such as requiring multi-factor authentication for all Engineering offices. Each local office (Project) is a separate cost center with its own resources (VMs, databases). Employees (IAM users) get access based on their role: a Salesperson might access only their local office, while a Division VP can manage all offices in their division. Billing flows up: each office pays its own bills, but the division sees a consolidated report, and HQ sees the entire company spend. The hierarchy allows delegation: HQ can give a Division VP full control over their division without touching other divisions. If a policy is set at HQ, it applies to all divisions and offices, but a division can override it only if allowed. This mirrors GCP's resource hierarchy: Organization, Folders, Projects, with IAM policies inherited downward and resource management scoped to projects.
What is the GCP Resource Hierarchy?
The GCP resource hierarchy is a tree-like structure that organizes cloud resources (projects, folders, and the organization node) to manage access control and configuration inheritance. It has four levels:
Organization node (root)
Folders (optional, can be nested)
Projects (leaf nodes)
Resources within projects (e.g., Compute Engine instances, Cloud Storage buckets)
Policies (IAM, Organization Policies) are inherited from parent to child. This means you can set a policy at the Organization level and it automatically applies to all folders and projects underneath, unless overridden (where allowed).
Why It Exists
Without a hierarchy, managing permissions across hundreds of projects would require manual assignment per project, leading to errors and security gaps. The hierarchy enables:
Centralized policy enforcement (e.g., restrict VM external IPs across all projects)
Delegated administration (e.g., give a team admin access to their folder only)
Cost tracking and billing aggregation (e.g., view costs by folder)
Logical grouping of resources (e.g., separate production and development)
How It Works Internally
Every GCP resource belongs to exactly one project. Projects are the fundamental unit of resource ownership and billing. Folders can contain projects and other folders, up to 10 levels deep. The Organization node is the top-level container for all resources under a Google Workspace or Cloud Identity account.
IAM policies are evaluated at each level and combined with inheritance. When a user makes an API call, the IAM system computes effective permissions by traversing the hierarchy from the resource up to the Organization, granting access if any node allows it (unless denied by an Organization Policy with a deny rule). Organization Policies (formerly called "Constraints") are enforced at the Organization, Folder, or Project level and can restrict specific services or features (e.g., disable Service Account key creation).
Key Components, Values, Defaults, and Timers
Organization Node: Created automatically when you have a Google Workspace or Cloud Identity account. The domain (e.g., example.com) becomes the organization ID. You cannot delete it; you can only transfer ownership. The first super admin becomes the Organization Admin.
Folders: Optional, but recommended for environments with >10 projects. You can nest folders up to 10 levels deep. Folder IDs are globally unique, auto-generated strings (e.g., 123456789012).
Projects: Each project has a unique project ID (user-created, immutable after creation), a project name (mutable), and a project number (auto-generated, globally unique). Billing is linked to a project; you cannot have a project without a billing account active. There is a soft quota of 30 projects per user, but you can request more.
IAM Inheritance: Policies are inherited downward. A policy set on a folder applies to all projects and subfolders within it. Deny policies (from Organization Policy constraints) are also inherited and cannot be overridden by child nodes unless explicitly allowed.
Organization Policy Constraints: Predefined list of constraints (e.g., compute.vmExternalIpAccess, iam.disableServiceAccountKeyCreation). They can have allow or deny lists. They are evaluated before IAM; if a constraint denies an action, IAM cannot override it.
Configuration and Verification Commands
To view the hierarchy:
gcloud organizations list
gcloud resource-manager folders list --organization=ORGANIZATION_ID
gcloud projects list --filter="parent.id:PARENT_ID"To create a folder:
gcloud resource-manager folders create --display-name="Production" --organization=ORGANIZATION_IDTo create a project under a folder:
gcloud projects create PROJECT_ID --folder=FOLDER_IDTo set IAM policy at the folder level:
gcloud resource-manager folders add-iam-policy-binding FOLDER_ID --member='user:admin@example.com' --role='roles/compute.instanceAdmin'To set an Organization Policy constraint:
gcloud resource-manager org-policies set-policy POLICY_FILE --organization=ORGANIZATION_IDHow It Interacts with Related Technologies
IAM: The hierarchy determines effective permissions. A user with roles/editor on a folder gets editor access to all projects under it.
Billing: Each project has a billing account. You can view costs aggregated by folder or organization using Cloud Billing reports.
Service Accounts: Service accounts are resources within a project. They can be granted IAM roles at higher levels (e.g., folder) to access resources in other projects.
VPC Service Controls: These operate at the project level but can be organized using folders to group perimeters.
Audit Logging: Admin Activity logs are enabled by default at the Organization level. You can use folder-level sinks to route logs to different destinations.
Best Practices and Traps
Flat Hierarchy: Avoid creating too many nested folders; keep depth <= 3 for manageability.
Naming Conventions: Use consistent naming for folders and projects (e.g., prod-us-east, dev-eu-west).
IAM vs Organization Policies: Remember that IAM grants access; Organization Policies restrict features. They are complementary.
Project Deletion: When you delete a project, you have a 30-day grace period to recover it. After that, the project ID cannot be reused.
Organization Node Deletion: You cannot delete the Organization node. If you leave Google Workspace, you must transfer ownership.
Common Exam Scenarios
Given a scenario where a user can't create a VM in a project, but they have compute.instanceAdmin at the project level, the issue might be an Organization Policy blocking external IPs or a missing folder-level permission.
When asked to delegate administration of a subset of projects, create a folder, move the projects into it, and grant the admin role on the folder.
For cost tracking, set up billing budget alerts at the folder or organization level.
Create the Organization Node
When you sign up for Google Workspace or Cloud Identity, GCP automatically creates an Organization node with the domain name as the ID. The initial super admin becomes the Organization Admin (roles/resourcemanager.organizationAdmin). This node is the root of your hierarchy. You cannot create it manually; it must be provisioned by Google. If you use a free Gmail account, you get a 'no organization' setup, meaning you cannot use folders or organization policies. To verify, run: `gcloud organizations list`. The output shows the organization ID and display name.
Create Folders for Logical Grouping
Folders are optional but recommended for environments with more than 10 projects. Use folders to group projects by environment (e.g., Production, Development), business unit, or lifecycle stage. To create a folder, use: `gcloud resource-manager folders create --display-name='Production' --organization=ORGANIZATION_ID`. The folder gets a unique numeric ID. You can nest folders up to 10 levels deep. For example, under 'Production' you might have 'US' and 'EU' subfolders. Move existing projects into folders using: `gcloud projects update PROJECT_ID --folder=FOLDER_ID`.
Create Projects Under Folders
Projects are the fundamental unit in GCP. Each project contains resources (VMs, buckets, etc.) and has its own billing account. To create a project under a folder, run: `gcloud projects create PROJECT_ID --folder=FOLDER_ID`. The project ID must be globally unique and immutable. The project number is auto-generated. You can also create a project without a folder, but then it is orphaned (directly under Organization). Best practice is to always create projects under a folder. After creation, you can add IAM members and enable APIs.
Set IAM Policies at Each Level
IAM policies are inherited downward. Set broad roles at the Organization level (e.g., Organization Viewer) and more specific roles at folder or project levels. For example, grant `roles/editor` on a folder to a team lead; they will have editor access to all projects in that folder. Use the principle of least privilege. To set IAM on a folder: `gcloud resource-manager folders add-iam-policy-binding FOLDER_ID --member='user:lead@example.com' --role='roles/editor'`. Remember that Organization Policies (constraints) can override IAM permissions – e.g., if a constraint denies external IPs, even an editor cannot assign external IPs.
Apply Organization Policies (Constraints)
Organization Policies are restrictions that apply to all child resources. They are defined using a YAML or JSON file with constraints. For example, to disable Service Account key creation for all projects: create a policy file with `constraint: constraints/iam.disableServiceAccountKeyCreation` and set `listPolicy` to deny all. Apply it with: `gcloud resource-manager org-policies set-policy POLICY_FILE --organization=ORGANIZATION_ID`. Policies can be applied at folder or project level too, overriding the parent policy if allowed. Common constraints include `compute.vmExternalIpAccess` (restrict external IPs) and `iam.allowedPolicyMemberDomains` (restrict IAM members to specific domains).
Enterprise Scenario 1: Multi-National Corporation with Compliance Requirements
A global retail company with 500+ projects across 3 regions (US, EU, Asia) needs to enforce strict data residency and compliance (GDPR, CCPA). They create an Organization node under their corporate domain. They then create top-level folders for each region: 'US', 'EU', 'Asia'. Under each region folder, they have subfolders for environment: 'Production', 'Staging', 'Development'. Each project is created under the appropriate environment folder. IAM roles are assigned at the folder level: 'EU-Production' folder grants roles/compute.admin to the EU infrastructure team, while 'US-Production' folder grants the same to the US team. Organization Policies are applied at the region folder level: for the 'EU' folder, they set a constraint constraints/gcp.resourceLocations to restrict resource creation to EU regions only. This prevents developers from accidentally creating resources in US regions, ensuring GDPR compliance. Billing budgets are set at the folder level to alert when costs exceed thresholds. This hierarchy simplifies audit: compliance auditors can review IAM policies and constraints at the folder level without inspecting every project.
Enterprise Scenario 2: Startup with Rapid Growth and Delegated Administration
A fast-growing startup has 50 projects and expects to double in 6 months. Initially, they had a flat structure with all projects under the Organization. As the team grew, they needed to delegate admin responsibilities to product teams. They created folders for each product line: 'ProductA', 'ProductB', 'ProductC'. Under each product folder, they created 'Dev', 'Staging', 'Prod' subfolders. Each product team lead was granted roles/resourcemanager.folderAdmin on their product folder, allowing them to create and manage projects within that folder without affecting others. The startup also used Organization Policies to enforce that all projects must have a billing account attached (though this is default) and that no project can use the default Compute Engine service account without explicit approval (using constraints/iam.automaticIamGrantsForDefaultServiceAccounts). This prevented security incidents. The hierarchy scaled smoothly as new projects were created under existing folders.
Common Pitfalls in Production
Orphaned Projects: When a folder is deleted, its projects become orphaned (directly under Organization). This can break IAM inheritance if you had roles granted on the folder. Always move projects to another folder before deleting a folder.
Overly Deep Nesting: One company created 8 levels of nested folders, making it impossible to navigate and manage policies. Keep depth to 3-4 levels max.
Misapplied Organization Policies: Setting a constraint at the Organization level that is too restrictive (e.g., disabling all external IPs) can block legitimate use cases. Test policies on a test folder first.
IAM Policy Size Limits: Each IAM policy binding has a limit of 1,500 members per role. If you need more, use groups instead of individual users. The entire policy size is limited to 256 KB.
What the ACE Exam Tests on This Topic
ACE objective 1.1 specifically asks you to "plan and configure the resource hierarchy" including Organization, Folders, and Projects. You will be expected to:
Understand the order of inheritance: Organization → Folder → Project → Resource
Know that IAM policies are additive (union of all allow policies) but Organization Policies can deny actions
Be able to identify the correct command to create a folder or project under a specific parent
Recognize when to use folders vs. projects for grouping
Understand that projects are the billing boundary and resource container
Know that the Organization node exists only with Google Workspace or Cloud Identity
Most Common Wrong Answers and Why Candidates Choose Them
"IAM policies are evaluated top-down, and the most restrictive policy wins." This is false. IAM is additive; the union of all allow policies is granted. Deny only comes from Organization Policies. Candidates confuse IAM with Organization Policies.
"You can create an Organization node using gcloud." False. The Organization node is automatically created when you sign up for Google Workspace/Cloud Identity. You cannot create it manually. Candidates think it's like creating a folder.
"Projects can be nested inside other projects." False. Projects are leaf nodes; they cannot contain other projects. Only folders can contain projects. Candidates confuse projects with folders.
"Deleting a project immediately removes all resources." False. There is a 30-day grace period. Resources are not immediately deleted; they are recoverable. Candidates think deletion is instantaneous.
Specific Numbers and Values to Memorize
Maximum folder nesting depth: 10 levels
Default project quota per user: 30 (soft limit)
Project deletion grace period: 30 days
Organization Policy constraint names: compute.vmExternalIpAccess, iam.disableServiceAccountKeyCreation, gcp.resourceLocations
IAM role for folder admin: roles/resourcemanager.folderAdmin
Command to move project: gcloud projects update PROJECT_ID --folder=FOLDER_ID
Edge Cases and Exceptions
If you have a Gmail account (no Google Workspace), you cannot use folders or Organization Policies. You can only create projects under the Organization node (which is essentially a virtual organization).
When you set an Organization Policy at a folder, it overrides the Organization-level policy only if the constraint allows overrides (most do).
IAM policies set on a resource (e.g., a VM) do not propagate to other resources; inheritance only applies down the hierarchy.
How to Eliminate Wrong Answers
If a question asks about restricting a feature (e.g., disabling external IPs), the answer is an Organization Policy, not an IAM role.
If a question asks about delegating project creation, the answer is to grant roles/resourcemanager.projectCreator at the folder level.
If a question mentions cost tracking, think of folders for aggregation and billing budgets.
Always check the parent: if a project is under a folder, IAM on that folder applies. If orphaned, only Organization-level IAM applies.
The resource hierarchy is Organization → Folder(s) → Project(s) → Resources.
IAM policies are inherited downward and are additive (union of all allows).
Organization Policies (constraints) are separate from IAM and can deny actions.
Folders are optional but recommended for >10 projects; max nesting depth is 10.
Projects are the billing boundary; each project must have a billing account.
The Organization node exists only with Google Workspace or Cloud Identity.
Deleted projects have a 30-day grace period before permanent deletion.
Use `gcloud resource-manager folders create` and `gcloud projects create --folder=` to build the hierarchy.
Grant `roles/resourcemanager.folderAdmin` to delegate folder management.
Organization Policy constraints like `compute.vmExternalIpAccess` restrict features globally.
These come up on the exam all the time. Here's how to tell them apart.
Folders
Contain projects and other folders (up to 10 levels deep)
Cannot contain resources directly (VMs, buckets)
Used for grouping and policy inheritance
No billing account attached; billing is at project level
Can have IAM policies and Organization Policies applied
Projects
Leaf nodes in the hierarchy; contain resources
Cannot contain other projects or folders
Fundamental unit of resource ownership and billing
Each project has a billing account; costs are tracked per project
Can have IAM policies and Organization Policies applied, but also resource-level IAM
Mistake
IAM policies are hierarchical and the most restrictive policy wins.
Correct
IAM policies are additive. All allow policies from the resource up to the Organization are combined; the user gets the union of all permissions. Deny only comes from Organization Policy constraints, which are separate from IAM.
Mistake
You can create an Organization node using gcloud or the console.
Correct
The Organization node is automatically created when you sign up for Google Workspace or Cloud Identity. You cannot create it manually. If you use a free Gmail account, you do not have an Organization node.
Mistake
Projects can contain other projects.
Correct
Projects are leaf nodes in the hierarchy. They cannot contain other projects. Only folders can contain projects and other folders.
Mistake
Deleting a project immediately removes all resources.
Correct
When you delete a project, it enters a 30-day grace period where resources are not accessible but can be recovered. After 30 days, the project is permanently deleted and its ID cannot be reused.
Mistake
Organization Policies are the same as IAM policies.
Correct
Organization Policies are constraints that restrict features (e.g., disable external IPs), while IAM policies grant access. They are separate systems. A constraint can deny an action even if IAM allows it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IAM policies grant permissions to users (who can do what), while Organization Policies (constraints) restrict features on resources (what can be done). IAM is additive; Organization Policies can deny actions even if IAM allows them. For example, an IAM policy may grant a user permission to create VMs, but an Organization Policy may block the use of external IPs, preventing the user from creating a VM with an external IP.
Yes, you can create a project directly under the Organization node. However, best practice is to create projects under folders to enable better policy management and cost tracking. If you have no Organization node (e.g., free Gmail), projects are created under a virtual organization.
Use the command: `gcloud projects update PROJECT_ID --folder=NEW_FOLDER_ID`. The project must be in the current folder (not orphaned). You can also do this in the console under IAM & Admin > Manage Resources. Note that moving a project may affect IAM inheritance: roles granted on the old folder will no longer apply.
The project enters a 30-day grace period. During this time, resources are not accessible but can be recovered by undeleting the project. After 30 days, the project and all its resources are permanently deleted. The project ID cannot be reused.
No. Folders require an Organization node, which is only available with Google Workspace or Cloud Identity. If you use a free Gmail account, you cannot create folders or use Organization Policies.
The initial super admin of Google Workspace/Cloud Identity becomes the Organization Admin (roles/resourcemanager.organizationAdmin). There is no default role assigned to other users; they must be explicitly granted access.
Use the Policy Troubleshooter in the console (IAM & Admin > Policy Troubleshooter) or the `gcloud policy-intelligence query-access` command. This tool shows which policies grant or deny access and helps debug permission issues.
You've just covered GCP Resource Hierarchy: Org, Folder, Project — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?