GCP for an AWS-shaped brain

Same purpose as the Azure note: enough to answer “we’re on GCP” credibly, plus the places the model actually differs.

Service mapping

Where the model genuinely differs

Projects are the unit of isolation, and they’re cheap. An AWS shop uses one account per environment reluctantly; a GCP shop spins up projects freely. Billing, quota, and IAM all attach at the project level, under an org → folder → project hierarchy.

Cloud Run is the flagship, and it’s the thing worth knowing. It runs any container that listens on $PORT, scales to zero, scales out on concurrency, and bills per request-second. It sits exactly where Fargate and Lambda both partially fit and is usually the right default for a containerized Python API on GCP.

# Nothing GCP-specific in the app - just respect $PORT.
import os
import uvicorn
from fastapi import FastAPI

app = FastAPI()

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))

Unlike Lambda, there’s no bespoke handler signature and no 15-minute ceiling, and concurrency is per-container (many requests share one instance) rather than one-request-per-environment. That last difference is the one interviewers probe: it means your process must actually be concurrency-safe, which Lambda lets you ignore.

BigQuery has no clusters to size. It’s serverless columnar SQL billed on bytes scanned (or slots). The performance discipline is therefore not indexing — it’s partitioning, clustering, and not writing SELECT *. Coming from Redshift, this is the biggest mental shift.

Spanner has no AWS equivalent: horizontally scalable, strongly consistent, relational, with external consistency backed by TrueTime. When someone asks “how would you do globally consistent transactions”, Spanner is the managed answer.

Application Default Credentials is the auth pattern, mirroring Azure’s DefaultAzureCredential:

from google.cloud import storage

# Picks up GOOGLE_APPLICATION_CREDENTIALS, gcloud auth, or the attached
# service account on Cloud Run / GCE - no key file in production.
client = storage.Client()

Workload Identity Federation lets external systems (GitHub Actions, EKS, on-prem) assume a GCP service account without a downloaded key — the modern answer to “how do you avoid long-lived service-account JSON keys”.

The AI angle

Vertex AI is the managed platform: Model Garden for hosted models (Gemini, Claude, Llama, Mistral and Google’s own), plus training, tuning, pipelines, a feature store and an eval service. For an AI-focused role, the distinguishing point versus Bedrock and Foundry is the data-gravity story — Vertex sits next to BigQuery, so retrieval and feature pipelines over warehouse-scale data stay inside one platform. Vector search is available both as a standalone Vertex service and directly in BigQuery and AlloyDB.

Interview angle

• “We’re on GCP — how quickly could you be productive?” — the mapping above, then the three real differences: projects as cheap isolation units, Cloud Run’s concurrency model, and BigQuery’s bytes-scanned cost model.
• “Cloud Run vs Lambda?” — Cloud Run takes any container, no handler signature, no 15-minute limit, and multiplexes many concurrent requests into one instance. That last point means shared in-process state is a real hazard, unlike Lambda’s one-request-per-environment model. Lambda wins on tight event-source integration; Cloud Run wins on portability.
• “How do you keep BigQuery costs sane?” — partition on ingestion date, cluster on high-cardinality filter columns, never SELECT *, use approximate aggregations where exactness isn’t needed, and set custom quotas. Cost is driven by bytes scanned, not rows returned.
• “How does a workload outside GCP authenticate without a key file?” — Workload Identity Federation: exchange an external OIDC token for short-lived GCP credentials. Downloaded service-account JSON keys are the thing you’re being asked to avoid.
• “When would you reach for Spanner?” — global strong consistency with relational semantics and horizontal scale. If the requirement is “multi-region ACID”, it’s the answer; if a single-region Postgres would do, it’s overkill and expensive.