GCP Interview Questions: Compute, Storage, and Networking Fundamentals

Cloud interviews start with fundamentals: can you pick the right compute option, the right storage, and explain how traffic flows? These are the GCP questions that come up in every cloud interview — each with the crisp answer and the follow-up trap underneath.

Compute

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

Decision rule: do you need VM control, Kubernetes control, or just an application runtime? Answer:

• Compute Engine (GCE) — raw VMs. You manage the OS, patching, scaling. Use when you need full control (custom kernels, licensed software, lift-and-shift).
• GKE — managed Kubernetes. Use for containerized microservices at scale, when you want orchestration (autoscaling, rolling updates, service discovery) without managing the control plane.
• Cloud Run — serverless containers. Push a container, get an HTTPS endpoint with scale-to-zero. Use for APIs, webhooks, and event-driven services where you don't want to think about nodes.
• App Engine — older managed application platform (Standard = sandboxed runtimes, Flexible = containers on VMs). Know it because existing systems use it — but for new applications, Google recommends evaluating Cloud Run first.
• Cloud Run functions (formerly Cloud Functions) — deploy function source for small HTTP or event-driven workloads; Google builds it into a container and deploys it as a Cloud Run service. Use for single-purpose event handlers (a Pub/Sub trigger, a Storage trigger).

Interview one-liner: "VMs for control, GKE for orchestration, Cloud Run for containers without nodes, Functions for events." Follow-up: "When would you pick GKE over Cloud Run?" — when you need Kubernetes APIs and primitives (custom operators/CRDs, DaemonSets, StatefulSets with stable storage), complex scheduling or networking requirements, or direct cluster control. The trap: don't choose Kubernetes merely because you're using containers — if it's a stateless container and you don't need Kubernetes primitives, start by evaluating Cloud Run before accepting GKE's operational cost.

2. What are Spot VMs (formerly preemptible), and when are they a trap?

Answer: Spot VMs are spare capacity at up to ~91% discount, but GCP can reclaim them with 30 seconds' notice. Perfect for fault-tolerant batch work (rendering, genomics, CI runners). Avoid Spot VMs for workloads that cannot tolerate interruption — no single-replica production services, no un-checkpointed long jobs. The interview follow-up is always: "How do you design for preemption?" — checkpointing, idempotent work units, and a managed instance group that replaces preempted nodes.

3. How does autoscaling work on GCP?

Answer: on GCE, a managed instance group (MIG) with an autoscaler adds/removes instances based on CPU utilization, load-balancer serving capacity, or a Cloud Monitoring metric (e.g., Pub/Sub queue depth). Key detail interviewers probe: the cooldown period — new instances need time to warm up before the autoscaler trusts their metrics, otherwise it thrash-scales. On GKE, the Horizontal Pod Autoscaler scales pods and cluster autoscaler scales nodes. On Cloud Run, autoscaling is built in — it scales on concurrent requests per instance, down to zero.

Storage

4. Cloud Storage classes — which one, when?

Answer: the four traditional general-purpose classes — one decision: how often do you read the data? (Google also offers Rapid storage for Rapid Bucket workloads, but these four are the interview core.)

• Standard — hot data, frequent access.
• Nearline — read less than monthly (backups, DR). 30-day minimum storage duration.
• Coldline — read less than quarterly. 90-day minimum.
• Archive — read less than yearly (compliance, cold backups). 365-day minimum, cheapest.

The trap: early-deletion fees. Delete a Nearline object on day 10 and you still pay for 30 days. The follow-up: "How do you move data between classes automatically?" — Object Lifecycle Management rules (age, created-before, or custom conditions). Also know: Autoclass manages class transitions automatically per bucket.

5. "Which GCP database do I use?" — the question behind half of data interviews

Answer: learn this table cold:

• Cloud SQL — managed MySQL/PostgreSQL/SQL Server. Relational, vertical scaling, regional HA. Use for traditional OLTP apps.
• AlloyDB — PostgreSQL-compatible, built for demanding OLTP with much higher throughput than Cloud SQL.
• Spanner — globally distributed relational with external consistency (TrueTime). Use when you need relational + horizontal scale + global reads/writes. The interview follow-up is always "when is Spanner overkill?" — when a regional, highly-available relational database such as Cloud SQL meets your scale, consistency, availability, and geographic requirements. Let architecture requirements lead the decision, not the price tag.
• Bigtable — wide-column NoSQL for massive scale, low-latency key lookups (think billions of rows, single-digit ms). Use for time-series, IoT, ad tech. Not for analytics — that's BigQuery.
• Firestore — document NoSQL with real-time sync. Use for mobile/web apps needing live updates.
• BigQuery — serverless data warehouse for analytics (OLAP). Use for SQL over terabytes, not for row-level OLTP.

Decision rule: access pattern + consistency + scale + geography. Interview one-liner: "Demanding PostgreSQL OLTP → AlloyDB; standard OLTP relational → Cloud SQL; global horizontally-scalable relational → Spanner; massive low-latency key-value → Bigtable; documents + realtime sync → Firestore; analytics → BigQuery."

6. Persistent Disk vs Cloud Storage vs Filestore?

Decision rule: block vs object vs shared filesystem. Answer: Persistent Disk is block storage attached to a VM (like a hard drive) — zonal or regional, and it can persist independently of the VM depending on the deletion configuration. Cloud Storage is object storage — buckets and objects over HTTP, effectively infinite scale, no filesystem semantics. Filestore is managed NFS file storage — use when legacy apps need a shared POSIX filesystem. The classic trap: "Can two VMs write to the same Persistent Disk?" — don't assume a normal Persistent Disk is shared storage. If multiple machines need shared filesystem semantics, that's a signal to evaluate Filestore or a specifically supported shared-disk architecture.

Networking

7. What's a VPC, and how do subnets and firewall rules fit in?

Answer: a VPC is your private software-defined network — global in GCP (unlike AWS where VPCs are regional), spanning all regions. Subnets are regional IP ranges inside the VPC. VPC firewall rules govern traffic to and from resources in the VPC and can target resources using mechanisms such as network tags or service accounts — remember they're deny-by-default on ingress, allow on egress, and they're stateful. The interview follow-up: "How do two VPCs talk?" — VPC peering (non-transitive) or Shared VPC (central host project sharing subnets with service projects — the enterprise pattern).

8. GCP load balancers — which type for what?

Decision rule: Layer 7 vs Layer 4, then external vs internal, then global vs regional. Answer: HTTP/HTTPS traffic goes to an Application Load Balancer (Layer 7 — URL maps, Cloud CDN, and Cloud Armor attach here). TCP/UDP traffic goes to a Network Load Balancer (Layer 4). Then scope it: external for public clients, internal (private IPs) for east-west traffic inside the VPC; global/cross-region for worldwide users, regional when backends live in one region.

Key GCP fact: these are software-defined, not appliance-based — no pre-warming, they scale automatically. Follow-up: "Where do you terminate TLS?" — TLS can terminate at the Application Load Balancer using Google-managed certificates; backend connections are configured separately and can also use encryption where required.

9. How do private VMs and GKE workloads communicate without public IPs?

Answer: categorize by direction — interviewers want the framework, not a list:

• Admin access: IAP TCP forwarding — SSH/RDP to VMs without public IPs or bastion hosts.
• Internet egress: Cloud NAT — private resources reach the internet outbound (note: NAT is egress, not inbound).
• Google API access: Private Google Access — reach Google APIs from private IPs.
• On-prem connectivity: Cloud VPN / Interconnect.
• Private service connectivity: Private Service Connect — consume services privately across VPCs and orgs.

The one-liner: "IAP for admin, NAT for egress, Private Google Access for Google APIs."

10. Regions, zones, and what "multi-regional" actually buys you

Answer: a region is a geographic area (e.g., us-central1); zones are isolated failure domains within it (us-central1-a/b/c). Deploying across zones survives a zone outage; across regions survives a regional outage — at the cost of cross-region latency and egress charges. The trap: "Is multi-region always better?" — no. A common default for high availability is multi-zone within one region (cheap, low latency); multi-region is justified when availability, geographic, latency, disaster-recovery, or regulatory requirements demand it — and it forces you to solve data replication (Spanner, multi-region Spanner, or async replication).

In this series

1. Top 20 GCP Interview Questions and Answers (2026 Edition) — start here.
2. GCP Interview Questions: Compute, Storage, and Networking Fundamentals (this post).
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.