Lesson 2: Creating a Resource Hierarchy

Before you start

This course is independent of Google. Google does not endorse it, and it cannot promise you a pass. The syllabus comes from Google's own Associate Cloud Engineer exam guide. We don't reproduce the guide here, but you can download it free from the certification page. The exam lasts 2 hours, has 50–60 multiple-choice and multiple-select questions and costs $125 (plus tax where applicable).

This level covers the first item in Section 1.1 of the guide: Creating a resource hierarchy.

The four levels of the hierarchy

Google Cloud arranges everything you own in a tree. If you know on-premises IT, think of Active Directory: a domain at the top, organizational units (OUs) in the middle and machines at the bottom.

1. Organization: the root node. It represents your company and is tied to one Google Workspace or Cloud Identity account. It is created automatically when a user of that account creates a project.
2. Folders (optional): groupings such as departments, teams or environments. You can nest folders up to 10 levels deep.
3. Projects: the base level for using Google Cloud. You enable APIs, attach billing and create resources inside a project.
4. Resources: VMs, buckets, databases and so on. Each one lives in exactly one project.

Key rule: every resource except the Organization has exactly one parent. A project's parent is either a folder or the Organization, never both.

Why policies flow downward

Access policies are inherited down the tree. The effective policy on a resource is the union of the policy set on the resource itself and every policy set on its ancestors, up to the Organization.

Worked example for a company called Acme:

Organization: acme.com
├── Folder: Engineering
│   ├── Folder: Prod  → project acme-web-prod
│   └── Folder: Dev   → project acme-web-dev
└── Folder: Finance   → project acme-ledger

• A grant at acme.com reaches every folder and project.
• A grant on Engineering reaches Prod, Dev and both web projects, but not Finance.
• Inheritance only adds access. A grant at a lower level can give more access, but it cannot remove access inherited from above.

What to do: group projects so they share a parent wherever they need the same controls, such as "all production" or "all of Finance". You can then set a control once on the folder instead of once per project. Organization policies and IAM grants are covered in L3 and L4.

Project ID, project name and project number

Every project has three identifiers, and the exam expects you to tell them apart.

To remember the difference:

• The name is a friendly label for people. Google APIs don't use it.
• The ID is what you type in gcloud --project=... and in your code.
• The number is what Google's internal systems, billing and quotas use.

What to do: choose IDs carefully, because a typo is permanent. A pattern like acme-web-prod works well.

Task 1: Create the hierarchy in the console

1. Open IAM & Admin → Manage Resources.
2. Click Create Folder. Enter a display name such as Engineering and choose the Organization as the parent. Display names must be 3–30 characters, start and end with a letter or digit, and be different from any sibling folder's name.
3. Repeat for the Prod and Dev folders, choosing Engineering as their parent.
4. Click Create Project. Enter a name, check or edit the suggested project ID, then set Location to the target folder.
5. Open the project dashboard and check the name, ID and number shown there.

To create folders you need the Folder Creator or Folder Admin role on the parent.

Task 2: Create the same hierarchy with gcloud

1. Find your Organization ID:

   gcloud organizations list
   

2. Create a top-level folder under the Organization:

   gcloud resource-manager folders create \
     --display-name="Engineering" \
     --organization=123456789012
   

3. Create a nested folder by using --folder instead of --organization:

   gcloud resource-manager folders create \
     --display-name="Prod" --folder=FOLDER_ID_OF_ENGINEERING
   

   Look up folder IDs with gcloud resource-manager folders list --organization=123456789012. Folder IDs take the form folders/12345.
4. Create a project inside a folder:

   gcloud projects create acme-web-prod \
     --name="Acme Web Prod" --folder=FOLDER_ID_OF_PROD
   

   Use --folder or --organization, never both, because a project can have only one parent.
5. Verify the result:

   gcloud projects describe acme-web-prod
   

   The output shows projectId, name, projectNumber and the parent.

What the exam asks about this

• Design scenarios: "Apply a control to all production projects with the least effort." Put those projects under one folder and set the control on the folder.
• Identifier traps: questions test which identifier is permanent, which is changeable, and why a deleted project's ID can't be reused.
• Command recognition: the folder command is gcloud resource-manager folders create. A project goes under a folder with gcloud projects create ... --folder.
• Inheritance logic: access granted higher up can't be taken away lower down.

Key takeaways

• The hierarchy runs Organization → folders (optional, up to 10 levels) → projects → resources, and each resource has exactly one parent.
• Policies are inherited downward. The effective policy is the union of the resource's own policy and all of its ancestors' policies.
• The project name can change. The project ID (you choose it) and the project number (Google generates it) are permanent.
• Project IDs are 6–30 characters, lowercase, start with a letter, cannot end with a hyphen, and are never reusable.
• Create folders with gcloud resource-manager folders create, and projects with gcloud projects create ID --folder=FOLDER_ID.