2.1 The GCP Resource Hierarchy: Organizations, Folders & Projects

Why the Resource Hierarchy Comes First

Every other topic on the Associate Cloud Engineer (ACE) exam attaches to a node in the resource hierarchy — billing accounts link to projects, IAM roles bind to organizations/folders/projects, and organization policies cascade down from the top. The official exam guide's very first bullet under "Setting up a cloud solution environment" is "Creating a resource hierarchy," and scenario questions routinely test whether you know where in the hierarchy to attach a control, not just what the control does.

Quick Answer: Google Cloud resources form a tree: Organization (root, optional but common for real companies) → Folders (optional, unlimited-purpose grouping) → Projects (the billing and IAM unit that actually contains resources) → Resources (VMs, buckets, GKE clusters, and so on). Permissions and organization policies set on a node are inherited by everything beneath it.

The Four Levels

The Organization Node

An organization resource is automatically provisioned the first time someone with a Cloud Identity or Google Workspace account creates a Google Cloud project — this is why Domain 1's Cloud Identity bullet (covered fully in section 2.3) is a prerequisite for a "real" organization node, not an optional add-on. The org node has a unique numeric organization ID, a display name derived from your verified primary domain, and it acts as the parent to every folder and project your company owns. The Google Workspace Super Admin automatically gets IAM authority over the new organization and should immediately delegate the Organization Administrator role (roles/resourcemanager.organizationAdmin) to a smaller group of cloud admins rather than operating everything from the Workspace super-admin account.

Without Cloud Identity/Workspace, a project simply has no organization — it floats as a standalone project owned by the individual who created it. This matters on the exam: a scenario describing projects that "don't roll up under any company-wide policy" is describing exactly this no-organization state.

Folders: Grouping Without Losing Inheritance

Folders sit between the organization and projects and exist purely to group resources for delegation and policy scoping — they model "different legal entities, departments, and teams within a company," and they nest, so a Marketing folder can contain Marketing/APAC and Marketing/EMEA subfolders.

Two hard limits the exam guide's blueprint expects you to know precisely:

• Maximum folder nesting depth: 10 levels below the organization.
• Maximum direct child folders per parent: 300 (this limit is on direct children only — a folder can still have unlimited descendants across all 10 levels).

A common real-world pattern is two top-level folders directly under the organization — Production and Non-Production (or Prod/Sandbox) — each with its own IAM bindings and organization policies, so every project a team creates automatically inherits the right guardrails just by being placed in the correct folder. This is far more scalable than tagging or labeling projects and hoping engineers remember to apply the right IAM bindings manually to each one.

Projects: ID, Number, and Name

A project is the actual container for resources, APIs, and billing — it's the smallest unit you can attach a Cloud Billing account to. Every project has three distinct identifiers that the exam loves to test candidates on confusing:

The Project ID is what you reference in most gcloud commands and API calls, and it can never be reused — even after the project is permanently deleted, its ID is retired forever. The Project Number is the truly immutable, Google-internal numeric key some APIs and Cloud Audit Log entries expose instead of the ID.

Project Lifecycle: Shutdown and Deletion

When a project is deleted ("shut down"), it doesn't disappear immediately — it enters a 30-day recovery window in a DELETE_REQUESTED state, during which an Owner can restore it. During this window most resources are recoverable, but Cloud Storage objects may be purged as early as 7 days after shutdown and are not guaranteed to survive the full 30 days. The associated Cloud Billing account is disconnected immediately on shutdown and must be manually re-linked after a restore. After the 30-day window closes, the project and all its resources are permanently and irrecoverably deleted, and — consistent with the ID rule above — its project ID can never be issued to a new project again.

Exam Scenario

A retail company has one Google Cloud organization. Their platform team wants every project created by the marketing analytics group to automatically inherit a stricter data-residency policy than projects created by the internal tools group, without engineers having to remember to configure anything per-project. The correct move is to create two folders under the organization — one for each group — attach the residency-related organization policy (see section 2.2) to the marketing analytics folder, and require new projects for that group to be created inside it. Any project dropped into that folder inherits the policy automatically; a label or naming convention would not enforce anything.

Takeaways for the Exam

• Know the exact order: Organization → Folder(s) → Project(s) → Resources, and that folders and the organization node are both optional (a project can exist standalone).
• Memorize the two folder limits: 10 levels of nesting, 300 direct child folders per parent.
• Never confuse Project ID (permanent, text, never reused), Project Name (mutable display label), and Project Number (permanent, system-assigned numeric).
• A deleted project has a 30-day restore window, but Cloud Storage data may be gone after just 7 days — don't assume the full 30 days applies to every resource type.