Google Cloud (GCP) interview revision notes

Google Cloud Platform: compute, storage, serverless. Written for developers preparing for an interview who want to refresh their Google Cloud (GCP) fast. Free, no sign-up.

18 topics in these notes

What is GCP?
Projects, billing & organization
IAM (Identity and Access Management)
Compute Engine (VMs)
Cloud Run
Cloud Functions
Cloud Storage
Cloud SQL
Firestore
BigQuery
Pub/Sub
VPC & networking
Cloud Build
Artifact Registry
Secret Manager
Cloud Logging & Monitoring
Deployment & CI/CD
Cost optimization & best practices

What is GCP?

Simple real-life example (Understand first — very important for understanding)

Think of a company that rents out computers, storage, and services over the internet: you don't buy servers, you use theirs and pay for what you use.
Google Cloud Platform (GCP) is one such provider: it offers virtual machines, databases, storage, and many managed services so you can build and run apps in the cloud.
Real-world idea: rent computing power and services instead of running your own data center.

Real-world idea: cloud = someone else runs the machines and services; you build and scale your app on top.

Technical definition

Google Cloud Platform (GCP) is Google's suite of cloud services: compute, storage, databases, ML, networking, and more. Competes with AWS and Azure.
Services are organized by category: Compute (VMs, containers, serverless), Storage, Databases, Networking, Big Data (BigQuery), AI/ML, and DevOps (Cloud Build, Artifact Registry).
Pay-as-you-go; free tier and credits for new accounts. Access via Console (web), gcloud CLI, or client libraries (e.g. Node, Python).

Simple practical example

Services are organized by category: Compute (VMs, containers, serverless), Storage, Databases, Networking, Big Data (BigQuery), AI/ML, and DevOps (Cloud Build, Artifact Registry).

Code example

# Install gcloud CLI, then:
gcloud auth login
gcloud config set project MY_PROJECT_ID
gcloud run deploy my-service --source .

Why it matters

Cloud roles often use GCP. "What is GCP?" and "How does it compare to AWS?" are common. Know the main service categories.

Interview tip

"GCP is Google's cloud: compute, storage, DB, ML, etc. Access via Console, gcloud CLI, or APIs. Pay-as-you-go; free tier available."

Projects, billing & organization

Simple real-life example (Understand first — very important for understanding)

A project is like a folder for your resources: all the VMs, databases, and APIs you create belong to a project, and billing is tracked per project.
You attach a billing account so usage is charged correctly; you can set budgets and alerts so you don't get surprised by the bill.
Organizing by project keeps teams and costs clear.

Real-world idea: one project = one place for resources and billing. Projects and billing settings keep usage and cost under control.

Technical definition

Project: top-level container for resources (all resources belong to a project). Has Project ID, name, and billing account. Used for isolation and quotas.
Organization: root for enterprises; contains folders and projects. Billing account links to a project so usage is charged. Set budget alerts to avoid surprises.
Enable APIs per project (e.g. Cloud Run API, Storage API). Quotas and limits are per project (or per region).

Simple practical example

Organization: root for enterprises; contains folders and projects.

Code example

gcloud projects list
gcloud config get-value project
# Enable API: gcloud services enable run.googleapis.com

Why it matters

Every resource lives in a project. "How do you organize GCP resources?" — projects and folders. Billing is tied to projects.

Interview tip

"Project = container for resources; has ID and billing. Enable APIs per project. Use folders and org for enterprise hierarchy."

IAM (Identity and Access Management)

Simple real-life example (Understand first — very important for understanding)

Like access control in a building: who can enter which room, who can only read, who can change settings.
IAM (Identity and Access Management) defines who (user, service account) can do what (roles) on which resource.
You grant the minimum permission needed so that if an account is compromised, the damage is limited.

Real-world idea: control who can do what. IAM roles and policies define access to your cloud resources.

Technical definition

Who (identity): Google account, service account, or group. What (role): collection of permissions (e.g. roles/storage.objectViewer). Which resource: project, bucket, etc.
Principle of least privilege: grant minimum roles needed. Prefer custom roles or predefined roles over primitive (owner/editor/viewer) for production.
Service accounts: identities for apps and VMs (no user login). Use for server-to-server auth. Never put keys in code — use Workload Identity or metadata when on GCP.

Simple practical example

Principle of least privilege: grant minimum roles needed.

Code example

# Grant a user Storage Object Viewer on a bucket
gcloud storage buckets add-iam-policy-binding gs://BUCKET \
  --member="user:alice@example.com" --role="roles/storage.objectViewer"

Why it matters

Security and access control are central. "How does IAM work?" — identity + role + resource. Service accounts for app auth.

Interview tip

"IAM: who (identity) + role (permissions) + resource. Use service accounts for apps; avoid key files — use Workload Identity when possible."

Compute Engine (VMs)

Simple real-life example (Understand first — very important for understanding)

Like renting a whole computer in the cloud: you choose the size (CPU, memory), the OS, and the disk; you get a VM you can SSH into and run anything on.
Compute Engine is for when you need full control: you manage the OS, updates, and the app; good for legacy apps or custom setups.
You pay for the VM while it runs; stopping it stops the charge for compute (disk may still be charged).

Real-world idea: a virtual machine in the cloud. Compute Engine gives you a full server you control.

Technical definition

Compute Engine: infrastructure-as-a-service (IaaS) — you create and manage VMs (instances). Choose machine type, disk, image (e.g. Ubuntu, Windows), and region/zone.
Use when you need full control (OS, networking, long-running processes). Managed instance groups (MIGs) for autoscaling and load balancing.
Preemptible/Spot VMs for cost savings (can be terminated by GCP). Use for batch or fault-tolerant workloads.

Simple practical example

Use when you need full control (OS, networking, long-running processes).

Code example

gcloud compute instances create my-vm \
  --zone=us-central1-a --machine-type=e2-medium \
  --image-family=debian-12 --image-project=debian-cloud

Why it matters

"When do you use Compute Engine vs Cloud Run?" — VMs when you need full control or legacy apps; Cloud Run for containers/serverless.

Interview tip

"Compute Engine = VMs, full control. Use MIGs for scaling. Preemptible for cost-sensitive, interruptible workloads."

Cloud Run

Simple real-life example (Understand first — very important for understanding)

Like a kitchen that only runs when there are orders: you give it your container (your app), and it scales to zero when idle and scales up when requests come.
Cloud Run runs containers; you don't manage servers—you just deploy and set limits (e.g. max instances, memory). It's good for APIs and web apps with variable traffic.
You pay per request and per CPU/memory time used; no cost when there's no traffic.

Real-world idea: run your app in a container without managing servers. Cloud Run scales with traffic and can scale to zero.

Technical definition

Cloud Run: fully managed platform for running containers (and source) that scale to zero. Pay per request and CPU/memory used. Supports HTTP requests and event-driven (Pub/Sub, events).
Deploy from container image (Dockerfile) or from source (buildpack). Specify CPU, memory, concurrency, min/max instances. Auto-scales; no servers to manage.
Use for: APIs, web apps, microservices, background jobs (Cloud Run Jobs). Good default for new apps when you can containerize.

Simple practical example

Deploy from container image (Dockerfile) or from source (buildpack).

Code example

gcloud run deploy my-service --source . --region us-central1 \
  --allow-unauthenticated
# Or: --image gcr.io/PROJECT/my-service

Why it matters

Cloud Run is often the recommended compute for modern apps. "What is Cloud Run?" — serverless containers, scale to zero, pay per use.

Interview tip

"Cloud Run: run containers (or source), scale to zero, pay per request. Use for APIs and microservices. Supports Jobs for batch."

Cloud Functions

Simple real-life example (Understand first — very important for understanding)

Like a single task that runs when something happens: a user clicks, a file is uploaded, or a message arrives; your code runs, does the task, and exits.
Cloud Functions are small, event-driven pieces of code; you don't run a server—you write a function and wire it to a trigger (HTTP, storage, Pub/Sub).
Good for webhooks, lightweight APIs, or glue between services; they scale automatically and you pay per invocation.

Real-world idea: run a small piece of code when an event happens. Cloud Functions are serverless and event-driven.

Technical definition

Cloud Functions: serverless functions (event-driven or HTTP). Write a single function in Node, Python, Go, etc.; GCP runs it when triggered. No container to build (unless using 2nd gen with custom runtime).
Triggers: HTTP, Pub/Sub, Storage events, Firestore events, Cloud Scheduler. Gen 2 runs on Cloud Run under the hood — more config (CPU, memory, VPC, min instances).
Use for: webhooks, small APIs, event processing (e.g. on file upload), scheduled tasks. For larger or more control, use Cloud Run.

Simple practical example

Triggers: HTTP, Pub/Sub, Storage events, Firestore events, Cloud Scheduler.

Code example

# Deploy HTTP function (Node)
gcloud functions deploy myFunc --runtime nodejs20 \
  --trigger-http --allow-unauthenticated --gen2

Why it matters

"Cloud Functions vs Cloud Run?" — Functions for small, event-driven units; Run for full apps or when you need more control/Docker.

Interview tip

"Cloud Functions: serverless, event or HTTP triggered. Gen 2 on Cloud Run. Use for webhooks, event handlers; Cloud Run for full services."

Cloud Storage

Simple real-life example (Understand first — very important for understanding)

Like a huge, durable filing cabinet in the cloud: you put files (images, backups, logs) in buckets; each file has a name and can be public or private.
Cloud Storage is for unstructured data (files); you get high durability and availability; you can set lifecycle rules (e.g. delete or archive old files).
Use for static assets, user uploads, backups, or any blob data.

Real-world idea: store files in the cloud. Cloud Storage gives you buckets and objects with access control and lifecycle options.

Technical definition

Cloud Storage: object storage (like S3). Store files (blobs) in buckets. Globally unique bucket name. Use for: static assets, backups, data lakes, uploads.
Storage classes: Standard (frequent access), Nearline, Coldline, Archive — lower cost for less access. Lifecycle rules to transition or delete automatically.
Access: gs://bucket/path. IAM at bucket or object level. Signed URLs for temporary public access. Versioning and retention available.

Simple practical example

Storage classes: Standard (frequent access), Nearline, Coldline, Archive — lower cost for less access.

Code example

gsutil cp file.txt gs://my-bucket/
gsutil ls gs://my-bucket/
# Or: gcloud storage cp file.txt gs://my-bucket/

Why it matters

Object storage is foundational. "When use Cloud Storage?" — unstructured data, static sites, backups. Know bucket vs object and lifecycle.

Interview tip

"Cloud Storage = object storage, buckets + objects. Storage classes for cost vs access. Lifecycle for auto transition/delete. IAM and signed URLs."

Cloud SQL

Simple real-life example (Understand first — very important for understanding)

Like a managed database: Google runs the database server, does backups and patches; you create a database instance, connect with a connection string, and use it like any MySQL or PostgreSQL.
Cloud SQL is for relational data when you want a familiar SQL database without managing the server yourself.
You choose size and region; you get high availability and automated backups.

Real-world idea: a database in the cloud that someone else runs. Cloud SQL is managed MySQL/PostgreSQL.

Technical definition

Cloud SQL: fully managed relational databases — MySQL, PostgreSQL, SQL Server. Automated backups, patches, high availability (HA) option.
Choose instance size, storage type, and region. Private IP (VPC) or public IP with authorized networks. Connect from Cloud Run/Functions via VPC or Cloud SQL Auth Proxy.
Use when you need a traditional RDBMS (transactions, SQL, existing app compatibility). For scale-out write workloads, consider Spanner.

Simple practical example

Choose instance size, storage type, and region.

Code example

# Create Postgres instance
gcloud sql instances create my-db --database-version=POSTGRES_15 \
  --tier=db-f1-micro --region=us-central1

Why it matters

"Which database for relational data?" — Cloud SQL for managed MySQL/Postgres. Know connection options (private IP, Auth Proxy).

Interview tip

"Cloud SQL: managed MySQL/Postgres/SQL Server. Use Auth Proxy or private IP from Run/Functions. For global scale, Spanner."

Firestore

Simple real-life example (Understand first — very important for understanding)

Like a flexible document store: you store data in collections and documents (like JSON); you can query and update in real time.
Firestore is a NoSQL database; good for app data, real-time sync (e.g. live updates), and when your structure evolves.
You pay for reads, writes, and storage; you design for efficient queries and avoid loading huge collections at once.

Real-world idea: store and sync document-shaped data in real time. Firestore is a managed NoSQL, real-time database.

Technical definition

Firestore: NoSQL document database. Collections and documents (JSON-like). Real-time listeners, offline support, automatic scaling. Native SDKs for mobile and web.
Modes: Native (recommended) and Datastore. Strong consistency, ACID transactions. Good for: app backends, real-time apps, mobile sync.
Query with indexes (composite indexes for complex queries). Security rules control read/write per path. Often used with Firebase (Auth, Hosting) for full-stack apps.

Simple practical example

Modes: Native (recommended) and Datastore.

Code example

// Node SDK
const doc = await db.collection('users').doc('id').get();
await db.collection('users').add({ name: 'Alice', role: 'admin' });

Why it matters

"Firestore vs Cloud SQL?" — Firestore for flexible schema, real-time, mobile; SQL for relational and complex queries.

Interview tip

"Firestore: NoSQL document DB, real-time, offline. Collections/documents; security rules. Use for app backends and real-time; SQL for relational."

BigQuery

Simple real-life example (Understand first — very important for understanding)

Like a warehouse for analytics: you have huge amounts of data (logs, events); you run SQL-like queries to analyze it without loading it all into your app.
BigQuery is for analytics and data warehousing; it scales to huge datasets and you pay per query (per byte processed).
Use it for reporting, dashboards, and ad-hoc analysis over large data.

Real-world idea: run analytics on huge data with SQL. BigQuery is for data warehousing and heavy queries.

Technical definition

BigQuery: serverless data warehouse for analytics. Run SQL on huge datasets (petabyte scale). Columnar storage; pay per query (bytes processed) and storage.
Use for: analytics, reporting, ML training on large data. Load data from Cloud Storage, streaming insert, or federated queries. Export to Sheets, Looker, etc.
Datasets contain tables. Use partitioning and clustering for cost and performance. Avoid SELECT * — only query columns you need to reduce cost.

Simple practical example

Use for: analytics, reporting, ML training on large data.

Code example

bq query --use_legacy_sql=false \
  'SELECT country, COUNT(*) FROM mydataset.events GROUP BY 1'

Why it matters

"What is BigQuery?" — data warehouse, SQL at scale, serverless. Different from transactional DBs (Cloud SQL, Firestore).

Interview tip

"BigQuery: analytics warehouse, SQL on huge data, pay per query. Partition/cluster tables; minimize bytes scanned for cost."

Pub/Sub

Simple real-life example (Understand first — very important for understanding)

Like a post office: one part of your system drops a message (event); other parts subscribe and get a copy without the sender knowing who they are.
Pub/Sub decouples producers and consumers: the sender doesn't wait for the receiver; you can add or remove subscribers without changing the publisher.
Use for async workflows, event-driven processing, or connecting different services.

Real-world idea: send messages that others can receive asynchronously. Pub/Sub decouples who produces and who consumes.

Technical definition

Cloud Pub/Sub: messaging service — publishers send messages to topics; subscribers receive via subscriptions. Decouples producers and consumers; at-least-once delivery.
Use for: event-driven architecture, streaming data, fan-out (one message to many subscribers). Push (HTTP to your endpoint) or pull (your code pulls).
Integrates with Cloud Functions (trigger on message), Dataflow, BigQuery (streaming insert). Ordering keys for ordered delivery per key.

Simple practical example

Use for: event-driven architecture, streaming data, fan-out (one message to many subscribers).

Code example

# Publish
gcloud pubsub topics publish my-topic --message '{"event":"order"}'
# Create subscription
gcloud pubsub subscriptions create sub1 --topic=my-topic

Why it matters

"How do you decouple services?" — Pub/Sub. Event-driven and async processing. Common in GCP architecture diagrams.

Interview tip

"Pub/Sub: topics + subscriptions, decouple publishers/subscribers. Push or pull; at-least-once. Use for events and streaming; integrates with Functions/Run."

VPC & networking

Simple real-life example (Understand first — very important for understanding)

Like a private network for your resources: VMs and services can talk to each other on a private network; you control which parts are exposed to the internet.
VPC (Virtual Private Cloud) lets you define subnets, firewalls, and routes so your cloud resources are isolated and secure.
You use it to segment environments (e.g. dev vs prod) and to control ingress and egress.

Real-world idea: your own private network in the cloud. VPC and networking control how resources see each other and the internet.

Technical definition

VPC (Virtual Private Cloud): virtual network for your project. Subnets per region; private IP ranges. Default VPC is auto-created; create custom VPCs for isolation and peering.
Firewall rules control ingress/egress (allow/deny by source, port, tag). No inbound by default; allow HTTP/HTTPS or specific ports for your services.
Private Google Access: VMs without public IP can reach GCP APIs. VPC peering or Private Service Connect to connect networks. Cloud Run/Functions can use VPC connector to reach private resources.

Simple practical example

Firewall rules control ingress/egress (allow/deny by source, port, tag).

Code example

# List networks
gcloud compute networks list
# Create firewall rule
gcloud compute firewall-rules create allow-http --allow tcp:80

Why it matters

"How do you make Cloud Run talk to Cloud SQL privately?" — VPC connector or Private IP + VPC. Firewall and VPC are common topics.

Interview tip

"VPC = virtual network, subnets per region. Firewall rules for traffic. VPC connector for Run/Functions to reach private resources (e.g. Cloud SQL)."

Cloud Build

Simple real-life example (Understand first — very important for understanding)

Like an automated factory: when you push code, the system builds it (e.g. run tests, build a container image) and can optionally deploy it.
Cloud Build runs steps (build, test, push to registry) in a pipeline; you define the steps in a config file.
Use for CI/CD: every push can trigger a build and deploy so your app is always in a known state.

Real-world idea: build and test code automatically on every change. Cloud Build is GCP's CI/CD building block.

Technical definition

Cloud Build: CI/CD and build service. Runs builds in containers; steps can run Docker, run scripts, deploy to Run/GKE/App Engine. Config via cloudbuild.yaml or trigger config.
Triggers: on push to Cloud Source Repositories, GitHub, Bitbucket; on schedule; or manual. Build can build container image, run tests, deploy.
Use for: build Docker images, run tests, deploy to Cloud Run. Alternative: GitHub Actions with GCP auth; Cloud Build is native and integrated.

Simple practical example

Triggers: on push to Cloud Source Repositories, GitHub, Bitbucket; on schedule; or manual.

Code example

# cloudbuild.yaml
steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/$PROJECT_ID/my-app', '.']
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    args: ['gcloud', 'run', 'deploy', 'my-app', '--image', 'gcr.io/$PROJECT_ID/my-app']

Why it matters

"How do you do CI/CD on GCP?" — Cloud Build (native) or external (GitHub Actions, GitLab CI) with workload identity or keys.

Interview tip

"Cloud Build: run build steps in containers, trigger on repo push. Use for build image, test, deploy to Run/GKE. cloudbuild.yaml or API."

Artifact Registry

Simple real-life example (Understand first — very important for understanding)

Like a warehouse for built artifacts: you store container images and other packages so other systems (e.g. Cloud Run) can pull and run them.
Artifact Registry holds your Docker images and other artifacts; you control who can push and pull.
You use it with Cloud Build (push after build) and with Cloud Run or GKE (pull to run).

Real-world idea: store and version your built images. Artifact Registry is where you keep container images and packages.

Technical definition

Artifact Registry: store and manage build artifacts — Docker images, npm, Maven, etc. Replaces Container Registry (gcr.io). One registry per project or shared.
Repositories: Docker, npm, etc. Use with Cloud Build to push images; Cloud Run and GKE pull from here. IAM controls who can push/pull.
Vulnerability scanning for images. Prefer Artifact Registry over public registries for private base images and faster pulls from GCP.

Simple practical example

Repositories: Docker, npm, etc.

Code example

# Create Docker repo
gcloud artifacts repositories create my-repo --repository-format=docker \
  --location=us-central1
# Push (after docker tag)
docker push us-central1-docker.pkg.dev/PROJECT/my-repo/my-image:tag

Why it matters

"Where do you store Docker images for Cloud Run?" — Artifact Registry (or Container Registry legacy). Part of standard CI/CD on GCP.

Interview tip

"Artifact Registry: store Docker (and other) artifacts. Use with Cloud Build and Run/GKE. Replaces gcr.io; IAM and scanning."

Secret Manager

Simple real-life example (Understand first — very important for understanding)

Like a safe for passwords and keys: you don't put secrets in code or config files; you store them in Secret Manager and your app fetches them at runtime.
Secrets are encrypted and access is controlled by IAM; you can version them and rotate without redeploying the app.
Use for API keys, DB passwords, and certificates so they never appear in source code or logs.

Real-world idea: keep secrets out of code. Secret Manager stores and serves them securely to your app.

Technical definition

Secret Manager: store API keys, passwords, certs securely. Versions supported; access via IAM. Applications fetch secrets at runtime (e.g. Cloud Run env var from secret).
Never put secrets in code or env files in repo. Use Secret Manager; grant service account access to the secret. Cloud Run: map secret to env var or volume.
Audit logging for secret access. Rotate secrets by adding new version and updating references; disable old versions.

Simple practical example

Never put secrets in code or env files in repo.

Code example

# Create secret
echo -n "my-api-key" | gcloud secrets create my-secret --data-file=-
# Grant Cloud Run service account access
# In Cloud Run: set env var from secret (Console or --set-secrets)

Why it matters

"How do you manage secrets on GCP?" — Secret Manager. Inject into Run/Functions as env or volume. IAM for access control.

Interview tip

"Secret Manager: store secrets, versioned. Access via IAM; inject into Run/Functions as env or volume. Never commit secrets."

Cloud Logging & Monitoring

Simple real-life example (Understand first — very important for understanding)

Like a control room: logs show what happened (errors, requests, debug messages); monitoring shows how healthy the system is (latency, errors, traffic).
You use Cloud Logging to search and alert on logs, and Cloud Monitoring (and metrics) to dashboards and alerting.
Good logging and monitoring let you find and fix issues before users notice.

Real-world idea: see what's happening and when something goes wrong. Logging and monitoring are essential for running apps in production.

Technical definition

Cloud Logging: centralized logs from GCP services (Run, Functions, VMs) and custom app logs. Query with filter language; export to BigQuery or Pub/Sub. Log levels and structured JSON.
Cloud Monitoring: metrics, dashboards, alerts. CPU, memory, request count, latency for Run/Functions/VMs. Uptime checks and alerting policies (e.g. email, PagerDuty when error rate > threshold).
Use for: debugging, SLA monitoring, incident response. Trace (Cloud Trace) for request tracing across services.

Simple practical example

Cloud Monitoring: metrics, dashboards, alerts.

Code example

# View logs
gcloud run services logs read my-service --region us-central1
# Or in Console: Logging → Logs Explorer, filter by resource and severity

Why it matters

Observability is expected in production. "How do you debug/monitor on GCP?" — Logging for logs, Monitoring for metrics and alerts.

Interview tip

"Logging: centralized logs, query and export. Monitoring: metrics, dashboards, alerts. Use for debugging and SLA; Trace for distributed tracing."

Deployment & CI/CD

Simple real-life example (Understand first — very important for understanding)

Like a pipeline from code to production: commit → build → test → deploy, so every change can be released in a consistent way.
CI/CD uses tools like Cloud Build and scripts to automate build, test, and deploy; you can have stages (e.g. deploy to staging first, then prod).
Automation reduces mistakes and makes releases fast and repeatable.

Real-world idea: automate build, test, and deploy. CI/CD keeps releases consistent and safe.

Technical definition

Typical flow: code in repo → Cloud Build trigger on push → build image → push to Artifact Registry → deploy to Cloud Run (or GKE). Use Cloud Deploy for managed pipelines (e.g. canary).
Environments: separate projects or branches for dev/staging/prod. Use substitution variables in Cloud Build for project/region. Service account for Build must have deploy permissions.
Rollback: redeploy previous image or use Cloud Run revisions (traffic split). Blue-green or canary with traffic percentage.

Simple practical example

Environments: separate projects or branches for dev/staging/prod.

Code example

# Manual deploy
gcloud run deploy my-service --image gcr.io/PROJECT/my-app:latest
# CI: Cloud Build trigger on main → build → deploy same command

Why it matters

"How do you deploy to GCP?" — Build → Artifact Registry → Run. Know triggers, env separation, and rollback strategy.

Interview tip

"CI/CD: Cloud Build on push → build image → push to Artifact Registry → deploy Run. Use secrets and env vars; separate projects/branches for envs."

Cost optimization & best practices

Simple real-life example (Understand first — very important for understanding)

Like managing your bills: you choose the right size for VMs, turn off what you don't need, use committed use or spot when it makes sense, and set budgets.
Cost optimization is about using the right service and size, cleaning up unused resources, and monitoring spend so you don't overpay.
Small habits (right-sizing, auto-shutdown, lifecycle rules) add up to big savings.

Real-world idea: pay for what you need. Cost optimization keeps cloud spend under control with the right choices and cleanup.

Technical definition

Compute: use managed services (Run, Functions) that scale to zero; right-size VMs; preemptible for batch. Storage: lifecycle rules to move to colder classes or delete.
BigQuery: query only columns needed; use partitioning/clustering; avoid repeated full scans. Networking: reduce egress (keep data in region), use CDN (Cloud CDN) for static.
Set budget alerts and quotas. Use labels for cost allocation. Review recommendations in Billing console. Prefer committed use (e.g. CUDs) for predictable, long-running workloads.

Simple practical example

BigQuery: query only columns needed; use partitioning/clustering; avoid repeated full scans.

Code example

# Set budget alert (Console: Billing → Budgets)
# Storage lifecycle: transition to Coldline after 90 days
# BigQuery: SELECT col1, col2 FROM t WHERE date = '...'  (partitioned)

Why it matters

"How do you control GCP costs?" — scale to zero, lifecycle, right-sizing, budgets, labels. Interviewers care about cost awareness.

Interview tip

"Scale to zero where possible; lifecycle for storage; minimize BQ bytes scanned; budgets and labels; use recommendations."

Practise the questions

Read the top 50 Google Cloud (GCP) interview questions and answers to test yourself after revising.