Top 30 GCP Interview Questions and Answers (2026 Edition)

Preparing for a GCP interview? These are the 30 questions that come up most often — each with a crisp, interview-ready answer. Every answer links to a full deep-dive guide in this series when you want the follow-up traps and trade-offs.

How to use this: read the question, say your answer out loud, then check. Interviewers score decision rules and failure modes, not definitions — for every answer, reach: requirement → GCP service → guarantee → failure mode → cost.

Compute, Storage & Networking

1. GCE vs GKE vs Cloud Run — when do you use each?

Answer: GCE when you need VM-level control (custom kernels, licensed software, lift-and-shift). GKE when you need Kubernetes orchestration at scale (autoscaling, rolling updates, custom operators). Cloud Run for serverless containers with scale-to-zero — the default to evaluate first for stateless services. Cloud Run functions (formerly Cloud Functions) for single-purpose event handlers. Deep dive →

2. What are Spot VMs, and how do you design to survive preemption?

Answer: spare GCP capacity at a steep discount, reclaimable on short notice. The decision rule: assume every Spot VM will be reclaimed — design for interruption tolerance, not for exploiting the notice window. Checkpoint progress frequently so interrupted work resumes instead of restarting, split work into idempotent units, and run in a managed instance group that automatically replaces preempted VMs. Perfect for fault-tolerant batch work (rendering, CI, genomics). The trap: treating Spot like cheap on-demand — anything that can't tolerate interruption doesn't belong on Spot. Deep dive →

3. Region vs zone vs multi-region — how do you design for high availability?

Answer: a zone is a single failure domain; spread across zones in a region for HA against zonal failure (regional managed instance groups, regional GKE clusters, regional Persistent Disk). Multi-region adds DR against regional failure — but also cost, replication complexity, latency, and consistency considerations. Decision rule: match the topology to the requirement — don't pay for multi-region when multi-zone meets the SLO. The follow-up trap: name your RTO (how quickly must the service recover?) and RPO (how much data loss is acceptable?) — those two numbers drive your backup, replication, and failover choices. Deep dive →

4. How do you pick a Cloud Storage class?

Answer: one decision — how often do you read the data? Standard (hot), Nearline (monthly, 30-day minimum), Coldline (quarterly, 90-day minimum), Archive (yearly, 365-day minimum). These are the traditional general-purpose classes; GCP also offers Rapid storage with Rapid Bucket for specialized high-performance, I/O-intensive workloads such as AI/ML and analytics. The trap is early-deletion fees: delete a Nearline object on day 10 and you still pay for 30 days. Use Object Lifecycle Management or Autoclass for automatic transitions. Deep dive →

5. Persistent Disk vs Cloud Storage vs Filestore?

Answer: decision rule: block vs object vs shared filesystem. Persistent Disk is block storage attached to a VM (zonal or regional); Cloud Storage is object storage — buckets and objects over HTTP at effectively infinite scale; Filestore is managed NFS for apps that need a shared POSIX filesystem. The trap: don't assume a normal Persistent Disk is shared storage — if multiple machines need shared filesystem semantics, evaluate Filestore. Deep dive →

6. Which GCP database for which workload?

Answer: the decision rule is access pattern + consistency + scale + geography. Cloud SQL → managed MySQL/PostgreSQL/SQL Server for conventional relational workloads; AlloyDB → PostgreSQL-compatible workloads where higher performance, scalability, or availability requirements justify it; global horizontally-scalable relational → Spanner; massive low-latency key-value → Bigtable; documents with realtime sync → Firestore; analytics over terabytes → BigQuery. Deep dive →

7. How do you choose a load balancer on GCP?

Answer: first Layer 7 vs Layer 4: HTTP/HTTPS → Application Load Balancer (URL maps, Cloud CDN, Cloud Armor attach here); TCP/UDP → Network Load Balancer. Then scope: external vs internal, global/cross-region vs regional. They're software-defined — they scale automatically, no pre-warming. Deep dive →

8. How do two VPCs communicate — peering vs Shared VPC?

Answer: decision rule: who owns the networks. VPC peering connects two VPCs privately, but it is non-transitive — A peered to B and B peered to C does not connect A to C. Shared VPC lets a central host project share subnets with service projects — the enterprise pattern for centralized networking with decentralized teams. The trap is assuming peering transitivity. Deep dive →

Data Engineering

9. How do you keep a BigQuery bill from exploding?

Answer: layers: dry runs and maximum bytes billed before execution; quotas and capacity reservations for governance; budgets and alerts for visibility (alerts don't stop a running query); partition by date and cluster by filter columns; avoid SELECT * on wide tables. Deep dive →

10. Batch vs streaming — how do you decide?

Answer: latency requirement vs cost and complexity. Streaming (Pub/Sub → Dataflow → BigQuery) gives seconds-fresh data but costs more and forces you to handle late/out-of-order data. The senior move: ask how real-time — sub-second, one minute, or fifteen? Most "real-time" needs turn out to be micro-batch. Deep dive →

11. Streaming inserts vs batch loads in BigQuery?

Answer: decision rule: bulk history vs continuous ingestion. Batch load jobs from GCS are free and preferred for bulk data. For streaming, use the Storage Write API for high-throughput ingestion. The default stream is at-least-once — so stable event IDs and idempotent downstream logic still matter. If you need exactly-once write semantics, application-created committed streams can use offsets. The trap: don't confuse exactly-once writes into BigQuery with end-to-end exactly-once business processing. Deep dive →

12. How do you handle duplicates and poison messages in Pub/Sub?

Answer: Pub/Sub is at-least-once by default, so consumers must be idempotent — dedupe on a stable event ID. Configure a dead-letter topic so poison messages are quarantined after N attempts instead of redelivered forever, and monitor oldest unacked message age to catch stuck subscriptions. The trap: Pub/Sub also supports exactly-once delivery in supported scenarios — don't translate that into "my whole business workflow is exactly once." Deep dive →

13. Pub/Sub vs Kafka — when does the interviewer want which answer?

Answer: decision rule: managed operations vs log semantics. Pub/Sub when you want deeply managed, GCP-native messaging with no brokers to operate; Kafka when its durable-log model, consumer-offset semantics, or ecosystem (Kafka Streams, Connect) is central to the architecture. The trap: don't make replay the differentiator — both can replay; the difference is operational model and ecosystem. Deep dive →

14. What are slots in BigQuery, and when do you buy reservations?

Answer: a slot is a unit of BigQuery compute. On-demand (pay per TB scanned) suits spiky workloads; capacity reservations (BigQuery editions) suit steady, predictable workloads needing controlled capacity and cost. One-liner: "on-demand for spiky, reservations for steady." Deep dive →

15. Explain windows, watermarks, and triggers in streaming.

Answer: Window — which events belong together (fixed, sliding, session). Watermark — how far through event time the system believes it has progressed. Trigger — when results are emitted. Allowed lateness — how long late data is still accepted. Streaming is about deciding what to do with late data. Deep dive →

Kubernetes & GKE

16. Walk me through what happens when you run kubectl apply.

Answer: kubectl → API server (auth/authz) → persisted to etcd → controller manager reconciles desired state (for a Deployment, it creates/updates the ReplicaSet) → scheduler assigns pods to nodes → kubelet pulls images and starts containers. The scoring sentence: "desired state vs actual state — controllers continuously reconcile the difference." Deep dive →

17. Requests vs limits — what happens when you get them wrong?

Answer: requests drive scheduling decisions; limits cap runtime usage. Memory limit exceeded → OOMKilled; CPU limit exceeded → throttling (slow, not killed); oversized requests → nodes look full while half-idle; poorly chosen or absent limits can contribute to resource contention and noisy-neighbor problems. Right-size with VPA recommendations. The follow-up trap: OOMKilled vs evicted — OOMKilled means your container exceeded its memory limit; evicted means the kubelet removed the pod under node pressure (memory, ephemeral storage, PID pressure). PodDisruptionBudgets protect against voluntary disruptions only — not node-pressure eviction. Deep dive →

18. HPA vs VPA vs cluster autoscaler — which scales what?

Answer: HPA scales pod count; VPA scales pod size (requests/limits); cluster autoscaler scales node count. One-liner: "HPA scales pods out, VPA scales pods up, cluster autoscaler scales nodes." Be careful combining HPA and VPA on the same signals — their feedback loops interact. Deep dive →

19. GKE Standard vs Autopilot — how do you choose?

Answer: Autopilot when you want Google to manage node infrastructure, scaling, and security configuration; Standard when you need deeper control over nodes and cluster infrastructure. Don't memorize "Autopilot cannot X" — discuss workload-specific restrictions, since the platform keeps getting more flexible. Deep dive →

20. A pod is stuck in CrashLoopBackOff — your debug sequence?

Answer: an ordered runbook: kubectl describe pod (events tell the story), kubectl logs --previous (the crashed container's last words), then check the usual suspects — bad image, missing config, failing probes, memory limit too low. Know the trio: Pending → couldn't schedule; CrashLoopBackOff → started then failed; ImagePullBackOff → couldn't pull the image. Deep dive →

21. How do you monitor and troubleshoot a production service on GCP?

Answer: think in signals, not product names: metrics (is something wrong?), logs (what happened?), traces (where did the request go wrong?) — tied to SLIs/SLOs, with alerts on burn rate rather than every CPU spike. The interview signal: you can describe the observability you'd build before naming the GCP products that implement it. Then troubleshoot in order: symptoms → scope (one pod? one zone? all traffic?) → recent changes → the signals. Deep dive →

22. A pod is stuck in Pending — walk me through why.

Answer: Pending means it couldn't get scheduled or started — reason through the scheduler's checklist: requests don't fit on any node, node selector/affinity/taints without tolerations, a PVC waiting to bind, namespace ResourceQuota exhausted, or all nodes cordoned with the autoscaler lagging. Check kubectl describe pod events first — the scheduler tells you why. Deep dive →

23. What is a private GKE cluster, and how do you operate one?

Answer: a private cluster has nodes with internal IPs rather than external IPs — frame it as two independent questions. Can the nodes reach what they need? Private Google Access for Google APIs and services from private nodes; Cloud NAT for internet egress — those are different things, don't conflate them. Can admins reach the Kubernetes API endpoint? Choose an appropriate control-plane access path — GKE's DNS-based endpoint with IAM is the modern option, or appropriately restricted IP-based endpoints/private connectivity where required. The trap: making nodes private doesn't automatically cut off kubectl — node privacy and control-plane access are separate dimensions. The follow-up: IAM says who can access data — what does VPC Service Controls add? Service perimeters around supported Google Cloud services to reduce data-exfiltration risk; IAM is authorization, perimeters are network-level containment. Deep dive →

IAM, Security & SRE

24. How does GCP IAM work, and what is least privilege in practice?

Answer: who (principals) + what (roles) + where (resource); allow bindings inherit downward, but deny policies can override grants. Least privilege in practice: predefined roles instead of Editor, the narrowest scope matching the operational model, IAM Recommender for over-privileged accounts, org policies blocking risky configurations. The follow-up: how do applications store and access secrets? Secret Manager + Workload Identity + least privilege + rotation/versioning — and KMS when you need control over cryptographic keys and encryption policy. Deep dive →

25. How do workloads authenticate to GCP without service-account keys?

Answer: Workload Identity Federation for GKE gives pods short-lived federated identities — IAM roles can be granted directly to Kubernetes identities, or through service-account impersonation; both patterns are valid. Same federation pattern for external workloads (GitHub Actions, AWS, on-prem). One-liner: "No static keys to rotate, no static keys to leak." Deep dive →

26. How do you give a developer temporary elevated access?

Answer: in order: Privileged Access Manager (PAM) for governed just-in-time elevation with approvals, justifications, and audit — the cleanest answer for humans; IAM Conditions for time-bound bindings ("this role expires Friday"); service-account impersonation where operationally appropriate. What you never do: permanently grant Owner "because it's urgent." Deep dive →

27. Define SLI, SLO, SLA — and what is an error budget?

Answer: SLI = the measurement (e.g., proportion of requests succeeding under 300 ms); SLO = the target on the SLI (99.9% over 30 days); SLA = the contractual commitment with consequences. The error budget is the gap between 100% and the SLO — teams use it to balance release velocity against reliability work. Deep dive →

28. Your error budget is burning — walk me through the incident.

Answer: detect (burn-rate alert), triage (declare incident, assign roles), mitigate first (roll back, fail over, shed load — restore the SLI before root-causing), resolve, then a blameless postmortem with action items and owners. The scoring sentence: "Triage enough to choose a safe mitigation, then restore service before deep root-cause analysis." Deep dive →

29. How do you ship safely on GCP?

Answer: rolling (gradual, default), blue/green (two environments, instant rollback), canary (small traffic %, judge against production signals, then ramp). On GCP, Cloud Deploy orchestrates this with canary phases; automated progressive delivery uses monitoring/SLO checks as promotion gates. And feature flags are another useful release-control mechanism, orthogonal to deployment strategy — they decouple deployment from release. Deep dive →

30. How do you keep the GCP bill under control?

Answer: layers: committed use discounts for steady compute (the exact discount varies by resource, so don't memorize one number); Spot VMs for fault-tolerant batch; right-sizing and killing idle IPs, disks, and load balancers; BigQuery partitioning/clustering plus reservations; budgets and alerts for visibility. The trap: budget alerts don't cap spending — they notify; shutdown automation needs careful safeguards. Deep dive →

In this series

1. Top 30 GCP Interview Questions and Answers (2026 Edition) (this post) — start here.
2. GCP Interview Questions: Compute, Storage, and Networking Fundamentals — pick the right compute, storage, and network.
3. GCP Data Engineering Interview Questions: BigQuery, Dataflow, Pub/Sub — analytics at scale.
4. Kubernetes and GKE Interview Questions — from kubectl to 3 AM debugging.
5. GCP IAM, Security, and SRE Interview Questions — identity, safety, and staying alive.

Related: System Design Interviews: A Practical Primer — the 4-step framework these cloud questions plug into.