25 GCP Cloud Interview Questions Asked in Real DevOps Interviews (2026)

1. What GCP services have you worked with and what did you build?
2. Explain GKE Autopilot vs Standard mode
3. How does Pub/Sub work and when do you use it?
4. How do you manage IAM in GCP?
5. How does Cloud SQL High Availability work?
6. How do you optimize GCP costs?
7. What are the GCP Load Balancer types?
8. How do you implement VPC networking for a production cluster?
9. What is Cloud Armor and how do you use it?
10. How does BigQuery work and when do you use it?
11. What is GCS versioning and lifecycle management?
12. How do you set up Cloud Build CI/CD pipeline?
13. What is Private Service Connect?
14. How do you handle database migration in Cloud SQL?
15. What is Memorystore for Redis?
16. How do you manage multiple GCP projects?
17. What is OS Patch Management in GCP?
18. How do you implement disaster recovery in GCP?
19. What is Billing Export and how do you analyze costs?
20. What is Security Command Center (SCC)?
21. What is a Private GKE Cluster and why use it?
22. Cloud Run vs GKE — when to use which?
23. How do you handle a flash sale with 10–20x traffic spike?
24. How do you connect GCP and AWS (cross-cloud networking)?
25. How would you design multi-region HA for a platform?

Q1. What GCP services have you worked with and what did you build?

This is the most common opening question. Structure your answer by category:

COMPUTE:
  GKE (Autopilot + Standard) → microservices platform
  Cloud Run                  → serverless event handlers
  Compute Engine             → legacy workloads, bastion hosts
DATA:
  Cloud SQL (PostgreSQL)     → relational databases
  BigQuery                   → analytics, data warehouse
  Pub/Sub                    → event-driven messaging
  Cloud Storage (GCS)        → object storage, backups
NETWORKING:
  VPC (Private + Public)     → network isolation
  Cloud Load Balancer        → traffic distribution
  Cloud NAT                  → private cluster internet access
  Cloud DNS                  → domain management
  Cloud Armor                → WAF, DDoS protection
CI/CD:
  Cloud Build                → CI/CD pipelines
  Artifact Registry          → Docker image storage
  Cloud Source Repos          → Git repository
MONITORING:
  Cloud Monitoring           → dashboards, alerts
  Cloud Logging              → centralized logs
  Cloud Trace                → distributed tracing
  Cloud Profiler             → code-level profiling
SECURITY:
  IAM                        → access control
  Secret Manager             → secrets storage
  Security Command Center    → vulnerability scanning
  Workload Identity          → pod-level GCP access

Interview tip: Don’t just list services. For each, mention a real use case and one challenge you solved.

Q2. Explain GKE Autopilot vs Standard mode

GKE Standard          │  GKE Autopilot
  ──────────────────────────────────────────┼──────────────────────
  Node management   YOU manage             │  Google manages
  Node pools        YOU configure          │  Automatic
  Scaling nodes     Cluster Autoscaler     │  Automatic
  OS patching       YOUR responsibility    │  Google handles
  Security config   YOU harden nodes       │  Google hardens
  Pricing           Pay per node (VM)      │  Pay per pod resources
  Best for          Full control needed    │  Reduce ops overhead
  Limitations       None                   │  No privileged pods,
                                           │  no host access,
                                           │  no DaemonSets (mostly)

When to use each:

AUTOPILOT:
  ✓ Small team, want to focus on apps
  ✓ Don't need node-level customization
  ✓ Want Google to handle security patching
  ✓ Cost-optimized (pay for what you use)
STANDARD:
  ✓ Need DaemonSets or privileged pods
  ✓ Need custom node images or GPU nodes
  ✓ Need direct node access for debugging
  ✓ Interviewer specifically asks about node management

Q3. How does Pub/Sub work and when do you use it?

Pub/Sub = Fully managed asynchronous messaging service
ARCHITECTURE:
  ┌──────────┐     ┌─────────┐     ┌──────────────┐
  │ Publisher │ ──→ │  TOPIC  │ ──→ │ Subscription │ ──→ Consumer
  │ (sender)  │     │         │     │              │
  └──────────┘     │         │     └──────────────┘
                    │         │     ┌──────────────┐
                    │         │ ──→ │ Subscription │ ──→ Consumer
                    └─────────┘     └──────────────┘
KEY CONCEPTS:
  Topic:        Message channel (like a radio station)
  Subscription: Consumer's mailbox (like a radio receiver)
  Ack:          Consumer confirms processing
  Ack Deadline: Time before message is redelivered (default 10s)

Common patterns:

FAN-OUT: 1 topic → multiple subscriptions
  Order placed → notify inventory, billing, shipping
  Each gets the same message independently

LOAD BALANCING: 1 subscription → multiple consumers
  Messages distributed across consumer pods
  Each message processed by ONE consumer only
DEAD LETTER QUEUE (DLQ):
  Message fails 5 times → auto-sent to DLQ topic
  DLQ topic → manual investigation, replay
  subscription:
    deadLetterPolicy:
      deadLetterTopic: projects/my-project/topics/my-dlq
      maxDeliveryAttempts: 5

Pub/Sub gotcha — uneven consumption:

Problem: 10 consumer pods but only 3 get messages
Cause: gRPC streaming holds connection to same pod

Fix: Use Pub/Sub Lite or adjust streamingPull settings
  maxOutstandingMessages: 100  (per pod)
  flowControl: balanced distribution

Q4. How do you manage IAM in GCP?

IAM HIERARCHY:

Organization
    └── Folder (team/department)
        └── Project
            └── Resources (GKE, Cloud SQL, etc.)
Permissions flow DOWN (inheritance):
  Org-level admin → has access to ALL projects
  Project-level viewer → only sees that project
MEMBERS:
  User:           person@company.com
  Group:          team-devops@company.com (recommended)
  Service Account: sa@project.iam.gserviceaccount.com
BEST PRACTICES:
  1. Use GROUPS, not individual users
  2. Principle of least privilege
  3. Use predefined roles (not primitive: owner/editor/viewer)
  4. Audit with Policy Analyzer
  5. Rotate service account keys (or don't use keys → use Workload Identity)

Workload Identity (GKE best practice):

PROBLEM:
  Pod needs to access Cloud SQL, GCS, Pub/Sub
  OLD way: mount service account key as Secret ← RISKY
BETTER:
  Workload Identity: K8s ServiceAccount → GCP ServiceAccount
  K8s SA: my-app-sa (in namespace)
     ↓ (IAM binding)
  GCP SA: my-app@project.iam.gserviceaccount.com
     ↓ (IAM roles)
  Access: Cloud SQL Client, Pub/Sub Subscriber
  No keys! Pod auto-authenticates to GCP.

Q5. How does Cloud SQL High Availability work?

Cloud SQL HA Architecture:
┌─────────────────────┐     ┌─────────────────────┐
  │  PRIMARY (Zone-A)  │     │  STANDBY (Zone-B)    │
  │  ┌──────────────┐   │     │  ┌──────────────┐   │
  │  │  PostgreSQL  │   │ ──→ │  │  PostgreSQL  │   │
  │  │  Read+Write  │   │sync │  │  (standby)   │   │
  │  └──────────────┘   │     │  └──────────────┘   │
  │  ┌──────────────┐   │     │  ┌──────────────┐   │
  │  │  Persistent  │   │     │  │  Persistent  │   │
  │  │  Disk        │   │     │  │  Disk        │   │
  │  └──────────────┘   │     │  └──────────────┘   │
  └─────────────────────┘     └─────────────────────┘
  Primary fails → automatic failover to Standby
  Same IP address → apps reconnect automatically
  ~60 second failover time
Read Replicas (for read scaling):
  Primary → Read Replica 1 (same region)
          → Read Replica 2 (another region)
  App sends writes to Primary, reads to replicas

Maintenance best practices:

Maintenance window:
  Schedule during low-traffic hours
  Enable "planned maintenance notification"
Backup:
  Automated daily backups (retained 7 days)
  Point-in-time recovery (PITR)
  On-demand backup before major changes
Connection:
  Cloud SQL Auth Proxy (recommended)
  Private IP (VPC peering)
  Never use public IP in production

Q6. How do you optimize GCP costs?

TOP 5 COST OPTIMIZATION STRATEGIES:
1. RIGHT-SIZE RESOURCES
   Cloud Monitoring → Recommender
   "This VM uses 15% CPU → downsize from n2-standard-8 to n2-standard-4"
   Savings: 40-60%
2. COMMITTED USE DISCOUNTS (CUD)
   1-year commitment → 37% discount
   3-year commitment → 55% discount
   Best for: stable baseline workloads
3. PREEMPTIBLE/SPOT VMs
   Up to 80% cheaper
   Can be terminated anytime (24h max)
   Best for: batch processing, CI/CD runners
4. AUTOSCALING
   GKE HPA: scale pods with traffic
   Cluster Autoscaler: scale nodes to fit pods
   Cloud SQL: stop dev instances on weekends
5. STORAGE LIFECYCLE
   GCS lifecycle rules:
     Standard → Nearline (30 days) → Coldline (90 days) → Archive
   BigQuery: partition tables, set expiration
   Delete unused snapshots and old images

Budget alerts:

Billing → Budgets & Alerts:
  Monthly budget: $5,000
  Alert at: 50%, 80%, 100%
  Notification: Email + Pub/Sub
Pub/Sub → Cloud Function → auto-action:
  At 80%: notify Slack
  At 100%: disable non-critical services

Q7. What are the GCP Load Balancer types?

┌──────────────────────┬─────────────┬──────────────┬─────────────┐
│ Load Balancer        │ Layer       │ Scope        │ Use Case    │
├──────────────────────┼─────────────┼──────────────┼─────────────┤
│ External HTTP(S)     │ L7 (HTTP)   │ Global       │ Web apps    │
│ External TCP/UDP     │ L4 (TCP)    │ Regional     │ TCP services│
│ External TCP Proxy   │ L4 (TCP)    │ Global       │ TCP global  │
│ External SSL Proxy   │ L4 (SSL)    │ Global       │ SSL offload │
│ Internal HTTP(S)     │ L7 (HTTP)   │ Regional     │ Internal APIs│
│ Internal TCP/UDP     │ L4 (TCP)    │ Regional     │ Internal TCP│
└──────────────────────┴─────────────┴──────────────┴─────────────┘
Most common for GKE:
  External HTTP(S) LB → Ingress for public APIs
  Internal HTTP(S) LB → Internal Ingress for service-to-service
GKE creates LB automatically when you create:
  Service type: LoadBalancer → TCP/UDP Network LB
  Ingress resource → HTTP(S) LB (GCE Ingress Controller)

Q8. How do you implement VPC networking for a production cluster?

VPC DESIGN:
  ┌──────────────────────────────────────────────────┐
  │ VPC: production-vpc                               │
  │                                                   │
  │ ┌───────────────────────────────────────────────┐ │
  │ │ Private Subnet: 10.0.0.0/20                   │ │
  │ │   GKE nodes (no public IPs)                   │ │
  │ │   Cloud SQL (private IP)                      │ │
  │ │   Redis (Memorystore)                         │ │
  │ └───────────────────────────────────────────────┘ │
  │                                                   │
  │ ┌───────────────────────────────────────────────┐ │
  │ │ GKE Secondary Ranges:                         │ │
  │ │   Pod range:     10.4.0.0/14                  │ │
  │ │   Service range: 10.8.0.0/20                  │ │
  │ └───────────────────────────────────────────────┘ │
  │                                                   │
  │ Cloud NAT → Internet access for private nodes     │
  │ Cloud Armor → WAF for external traffic            │
  │ Private Google Access → GCP API without internet  │
  └──────────────────────────────────────────────────┘
KEY RULES:
  1. Private nodes (no public IPs)
  2. Cloud NAT for outbound internet
  3. Private Google Access for GCP APIs
  4. VPC-native cluster (alias IPs)
  5. Firewall rules: deny all, allow specific

Q9. What is Cloud Armor and how do you use it?

Cloud Armor = WAF + DDoS protection for HTTP(S) Load Balancer
Security policies:
  1. IP Allowlist/Denylist
     rule: deny IP 203.0.113.0/24 (block known attackers)
  2. Rate Limiting
     rule: limit 100 requests/min per IP
     action: throttle or deny
  3. WAF Rules (OWASP Top 10)
     SQL injection protection
     XSS (Cross-Site Scripting) protection
     Remote code execution protection
  4. Geographic Restriction
     rule: allow only from JP, US
     action: deny all other countries
  5. Bot Management
     Adaptive Protection (ML-based)
     Detect and block DDoS attacks automatically
Apply to Load Balancer:
  gcloud compute backend-services update my-backend \
    --security-policy=my-armor-policy

Q10. How does BigQuery work and when do you use it?

BigQuery = Serverless data warehouse for analytics
Architecture:
  Data sources → BigQuery (store) → SQL queries → Dashboards
Key features:
  - Serverless (no infrastructure to manage)
  - Handles petabytes of data
  - SQL interface
  - Pay per query (bytes scanned)
  - Columnar storage (fast aggregations)
Use cases:
  - Analytics dashboards
  - Log analysis (Cloud Logging sink → BigQuery)
  - Business intelligence
  - Machine learning (BigQuery ML)
Cost optimization:
  1. Partition tables by date
     → Queries scan only relevant partitions
  2. Cluster by frequently filtered columns
  3. Use column selection (avoid SELECT *)
  4. Set table expiration for temporary data
  5. Use flat-rate pricing for predictable workloads

Q11. What is GCS versioning and lifecycle management?

VERSIONING:
  When enabled, GCS keeps ALL versions of an object
  Delete a file → previous version still exists
  Overwrite a file → both versions stored

Enable: gsutil versioning set on gs://my-bucket
  Use case: Accidental deletion recovery
LIFECYCLE RULES:
  Automatically transition or delete objects
  rules:
    - action: SetStorageClass (Nearline)
      condition: age > 30 days
    - action: SetStorageClass (Coldline)
      condition: age > 90 days
    - action: Delete
      condition: age > 365 days
  Storage classes & pricing:
    Standard  → frequently accessed ($0.020/GB)
    Nearline  → once a month ($0.010/GB)
    Coldline  → once a quarter ($0.004/GB)
    Archive   → once a year ($0.0012/GB)

Q12. How do you set up Cloud Build CI/CD pipeline?

CLOUD BUILD PIPELINE:
cloudbuild.yaml:
  steps:
    # Step 1: Run tests
    - name: 'maven:3.9-eclipse-temurin-17'
      args: ['mvn', 'test']
    # Step 2: Build JAR
    - name: 'maven:3.9-eclipse-temurin-17'
      args: ['mvn', 'package', '-DskipTests']
    # Step 3: Build Docker image
    - name: 'gcr.io/cloud-builders/docker'
      args: ['build', '-t',
        '${_REGION}-docker.pkg.dev/${PROJECT_ID}/${_REPO}/${_IMAGE}:${SHORT_SHA}',
        '.']
    # Step 4: Push to Artifact Registry
    - name: 'gcr.io/cloud-builders/docker'
      args: ['push',
        '${_REGION}-docker.pkg.dev/${PROJECT_ID}/${_REPO}/${_IMAGE}:${SHORT_SHA}']
    # Step 5: Deploy to GKE
    - name: 'gcr.io/cloud-builders/gke-deploy'
      args:
        - run
        - --filename=k8s/
        - --image=${_REGION}-docker.pkg.dev/${PROJECT_ID}/${_REPO}/${_IMAGE}:${SHORT_SHA}
        - --cluster=${_CLUSTER}
        - --location=${_REGION}
Triggers:
  Push to main → deploy to staging
  Tag (v*) → deploy to production
  PR → run tests only

Q13. What is Private Service Connect?

Private Service Connect = private connection to Google APIs
without using public internet

BEFORE (public):
  Pod → Cloud NAT → Internet → pubsub.googleapis.com
  Traffic goes over public internet ← SLOW, LESS SECURE
AFTER (PSC):
  Pod → VPC → PSC endpoint → pubsub.googleapis.com
  Traffic stays within Google's network ← FAST, SECURE
Setup:
  1. Create PSC endpoint in your VPC
  2. DNS resolves Google APIs to PSC endpoint IP
  3. Traffic routes privately to Google services
Use cases:
  - Private GKE cluster accessing GCP APIs
  - Compliance (no internet exposure)
  - Better latency (internal network)
  - Works with: Pub/Sub, BigQuery, Cloud SQL, etc.

Q14. How do you handle database migration in Cloud SQL?

3 APPROACHES:
1. DATABASE MIGRATION SERVICE (DMS)
   Source: on-prem MySQL/PostgreSQL
   Target: Cloud SQL
   Method: Continuous replication
   Downtime: Minutes (final cutover only)
2. pg_dump / pg_restore
   pg_dump -h old-host -d mydb > backup.sql
   psql -h cloud-sql-ip -d mydb < backup.sql
   Downtime: depends on database size
3. IMPORT FROM GCS
   pg_dump → upload to GCS bucket → Cloud SQL import
   gcloud sql import sql my-instance \
     gs://bucket/backup.sql --database=mydb
SCHEMA MIGRATION (ongoing):
  Tools: Flyway, Liquibase
  Version control for database schema
  Applied in CI/CD pipeline before app deployment

Q15. What is Memorystore for Redis?

Memorystore = Fully managed Redis on GCP
Use cases:
  - Session caching (user login state)
  - API response caching
  - Rate limiting
  - Pub/Sub (short-lived messaging)
  - Leaderboards (sorted sets)
Architecture:
  App Pod → (private IP) → Memorystore Redis
Standard tier:
  Single instance, no HA
  Good for: caching (data can be rebuilt)
High availability tier:
  Primary + Replica (cross-zone)
  Automatic failover (<1 minute)
  Good for: session storage, critical caching
Connection from GKE:
  Same VPC (private IP)
  No Cloud SQL Auth Proxy needed
  Connect directly: redis://10.0.0.X:6379

Q16. How do you manage multiple GCP projects?

PROJECT STRUCTURE:
Organization: company.com
    ├── Folder: Production
    │   ├── Project: prod-api
    │   ├── Project: prod-data
    │   └── Project: prod-shared-vpc
    ├── Folder: Staging
    │   ├── Project: staging-api
    │   └── Project: staging-data
    └── Folder: Development
        └── Project: dev-sandbox
SHARED VPC:
  Host project: shared-vpc
    → Contains VPC, subnets, firewall rules
  Service projects: prod-api, prod-data
    → Use subnets from host project
    → Network managed centrally
Benefits:
  1. Billing isolation per project
  2. IAM isolation (dev team can't touch prod)
  3. Resource quotas per project
  4. Centralized networking (Shared VPC)
  5. Organization policies (enforce security)

Q17. What is OS Patch Management in GCP?

VM Manager (OS Config) → Automated OS patching
Setup:
  1. Enable VM Manager on project
  2. Install OS Config agent on VMs
  3. Create patch deployment:
  gcloud compute os-config patch-deployments create weekly-patch \
    --instance-filter-names=zone/us-central1-a/instance-name \
    --patch-config='{"apt":{"type":"DIST"}}' \
    --recurring-schedule-frequency=WEEKLY \
    --recurring-schedule-day-of-week=SATURDAY \
    --recurring-schedule-time-of-day='02:00' \
    --recurring-schedule-time-zone='UTC'
Patch compliance dashboard:
  VM Manager → shows which VMs are patched/unpatched
  Report: CVEs fixed, pending patches
For GKE:
  Standard: node auto-upgrade handles OS patches
  Autopilot: Google manages everything

Q18. How do you implement disaster recovery in GCP?

DR STRATEGIES (by recovery time):
┌────────────────┬─────────┬─────────┬───────────────────┐
│ Strategy       │ RTO     │ RPO     │ Cost              │
├────────────────┼─────────┼─────────┼───────────────────┤
│ Backup/Restore │ Hours   │ Hours   │ $ (lowest)        │
│ Pilot Light    │ Minutes │ Minutes │ $$                │
│ Warm Standby   │ Minutes │ Seconds │ $$$               │
│ Hot Standby    │ Seconds │ Zero    │ $$$$ (highest)    │
└────────────────┴─────────┴─────────┴───────────────────┘
RTO = Recovery Time Objective (how fast to recover)
RPO = Recovery Point Objective (how much data can you lose)
GCP Implementation:
  Multi-region GKE: clusters in 2+ regions
  Cloud SQL: cross-region read replica → promote on failure
  GCS: multi-region bucket (automatic replication)
  Cloud DNS: health-check based routing (failover)
  Pub/Sub: global service (no DR needed)

Q19. What is Billing Export and how do you analyze costs?

BILLING EXPORT TO BIGQUERY:
Billing → Billing Export → Enable BigQuery export
  Creates: billing_dataset.gcp_billing_export
  Query example (top spending services):
  SELECT
    service.description,
    SUM(cost) as total_cost
  FROM billing_dataset.gcp_billing_export
  WHERE invoice.month = '202606'
  GROUP BY service.description
  ORDER BY total_cost DESC
  Output:
  ┌────────────────────┬────────────┐
  │ Service            │ Cost ($)   │
  ├────────────────────┼────────────┤
  │ Compute Engine     │ 3,200      │
  │ Cloud SQL          │ 1,800      │
  │ BigQuery           │ 950        │
  │ Cloud Storage      │ 450        │
  └────────────────────┴────────────┘
  Dashboard: Looker Studio connected to BigQuery
  Alerts: Budget notification at 50%, 80%, 100%

Q20. What is Security Command Center (SCC)?

SCC = GCP's security management and risk platform
Features:
  1. VULNERABILITY SCANNING
     Finds: open firewall rules, public buckets, unpatched VMs
     Auto-detects misconfigurations
  2. THREAT DETECTION
     Event Threat Detection: suspicious IAM activity
     Container Threat Detection: suspicious container behavior
     Web Security Scanner: OWASP vulnerability scanning
  3. COMPLIANCE
     CIS benchmark compliance
     PCI DSS, HIPAA compliance checks
     Export findings to SIEM
  4. ASSET INVENTORY
     All GCP resources in one view
     Track changes over time
     Find unused resources (cost savings)
Tiers:
  Standard: basic vulnerability scanning (free)
  Premium: full threat detection, compliance ($$$)
Integration:
  SCC findings → Pub/Sub → Slack notifications
  SCC findings → BigQuery → compliance dashboards

Q21. What is a Private GKE Cluster and why use it?

Private GKE cluster = nodes have ONLY internal (private) IPs
Internet
                    │
         ┌──────── LB ─────────┐
         │    (Public IP)       │
         ▼                      │
  ┌──────────────────┐         │
  │ GKE Control Plane│         │
  │ (Google Managed) │         │
  │ Private Endpoint │         │
  └────────┬─────────┘         │
           │ Private Network    │
  ┌────────▼─────────┐         │
  │ Private Node     │         │
  │ (No Public IP)   │         │
  │ 10.0.2.5         │         │
  │ ┌─────┐ ┌─────┐ │         │
  │ │Pod 1│ │Pod 2│ │         │
  │ └─────┘ └─────┘ │         │
  └────────┬─────────┘         │
  ┌────────▼─────────┐         │
  │ Cloud NAT        │─────────┘
  │ (outbound only)  │
  └──────────────────┘
Why use it:
  Security:    Nodes not exposed to internet
  Compliance:  Regulations require private infrastructure
  Control:     All traffic flows through defined paths
  Data:        Sensitive data stays within private network
Key components:
  Master Authorized Networks → who can access API server
  Cloud NAT → outbound internet for private nodes
  Private Google Access → GCP APIs without internet

Q22. Cloud Run vs GKE — when to use which?

Cloud Run          │  GKE
  ─────────────────────────────────────┼──────────────────────
  Management     Fully serverless    │  Manage cluster/nodes
  Scaling        0 to N (scale to 0!)│  1 to N (min 1 node)
  Cost           Pay per request     │  Pay for running nodes
  Complexity     Very simple         │  Complex but flexible
  Networking     Auto URL            │  Full VPC control
  Stateful       No                  │  Yes (StatefulSets)
  Use case       Simple APIs,        │  Complex microservices,
                 webhooks, async     │  stateful apps

Decision:
  Simple stateless service → Cloud Run (cheaper, simpler)
  Complex microservice platform → GKE (more control)
  Need scale to zero → Cloud Run
  Need service mesh, DaemonSets → GKE

Q23. How do you handle a flash sale with 10–20x traffic spike?

BEFORE (1-2 weeks):
  ✓ Load test with expected traffic
  ✓ Pre-scale GKE nodes and pod replicas
  ✓ Add database read replicas
  ✓ Warm CDN cache
  ✓ Enable Cloud Armor rate limiting
  ✓ Freeze non-critical deployments

DURING:
  ✓ War room monitoring (dashboards, error rates, latency)
  ✓ React: scale consumers if queues build up
  ✓ Circuit break non-critical services if needed
  ✓ Communicate: status page updated
AFTER:
  ✓ Scale down nodes and replicas
  ✓ Remove extra read replicas
  ✓ Post-mortem: what worked, what didn't
  ✓ Document and automate for next time

Q24. How do you connect GCP and AWS (cross-cloud networking)?

OPTION 1: Cloud VPN (~$50/month, up to 3 Gbps)
  ┌──────────┐    IPSec Tunnel    ┌──────────┐
  │ GCP VPC  │ ══════════════════ │ AWS VPC  │
  └──────────┘                    └──────────┘
  Good for: dev/test, low bandwidth needs

OPTION 2: Dedicated Interconnect ($1000+/month, 10-100 Gbps)
  ┌──────────┐    Physical Link   ┌──────────┐
  │ GCP VPC  │ ══════════════════ │ AWS VPC  │
  └──────────┘                    └──────────┘
  Good for: production, high bandwidth, low latency
Key considerations:
  1. Non-overlapping CIDR ranges (GCP 10.0.x.x, AWS 172.16.x.x)
  2. DNS resolution between clouds
  3. Private IPs only (no internet exposure)
  4. Monitor VPN tunnel status and latency
  5. Firewall rules on both sides

Q25. How would you design multi-region HA for a platform?

Users
    │
  ┌─────────────────────┐
  │ Cloud CDN + Armor   │  ← cache + WAF
  └─────────────────────┘
    │
  ┌─────────────────────┐
  │ Global HTTP(S) LB   │  ← routes to nearest healthy region
  └─────────────────────┘
    │                │
┌─────────┐    ┌─────────┐
│Region 1 │    │Region 2 │
│(Primary)│    │(DR/Scale)│
│ GKE     │    │ GKE     │
│Cloud SQL│──→ │Cloud SQL│  (cross-region replica)
│ Redis   │    │ Redis   │
└─────────┘    └─────────┘

Design principles:
  1. Stateless services (shared-nothing)
  2. Cross-region database replication
  3. Redis cache in each region (independent)
  4. CDN at the edge (static content)
  5. Automatic failover via health-check routing
  6. DNS-based traffic steering (latency-based)

Quick Reference

ServiceOne-LinerGKEManaged Kubernetes (Standard or Autopilot)Cloud SQLManaged PostgreSQL/MySQL with HAPub/SubAsync messaging (topic → subscription → consumer)BigQueryServerless data warehouse (SQL, pay-per-query)Cloud StorageObject storage with lifecycle managementIAMWho can do what on which resourceWorkload IdentityK8s pod → GCP service account (no keys)Cloud ArmorWAF + DDoS protectionCloud BuildCI/CD pipeline (build, test, deploy)Secret ManagerSecure secret storage with versioningCloud NATInternet access for private instancesSCCSecurity scanning and compliance

This article is part of my “Real DevOps Interview Questions” series. Follow me for more GCP, Kubernetes, and SRE content.