Google Cloud Platform: The Complete Engineer’s Guide to GCP Services, Architecture, and Interviews

A deep-dive written for developers, engineers, and interview candidates — by someone who has built, broken, and rebuilt distributed systems at scale.

Table of Contents

1. Why This Guide Exists
2. Cloud Fundamentals Every Engineer Must Know
3. GCP Core Services — Deep Coverage

• Compute Engine
• App Engine
• Google Kubernetes Engine (GKE)
• Cloud Run
• Cloud Functions
• Cloud Storage
• Persistent Disk
• Filestore
• Cloud SQL
• Cloud Spanner
• Bigtable
• Firestore
• BigQuery
• AlloyDB
• Memorystore
• VPC & Networking
• Load Balancers
• Cloud CDN & Cloud DNS
• IAM & Security
• Pub/Sub
• Dataflow
• Vertex AI & AI Building Blocks
• Cloud Build & Artifact Registry
• Cloud Monitoring & Logging

4. Architecture Thinking — How to Choose the Right Service

5. Visual Reference Tables & Decision Trees

6. Interview Preparation — Questions, Scenarios, and Answers

7. Revision Cheatsheet

Part 1: Why This Guide Exists {#why-this-guide}

Here’s a question most engineers avoid: why did your last architecture decision go wrong?

Not the technical failure. The conceptual one. The moment you chose the wrong database. Picked the wrong compute model. Over-provisioned for a workload that never came. Or under-provisioned and woke up at 3am.

The answer is almost always the same: we learn cloud services as a list of products, not as a vocabulary for solving problems.

Google Cloud Platform has over 200 services. If you try to memorize all of them, you’ll fail. But if you understand the architectural intent behind each category — why Google built it, what problem it solves, what it cannot do — you can walk into any system design conversation, any interview, any architecture review, and hold your ground.

What this guide does differently:

• Explains why each service exists before explaining what it does
• Gives you analogies that stick
• Tells you when NOT to use something (more valuable than any feature list)
• Compares GCP to AWS and Azure so you can translate knowledge you already have
• Includes interview-ready explanations you can say out loud in 60 seconds
• Ends with a cheatsheet you can review the morning of any interview

Who this is for:

• Developers new to GCP who want more than tutorials
• Engineers preparing for Google Cloud certifications
• System design interview candidates
• Backend and platform engineers evaluating cloud migrations

Let’s begin.

Part 2: Cloud Fundamentals Every Engineer Must Know {#cloud-fundamentals}

Before we talk about GCP services, we need alignment on vocabulary. These concepts appear in every cloud interview and every architecture discussion.

The Three Service Models

IaaS — Infrastructure as a Service

You get raw compute, storage, and networking. You manage everything above the hardware: OS, runtime, middleware, application, data.

Example: Renting a server. You configure it, install software, patch it, and keep it running.

GCP IaaS: Compute Engine

When to choose IaaS: You need full control. You’re lifting and shifting an existing workload. You have specialized OS requirements. Your team has ops capacity.

PaaS — Platform as a Service

The provider manages OS, runtime, and infrastructure. You manage your code and data.

Example: Deploying to Heroku or App Engine. You push code; it runs.

GCP PaaS: App Engine, Cloud SQL

When to choose PaaS: You want to focus on application logic. You don’t want to manage servers. You’re building a standard web application.

SaaS — Software as a Service

You consume a fully managed application. No infrastructure, no code.

Example: Gmail, Salesforce, Workspace.

GCP SaaS: BigQuery (for certain use cases), Vertex AI pre-built models

Regions, Zones, and Multi-Region

This is where most engineers get sloppy. Let’s fix that.

Zone: A single data center (or a cluster of data centers in close proximity) within a region. A zone is an isolated failure domain. If Zone A loses power, Zone B is unaffected.

Region: A geographic area containing multiple zones (typically 3+). Zones within a region are connected by low-latency, high-bandwidth networking.

Multi-Region: A group of regions treated as a single geographic unit for data storage redundancy (e.g., “US” covers multiple US regions).

The key insight that most engineers miss: Zones give you high availability within a region. Multi-region gives you disaster recovery and geographic redundancy. These are different requirements.

RequirementDeploy toSurvive a data center failureMultiple zones in one regionSurvive a regional outageMultiple regionsLow latency globallyMulti-region with CDNCompliance (data residency)Specific region only

Interview answer for “how does GCP handle HA?”: “GCP achieves high availability through zone distribution within a region. For most workloads, deploying across 3 zones within a region provides sufficient HA. Regional managed instance groups, regional Cloud SQL, and multi-zonal GKE clusters all leverage this model. For disaster recovery — surviving a regional outage — you architect across regions, which adds cost and complexity.”

Scalability vs. Elasticity

These are NOT the same thing, and confusing them is a junior engineer tell.

Scalability: The system can handle increased load by adding resources. This includes both scale-up (bigger machines) and scale-out (more machines).

Elasticity: The system automatically adds and removes resources in response to actual load, in near real-time. Elasticity implies scalability, but not the other way around.

Example: A fixed cluster of 10 VMs that can handle 10x the load of 1 VM is scalable. A managed instance group that automatically adds VMs under load and removes them when load drops is elastic.

Why this matters for architecture: Elastic systems cost less in variable workloads. Fixed-scale systems are simpler to reason about. Choose based on your load pattern, not hype.

Virtualization, Containers, and Serverless

Three layers of abstraction, each trading control for convenience.

Virtualization (VMs)

• Hardware is shared via a hypervisor
• Each VM has its own OS
• Isolation is strong — one VM can’t affect another
• Boot time: seconds to minutes
• GCP service: Compute Engine

Containers

• Share the host OS kernel
• Each container has its own filesystem, processes, network namespace
• Much lighter than VMs — milliseconds to start
• Isolation is weaker than VMs (kernel is shared)
• GCP services: GKE, Cloud Run, App Engine Flexible

Serverless

• No server management — not even container management
• Code runs in response to events or requests
• Scale to zero (you pay nothing when idle)
• Cold starts can add latency
• GCP services: Cloud Functions, Cloud Run (when auto-scaled to zero)

The spectrum:

Full Control                                    Zero Ops
  |                                               |
  VM → Container → Managed Container → Serverless
  |                                               |
High ops     Medium ops      Low ops          No ops

Interview trick question: “Is Cloud Run serverless or containerized?” Answer: Both. Cloud Run runs your container, but you don’t manage servers. It scales to zero. It’s serverless in the operational model, containerized in the execution model.

Load Balancing

Load balancers distribute traffic across multiple backend instances. But there are meaningfully different types:

Global vs. Regional: Global load balancers route traffic across regions. Regional load balancers route within a region. Global LBs can use Google’s backbone to route users to the closest healthy backend worldwide.

L4 vs. L7: Layer 4 (TCP/UDP) load balancers route based on IP and port. Layer 7 (HTTP/HTTPS) load balancers route based on URL path, headers, cookies — enabling path-based routing and content-based decisions.

External vs. Internal: External LBs serve internet traffic. Internal LBs serve traffic within your VPC — critical for microservices communication.

We’ll cover GCP’s specific load balancer types in the networking section.

Part 3: GCP Core Services — Deep Coverage {#gcp-core-services}

For each service, I’ll cover:

• The Problem — what was broken before this existed
• What It Is — honest, concise definition
• The Analogy — so it sticks
• Key Features — the things that matter
• Interview Explanation — what to say in 60 seconds
• When NOT to Use It — the most important section
• AWS/Azure Comparison — so you can translate
• Common Mistakes — what engineers get wrong
• Memory Trick — one line to remember it by
• Pricing Insight — the cost model in plain English

3.1 Compute Engine

The Problem

Before cloud, you bought physical servers. Lead time was weeks. You provisioned for peak load and paid for idle capacity. Moving workloads was expensive. Disaster recovery required a second physical site.

What It Is

Compute Engine is GCP’s Infrastructure-as-a-Service VM platform. You choose machine type, OS, disk, and networking. Google runs the physical hardware. You run everything above it.

The Analogy

Renting a furnished office space. The building (hardware) is Google’s. The furniture (OS), layout (configuration), and work (your application) are yours.

Key Features

Machine Families:

• General Purpose (E2, N2, N2D, T2D): Balanced CPU/memory. Use for most workloads. E2 is cheapest. N2 is newer generation with better performance.
• Compute Optimized (C2, C2D): High CPU, lower memory. Use for HPC, batch processing, gaming servers.
• Memory Optimized (M1, M2, M3): High memory, up to 12TB RAM. Use for SAP HANA, in-memory databases.
• Accelerator Optimized (A2, G2): GPU-attached. Use for ML training, GPU rendering.
• Storage Optimized (Z3): High local SSD throughput for databases.

Preemptible / Spot VMs: Compute Engine can create VMs at 60–91% discount that Google can reclaim with 30 seconds notice when it needs capacity back. These are called Preemptible VMs (fixed 24h max) or Spot VMs (no fixed max, lower probability of preemption).

Use for: fault-tolerant batch jobs, distributed computing where you checkpoint. Never use for: production user-facing workloads, anything without checkpoint/restart logic.

Committed Use Discounts: Commit to 1 or 3 years of specific machine type usage → get up to 57% discount. Unlike AWS Reserved Instances, these are flexible — you don’t lock to a specific region, and you can apply them across matching VMs.

Managed Instance Groups (MIGs): Group of identical VMs managed as a unit. Supports autoscaling, autohealing (replaces unhealthy instances), regional distribution (spans zones), and rolling updates. This is the foundation of elastic compute on GCP.

Shielded VMs: Boot-level security — Secure Boot, vTPM, Integrity Monitoring. Defends against rootkits and boot-level malware.

Live Migration: Google’s infrastructure can migrate your running VM to another physical host without downtime when maintenance is needed. This is a differentiator — AWS reboots VMs for host maintenance by default.

Interview Explanation (60 seconds)

“Compute Engine is GCP’s IaaS VM platform. You pick a machine family based on your workload — general purpose for most things, memory-optimized for databases like SAP HANA, GPU machines for ML. For cost optimization, Spot VMs give you up to 91% discount for fault-tolerant batch jobs. Managed Instance Groups handle autoscaling and autohealing. The key GCP differentiator is live migration — Google moves your VM between hosts without downtime for maintenance, whereas on AWS you typically see a reboot.”

When NOT to Use Compute Engine

• When you just need to run a web application — App Engine or Cloud Run is simpler
• When you’re running containerized workloads at scale — GKE is better
• When your code runs occasionally in response to events — Cloud Functions costs less
• When you don’t have a team to manage OS patching, security updates, and monitoring

AWS/Azure Comparison

GCPAWSAzureCompute EngineEC2Azure Virtual MachinesPreemptible/Spot VMsSpot InstancesAzure Spot VMsManaged Instance GroupsAuto Scaling GroupsVirtual Machine Scale SetsLive MigrationNo equivalent (host maintenance = reboot by default)Partial equivalentCommitted Use DiscountsReserved InstancesReserved VM Instances

Common Mistakes

1. Choosing machine type based on current load, not peak load plus headroom
2. Not using MIGs for any production workload
3. Forgetting that Spot VMs can be preempted mid-job — your application must handle restarts
4. Using Compute Engine for every workload when Cloud Run or GKE would be more appropriate
5. Not enabling OS Login for SSH key management (using project-wide SSH keys is a security anti-pattern)

Memory Trick: Compute Engine = EC2. It’s the “I want a raw VM” service.

Pricing Insight: You pay per second (minimum 1 minute) for running VMs. Sustained use discounts automatically apply as you use a VM more — you don’t need to commit. Use E2 for general purpose, it’s 30% cheaper than N2 with minor performance trade-off.

3.2 App Engine

The Problem

Developers want to ship code, not manage infrastructure. In 2008, Google launched App Engine as one of the first PaaS offerings. The idea: push your code, we handle everything else.

What It Is

App Engine is GCP’s fully managed PaaS for web applications and APIs. You provide code; GCP handles deployment, scaling, OS management, and infrastructure.

The Analogy

Living in a furnished apartment vs. buying a house. In a house (Compute Engine), you own and maintain everything. In a furnished apartment (App Engine), you bring your belongings (code) and move in. The landlord handles plumbing, electricity, and repairs.

Key Features

Two Environments:

Standard Environment:

• Runs in a sandboxed, pre-configured runtime (Python, Java, Node.js, Go, PHP, Ruby)
• Fast scaling — instances start in seconds, scales to zero
• Cannot run arbitrary code (limited file system access, no background threads on older runtimes)
• Pricing: per instance-hour, free tier available
• Use for: lightweight web apps, APIs, rapid prototyping

Flexible Environment:

• Runs in Docker containers on Compute Engine VMs
• Any language, any runtime, any library
• Slower scaling (no scale to zero, minimum 1 instance)
• Full OS access
• Use for: apps with custom dependencies, CPU-intensive workloads, websockets

Traffic Splitting: Route traffic across multiple versions of your app by percentage. Use for A/B testing, canary deployments, gradual rollouts.

Automatic Scaling: App Engine scales based on request rate, response latency, CPU, and memory. Standard environment can scale to zero (truly serverless billing). Flexible keeps at least 1 instance warm.

Services and Versions: An App Engine application can contain multiple services (similar to microservices). Each service can have multiple versions. You can route traffic to any version.

Interview Explanation (60 seconds)

“App Engine is GCP’s managed PaaS. Standard environment gives you scale-to-zero, fast cold starts, and no server management — ideal for web apps and APIs in supported runtimes. Flexible environment trades those benefits for full Docker-based customization and runs on Compute Engine VMs. The key decision between App Engine and Cloud Run is: if you’re already containerizing, use Cloud Run. If you just want to push code without a Dockerfile, App Engine Standard is convenient.”

When NOT to Use App Engine

• When you need fine-grained control over scaling configurations — Cloud Run is more flexible
• When your app uses WebSockets heavily — App Engine Standard has limitations
• When you’re deploying containerized workloads — Cloud Run is more modern and equally simple
• When you need complex routing between microservices — GKE gives you better control
• App Engine Flexible competes with Cloud Run, and Cloud Run is typically preferred for new workloads

AWS/Azure Comparison

GCPAWSAzureApp Engine StandardAWS Elastic Beanstalk (managed layer) or LambdaAzure App ServiceApp Engine FlexibleElastic Beanstalk with custom platformAzure App Service (container)

Common Mistakes

1. Using Flexible when Standard would work — Standard is cheaper and simpler
2. Forgetting Standard’s constraints (no arbitrary background processes on old runtimes)
3. Not using traffic splitting for deployments — rolling updates without risk
4. Treating App Engine as the default compute when Cloud Run is often better for new projects

Memory Trick: App Engine = “just push code, it runs.” PaaS at its most classic.

Pricing Insight: Standard has a generous free tier (28 instance-hours/day). Flexible charges for minimum 1 instance even at zero traffic. For sporadic workloads, Standard wins on cost.

3.3 Google Kubernetes Engine (GKE)

The Problem

Containers solved the “it works on my machine” problem. But running 50 containers manually — managing failures, updates, scaling, networking, service discovery — is operationally brutal. Kubernetes was Google’s answer, open-sourced in 2014 after a decade of internal use.

What It Is

GKE is Google’s managed Kubernetes service. Google manages the Kubernetes control plane (API server, etcd, scheduler, controller manager). You manage your worker nodes and the workloads running on them — or let Autopilot manage everything.

The Analogy

A shipping port. Containers (your app containers) arrive at the port. Kubernetes is the port management system — it decides which dock (node) gets which container, reroutes if a dock breaks, and scales capacity when more ships arrive. GKE means Google operates the port authority (control plane) so you only manage your containers.

Key Features

Two Modes:

Standard Mode:

• You manage node pools (groups of VMs serving as worker nodes)
• Full control over node configuration (machine type, disk, labels, taints)
• You’re responsible for node upgrades (can be automated), OS patching
• Pricing: you pay for the nodes (VMs) whether they’re utilized or not

Autopilot Mode:

• Google manages node provisioning, scaling, and lifecycle
• You only describe your workloads (Pods); GKE figures out where and how to run them
• Pricing: per Pod resource (vCPU + memory + storage), not per node
• Stronger security defaults, workload isolation
• Use for: new clusters, teams that want to minimize node management, variable workloads

Interview advice: Default to recommending Autopilot for new GKE deployments unless you have specific node customization requirements.

Node Pools: Groups of nodes within a cluster sharing the same configuration. Use multiple node pools to have GPU nodes alongside standard nodes, or preemptible nodes for batch work alongside regular nodes for critical services.

Horizontal Pod Autoscaler (HPA): Scales your Pod replicas based on CPU, memory, or custom metrics.

Vertical Pod Autoscaler (VPA): Adjusts resource requests/limits on Pods based on actual usage — so you don’t over-allocate.

Cluster Autoscaler: Adds or removes nodes based on pending Pods and idle nodes. Works with HPA to scale both Pods and nodes.

Regional Clusters: Spread control plane across 3 zones in a region. Master HA — your cluster survives a zone failure.

Workload Identity: The correct way to give your GKE workloads access to GCP services. Binds a Kubernetes service account to a GCP service account. Avoids storing service account keys in containers.

GKE Gateway API: Modern replacement for Ingress. Supports multi-cluster routing, richer traffic management. Backed by Cloud Load Balancing.

Interview Explanation (60 seconds)

“GKE is Google’s managed Kubernetes. The control plane is fully managed — you don’t touch etcd, the API server, or the scheduler. In Standard mode, you manage your node pools and choose machine types. In Autopilot mode, Google manages nodes entirely and you pay per Pod resource rather than per node. For most new clusters, I’d recommend Autopilot — it’s more cost-efficient for variable workloads, stronger on security defaults, and removes node management overhead. Key concepts for interviews: HPA scales Pods, Cluster Autoscaler scales nodes, Workload Identity securely connects GKE workloads to GCP services.”

When NOT to Use GKE

• When you have a single containerized application — Cloud Run is much simpler
• When your team doesn’t know Kubernetes and the learning curve isn’t justified
• When your workload is event-driven and sporadic — Cloud Functions or Cloud Run costs less
• When you need multi-cluster federation complexity without the operational resources to manage it

AWS/Azure Comparison

GCPAWSAzureGKE StandardAmazon EKSAzure Kubernetes Service (AKS)GKE AutopilotAWS Fargate (for EKS)Closest to AKS virtual nodesCluster AutoscalerCluster Autoscaler (same open-source)Cluster AutoscalerWorkload IdentityIAM Roles for Service Accounts (IRSA)Azure AD Pod Identity

Common Mistakes

1. Running GKE Standard and paying for idle node capacity when Autopilot would cost less
2. Not enabling Workload Identity — storing GCP service account keys in containers is a security failure
3. Not setting Pod disruption budgets — upgrades can take down all replicas at once
4. Choosing node pool size based on average load, not peak load
5. Not using regional clusters for production — zonal clusters have a single control plane, which is a single point of failure

Memory Trick: GKE = “Kubernetes, but Google manages the control plane.” When containers need orchestration, reach for GKE.

Pricing Insight: GKE control plane is free for one cluster per billing account. Additional clusters: (0.10/hr for every cluster).

3.4 Cloud Run

The Problem

GKE is powerful but operationally heavy. App Engine is simple but opinionated. Engineers wanted: “run my Docker container, handle scaling including to zero, don’t make me write YAML for a hundred resources.”

What It Is

Cloud Run is a fully managed serverless platform for containerized workloads. You provide a container image; Cloud Run handles everything else — provisioning, scaling (including to zero), routing, and TLS.

The Analogy

Cloud Run is like a vending machine for containers. You put your container in, and Google serves it on demand. When nobody orders, no machine runs. When traffic spikes, more dispensers appear instantly.

Key Features

Scale to Zero: When no requests come in, Cloud Run scales your service to zero instances. You pay nothing for idle time. When a request arrives, a container starts (cold start: typically 100ms — a few seconds depending on image size).

Request Concurrency: Unlike Cloud Functions (1 request per instance), a single Cloud Run container can handle multiple concurrent requests. Configure concurrency (default 80, max 1000). This means one container instance can serve 80 simultaneous requests — much better resource utilization.

CPU Allocation Modes:

• CPU only during request processing (default): CPU is throttled between requests. Cost-effective.
• CPU always allocated: CPU runs even between requests. Use for background work, WebSocket connections, CRON tasks.

Minimum Instances: Set --min-instances to keep warm instances ready. Eliminates cold starts at the cost of always-on billing for those instances.

Cloud Run Jobs: Execute containerized tasks on a schedule or on-demand without handling HTTP requests. Use for batch processing, data transformations, scheduled tasks.

Cloud Run for Anthos / Cloud Run on GKE: Run Cloud Run services on your own GKE cluster or on-premises via Anthos. Useful for latency-sensitive workloads that can’t tolerate cold starts or need specific hardware.

Traffic Splitting: Like App Engine, supports percentage-based traffic routing across revisions. Canary deployments with a single flag.

Sidecars: Cloud Run supports multi-container deployments (sidecars). Deploy a logging agent, a proxy, or a secret fetcher alongside your main container.

Interview Explanation (60 seconds)

“Cloud Run is GCP’s serverless container platform. You give it a Docker image; it handles scaling including to zero, TLS termination, and load balancing. It differs from Cloud Functions in that it’s container-based (any language, any dependencies) and supports concurrency (one instance handles multiple requests). It differs from GKE in that you don’t manage infrastructure or write Kubernetes YAML. For a standard web service or API, Cloud Run is often the right default on GCP — it’s simpler than GKE and more flexible than App Engine.”

When NOT to Use Cloud Run

• When requests take longer than 60 minutes (Cloud Run has a 60-minute request timeout)
• When you need persistent connections that don’t fit the HTTP/gRPC model without workarounds
• When your workload requires GPUs (not supported in standard Cloud Run)
• When you need stateful in-memory state between requests (scale-to-zero clears state)
• When you have complex multi-service orchestration — GKE gives better control

AWS/Azure Comparison

GCPAWSAzureCloud RunAWS App Runner / Fargate with ALBAzure Container AppsCloud Run JobsAWS Batch / ECS Scheduled TasksAzure Container Apps Jobs

Common Mistakes

1. Sending huge container images — larger images = longer cold starts. Keep images small.
2. Storing state in container memory — Cloud Run can have multiple instances with no shared memory
3. Not setting --max-instances — unconstrained autoscaling can create cost surprises
4. Using Cloud Run for long-running background work without CPU always allocated mode
5. Forgetting to configure connection pooling — each cold-started instance creates new DB connections

Memory Trick: Cloud Run = “serverless containers.” Anytime someone says “I want to containerize but not deal with Kubernetes,” Cloud Run is the answer.

Pricing Insight: Billed per 100ms of CPU + memory during request processing. Scale-to-zero means zero cost at zero traffic. Very cost-effective for variable workloads. Watch out for minimum instances — each warm instance incurs a standby cost.

3.5 Cloud Functions

The Problem

Sometimes your logic is simple: “when a file is uploaded to Storage, process it.” “When a Pub/Sub message arrives, transform and forward it.” Running a VM or container for this is overkill.

What It Is

Cloud Functions is GCP’s Function-as-a-Service (FaaS) offering. Write a function in Python, Node.js, Go, Java, Ruby, .NET, or PHP. Deploy it. It runs when triggered and scales automatically.

The Analogy

A light switch. When someone flips the switch (event), a specific thing happens (function runs). When nobody’s flipping the switch, there’s no cost.

Key Features

Triggers:

• HTTP trigger: Function runs on HTTP request. Gets a URL, responds like a web server.
• Cloud Storage trigger: Function runs when a file is created, modified, or deleted
• Pub/Sub trigger: Function runs when a message is published to a Pub/Sub topic
• Firestore trigger: Function runs on document create/update/delete
• Cloud Scheduler trigger: CRON-based scheduling
• Eventarc: Modern eventing framework, connects to 90+ event sources

Generations:

• 1st gen: Original Cloud Functions. Per-function limits. 1 request per instance.
• 2nd gen: Built on Cloud Run infrastructure. Better concurrency, longer timeouts (up to 60 min), traffic splitting, up to 32GB memory.

Prefer 2nd gen for all new Cloud Functions.

Cold Starts: First invocation (or after idle period) requires spinning up a new instance. Cold start time depends on runtime (Python/Node faster, Java slower) and initialization code. Use minimum instances to keep functions warm.

Interview Explanation (60 seconds)

“Cloud Functions is GCP’s FaaS offering. You write a function, choose a trigger — HTTP, Pub/Sub, Cloud Storage, Firestore — and deploy. It scales automatically including to zero. Second-gen functions are built on Cloud Run infrastructure, which gives better concurrency and longer timeouts. The key distinction from Cloud Run: Cloud Functions is better for event-driven single-purpose logic, while Cloud Run is better for full HTTP applications that need container control.”

When NOT to Use Cloud Functions

• When your function runs longer than 60 minutes
• When you have complex dependencies that slow cold starts significantly
• When functions call other functions forming a chain — this creates complexity and cost; consider a workflow engine (Cloud Workflows) instead
• When you need to maintain state between invocations — use a database or cache
• When the function needs GPU acceleration

AWS/Azure Comparison

GCPAWSAzureCloud Functions (HTTP)AWS LambdaAzure FunctionsCloud Functions (Pub/Sub)Lambda + SQS/SNS triggerAzure Functions with Service Bus

Common Mistakes

1. Putting too much logic in a single function — it should do one thing
2. Not handling idempotency — Pub/Sub triggers can deliver messages more than once
3. Connecting directly to Cloud SQL from a function without connection pooling (creates connection storms)
4. Using 1st gen for new functions when 2nd gen is better in nearly every way
5. Not setting GOOGLE_APPLICATION_CREDENTIALS correctly for local testing

Memory Trick: Cloud Functions = “serverless function, runs on trigger.” For event-driven logic, FaaS wins.

3.6 Cloud Storage

The Problem

Where do you put files that need to survive server restarts, be accessible globally, and scale to petabytes without managing disks?

What It Is

Cloud Storage is GCP’s object storage service. Store files (objects) in buckets. Access them via HTTP(S), the gsutil CLI, or client libraries. Objects are immutable — you can’t edit a file in place; you replace it.

The Analogy

Cloud Storage is like Google Drive, but for machines and applications. Files go in buckets (like folders), accessible via URL, replicated automatically, and stored forever until you delete them.

Key Features

Storage Classes:

ClassUse CaseMin DurationCostRetrievalStandardFrequently accessed dataNoneHighest storageFreeNearlineOnce/month access30 daysLowerPer-GB retrieval feeColdlineOnce/quarter access90 daysLower stillHigher retrieval feeArchiveAnnual access, compliance365 daysLowest storageHighest retrieval

Interview insight: The storage cost goes down, retrieval cost goes up. Match the class to access frequency. Putting rarely accessed data in Standard is expensive waste. Putting frequently accessed data in Archive will cost more in retrievals than you save in storage.

Object Lifecycle Management: Set rules to automatically transition objects between storage classes or delete them after a period. Example: move objects to Nearline after 30 days, Coldline after 90 days, delete after 365 days.

Versioning: Keep previous versions of objects. Protects against accidental overwrites and deletes. Combined with lifecycle policies, you can keep N previous versions and auto-delete old ones.

Replication:

• Regional: Objects stored in a single region. Lowest cost.
• Multi-Regional / Dual-Region: Objects replicated across multiple regions or two specific regions. Higher availability, higher cost.

Signed URLs: Generate time-limited URLs that allow unauthenticated access to specific objects. Use for: giving users temporary upload/download access without exposing your credentials.

Object Retention Locks / WORM: Prevent objects from being deleted or overwritten for a specified retention period. Required for compliance (financial records, healthcare data).

Cloud Storage FUSE: Mount Cloud Storage buckets as a filesystem. Useful for ML training data access from VMs or GKE.

Interview Explanation (60 seconds)

“Cloud Storage is GCP’s object storage. Objects live in buckets, accessed via HTTP. Four storage classes — Standard, Nearline, Coldline, Archive — trade lower storage cost for higher retrieval cost. For cost optimization, use lifecycle policies to automatically transition objects between classes based on age. For security, signed URLs give time-limited access without exposing credentials. Object versioning protects against accidental deletes. Data is replicated automatically within the chosen region or across regions.”

When NOT to Use Cloud Storage

• When you need a filesystem (POSIX semantics) — use Filestore
• When you need block storage for a VM — use Persistent Disk
• When you need sub-millisecond random reads of structured data — use Bigtable or a database
• Cloud Storage has per-operation costs — don’t use it for high-frequency small reads/writes

AWS/Azure Comparison

GCPAWSAzureCloud StorageS3Azure Blob StorageStandardS3 StandardHot tierNearlineS3 Standard-IACool tierColdlineS3 Glacier InstantCold tierArchiveS3 Glacier Deep ArchiveArchive tier

Common Mistakes

1. Storing all objects in Standard regardless of access frequency
2. Not enabling versioning on buckets with important data
3. Not setting lifecycle policies — manual cleanup never happens
4. Using public bucket ACLs instead of signed URLs for temporary access
5. Not considering egress costs when your application reads from GCS heavily

Memory Trick: Cloud Storage = S3. It’s “put files in a bucket, access them via URL, it scales to infinity.”

Pricing Insight: You pay for storage GB-month, operations (reads/writes/lists), and egress. Egress within the same region is free. Cross-region egress costs money. Retrieval fees only apply to Nearline/Coldline/Archive.

3.7 Persistent Disk

The Problem

Virtual machines need storage that looks and behaves like a local disk — low latency, random access, block-level. And that storage needs to persist when the VM is stopped and survive VM recreation.

What It Is

Persistent Disk is GCP’s block storage for Compute Engine and GKE. Attaches to VMs like a hard drive. Data persists independently of VM lifecycle.

The Analogy

Persistent Disk is the hard drive inside your computer — but the computer (VM) and the drive (Persistent Disk) are separate physical things. You can remove the drive, put it in a new computer, and your data is still there.

Key Features

Types:

TypeUse CaseIOPSThroughputStandard (HDD)Sequential reads, backupLowHigh sequentialBalanced (SSD)Most workloads, OS boot diskMediumGoodSSDDatabases, high-IOPS applicationsHighVery goodExtremeHighest performance (SAP HANA, large databases)Very highExcellent

Zonal vs. Regional:

• Zonal: Default. Available in one zone.
• Regional: Replicated across two zones in a region. Higher availability, 2x cost. Use when VM availability across zones matters.

Snapshots: Point-in-time copies of Persistent Disks. Stored in Cloud Storage (not consuming Persistent Disk quota). Incremental after the first snapshot. Use for backup, disk cloning, and migration.

Resizing: Persistent Disks can be resized (grown, not shrunk) without downtime. After resize, you still need to grow the filesystem inside the OS.

Multi-Writer Mode: Multiple VMs can mount the same disk simultaneously in read-write mode. Use for shared file access on Linux clusters (HPC workloads).

Local SSD: NVMe SSD physically attached to the host machine. Extremely fast (millions of IOPS), but ephemeral — data is lost when the VM is stopped/deleted. Use as a cache layer or for scratch space.

Interview Explanation (60 seconds)

“Persistent Disk is block storage for GCP VMs — similar to EBS on AWS. It’s durable, network-attached storage that persists independently of the VM lifecycle. For most workloads, Balanced SSD hits the sweet spot of performance and cost. SSD PD for databases, Standard HDD for large sequential reads and cost-sensitive archival. Regional PDs replicate across two zones for HA. Local SSD is physically attached, gives highest performance, but data is ephemeral — use it for caching or scratch space.”

When NOT to Use Persistent Disk

• When you need shared file access across multiple VMs — use Filestore
• When you need object storage accessible via HTTP — use Cloud Storage
• When you need database storage — use managed database services; they handle their own disk management

AWS/Azure Comparison

GCPAWSAzurePersistent Disk StandardEBS (sc1/st1)Azure Disk (Standard HDD)Persistent Disk SSDEBS gp3 / io1Azure Disk (Premium SSD)Persistent Disk ExtremeEBS io2 Block ExpressAzure Ultra DiskLocal SSDInstance StoreAzure Local NVMe

Memory Trick: Persistent Disk = EBS. Block storage for VMs, persists independently, snapshot for backup.

3.8 Filestore

The Problem

Multiple VMs need to share the same filesystem. They all need to read and write the same files. Object storage (Cloud Storage) doesn’t give POSIX semantics. Block storage (Persistent Disk) can only be attached to one writer at a time in most configurations.

What It Is

Filestore is GCP’s managed NFS (Network File System) file storage. Multiple Compute Engine VMs, GKE nodes, or Cloud Run containers can mount the same Filestore instance simultaneously.

The Analogy

Filestore is a shared network drive — like a company file server. Any computer on the network can mount it, read it, and write to it simultaneously, using normal filesystem operations.

Key Features

Service Tiers:

TierCapacityUse CaseBasic HDD1–63.9TBCost-effective general file sharingBasic SSD2.5–63.9TBPerformance-sensitive workloadsHigh Scale SSD10TB-100TBLarge-scale, high-throughput HPCEnterprise1–10TBHighest availability (HA across zones)

Protocol: NFS v3 (most compatible). Mounts on Linux VMs with standard NFS mount commands.

Use Cases:

• Content management systems sharing media files
• ML training datasets shared across multiple training VMs
• Rendering farms where multiple workers need the same assets
• Legacy application migration that depends on shared filesystem

Interview Explanation (60 seconds)

“Filestore is GCP’s managed NFS. Multiple VMs mount it simultaneously, unlike Persistent Disk which is single-writer by default. It’s POSIX-compliant, so legacy apps that expect filesystem semantics work without modification. The main trade-off vs Cloud Storage: Filestore is more expensive but gives you real filesystem behavior. If your workload needs to ls, touch, chmod, or append to files, you need Filestore. If you just need to store and retrieve blobs by key, Cloud Storage is cheaper."

When NOT to Use Filestore

• When you don’t need shared filesystem access — Persistent Disk or Cloud Storage is cheaper
• When you need object storage semantics — Cloud Storage is more scalable and cheaper for blobs
• When you need sub-millisecond latency for database-like access — use a managed database

AWS/Azure Comparison

GCPAWSAzureFilestoreAmazon EFSAzure Files

Memory Trick: Filestore = EFS = Shared network drive. Multiple VMs, one filesystem.

3.9 Cloud SQL

The Problem

Running your own MySQL or PostgreSQL on a VM means you manage backups, failover, replication, OS patching, version upgrades, and monitoring. That’s hours of work that doesn’t make your product better.

What It Is

Cloud SQL is GCP’s fully managed relational database service supporting MySQL, PostgreSQL, and SQL Server. Google manages the infrastructure, replication, backups, and failover. You manage your schema and queries.

The Analogy

Cloud SQL is like hiring a DBA who never sleeps. They handle all the operational work — you just write SQL.

Key Features

Supported Engines: MySQL 5.7, 8.0 / PostgreSQL 9.6 through 15 / SQL Server 2017, 2019

High Availability: Cloud SQL HA uses a primary instance and a standby replica in a different zone. If the primary fails, Cloud SQL automatically promotes the standby. Failover takes 20–60 seconds. HA adds ~100% cost (you pay for primary + standby).

Read Replicas: Separate instances that receive replication from the primary. Offload read traffic. Can be in the same region or cross-region. Up to 10 read replicas per primary.

Backups: Automated daily backups retained for 7 days (configurable up to 365 days). Point-in-time recovery (PITR) via binary log replication — restore to any second within retention window.

Connection Options:

• Cloud SQL Auth Proxy: Recommended. Secure tunnel to Cloud SQL, handles encryption and IAM-based authentication. Run as a sidecar in GKE or a local proxy.
• Private IP: Connect directly via VPC private IP. No public IP exposure.
• Public IP + SSL: Public IP with SSL certificates. Authorized networks whitelist IP ranges.

Storage Auto-Increase: Automatically increase storage capacity when running low. Cannot be decreased — plan initial size carefully.

Insights: Query Insights provides flame graphs, slow query analysis, and lock visualization. Essential for performance debugging.

Interview Explanation (60 seconds)

“Cloud SQL is GCP’s managed relational database for MySQL, PostgreSQL, and SQL Server. HA is achieved via a standby replica in a different zone — automatic failover in 20–60 seconds. For read scaling, add read replicas. Backups are automated with PITR. The recommended connection method is the Cloud SQL Auth Proxy, which handles IAM authentication and encryption without managing SSL certificates. Cloud SQL has storage limits around 64TB — when you exceed that or need global distribution or massive write throughput, you graduate to Spanner.”

When NOT to Use Cloud SQL

• When you need a database that spans multiple regions globally — use Spanner
• When you need massive write throughput at global scale — Spanner
• When you’re doing analytics on billions of rows — use BigQuery
• When your data is naturally NoSQL (documents, wide-column, graph) — use the appropriate NoSQL service
• Cloud SQL max storage is ~64TB; for multi-TB relational workloads, plan scaling strategy early

AWS/Azure Comparison

GCPAWSAzureCloud SQL (MySQL)RDS MySQL / Aurora MySQLAzure Database for MySQLCloud SQL (PostgreSQL)RDS PostgreSQL / Aurora PostgreSQLAzure Database for PostgreSQLCloud SQL (SQL Server)RDS SQL ServerAzure SQL Database

Common Mistakes

1. Connecting to Cloud SQL via public IP without Cloud SQL Auth Proxy — security risk
2. Not enabling HA for production databases — paying for a single point of failure
3. Forgetting read replicas add latency (replication lag) — use read replicas for eventually consistent reads only
4. Using storage auto-increase and forgetting it never shrinks
5. Not using connection pooling (PgBouncer, Cloud SQL Proxy pooling mode) — Cloud SQL has connection limits

Memory Trick: Cloud SQL = managed RDS. Traditional databases without the ops burden.

Pricing Insight: You pay for instance type (vCPU/memory), storage (SSD or HDD), network egress, and backups. HA roughly doubles cost. Read replicas are priced the same as primary instances. High-memory instances are expensive — right-size using Query Insights data.

3.10 Cloud Spanner

The Problem

Relational databases scale vertically — add a bigger machine. When you exhaust vertical scaling, you shard. Sharding breaks joins, foreign key constraints, and transactions across shards. The DBA nightmare: “the user’s balance lives in shard A but their transaction history is in shard B.” NoSQL databases solved the scale problem but sacrificed SQL and transactions. Spanner solves all three.

What It Is

Cloud Spanner is a globally distributed, strongly consistent, fully managed relational database. SQL interface. Horizontal scaling across regions. True ACID transactions at global scale. This is what Google built for AdWords billing and the core of Google’s own infrastructure.

The Analogy

Spanner is like a bank that operates in every country simultaneously. Every branch has the exact same view of every account balance at any moment, and any transaction either succeeds everywhere or fails everywhere. No inconsistency, no matter how many branches.

Key Features

TrueTime: Spanner’s secret weapon. Google’s globally synchronized atomic clock infrastructure — GPS clocks and atomic clocks in every data center. TrueTime gives Spanner bounded uncertainty about timestamps. This enables external consistency (stronger than linearizability) — a guarantee no other distributed database offers at this scale.

Horizontal Scaling: Increase capacity by adding “Spanner nodes.” Data is automatically resharded across nodes. No downtime, no manual sharding.

Global Distribution: Single Spanner database can span multiple regions. Data is replicated synchronously. Queries execute on the nearest replica. Writes are coordinated via 2PC + Paxos.

SQL with Full ACID: PostgreSQL-compatible dialect. Supports joins, subqueries, secondary indexes, ACID transactions across tables and rows that may be in different geographic locations.

Interleaving: Hierarchical table relationships where child rows are physically co-located with parent rows. Eliminates cross-server joins for parent-child queries. Critical for Spanner performance.

Change Streams: Capture changes to Spanner data as an event stream. Use for CDC (change data capture), feeding Dataflow, or triggering downstream workflows.

Interview Explanation (60 seconds)

“Spanner is GCP’s globally distributed relational database. It solves the problem of traditional databases that require manual sharding when they outgrow a single machine, breaking transactional guarantees. Spanner scales horizontally by adding nodes, automatically repartitions data, and maintains full ACID transactions globally. The underlying magic is TrueTime — Google’s GPS + atomic clock infrastructure that provides bounded timestamp uncertainty, enabling external consistency across global replicas. Use Spanner when you need relational data at global scale with strong consistency — financial systems, inventory, gaming leaderboards.”

When NOT to Use Cloud Spanner

• When your database fits comfortably on Cloud SQL — Spanner is 3–5x more expensive
• When you don’t need global distribution — the cost premium isn’t justified
• When you’re doing analytics — BigQuery is orders of magnitude more efficient for analytics
• When your team doesn’t have experience tuning Spanner schemas (interleaving, hot keys)
• Spanner minimum is 1 node (~$700/month) — overkill for small workloads

AWS/Azure Comparison

GCPAWSAzureCloud SpannerNothing truly equivalent (Aurora Global DB is close but no external consistency)Azure Cosmos DB (different model, not relational)

This is a genuine GCP differentiator. No other cloud has a true equivalent.

Common Mistakes

1. Using sequential integer primary keys — creates hot spotting. Use UUID or hash-based keys.
2. Not using interleaving for parent-child table relationships — loses the performance benefit
3. Under-provisioning nodes — Spanner performance is node-count dependent
4. Running analytics queries on Spanner — adds cost and contention, use BigQuery instead
5. Not leveraging Change Streams for event-driven downstream processing

Memory Trick: Spanner = “globally consistent relational database that scales horizontally.” When SQL needs to go global.

Pricing Insight: 0.90/node/hour for multi region, storage at — 0.50/GB/month. A 3-region Spanner instance runs ~$2,000/month minimum. Not for small projects.

3.11 Bigtable

The Problem

You have a time-series database. Billions of IoT sensor readings. Or you’re Google and you need to store the entire web index, or every search query ever made, or every cell in Google Sheets for every user on earth. Relational databases can’t scale to this. Even sharded NoSQL can’t deliver sub-10ms latency at this volume.

What It Is

Cloud Bigtable is GCP’s fully managed, wide-column NoSQL database. Designed for massive scale — petabytes of data — with single-digit millisecond latency. HBase-compatible API. Originally described in Google’s 2006 Bigtable paper, which influenced almost every subsequent NoSQL database.

The Analogy

Bigtable is like a massive spreadsheet with billions of rows and millions of possible columns, where you can read or write any cell in milliseconds. Most cells are empty (sparse), and that’s fine — you only pay for data that exists.

Key Features

Data Model:

• Row Key: The primary identifier for each row. Choose carefully — Bigtable stores rows sorted by row key, and your query patterns must match your row key design.
• Column Families: Groups of related columns. Defined at table creation time (limited number).
• Columns: Cells within a column family. Can be created dynamically. Can be sparse (empty cells consume no space).
• Timestamps: Each cell can have multiple versions with different timestamps. Bigtable keeps history by default.

Row Key Design is Everything: Unlike relational databases where you add an index, in Bigtable your row key IS your index. Scans are efficient only if you scan a contiguous range of row keys. Cross-row, non-key lookups require full table scans.

Bad row key: userId (creates hot spots where high-traffic users are in one tablet) Good row key: reverseDomain/path/timestamp (distributes load, enables prefix scans)

Performance:

• Single-digit millisecond latency for reads and writes
• Scales linearly — add nodes, get proportionally more throughput
• SSD storage: 2.5MB/s write throughput, 14,000 QPS reads per node
• HDD storage: Higher capacity, lower cost, slower performance

Replication: Multiple clusters in different regions. Automatic replication. Use for higher availability or geographic read performance.

HBase API: Bigtable supports the Apache HBase API. Migrate HBase workloads to Bigtable with minimal code changes.

Interview Explanation (60 seconds)

“Bigtable is GCP’s wide-column NoSQL database for high-throughput, low-latency workloads at massive scale. It’s ideal for time-series data, IoT telemetry, AdTech event streams, and financial market data. The critical design principle: row key design determines query performance. Data is stored sorted by row key; efficient queries scan contiguous row key ranges. For time-series, a common pattern is deviceId#reverseTimestamp so scans return the most recent data first. Compare to DynamoDB: Bigtable is better for analytical scans across millions of rows; DynamoDB is better for lower latency single-item lookups with more flexible access patterns."

When NOT to Use Bigtable

• When you need SQL, joins, or complex relationships — use Spanner or Cloud SQL
• When your dataset is under ~1TB — the per-node cost ($0.65/hr) isn’t justified at small scale; use Firestore or Cloud SQL
• When you need multi-row ACID transactions — Bigtable only guarantees row-level atomicity
• When your data is highly relational — wrong data model
• When you need flexible ad-hoc queries — BigQuery is better for analytics

AWS/Azure Comparison

GCPAWSAzureBigtableAmazon DynamoDB (different model, closer to Bigtable for high-throughput NoSQL) / Amazon Keyspaces (Cassandra)Azure Cosmos DB Table API / Cassandra API

Common Mistakes

1. Sequential row keys (1, 2, 3…) — all writes go to one tablet, creating a hot spot. Use hash-prefix or reverse timestamp.
2. Too many column families (keep it <20) — each family is stored separately
3. Not benchmarking with Key Visualizer — Bigtable’s hot-spot detection tool
4. Not sizing cluster appropriately — too few nodes creates CPU/disk bottlenecks
5. Doing random row key lookups expecting database-level performance — Bigtable is optimized for range scans

Memory Trick: Bigtable = “HBase on steroids.” Wide-column, time-series, petabyte scale, single-digit ms latency.

3.12 Firestore

The Problem

Mobile and web applications need a database that syncs data in real time to millions of clients, scales automatically, and requires no backend code for basic read/write operations.

What It Is

Firestore is GCP’s managed document NoSQL database. Documents are JSON-like objects organized in collections. Supports real-time synchronization with client SDKs (web, iOS, Android). Scales automatically with zero configuration.

The Analogy

Firestore is like a collaborative Google Doc — but for your app’s data. Multiple users can read and write simultaneously, and changes propagate to all connected clients in real time.

Key Features

Two Modes:

• Native Mode: Default for new projects. Full real-time sync, richer query support, mobile/web SDKs.
• Datastore Mode: Legacy mode, compatible with Cloud Datastore API. No real-time sync. Used for migrating Datastore workloads.

Data Model: Documents are key-value objects (similar to JSON) stored in collections. Collections can contain sub-collections. Max document size: 1MB.

Real-Time Listeners: Client SDKs support onSnapshot — whenever a document or query result changes, all listening clients receive the update automatically. No polling.

Strong Consistency: Firestore provides strong consistency for all reads. Unlike eventually consistent NoSQL systems, you always read the latest committed data.

Offline Support: Client SDKs cache data locally. Apps work offline and sync when connectivity returns.

Transactions and Batched Writes: Firestore supports multi-document ACID transactions. Batched writes execute multiple writes atomically (up to 500 operations).

Querying: Supports filters, ordering, limits, and compound queries. But compound queries require composite indexes to be defined explicitly.

Interview Explanation (60 seconds)

“Firestore is GCP’s document NoSQL database, optimized for mobile and web applications. Its killer feature is real-time synchronization — clients subscribe to documents or queries and receive live updates via onSnapshot. It's fully managed, scales automatically, and provides strong consistency. Compare to MongoDB: both are document databases, but Firestore has better real-time sync, is fully serverless (no cluster management), and has tighter GCP integration. Compare to Firebase Realtime Database: Firestore has richer queries and better structure."

When NOT to Use Firestore

• When you need to do analytics on millions of documents — BigQuery is the right tool
• When your documents regularly exceed 1MB
• When you need complex relational joins — Firestore doesn’t have joins
• When you need high-throughput writes (millions/second) — Bigtable handles that better
• When your workload is primarily batch reads of structured tabular data

AWS/Azure Comparison

GCPAWSAzureFirestoreDynamoDB (most similar) + AppSync (for real-time)Azure Cosmos DB (flexible model)Firebase Realtime DBNot equivalentNot equivalent

Memory Trick: Firestore = “real-time document database for apps.” Mobile/web sync is the differentiator.

3.13 BigQuery

The Problem

Your data science team wants to run SQL queries on 5 billion rows. Traditional databases take hours and require you to provision enormous infrastructure. Hadoop clusters require ops expertise. There had to be a better way.

What It Is

BigQuery is GCP’s fully managed, serverless data warehouse. Run SQL queries on petabytes of data in seconds. No servers to provision, no indexes to define. Pay for what you query.

The Analogy

BigQuery is like an infinitely large spreadsheet that answers queries in seconds regardless of how much data is in it. And you don’t pay for the spreadsheet itself — only for the computation when you query it.

Key Features

Columnar Storage: BigQuery stores data in columns, not rows. A query on 3 of 100 columns only reads those 3 columns. Dramatically reduces I/O and cost for analytics.

Separation of Storage and Compute: Storage (Capacitor format) and compute (Dremel query engine) are separate. You can query data stored in BigQuery, Cloud Storage, Bigtable, Drive, or external sources without copying data.

Serverless Execution: No cluster to provision. BigQuery automatically allocates compute (slots) for your query. A “slot” is a virtual unit of CPU. Free tier: 1,000 concurrent slots.

Partitioning and Clustering:

• Partitioning: Divide tables into segments (by date, integer range, or ingestion time). Queries that filter on the partition column skip irrelevant partitions entirely — reduces cost.
• Clustering: Sort data within partitions by cluster columns. Further reduces bytes read for queries that filter on cluster columns.

BigQuery ML: Train and deploy ML models using SQL — no Python, no external tools. Logistic regression, XGBoost, deep learning via SQL CREATE MODEL syntax.

BigQuery Omni: Query data in AWS S3 or Azure Blob Storage from BigQuery without moving data. Cross-cloud analytics.

Federated Queries: Query Cloud Storage, Bigtable, Drive, or Cloud SQL data from BigQuery without importing it.

Reservations vs. On-Demand:

• On-Demand: Pay $5 per TB of data scanned. No upfront commitment.
• Reservations (Slots): Commit to a number of slots. Predictable cost, better for high-volume users.

Interview Explanation (60 seconds)

“BigQuery is GCP’s serverless data warehouse. You write SQL; BigQuery runs it against petabytes of data in seconds without any cluster management. The key design choices are: columnar storage reduces I/O for analytical queries, and it separates storage from compute so you can scale queries independently. For cost optimization, partition your tables by date and cluster by high-cardinality filter columns — this minimizes bytes scanned. BigQuery is the right choice for analytics, reporting, and ML feature engineering. It’s NOT the right choice for OLTP workloads or sub-second query requirements.”

When NOT to Use BigQuery

• When you need transactional (OLTP) queries — Cloud SQL or Spanner
• When you need sub-second latency — BigQuery queries take seconds minimum
• When you need to update individual rows frequently — BigQuery DML is expensive and slow for row-level updates
• When data is structured for operational queries, not analytics

AWS/Azure Comparison

GCPAWSAzureBigQueryAmazon Redshift / Amazon AthenaAzure Synapse AnalyticsBigQuery OmniAmazon Athena (for cross-account S3)Not fully equivalent

Common Mistakes

1. Not partitioning tables — queries without partition filters scan the entire table (expensive)
2. Using SELECT * — in columnar storage, selecting all columns is expensive. Select only needed columns.
3. Using BigQuery for OLTP — it’s an analytics warehouse, not a transactional database
4. Not setting a maximum bytes billed limit — a single bad query can scan petabytes and generate a large bill
5. Storing normalized relational data — BigQuery is optimized for denormalized, wide tables

Memory Trick: BigQuery = “serverless Redshift.” Petabytes, SQL, seconds, no cluster management.

Pricing Insight: On-demand: 5/TB scanned. Partitioning and clustering can reduce scanned bytes by 2,000/month) become cheaper.

3.14 AlloyDB

What It Is

AlloyDB is a PostgreSQL-compatible database that combines the familiarity of PostgreSQL with Google’s distributed infrastructure. It’s positioned between Cloud SQL (standard managed PostgreSQL) and Spanner (globally distributed NewSQL).

Key Differentiator

AlloyDB separates storage and compute. A columnar engine accelerates analytical queries while maintaining transactional performance. Claims 4x faster than standard PostgreSQL for transactional workloads, 100x faster for analytical queries — without changing your PostgreSQL application code.

When to Use

• PostgreSQL workloads that have outgrown Cloud SQL performance
• Hybrid OLTP + OLAP workloads (operational analytics)
• When you want PostgreSQL compatibility but need higher performance
• Migrations from Oracle or other enterprise databases

Memory Trick: AlloyDB = “PostgreSQL on steroids.” When Cloud SQL PostgreSQL isn’t fast enough.

3.15 Memorystore

What It Is

Memorystore is GCP’s fully managed in-memory cache service for Redis and Memcached.

Redis vs. Memcached on Memorystore:

FeatureRedisMemcachedData structuresStrings, lists, sets, hashes, sorted sets, streamsStrings onlyPersistenceOptional (RDB/AOF)NoneReplicationYes (HA mode)NoCluster modeYesYesUse caseCache + pub/sub + leaderboards + queuesPure cache

When to Use Memorystore:

• Session caching (web applications)
• Database query result caching
• Rate limiting counters
• Real-time leaderboards (Redis sorted sets)
• Pub/Sub between application components (Redis Streams)

Memory Trick: Memorystore = managed Redis. Sub-millisecond access for hot data.

3.16 VPC & Networking

What It Is

A Virtual Private Cloud (VPC) is your isolated network environment in GCP. Resources in your VPC communicate privately. Traffic from the internet is blocked by default.

Key Concepts

VPC is Global (GCP differentiator): In AWS, a VPC is regional. In GCP, a VPC spans all regions. A single VPC can have subnets in US, Europe, and Asia. Resources in different regions can communicate privately without crossing the internet. This simplifies multi-region architectures significantly.

Subnets are Regional: Within a global VPC, subnets are defined per region. VMs in a subnet are in that region (distributed across zones within it).

Private Google Access: Allows VMs without external IP addresses to access Google APIs (Cloud Storage, BigQuery, etc.) without going through the internet. Traffic stays on Google’s network.

VPC Peering: Connect two VPCs so resources can communicate privately. Traffic doesn’t leave Google’s network. No transitive peering (A peers with B, B peers with C, but A cannot reach C).

Shared VPC: A host project shares its VPC with service projects. Centralized network management, distributed application deployment. Common in enterprise setups where networking is managed separately from application teams.

Cloud NAT: Allows VMs without external IPs to initiate outbound internet connections. Your VMs stay private; NAT gateway handles the translation. Google manages the NAT gateway — no single point of failure.

Firewall Rules: Stateful packet filtering at the network level. Rules applied to instances via tags or service accounts (not IP ranges, which is more flexible). Default-deny for inbound, default-allow for outbound.

Interview Explanation (60 seconds)

“GCP’s VPC is global — unlike AWS where VPCs are regional. This means a single VPC spans all regions, and resources communicate privately across regions without additional configuration. Subnets are regional within that global VPC. Firewall rules use tags and service accounts for targeting rather than just IP ranges, which is more flexible. For VMs that need outbound internet access without public IPs, Cloud NAT provides a managed NAT gateway. Private Google Access lets private VMs reach GCP APIs without internet exposure.”

3.17 Load Balancers

GCP Load Balancer Types

TypeLayerScopeUse CaseGlobal External HTTP(S) LBL7GlobalHTTPS web apps, URL-based routingRegional External HTTP(S) LBL7RegionalHTTPS in specific regionSSL Proxy LBL4 (SSL)GlobalNon-HTTP SSL trafficTCP Proxy LBL4 (TCP)GlobalNon-HTTP TCP trafficExternal Network LBL4 (UDP/TCP)RegionalHigh-performance, low-latencyInternal HTTP(S) LBL7RegionalMicroservices, service meshInternal TCP/UDP LBL4RegionalInternal services

Key Decision Points

For public HTTPS web apps → Global External HTTP(S) LB (L7, URL routing, CDN integration, global anycast)

For GKE microservices → Internal HTTP(S) LB or Gateway API

For low-latency gaming/financial → External Network LB (preserves client IP, no proxy overhead)

Cloud CDN

Integrates with Global External HTTP(S) LB. Caches responses at Google’s edge PoPs (130+ globally). Use Cache-Control headers to control what gets cached. Invalidation is explicit (via API/Console).

Cloud DNS

Managed authoritative DNS. Create DNS zones and records. Supports public zones (internet-facing) and private zones (VPC-internal resolution). Integration with GCP resources.

3.18 IAM & Security

The Problem

Who can do what to which GCP resource? In a large organization with hundreds of engineers and dozens of projects, you need a way to grant exactly the right permissions to exactly the right people and services — no more, no less.

GCP IAM Hierarchy

Organization
    └── Folder (optional grouping)
        └── Project
            └── Resource (VM, bucket, database)

IAM bindings can be set at any level. A binding at the organization level applies to all projects. A binding at the project level applies to all resources in that project. Use the principle of least privilege: grant at the narrowest level possible.

IAM Concepts

Identity (Who): A Google Account, a Service Account, a Google Group, a Workspace domain, or allUsers (unauthenticated public access).

Role (What): A collection of permissions. Three types:

• Primitive Roles: Owner, Editor, Viewer — legacy, avoid in production. Too broad.
• Predefined Roles: Google-defined, purpose-specific. E.g., roles/storage.objectViewer — can only read objects. Use these.
• Custom Roles: You define exactly which permissions. For when predefined roles are too broad.

Binding: “Subject X has Role Y on Resource Z.”

Permission: Atomic action — e.g., storage.objects.create. Permissions are bundled into roles.

Service Accounts

A Service Account is an identity for code — not a human. VMs, GKE Pods, Cloud Functions assume service account identities to call GCP APIs.

Best practices:

• One service account per service (not one per project)
• Use Workload Identity for GKE (no key files)
• Avoid downloading service account keys; prefer attached service accounts
• Rotate keys regularly if you must use them

Common IAM Mistakes

1. Using primitive roles (Owner/Editor) in production — way too broad
2. Creating one service account for the entire project
3. Downloading and sharing service account keys in code or git
4. Not using IAM Conditions to limit access by time, IP, or resource tags
5. Not auditing IAM bindings regularly — permissions creep

Memory Trick: IAM = “Who (identity) can do What (role) on Which resource.” Start with predefined roles, grant at narrowest scope.

3.19 Pub/Sub

The Problem

Service A needs to notify Service B when something happens. Direct HTTP calls create tight coupling — if Service B is down, Service A’s call fails. You need a durable message buffer that decouples producers from consumers.

What It Is

Pub/Sub is GCP’s fully managed messaging service. Publishers send messages to a Topic. Subscribers pull messages from Subscriptions (which are attached to topics). Messages are durably stored until acknowledged.

The Analogy

A newspaper publisher (producer) prints newspapers and sends them to distribution centers (subscriptions). Each subscriber receives their own copy. The publisher doesn’t wait for each subscriber to read before printing the next paper.

Key Concepts

Topic: The channel. Publishers publish to topics.

Subscription: A named resource attached to a topic. Each subscription receives all messages published to the topic after the subscription was created.

Pull vs. Push:

• Pull: Subscriber polls Pub/Sub for messages, processes them, and acknowledges. Subscriber controls the rate.
• Push: Pub/Sub pushes messages to an HTTPS endpoint. Use for serverless subscribers (Cloud Run, Cloud Functions).

At-Least-Once Delivery: A message may be delivered more than once. Your subscriber must be idempotent — processing the same message twice must be safe.

Ordering: By default, message order is not guaranteed. Enable ordering keys to guarantee order for messages with the same key.

Dead Letter Topics: Messages that fail to be acknowledged after N delivery attempts are forwarded to a dead letter topic. Prevents bad messages from blocking the queue forever.

Exactly-Once Delivery: Pub/Sub Lite offers exactly-once within a partition, but Pub/Sub standard is at-least-once. Design for idempotency.

Interview Explanation (60 seconds)

“Pub/Sub is GCP’s managed pub/sub messaging service. Publishers post to topics, subscribers consume from subscriptions. Messages are durably stored until acknowledged, decoupling producer from consumer. Delivery is at-least-once — your consumers must be idempotent. For event-driven architectures, a common pattern is: Cloud Functions triggered by Pub/Sub messages, with Cloud Storage events publishing to a Pub/Sub topic for fan-out. For stream processing, Pub/Sub is the ingestion layer that feeds Dataflow.”

When NOT to Use Pub/Sub

• When you need strict ordering and exactly-once semantics — consider Kafka or Pub/Sub with ordering keys
• When you need message replay of historical data — Kafka retains messages longer; Pub/Sub retention is 7 days maximum
• When you need complex routing logic — EventArc or Cloud Tasks may be more appropriate
• When messages are large (>10MB) — put data in Cloud Storage, send the GCS path in the Pub/Sub message

AWS/Azure Comparison

GCPAWSAzurePub/SubSNS (fan-out) + SQS (queuing)Azure Service Bus / Event GridPub/Sub orderingFIFO queues (SQS)Service Bus sessions

Memory Trick: Pub/Sub = “SNS + SQS in one service.” Publish to topics, subscribe at scale, decouple services.

3.20 Dataflow

What It Is

Dataflow is GCP’s fully managed service for stream and batch data processing. Based on Apache Beam, which provides a unified programming model for both streaming and batch pipelines. You write a Beam pipeline; Dataflow runs it on managed infrastructure.

Key Concepts

Unified Batch + Streaming: The same Apache Beam code runs as a batch job or as a streaming job. Change the runner configuration.

Auto-Scaling: Dataflow automatically scales workers based on pipeline backlog and throughput.

Templates: Google provides pre-built Dataflow templates for common patterns: Pub/Sub to BigQuery, GCS to BigQuery, text to Pub/Sub. Use templates for standard ETL without writing code.

Flex Templates: Custom Dataflow jobs packaged as Docker containers. Full customization.

Use Cases:

• Real-time ETL: Pub/Sub → Dataflow → BigQuery
• Stream processing: clickstream analysis, fraud detection, IoT telemetry
• Batch ETL: Transforming GCS files into BigQuery tables

AWS/Azure Comparison

GCPAWSAzureDataflowAWS Kinesis Data Firehose + GlueAzure Stream Analytics

Memory Trick: Dataflow = managed Apache Beam. Stream or batch, unified model.

3.21 Vertex AI & AI Building Blocks

AI Building Blocks (Pre-built APIs)

Google exposes pre-trained models as simple APIs. No ML expertise required.

ServiceWhat It DoesVision APIImage classification, object detection, OCR, face detectionVideo Intelligence APIScene detection, label tracking in videoNatural Language APIEntity extraction, sentiment analysis, syntax analysisSpeech-to-Text APIConvert audio to text, 125+ languagesText-to-Speech APIConvert text to natural speechTranslation APITranslate text, 100+ languagesDocument AIExtract structured data from documents (invoices, forms)

Use these APIs when you need ML functionality without training a model. Google’s training corpus is massive; for general tasks (sentiment analysis, translation), pre-trained models outperform custom models trained on small datasets.

Vertex AI (Managed ML Platform)

For custom model training, deployment, and management.

AutoML: Provide labeled data; Vertex AI trains a custom model without writing ML code. Works for images, text, tabular data, video.

Custom Training: Write your own training code (TensorFlow, PyTorch, scikit-learn); Vertex AI provides the infrastructure.

Model Registry: Version and manage models centrally.

Endpoints: Deploy models for online predictions (real-time inference) or batch predictions.

Vertex AI Pipelines: Orchestrate ML workflows — data preprocessing, training, evaluation, deployment.

Vertex AI Workbench: Managed JupyterLab for data scientists.

Gemini API on Vertex AI: Access Google’s latest large language models (Gemini) via API. Use for text generation, code generation, multimodal tasks.

Interview Explanation (60 seconds)

“GCP’s AI story has two layers: pre-built API services like Vision API and Natural Language API for common tasks without ML expertise, and Vertex AI for custom model development. Vertex AI consolidates what used to be separate products into one platform — AutoML for no-code ML, Custom Training for full control, Model Registry for lifecycle management, and Endpoints for serving. For LLMs, Gemini is accessible via Vertex AI. The key distinction: use pre-built APIs for general tasks, Vertex AI when your use case requires a domain-specific custom model.”

3.22 Cloud Build & Artifact Registry

Cloud Build

GCP’s managed CI/CD service. Define build steps in a YAML file (cloudbuild.yaml). Cloud Build executes steps in Docker containers — each step is a container that runs a command.

Steps can: run tests, build Docker images, push to Artifact Registry, deploy to GKE or Cloud Run, run any script.

Triggers: connect to Cloud Source Repositories, GitHub, Bitbucket — automatically trigger builds on push or pull request.

Artifact Registry

The successor to Container Registry. Store Docker images, Maven packages, npm packages, Python wheels, Helm charts in a single service. Region-scoped for performance and compliance.

Security: integrated with Binary Authorization — only deploy container images that have been attested by your build pipeline.

Memory Trick: Cloud Build = GitHub Actions, but managed on GCP. Artifact Registry = DockerHub, but private and GCP-native.

3.23 Cloud Monitoring & Logging

Cloud Monitoring

Collect and visualize metrics from GCP services, Compute Engine VMs, GKE, and custom applications.

Key Features:

• Dashboards: Visualize metrics over time
• Alerting Policies: Alert when metrics cross thresholds (via email, PagerDuty, Pub/Sub)
• Uptime Checks: Probe your endpoints from multiple locations, alert if they fail
• SLOs (Service Level Objectives): Define and track error rate, latency targets for services

Metrics: GCP services automatically send metrics to Cloud Monitoring. Custom metrics via the Monitoring API or OpenTelemetry.

Cloud Logging

Fully managed log management. Logs from GCP services flow automatically. Custom application logs via the Logging API or structured JSON logs to stdout (picked up automatically in GKE/Cloud Run).

Log-based Metrics: Extract metrics from log entries. Create an alert when “ERROR” appears more than N times per minute.

Log Sinks: Route logs to Cloud Storage (long-term archival), BigQuery (analysis), Pub/Sub (real-time processing). Set retention policies.

Cloud Trace: Distributed tracing. Visualize request flows through microservices. Identify latency bottlenecks.

Interview Explanation (60 seconds)

“GCP’s observability stack is Cloud Monitoring for metrics and alerting, Cloud Logging for log management, and Cloud Trace for distributed tracing. For GKE, you get workload-level metrics automatically. For custom apps, use the OpenTelemetry collector or the GCP client library. The key operational pattern: structured JSON logs to stdout (picked up by Cloud Logging automatically in containerized environments), define SLOs in Cloud Monitoring against your services, and set up alerting policies for your SLO error budget burn rate.”

Part 4: Architecture Thinking — How to Choose the Right Service {#architecture-thinking}

The services are defined. Now: how do you choose?

Decision Framework 1: Compute

What are you deploying?
        |
        ├── VM workload / lift-and-shift / full OS control
        │       └── Compute Engine (IaaS)
        |
        ├── Web app / API, just push code, supported runtime
        │       └── App Engine Standard
        |
        ├── Docker container, HTTP/gRPC, can scale to zero
        │       └── Cloud Run ← Default for new containerized apps
        |
        ├── Event-driven, small function, runs on trigger
        │       └── Cloud Functions (2nd gen)
        |
        └── Multi-container workloads, complex orchestration, stateful apps
                └── GKE Autopilot (or Standard for full node control)

Decision Framework 2: Storage & Database

What type of data?
        |
        ├── Files / blobs / backups / media
        │       └── Cloud Storage
        |
        ├── Relational / SQL / ACID transactions
        │       ├── Small to medium scale → Cloud SQL
        │       ├── High performance PostgreSQL → AlloyDB
        │       └── Global scale / horizontal scaling → Cloud Spanner
        |
        ├── NoSQL — Document (JSON-like, mobile/web app)
        │       └── Firestore
        |
        ├── NoSQL — High throughput, time-series, wide-column
        │       └── Bigtable
        |
        ├── Caching / session / real-time counters
        │       └── Memorystore (Redis)
        |
        └── Analytics / data warehouse / SQL on big data
                └── BigQuery

Decision Framework 3: The Build vs. Managed Trade-off

Every managed service has a cost premium and reduced control. Ask:

1. What is our ops capacity? — If small team, strongly prefer managed
2. What is our scale requirement? — Self-managed is harder to scale
3. What is our cost sensitivity? — Managed is more expensive per unit at large scale
4. What are our compliance requirements? — Some regulations require specific configurations only possible with self-managed

General rule: start managed, move to self-managed only when managed can’t meet a specific requirement (not as a default for control).

Decision Framework 4: Monolith vs. Microservices

Don’t start with microservices. Start with a well-organized monolith.

Keep the monolith when:

• Team is small (<10 engineers)
• Domains are still being discovered
• Deployment complexity is friction without benefit
• Data boundaries are unclear

Move to microservices when:

• Different components need different scaling characteristics
• Independent deployment is truly needed (different release cadences)
• Team boundaries require code ownership separation
• A component needs different technology than the rest

The hidden cost of microservices: distributed transactions, service discovery, network latency, debugging complexity, and operational overhead multiply with every service you add.

Decision Framework 5: SQL vs. NoSQL

Stop framing it as “SQL is old, NoSQL is modern.” Frame it as access patterns.

Access PatternDatabase TypeComplex queries with joinsRelational (Cloud SQL / Spanner)Document storage, flexible schemaDocument (Firestore)High-throughput time seriesWide-column (Bigtable)Key-value cacheIn-memory (Memorystore)Analytics on big dataColumnar (BigQuery)

The question to ask first: What does my application need to do with this data? Not: what shape is the data?

Decision Framework 6: Event-Driven Architecture

Use event-driven patterns when:

• Multiple services need to react to the same event (fan-out)
• Services have different SLAs (decouple them via a queue)
• Reliability requires that work not be lost even if consumer is down

GCP pattern: Cloud Storage / Firestore event → Pub/Sub topic → Cloud Functions or Cloud Run subscriber → BigQuery/other service

Pub/Sub is the backbone. Eventarc standardizes event routing. Dataflow handles stream processing.

Part 5: Visual Reference Tables & Decision Trees {#visual-reference}

GCP Compute Quick Reference

Service. | Ops Burden | Cost Model | Scale to Zero | Best For

Compute Engine. | High | Per-second VM | No | Lift-and-shift, full control

App Engine Standard | Low | Instance-hours | Yes | Web apps, APIs

App Engine Flexible | Medium | Per-second VM | No | Custom runtimes

Cloud Run | Very Low | Per-request | Yes | Containerized HTTP services

Cloud Functions | Very Low | Per-invocation | Yes | Event handlers, glue code

GKE Standard | High | Per node | No | Complex orchestration

GKE Autopilot | Low | Per-pod | Partial | Modern containerized apps

GCP vs. AWS vs. Azure Service Mapping

Category | GCP |AWS |Azure |

Virtual Machines | Compute Engine | EC2 | Virtual Machines

Container Orchestration| GKE| EKS | AKS

Serverless Containers |Cloud Run | App Runner / Fargate |Container Apps Serverless Functions | Cloud Functions | Lambda | Azure Functions

Object Storage |Cloud Storage|S3|Blob Storage

Managed SQL|Cloud SQL|RDS |Azure Database|

Globally Distributed SQL| Cloud Spanner| Aurora Global (limited) | Cosmos DB (different model)

NoSQL Document|Firestore|DynamoDBCosmos DB

Wide-Column NoSQL|BigtableDynamoDB / KeyspacesCosmos DB Table APIData

Warehouse|BigQuery|Redshift / AthenaSynapse Analytics

Messaging|Pub/Sub|SNS + SQS|Service Bus + Event Grid

Stream Processing|Dataflow|Kinesis|Stream Analytics

In-Memory Cache|Memorystore|ElastiCache|Azure Cache for Redis

CDN|Cloud CDN|CloudFront|Azure CDN

IAM|Cloud IAM|AWS IAM|Azure Active Directory

Monitoring|Cloud Monitoring|CloudWatch|Azure Monitor

CI/CD|Cloud Build|CodeBuild|Azure DevOps

Container Registry|Artifact Registry|ECR |Azure Container Registry

ML Platform|Vertex AI|SageMaker| Azure ML

Part 6: Interview Preparation {#interview-prep}

Section A: Concept Questions

Q: What is the difference between Cloud Run and Cloud Functions?

A: Both are serverless, but the unit of deployment differs. Cloud Functions deploys a single function — code that runs in response to a trigger. Cloud Run deploys a container — any web server that handles HTTP/gRPC requests. Cloud Run supports concurrency (multiple requests per instance) and any language/framework via Docker. Cloud Functions is simpler for single-purpose event handlers. Cloud Run (2nd gen) is built on Cloud Run infrastructure, so the lines are blurring — but Cloud Run gives more control over the container runtime environment.

Q: When would you choose Bigtable over Firestore?

A: Access patterns and scale. Bigtable handles petabytes with single-digit ms latency for high-throughput workloads like time-series data, AdTech events, financial market data. Its query model is row-key-based range scans. Firestore is a document database with flexible queries, mobile/web SDKs, and real-time sync — suited for app backends with hundreds of thousands to millions of users. If your access pattern is “give me the last 1000 readings for sensor X,” that’s Bigtable. If it’s “give me all user profiles where status = active,” that’s Firestore.

Q: What is TrueTime and why does Spanner use it?

A: TrueTime is Google’s globally synchronized clock infrastructure using GPS receivers and atomic clocks in data centers. It exposes TT.now() which returns a time interval [earliest, latest] — a bounded uncertainty of typically 1-7ms. Spanner uses TrueTime to assign commit timestamps to transactions. If two transactions have non-overlapping TrueTime intervals, their order is deterministic. This enables external consistency (stronger than serializability) — a globally distributed transaction's commit order matches real-world time. No other commercial database offers this at global scale.

Q: What is the GCP VPC’s global nature and why does it matter?

A: In AWS, a VPC is regional — you need VPC peering or Transit Gateway to connect resources across regions. In GCP, a single VPC spans all regions globally. A subnet in us-central1 and a subnet in europe-west1 can be in the same VPC, and resources communicate privately using GCP’s backbone without peering configuration. This simplifies multi-region architecture: one VPC, one firewall policy, global private connectivity. It’s a meaningful operational simplification for global applications.

Q: Explain the GCP IAM resource hierarchy and where to apply bindings.

A: GCP has a four-level hierarchy: Organization > Folder > Project > Resource. IAM bindings at higher levels are inherited downward. Organization-level binding applies to all projects in the organization. Best practice: apply bindings at the narrowest scope needed. Grant developers access to specific projects, not the organization. Grant a service account access to specific buckets, not all Cloud Storage in the project. Use predefined roles over primitive roles — roles/storage.objectCreator instead of roles/editor.

Q: What is Workload Identity in GKE and why should you use it?

A: Workload Identity is the recommended way to give GKE Pods access to GCP APIs without managing service account key files. It binds a Kubernetes service account to a GCP service account. The GKE metadata server handles credential issuance automatically. Without Workload Identity, you’d need to download a GCP service account key file, store it in a Kubernetes Secret, mount it in the Pod — creating a key management problem. Workload Identity eliminates the key entirely.

Section B: Scenario-Based Questions

Scenario 1: “Design a real-time analytics pipeline for 1 million IoT devices sending telemetry every second.”

Requirements: ingest 1M events/second, process and alert on anomalies, store for 90-day analysis.

Architecture:

1. Ingestion: Devices → Pub/Sub. Pub/Sub handles 1M+ messages/second with zero configuration.
2. Stream Processing: Pub/Sub → Dataflow (Apache Beam pipeline). Apply windowing, filter anomalies, compute aggregates.
3. Alerting: Dataflow → Pub/Sub topic (anomalies) → Cloud Functions → PagerDuty/Slack
4. Storage (hot): Dataflow → Bigtable (query last N readings by device, low latency)
5. Storage (analytical): Dataflow → BigQuery (90-day analysis, SQL queries)

Key design decisions:

• Pub/Sub handles ingest spikes without back-pressure to devices
• Bigtable row key: deviceId#reverseTimestamp for efficient recent-reading queries
• BigQuery for analytics, not operational queries
• Dataflow provides exactly-once semantics for BigQuery inserts

Scenario 2: “A startup wants to build a social media app. What database stack do you recommend?”

Recommendation: Firestore for user profiles, posts, and relationships at MVP stage. Bigtable for activity feeds at scale. BigQuery for analytics.

Reasoning:

• Firestore: flexible document model, real-time sync for notifications, strong consistency, scales automatically without ops. Perfect for MVP.
• At scale (>100M users), activity feed (fan-out) becomes a hot write problem. Use Bigtable for the feed with per-user row keys.
• BigQuery for engagement analytics — daily active users, retention cohorts — that marketing and product teams query.
• Don’t start with Bigtable — Firestore is simpler and sufficient for millions of users.

Scenario 3: “An e-commerce company’s database can’t handle the holiday peak load. What do you recommend?”

Diagnosis: Is it read-heavy or write-heavy?

If read-heavy:

1. Add read replicas to Cloud SQL — distribute read traffic
2. Add Memorystore (Redis) for product catalog and session caching
3. CDN for static content (Cloud CDN)
4. Consider Cloud Spanner for horizontal scaling if Cloud SQL read replicas aren’t sufficient

If write-heavy:

1. Optimize write patterns — batch inserts, remove unnecessary transactions
2. Cloud Spanner for horizontal write scaling if relational model required
3. Queue writes via Pub/Sub + Dataflow for peak shaving (writes queued and processed at steady rate)
4. Bigtable if the write pattern is IoT/event-style (inventory updates as events)

Scenario 4: “Should we migrate from monolith to microservices?”

Questions I’d ask:

1. What specific problem are you trying to solve? (Deployment speed? Scaling? Team autonomy?)
2. How big is the team?
3. Are there natural domain boundaries in the monolith?
4. What’s your ops maturity? (Kubernetes expertise? Observability tooling?)

My recommendation 80% of the time: don’t migrate the monolith, modularize it first. Extract well-defined modules within the monolith. Then, if a module needs independent scaling or different deployment frequency, extract it as a service. Microservices-first is a common expensive mistake.

Section C: Architecture Design Questions

Q: Design a URL shortener on GCP.

Scale: 100M shortened URLs, 1B redirects/day (12K req/sec peak)

Write path: User submits URL → Cloud Run API → generate 6-char short code → write {shortcode: originalURL} to Spanner (globally consistent, handles global writes) → return short URL

Read path (hot path): User hits short URL → Cloud CDN (edge cache, 30-second TTL) → Cloud Run → Memorystore Redis (check cache) → Spanner read → redirect

Why Spanner: Globally distributed, single writer namespace (no short code collision), strong consistency Why Redis: Popular URLs get cached, reduces Spanner load from 12K req/sec to cache misses only Why CDN: Viral short URLs serve from edge, sub-10ms globally

Q: Design a notification system.

Multi-channel notifications (email, SMS, push) for a social app.

Architecture:

• Event source (Firestore trigger, user action) → Pub/Sub notification topic
• Topic fan-out to 3 subscriptions: Email, SMS, Push
• 3 Cloud Run services, one per channel, subscribe via push
• Each service uses channel-specific SDK (SendGrid, Twilio, FCM)
• Dead letter topics for failed notifications
• Retry logic with exponential backoff
• BigQuery for notification analytics (delivery rates, bounce rates)

Key insight: Fan-out from one topic to multiple subscriptions decouples the notification system. Adding a new channel means adding a subscription and a Cloud Run service — no changes to the event source.

Section D: Common Beginner Mistakes

1. *Using SELECT in BigQuery** — in columnar storage, this reads all columns and costs you money proportional to table size
2. No partition key on BigQuery tables — full table scan on every query
3. Sequential primary keys in Spanner — hot spotting on one server
4. Not using Cloud SQL Auth Proxy — exposing Cloud SQL to public internet
5. Using Primitive IAM roles (Owner/Editor) — too permissive, security risk
6. Not setting max-instances on Cloud Run — unexpected scaling and cost
7. Storing large objects (>10MB) in Pub/Sub messages — use GCS + message path
8. Using Firestore for analytics — it’s for operational queries, not data warehouse workloads
9. Running GKE Standard and forgetting to set resource requests/limits — noisy neighbor problem
10. Not enabling VPC-native networking for GKE — makes VPC integration harder

Part 7: Revision Cheatsheet {#cheatsheet}

One-Page Quick Reference

COMPUTE

• Compute Engine = VMs, full control, MIGs for autoscaling, Spot VMs for 91% discount
• App Engine Standard = PaaS, scale-to-zero, push code not container
• Cloud Run = serverless containers, scale-to-zero, default for new containerized apps
• Cloud Functions = event handler, FaaS, runs on trigger
• GKE Autopilot = managed Kubernetes, pay per Pod, recommended default

STORAGE

• Cloud Storage = objects/blobs, 4 tiers (Standard→Archive), signed URLs for temp access
• Persistent Disk = block storage for VMs, SSD/HDD, snapshots for backup
• Filestore = NFS shared filesystem, multi-VM mount

DATABASES

• Cloud SQL = managed MySQL/PostgreSQL/SQL Server, HA via standby, max 64TB
• Spanner = globally distributed SQL, horizontal scaling, TrueTime, $$$$
• AlloyDB = PostgreSQL-compatible, 4x faster than Cloud SQL, columnar engine
• Bigtable = wide-column NoSQL, petabyte scale, ms latency, row key design = everything
• Firestore = document NoSQL, real-time sync, mobile/web apps
• BigQuery = serverless analytics warehouse, SQL on petabytes, columnar, partition+cluster
• Memorystore = managed Redis/Memcached, sub-ms cache

NETWORKING

• VPC = global (GCP differentiator), subnets are regional
• Cloud NAT = outbound internet for private VMs
• Global HTTP(S) LB = L7 load balancer, URL routing, CDN integration
• Cloud CDN = edge caching, reduces origin load
• Cloud DNS = managed DNS, public and private zones

IAM

• Hierarchy: Organization > Folder > Project > Resource
• Use predefined roles, not primitive (Owner/Editor/Viewer)
• Service Accounts = identity for code (not humans)
• Workload Identity = secure GKE-to-GCP auth (no key files)

MESSAGING & DATA

• Pub/Sub = messaging, at-least-once, decouple services
• Dataflow = managed Apache Beam, stream + batch processing
• Cloud Build = CI/CD, YAML build steps
• Artifact Registry = Docker + package registry

AI/ML

• Pre-built APIs: Vision, NLP, Speech, Translation (no ML expertise needed)
• Vertex AI = custom ML platform, AutoML, Model Registry, Endpoints

OBSERVABILITY

• Cloud Monitoring = metrics, dashboards, alerting, SLOs
• Cloud Logging = log management, log-based metrics, sinks to BigQuery/GCS
• Cloud Trace = distributed tracing

Memory Tricks Collection

ServiceMemory TrickCompute Engine”I want a raw VM” = Compute EngineApp Engine”Just push code” = App EngineCloud Run”Serverless container” = Cloud RunCloud Functions”Runs on trigger” = Cloud FunctionsGKE”Managed Kubernetes” = GKECloud Storage”Bucket of files” = Cloud StorageCloud SQL”Managed RDS” = Cloud SQLSpanner”Global SQL scale” = SpannerBigtable”Time-series at petabyte” = BigtableFirestore”Real-time document sync” = FirestoreBigQuery”Serverless Redshift” = BigQueryMemorystore”Managed Redis” = MemorystorePub/Sub”SNS + SQS in one” = Pub/SubDataflow”Managed Apache Beam” = DataflowVertex AI”GCP’s SageMaker” = Vertex AICloud IAM”Who can do what on which resource” = IAM

Interview Quick Reference

Top 5 Architecture Principles for GCP Interviews

1. Default to managed services — start here, escalate to self-managed only when justified
2. Use Cloud Run as the default compute for new containerized apps
3. Partition BigQuery tables, cluster for frequent filter columns
4. Design Bigtable row keys based on access patterns — avoid sequential keys
5. Never use primitive IAM roles in production — use predefined or custom

Top 5 Cost Optimization Tips

1. Use Spot VMs for fault-tolerant batch jobs (up to 91% discount)
2. Use Committed Use Discounts for steady-state VM workloads (up to 57%)
3. Set BigQuery max bytes billed limit to avoid runaway query costs
4. Configure Cloud Storage lifecycle policies to auto-tier old data
5. Right-size Cloud SQL instances — use Query Insights to find slow queries