GCP Platform Overview

• GCP is one of the three largest public clouds and the platform of choice for many data-heavy and Kubernetes-native companies.
• Every other concept in this module (Compute Engine, Cloud Storage, GKE, Cloud Run) is a specific GCP service — you need the map before the services.
• The project is the unit of everything: permissions, billing, quotas and enabled APIs all hang off the project you are working in.
• Regions and zones drive latency, cost and high-availability decisions on every GCP project.
• Billing awareness — free tier limits, committed use discounts, egress costs — is part of being a good DevOps engineer.

Each warehouse is a region, and each wing with independent power and water is a zone. Your storage unit is a project: you rent only your units, each has its own lease and bill (billing account), and the property manager can apply rules to a whole wing of units (folders) so a leak in one unit never crosses into another. The front desk (Console and gcloud CLI) is the only place you ever request units, sizes and access — you never enter the warehouse floor.

• Google operates data centers worldwide, grouped into regions; most regions have multiple zones with independent power, cooling and networking.
• You create resources inside a project, the fundamental scoping container; the organization, folders and labels sit above it to apply policies, budgets and access at scale.
• You manage resources through the control plane — Console, gcloud CLI, SDKs or IaC tools like Terraform — and services provision them in seconds to minutes.
• Identity is enforced by IAM: every Console user or CLI call is authenticated as a user, service account or group with attached roles.
• Usage is metered — vCPU hours, GB stored, network egress, API calls — and billed to a billing account; the free tier lets you experiment within limits.

• Organize projects with folders per team and environment (dev, staging, prod) so IAM policies and budgets apply cleanly.
• Enable only the APIs you need per project and track them with gcloud services list.
• Use committed use discounts and spot VMs to cut compute cost for stable and fault-tolerant workloads.
• Set budget alerts and export billing to BigQuery so spend is reviewed weekly, not quarterly.
• Prefer infrastructure as code so every environment is reproducible and reviewable.

• Name projects with a consistent scheme like company-env-app, because project IDs become part of resource URLs.
• Always create resources in the region you intend — a VM in us-central1 is invisible to a team on europe-west1.
• Default to least-privilege IAM roles instead of granting blanket owner access.
• Write down your organization ID and billing account ID somewhere safe, and enable MFA on every admin account.
• Keep billing and quota awareness from day one — a free-tier project can still incur egress costs.

• Working in the wrong project and wondering why resources are missing or the bill is wrong.
• Creating one giant project for everything instead of isolating environments with folders.
• Leaving the default VPC network with broad firewall rules enabled 'temporarily'.
• Forgetting that egress (data leaving the cloud) is billed, which surprises data-heavy workloads.
• Assuming every service is available in every region — some newer services are regional only.

• Start every debugging session with gcloud config list to confirm project, region, zone and account.
• Check the region you are targeting; many 'permission denied' errors are actually wrong-project requests.
• Use gcloud projects list and gcloud auth list to confirm you are where you think you are.
• Use the Google Cloud Status page to separate provider incidents from your own configuration.
• Read the API error code before guessing: PERMISSION_DENIED, NOT_FOUND and RESOURCE_EXHAUSTED all mean different fixes.