GKE in practice

One of the roles in scope runs primarily on GKE with legacy AWS components alongside. Kubernetes fundamentals are in ../17_kubernetes/; this is what is specific to Google’s managed offering.

Autopilot or Standard

The first question, and the one with a real answer.

Autopilot is the sensible default now, and the reason to articulate is operational: node upgrades, autoscaling and security hardening stop being your problem. You give up privileged DaemonSets, which rules out some observability and security agents — check that before committing.

The billing difference bites in both directions. Autopilot charges for what pods request, so over-requested resources cost real money and right-sizing requests becomes a direct cost lever. Standard charges for nodes, so poor bin-packing wastes capacity you already paid for.

Workload Identity

The GKE-specific answer to “how does a pod authenticate to cloud services”, and the thing to get right.

A Kubernetes service account is bound to an IAM principal, so pods obtain short-lived Google credentials automatically. No service account key files, no secrets to rotate, no long-lived credentials in a Kubernetes Secret.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api
  annotations:
    iam.gke.io/gcp-service-account: api@my-project.iam.gserviceaccount.com

Mounting a downloaded service-account JSON key into a pod is the anti-pattern this replaces, and it is worth naming explicitly — a leaked key file is a long-lived credential with no expiry. This is the same argument as IRSA on EKS and managed identity on AKS; recognising it as one pattern across clouds is the senior framing. See ../19_cloud_aws/Security_Identity_and_Compliance/02_AWS_Identity_and_Access_Management/.

Networking

VPC-native clusters (alias IP ranges) are the default: pods get real VPC IPs, so they are routable and firewall rules apply to them directly. Plan the pod and service CIDR ranges before creating the cluster — they cannot be changed afterwards, and an undersized pod range caps how far the cluster can scale.

Ingress. GKE Ingress provisions Google Cloud Load Balancers. New work should use the Gateway API, which is GA and is the successor to Ingress across Kubernetes generally — GKE has a mature implementation. It separates infrastructure concerns (the platform team owns the Gateway) from routing (app teams own HTTPRoutes), which is exactly the split multi-team clusters need. See ../17_kubernetes/.

Private clusters put nodes on internal IPs only, with an authorised-networks allow-list for the control plane and Cloud NAT for egress. Standard for anything handling sensitive data.

Autoscaling

Three layers, and confusing them is a common interview slip:

HPA and VPA conflict on the same metric — VPA raising requests changes the CPU utilisation ratio HPA is targeting. Use VPA in recommendation mode alongside HPA rather than both actively adjusting.

Custom and external metrics matter for real workloads: scaling a Celery worker deployment on Pub/Sub queue depth is correct; scaling it on CPU is not, because a worker waiting on I/O shows low CPU while fully saturated.

Cost control

The predictable cost conversation, and specifics land better than generalities:

• Spot VMs for interruptible work — batch, CI, stateless services with enough replicas. Large discount, with preemption you must design for.
• Right-size requests, especially on Autopilot where requests are the bill. VPA recommendations are the input.
• Committed use discounts for baseline capacity.
• Watch egress and cross-zone traffic. A service accidentally spread across zones, or chatty cross-zone calls, produce a data-transfer line nobody expects — the same trap as AWS cross-AZ charges.
• Scale to zero for dev and staging environments outside working hours.

The rest of the GCP stack you will meet

Cloud Run versus GKE is a live question: Cloud Run for a stateless HTTP service that should scale to zero with no cluster to operate; GKE when you need long-running processes, sidecars, DaemonSets, non-HTTP protocols, or you already run a platform. “We use Kubernetes because it’s Kubernetes” is not an answer.

Running on GCP and AWS together

The realistic situation in that role: primary on GCP, legacy components on AWS.

• Identity is the hard part. Workload Identity Federation lets a GCP workload assume an AWS role (and the reverse) without long-lived keys. Do this rather than storing AWS access keys in a Kubernetes Secret.
• Watch egress between clouds. Cross-cloud traffic is billed on both sides and adds latency; keep chatty interactions inside one cloud and move only the data that must cross.
• Terraform or OpenTofu across both, with separate state per environment. One IaC tool over two providers is the main argument for not using CloudFormation or Deployment Manager. See ../18_iac/.
• Decide the direction of travel. Multi-cloud as a permanent strategy costs real money in duplicated expertise and egress; multi-cloud as a migration state is fine. Ask which one you are in.

Interview angle

• “Autopilot or Standard GKE?” - Autopilot by default: node management, upgrades and hardening stop being your problem and you pay per pod request. Standard when you need GPUs, privileged DaemonSets, custom kernels, or tight bin-packing control.
• “How does a pod authenticate to Google Cloud services?” - Workload Identity: bind the Kubernetes service account to an IAM principal so pods get short-lived credentials automatically. Mounting a service-account key file is the anti-pattern - a long-lived credential with no expiry.
• “HPA, VPA or cluster autoscaler?” - HPA scales replicas, VPA adjusts requests, the cluster autoscaler adds nodes for unschedulable pods. HPA and VPA fight over the same metric, so run VPA in recommendation mode alongside HPA.
• “Ingress or Gateway API?” - Gateway API for new work. It is GA and is the successor to Ingress, and it separates the platform team’s Gateway from the app teams’ routes, which is what multi-tenant clusters need.
• “Cloud Run or GKE?” - Cloud Run for stateless HTTP that should scale to zero with no cluster to operate; GKE for long-running workloads, sidecars, non-HTTP protocols, or when a platform already exists. Running a cluster for one stateless service is cost and operational burden with no return.
• “How do you run across GCP and AWS?” - Workload Identity Federation for cross-cloud auth without static keys, one IaC tool over both, and a deliberate answer about egress, because cross-cloud chatter is billed on both sides.