Google Cloud Fundamentals
Organizations, folders, projects, and resources - plus regions and zones - the shape every Google Cloud deployment shares.
On this page5 sections
The earlier cloud lessons covered ideas every provider shares. This lesson and the seven after it make those ideas concrete on Google Cloud (often called GCP), using the official documentation's own terms and the real gcloud commands.
The practice terminal simulates
gcloud. Nothing you type there touches a real Google Cloud account, but every command works the same way on a real project.
The resource hierarchy
Everything in Google Cloud sits in a tree with four levels:
Organization example.com - the company itself
└── Folders optional: departments, teams, environments
└── Projects where you actually enable services and get billed
└── Resources VMs, buckets, Cloud Run services, clusters...
- The organization is the root. It represents a company and is the parent of every folder and project.
- Folders are optional grouping. Teams commonly use them for departments or for
prodversusdev. - A project is the basic unit you work in. You enable APIs, create resources, and attach billing at the project level. Every resource belongs to exactly one project.
- Resources are the services themselves: Compute Engine VMs, Cloud Storage buckets, and so on.
Policies flow downwards
Access-control (IAM) policies and organization policies set on a node are inherited by everything below it. Grant a team a role on their folder, and they have it on every project in that folder automatically. That is why the hierarchy matters for security, not just tidiness.
Three ways to name a project
| Identifier | Who picks it | Can it change? | Unique? |
|---|---|---|---|
| Project name | You | Yes, any time | No |
| Project ID | You, at creation | Never | Globally, across all of Google Cloud |
| Project number | Google, automatically | Never | Yes |
The project ID is what you type in commands and API calls: 6 to 30 lowercase letters, digits, or hyphens, starting with a letter. Pick it with care, because it is permanent.
Regions and zones
A region is a geographic location such as us-central1 (Iowa) or europe-west1 (Belgium). Each region is divided into zones, such as us-central1-a. Most regions have three or more zones, and zones are isolated from one another so a failure in one rarely affects the others.
Resources have a scope that follows from this:
- Zonal - a Compute Engine VM and its disks live in one zone.
- Regional - a Cloud Run service or a regional GKE cluster spans the zones of one region.
- Global - a VPC network or a global load balancer is not tied to any region.
Spreading a workload across zones protects against a zone outage. Spreading it across regions protects against a regional one.
Try it
gcloud projects list
gcloud config set project learninx-demo
gcloud compute regions list
gcloud compute zones list
When you're ready, hit Mark complete and move to the next lesson.
Further reading
- Resource hierarchy (opens in a new tab) - official overview of organizations, folders, projects, and policy inheritance.
- Geography and regions (opens in a new tab) - how regions and zones are laid out and how to design for them.
- "Google Cloud Platform in Action" by JJ Geewax (Manning) - a book-length tour of the core services, written by a Google engineer.
Challenge
Point the gcloud CLI at the project whose ID is learninx-demo, so every following command acts on it.
Want to experiment first? Try things in the practice terminal (opens in a new tab), then enter the command that solves the task here.
Quiz
Lock in the concepts. Score at least 80% to mark the lesson complete.
Done with this one?
Skipped the challenge? You can mark the lesson complete by hand.