Google Cloud Fundamentals - Complete Guide from Zero to Exam Ready

Understanding the GCP Resource Hierarchy and Projects

### The four-level hierarchy that organizes everything Google Cloud organizes every resource inside a strict hierarchy, and unlike a flat list of accounts, permissions and policies set at a higher level automatically apply to everything beneath it. +------------------------------------------+ | Organization (tied to a Google Workspace | | or Cloud Identity domain) | +------------------------------------------+ | v +------------------------------------------+ | Folders (optional - group projects by team,| | department, or environment) | +------------------------------------------+ | v +------------------------------------------+ | Projects (the actual billing and IAM | | scoping boundary) | +------------------------------------------+ | v +------------------------------------------+ | Resources (VMs, buckets, databases, etc.) | +------------------------------------------+ A **Project** is the fundamental unit almost everything else in GCP is scoped to - every resource belongs to exactly one project, every project has its own unique Project ID (globally unique, chosen once, never changeable), and billing is configured per project by linking it to a Billing Account. > 🔴 **Common Mistake:** Assuming a GCP Project works like an AWS Account or an Azure Subscription in every respect. It is the closest equivalent for IAM and billing scoping, but a single Google Cloud Organization commonly contains many projects, often one per application or environment, rather than the coarser account-per-team pattern common elsewhere. ### Creating and organizing projects ```bash # Create a new project with a specific, permanent Project ID gcloud projects create devops-network-prod-01 \ --name="DevOps Network Production" # List all projects you have access to gcloud projects list # Set a project as the active default for subsequent commands gcloud config set project devops-network-prod-01 ``` > **Note:** The Project ID (`devops-network-prod-01` here) is globally unique across all of Google Cloud and cannot be changed after creation - choose it carefully, since a typo or a name you later regret means creating an entirely new project rather than renaming this one. ### Organizational Policies - governance rules that apply automatically **Organization Policies** let you set constraints that apply across an entire Organization, Folder, or Project - for example, restricting which regions resources can be created in, or disabling the creation of external IP addresses on VMs by default. ```bash # View the current state of a specific organization policy constraint gcloud resource-manager org-policies describe \ compute.vmExternalIpAccess \ --project=devops-network-prod-01 ``` > 💡 **Tip:** Set Organizational Policies at the Folder level when a rule should apply to every project within a specific team or environment, rather than configuring the same constraint individually on each project - policy inheritance means you only need to set it once at the right level. ### Managing users and groups with Cloud Identity **Cloud Identity** is Google's identity management service - similar in role to Azure AD or an AWS Organization's user management, it's where your organization's users and groups actually live, separate from any single project. ```bash # Grant a user a role at the project level gcloud projects add-iam-policy-binding devops-network-prod-01 \ --member="user:priya.sharma@example.com" \ --role="roles/editor" ``` ### Enabling APIs - the gatekeeper for every GCP service Unlike some clouds where every service is available the moment an account exists, GCP requires each service's API to be explicitly enabled per project before it can be used at all - a deliberate friction point that also serves as a simple audit trail of what a project actually uses. ```bash # Enable the Compute Engine API for the active project gcloud services enable compute.googleapis.com # List all currently enabled APIs for the active project gcloud services list --enabled ``` > 🔴 **Common Mistake:** Trying to create a resource and getting a confusing "API not enabled" error, then assuming something is broken with the account. This is expected default behavior - the specific service's API simply needs to be enabled for that project first, which typically takes seconds once run. ### Assessing and requesting quota increases Every project has default resource quotas - a limit on how many VM CPUs, IP addresses, or API calls can be used per project per region, designed to prevent runaway costs and protect shared infrastructure. ```bash # Check current quota usage and limits for Compute Engine in a region gcloud compute regions describe asia-south1 \ --project=devops-network-prod-01 ``` > 📌 **Remember:** Quotas are a safety mechanism, not a bug - a project hitting its quota unexpectedly during a legitimate scaling event should trigger a quota increase request through the Console, not a workaround. Requesting an increase in advance of a known future need (like a planned launch event) avoids being blocked at the worst possible moment. ---