Question 1

What is GKE and what does it manage for you?

Accepted Answer

GKE is Google's managed Kubernetes service. Google runs and secures the control plane — the API server, scheduler, controller manager and etcd — handles its availability and upgrades, and provides deep integration with GCP networking, IAM, logging, monitoring and load balancing. You supply workloads and, in Standard mode, manage the worker nodes. The credibility marker is knowing that Kubernetes originated at Google from the Borg system, and that GKE is generally the reference implementation — new Kubernetes versions land on GKE early. Mentioning that the control plane is not billed per-node but as a flat cluster management fee is a useful detail.

Question 2

What is the difference between GKE Autopilot and GKE Standard?

Accepted Answer

In Standard mode you choose, size, scale and patch node pools, and you pay for the nodes whether or not pods use them. In Autopilot, Google provisions and manages nodes entirely; you specify pod-level CPU, memory and storage requests and are billed for those requested resources. Autopilot enforces security and configuration best practices, which also means it restricts privileged operations. The decision rule to state: Autopilot for most application teams, because it removes node management and bin-packing entirely; Standard when you need something Autopilot forbids — privileged containers, custom node OS or kernel settings, certain DaemonSets, specific GPU or sole-tenant configurations. Naming a concrete Autopilot restriction is what proves you have used it.

Question 3

What is a node pool?

Accepted Answer

A node pool is a group of nodes in a cluster that share the same configuration — machine type, disk, image, labels, taints and autoscaling settings. A cluster can have several pools, which is how you run mixed workloads: a general pool on E2, a GPU pool for inference, and a Spot pool for batch, each with taints so only the right pods land there. The pattern to describe is taints and tolerations plus node selectors or node affinity: taint the expensive GPU pool so ordinary pods cannot schedule onto it, and give GPU pods a matching toleration. Without taints, a Spot or GPU pool will fill with unrelated workloads.

Question 4

What is the difference between a zonal, regional and multi-zonal GKE cluster?

Accepted Answer

A zonal cluster has a single control-plane replica in one zone and nodes in that zone — cheapest, but the control plane is a single point of failure and is unavailable during upgrades. A multi-zonal cluster has a single-zone control plane but nodes across several zones. A regional cluster replicates the control plane across three zones and spreads nodes across them, so both the API and the workloads survive a zone failure. The production answer is regional for anything that matters, and the reason is specific: with a zonal cluster, a control-plane upgrade or zone incident means you cannot deploy, scale or self-heal, even though existing pods keep running. Also note that a regional cluster creates the specified node count *per zone*, which surprises people on their first bill.

Question 5

What is a private GKE cluster?

Accepted Answer

A private cluster gives nodes internal IP addresses only, so they have no direct inbound or outbound internet exposure. The control plane is reachable over a private endpoint through VPC peering, and you can optionally restrict or disable the public control-plane endpoint. Nodes reach the internet through Cloud NAT for pulling images and updates. The two operational consequences to name: you must configure authorised networks or use a bastion/IAP tunnel to run kubectl, and without Cloud NAT your pods cannot pull from public registries — the classic "ImagePullBackOff on a brand new private cluster" symptom. Artifact Registry with Private Google Access is the cleaner fix for images.

Question 6

Explain the GKE networking model — how do pods get IP addresses?

Accepted Answer

GKE uses VPC-native (alias IP) clusters, where pods and services get real IP addresses from secondary ranges on the VPC subnet rather than from an overlay. That means pods are routable inside the VPC, firewall rules and VPC flow logs apply to pod traffic directly, and there is no encapsulation overhead. Each node is allocated a slice of the pod range, defaulting to a /24 supporting up to 110 pods. The planning trap this leads to: the pod secondary range must be sized for maximum nodes multiplied by pods per node, and it cannot be expanded easily after cluster creation. Undersizing it caps how far the cluster can ever scale, which is a genuinely painful mistake — hence questions like "how many nodes can this cluster grow to?"

Question 7

What is the difference between a Kubernetes Service of type ClusterIP, NodePort and LoadBalancer on GKE?

Accepted Answer

ClusterIP exposes the service on an internal virtual IP reachable only inside the cluster. NodePort opens the same service on a static port on every node. LoadBalancer provisions a real GCP load balancer — a regional passthrough Network Load Balancer by default — and points it at the service. On GKE, an Ingress or Gateway resource instead provisions a global Application Load Balancer. The GKE-specific detail that scores: container-native load balancing with Network Endpoint Groups sends traffic directly to pod IPs rather than hopping through a node and kube-proxy, which removes a network hop, gives accurate health checking and improves latency. That is the answer to "how does GKE load balancing differ from vanilla Kubernetes?"

Question 8

What is container-native load balancing and why does it matter?

Accepted Answer

Container-native load balancing uses Network Endpoint Groups (NEGs) so the GCP load balancer targets pod IPs directly instead of node IPs. It removes the extra kube-proxy hop and the second round of load balancing inside the node, gives the load balancer real pod-level health checks, and preserves the client source IP correctly. The measurable benefits are lower latency and even traffic distribution — without NEGs, traffic is balanced across nodes first and then across pods on each node, which distributes unevenly when pods per node vary. It is the default for VPC-native clusters using Ingress, and it is what makes GKE Ingress meaningfully better than a generic implementation.

Question 9

What is Workload Identity and why should you use it?

Accepted Answer

Workload Identity lets a Kubernetes service account impersonate a Google service account, so pods obtain short-lived GCP credentials automatically without any exported key file. You bind the KSA to the GSA with an IAM policy and annotate the KSA; the GKE metadata server then issues tokens scoped to that identity. It replaces the two bad alternatives: mounting a service-account JSON key as a secret, and giving the node's service account broad permissions so every pod on the node inherits them. Workload Identity also blocks pod access to the node metadata endpoint, which closes the SSRF-to-node-credentials attack path. This is the single most likely GKE security question you will be asked.

Question 10

What is the Horizontal Pod Autoscaler and how does it differ from the Cluster Autoscaler?

Accepted Answer

The Horizontal Pod Autoscaler changes the number of pod replicas in a Deployment based on CPU, memory or a custom or external metric. The Cluster Autoscaler changes the number of *nodes* in a node pool when pods cannot be scheduled for lack of capacity, or when nodes are underutilised. They work together: HPA adds pods, and if there is nowhere to put them the Cluster Autoscaler adds nodes. The dependency people miss is that HPA on CPU only works if pods declare CPU *requests* — without requests there is no utilisation percentage to compute and the HPA reports unknown. That is the most common reason "my HPA is not scaling".

Question 11

What is the Vertical Pod Autoscaler and can you use it with HPA?

Accepted Answer

VPA adjusts the CPU and memory requests and limits of pods based on observed usage, either recommending values or applying them by evicting and recreating pods. Using VPA and HPA together on the same metric is not supported, because they would fight — VPA raising requests while HPA scales on utilisation of those requests. VPA in recommendation mode alongside HPA on a custom metric is a workable combination. The practical value of VPA is in recommendation mode: it tells you how badly your requests are mis-set, which is usually the single biggest source of wasted spend in a cluster. Autopilot uses request values for billing, so accurate requests translate directly into money.

Question 12

What are resource requests and limits, and what happens when a pod exceeds each?

Accepted Answer

A request is the guaranteed amount the scheduler reserves when placing the pod; a limit is the ceiling enforced at runtime. Exceeding a CPU limit causes throttling — the container is slowed, not killed. Exceeding a memory limit causes the container to be OOM-killed and restarted, because memory is incompressible. That asymmetry between CPU and memory is the heart of the question. The follow-up is usually QoS classes: Guaranteed when requests equal limits, Burstable when requests are lower than limits, and BestEffort when neither is set — and eviction under node pressure happens in reverse order, BestEffort first.

Question 13

A pod is stuck in Pending. How do you diagnose it?

Accepted Answer

Run kubectl describe pod and read the Events. The usual causes are insufficient CPU or memory on any node, a node selector, affinity rule or taint that no node satisfies, a PersistentVolumeClaim that cannot be bound, or a pod-range exhaustion in a VPC-native cluster. If the Cluster Autoscaler is enabled, check its events to see why it did or did not add a node. The interviewer is checking whether you go to Events first rather than guessing. The autoscaler-specific detail that impresses: it will not add a node if the pod could never fit on the largest node in any pool, and it logs exactly that, which turns a mystery into a two-minute fix.

Question 14

A pod keeps restarting with CrashLoopBackOff. What do you check?

Accepted Answer

Look at the previous container's logs with kubectl logs --previous, then kubectl describe pod for the exit code and reason. Exit code 137 means OOM-killed, so the memory limit is too low or there is a leak. Other common causes are a failing liveness probe with too short an initial delay, a missing config map or secret, a bad image entrypoint, or a dependency the app cannot reach at startup. Naming exit code 137 and the liveness-probe initialDelaySeconds mistake specifically is what makes this answer read as real operational experience rather than a checklist. Startup probes exist precisely to solve the slow-starting-app case without weakening the liveness probe.

Question 15

What is the difference between a liveness, readiness and startup probe?

Accepted Answer

A liveness probe determines whether the container is still healthy — failing it restarts the container. A readiness probe determines whether the container can serve traffic — failing it removes the pod from Service endpoints without restarting it. A startup probe protects slow-starting applications by disabling the other two until it succeeds once. The dangerous misconfiguration to call out: pointing a liveness probe at a dependency such as a database. When the database blips, every replica fails liveness and restarts simultaneously, turning a partial outage into a total one. Liveness should test only the process itself; readiness is where dependency checks belong.

Question 16

What is a PodDisruptionBudget and why does it matter on GKE?

Accepted Answer

A PDB declares the minimum number or percentage of pods that must remain available during voluntary disruptions — node upgrades, autoscaler scale-down, node draining. GKE respects PDBs during automated maintenance, so without one an upgrade can evict all replicas of a service at once. The counterpart failure is a PDB that is too strict — for example minAvailable equal to the replica count — which blocks node drains entirely and stalls a cluster upgrade indefinitely. Interviewers love this because it shows the same mechanism can cause both an outage and a stuck upgrade.

Question 17

How do GKE cluster upgrades work?

Accepted Answer

The control plane is upgraded by Google, automatically on a release channel or manually within the supported version skew. Node pools are upgraded separately using a surge upgrade strategy — new nodes are created, workloads are drained onto them respecting PDBs and graceful termination, and old nodes are removed — or with a blue-green strategy that keeps the old pool until you validate and then cuts over. The release channels are the detail to name: Rapid, Regular and Stable, trading freshness against soak time. Maintenance windows and exclusions let you keep upgrades away from a sale event or quarter end. "We are on Regular with a maintenance window and exclusions around peak periods" is a production-sounding answer.

Question 18

What is a GKE release channel?

Accepted Answer

A release channel controls which Kubernetes versions your cluster automatically receives. Rapid gets the newest versions soonest with the least soak time, Regular is the balanced default with a few months of validation, and Stable prioritises reliability with the longest soak. Enrolling in a channel means Google handles version selection and upgrade timing within your maintenance window. The advice to give: use Regular for production and run a Rapid cluster in a staging environment to catch deprecations early. Also mention that staying on a static version eventually forces an unplanned upgrade when the version leaves support, which is worse than a scheduled one.

Question 19

What is the GKE Gateway API and how does it compare with Ingress?

Accepted Answer

Gateway API is the successor to Ingress, splitting responsibilities across GatewayClass, Gateway and HTTPRoute resources so that platform teams own the infrastructure while application teams own routing. It supports richer traffic management — header-based routing, traffic splitting for canaries, multiple protocols — without the vendor-specific annotations that Ingress required. The reason it exists is that Ingress could only express its features through annotations, which destroyed portability. On GKE, the multi-cluster Gateway is the compelling capability: one global load balancer routing across clusters in several regions, which Ingress could not do cleanly.

Question 20

What is a StatefulSet and when do you need one on GKE?

Accepted Answer

A StatefulSet provides stable, ordered pod identities (app-0, app-1), stable per-pod persistent storage through volumeClaimTemplates, and ordered rolling updates and scaling. You need it for workloads where identity and storage must survive rescheduling — databases, Kafka, Zookeeper, Elasticsearch. The honest senior answer adds a caveat: running a stateful database on Kubernetes means you own backup, failover, upgrades and disaster recovery. On GCP, Cloud SQL, AlloyDB, Spanner or Memorystore usually beat a self-managed StatefulSet unless there is a specific reason. Interviewers respect a candidate who recommends *not* running it on Kubernetes.

Question 21

What is a DaemonSet and give a GKE example?

Accepted Answer

A DaemonSet runs exactly one copy of a pod on every node (or every node matching a selector), and automatically places one on any new node that joins. Typical examples are log collectors, node-level monitoring agents, CNI plugins and security agents. GKE runs several of its own as system DaemonSets, such as the logging and metrics agents. The Autopilot constraint is worth naming: Autopilot restricts custom DaemonSets and privileged access, so a third-party security agent that requires host-level access may be the concrete reason a team has to use Standard mode.

Question 22

How do you store secrets securely in GKE?

Accepted Answer

Kubernetes Secrets are only base64-encoded in etcd by default, so the strong options are: enable Application-layer Secrets Encryption so etcd contents are encrypted with a Cloud KMS key; or, better, keep secrets in Secret Manager and pull them at runtime using Workload Identity, optionally through the Secret Manager CSI driver which mounts them as files. The base64 point is the one interviewers test — candidates who describe Secrets as "encrypted" are wrong. The architectural argument for Secret Manager is rotation and audit: you get versioning, IAM-level access control and audit logs, none of which a raw Kubernetes Secret provides.

Question 23

What is a namespace and how do you enforce limits per namespace?

Accepted Answer

A namespace is a logical partition of cluster resources used to separate teams or environments. You enforce boundaries with a ResourceQuota, which caps total CPU, memory, storage and object counts in the namespace, and a LimitRange, which sets default and maximum per-container requests and limits so pods without explicit values do not consume unbounded resources. The pairing matters: a ResourceQuota that requires requests, combined with a LimitRange that supplies defaults, is what stops a team deploying pods with no requests at all. Namespaces alone provide no security isolation — that needs NetworkPolicy and RBAC on top.

Question 24

What is a NetworkPolicy and is it enabled by default on GKE?

Accepted Answer

A NetworkPolicy restricts which pods can talk to which, by pod selector, namespace and port. It is not enforced by default — GKE clusters allow all pod-to-pod traffic until you enable network policy enforcement, either with Calico or by using GKE Dataplane V2, which is eBPF-based and enforces policy natively. The behaviour to explain carefully: policies are additive and default-deny only applies once a pod is selected by at least one policy. So the standard hardening pattern is to apply a default-deny-ingress policy per namespace first, then explicitly allow the flows you need.

Question 25

What is GKE Dataplane V2?

Accepted Answer

Dataplane V2 replaces kube-proxy and iptables with an eBPF-based dataplane built on Cilium. It gives more scalable service routing, native NetworkPolicy enforcement, and network policy logging that shows exactly which flows were allowed or denied — visibility that Calico-based enforcement did not provide. The scaling reason is worth stating: iptables rule evaluation degrades as service count grows into the thousands, whereas eBPF maps look up in constant time. The policy-logging capability is usually what sells it to a security team.

Question 26

What is Binary Authorization?

Accepted Answer

Binary Authorization is a deploy-time policy control that only allows container images to run if they carry the required cryptographic attestations — for example proof that they were built by your trusted CI system and passed a vulnerability scan. It enforces at admission, so an unattested image is rejected before it ever schedules. The supply-chain framing is what interviewers want: it prevents an engineer from deploying an image built on a laptop, and it prevents a compromised registry entry from running. Pair it with Artifact Registry vulnerability scanning and a break-glass exemption process, because you will eventually need to deploy urgently.

Question 27

How do you run cost-efficient batch workloads on GKE?

Accepted Answer

Use a dedicated Spot node pool with a taint, size it with cluster autoscaling from zero, and give batch pods the matching toleration plus a low PriorityClass so they are preempted before serving workloads. Make jobs checkpoint and be restartable, and use the Kubernetes Job or the GKE-integrated Batch service for orchestration. Scaling a node pool to zero minimum is the specific lever that makes this cheap, and it only works if the pool is dedicated and tainted. Adding "and I would use PriorityClass and preemption so batch never starves the serving tier" turns a cost answer into a reliability answer as well.

Question 28

What is the difference between a Deployment, a ReplicaSet and a Pod?

Accepted Answer

A Pod is the smallest deployable unit, one or more containers sharing a network namespace and storage. A ReplicaSet ensures a specified number of identical pods are running. A Deployment manages ReplicaSets to give you declarative rolling updates and rollbacks — it creates a new ReplicaSet for each revision and shifts replicas between them. The insight that makes this a good answer is why the layer exists: the Deployment holds the *history*, which is what makes kubectl rollout undo possible. You almost never create a ReplicaSet directly; you let the Deployment own it.

Question 29

How does a rolling update work and how do you control it?

Accepted Answer

A Deployment rolling update creates pods in a new ReplicaSet while scaling down the old one, governed by maxSurge (how many extra pods above the desired count may exist) and maxUnavailable (how many may be missing). Readiness probes gate progress — a new pod does not count as available until it is ready — and progressDeadlineSeconds fails the rollout if it stalls. The zero-downtime configuration to name is maxUnavailable: 0 with maxSurge: 1 or higher, which guarantees full capacity throughout at the cost of temporarily needing extra headroom. Without a correct readiness probe, a rolling update happily replaces healthy pods with broken ones.

Question 30

What is Config Connector?

Accepted Answer

Config Connector is a GKE add-on that lets you manage GCP resources — buckets, Cloud SQL instances, Pub/Sub topics, IAM bindings — as Kubernetes custom resources. Applying a YAML manifest creates the GCP resource, and the controller continuously reconciles drift back to the declared state. The reason it appeals is continuous reconciliation, which plain Terraform does not give you unless you run it on a schedule. The trade-off is that your cluster becomes a dependency for provisioning infrastructure, which is a circular-dependency risk worth acknowledging.

Question 31

What is Anthos Service Mesh and when is a service mesh worth the complexity?

Accepted Answer

Anthos Service Mesh is Google's managed Istio distribution, providing mutual TLS between services, fine-grained traffic management such as canaries and fault injection, and consistent telemetry, all through sidecar proxies. It is worth the complexity when you have enough services that per-service implementations of retries, mTLS and observability have become inconsistent — typically tens of services and multiple teams. The honest part of this answer is the cost: sidecars add latency, memory overhead per pod, and a substantial operational learning curve. For a handful of services, a mesh is a net negative, and saying so is a stronger signal than enthusiasm.

Question 32

How do you handle persistent storage in GKE?

Accepted Answer

Through PersistentVolumeClaims bound to a StorageClass. The GCE Persistent Disk CSI driver provisions zonal or regional persistent disks dynamically; Filestore CSI provisions NFS shares for ReadWriteMany access; and Cloud Storage FUSE CSI mounts buckets for read-heavy object access. Standard persistent disks are ReadWriteOnce, so only one node can mount them read-write. The ReadWriteOnce constraint is the one that catches people: if several pods across nodes need shared read-write storage, a persistent disk cannot do it and you need Filestore. Also worth naming: a zonal PD pins the pod to a zone, which quietly defeats a regional cluster's availability story.

Question 33

What is node auto-provisioning?

Accepted Answer

Node auto-provisioning extends the Cluster Autoscaler by creating entirely new node pools with appropriate machine types when pending pods do not fit any existing pool — for example a pod requesting a GPU or a very large memory shape. It removes the need to pre-create a pool for every possible workload profile. The control you must apply is resource limits at the cluster level, otherwise an accidental pod requesting 400 vCPU will happily provision a very expensive node. Bounding total CPU, memory and accelerator counts is the guardrail interviewers want to hear about.

Question 34

How do you monitor a GKE cluster?

Accepted Answer

GKE integrates with Cloud Monitoring and Cloud Logging out of the box: system and workload metrics, container logs and control-plane logs flow automatically. Google Cloud Managed Service for Prometheus collects Prometheus-format application metrics at scale without you running Prometheus servers, and you build SLOs and alerting policies in Cloud Monitoring on top. The specific signals to say you alert on: pod restart rate, pending pods, node not-ready, memory working set against limits, and error-budget burn on latency and availability SLOs. Alerting on raw CPU alone is the answer of someone who has not been on call.

Question 35

What are the main GKE cost drivers and how do you reduce them?

Accepted Answer

Cost is driven by node capacity you pay for but do not use, the cluster management fee, load balancers, and egress. Reduce it by right-sizing requests using VPA recommendations, enabling cluster autoscaling with sensible minimums, using Spot pools for fault-tolerant work, consolidating small clusters, applying committed use discounts to the baseline, and considering Autopilot so you pay for pod requests instead of node capacity. The insight to lead with is that in Standard mode you pay for *nodes*, not pods, so unused headroom is pure waste and bin-packing efficiency is the main lever. GKE cost allocation, which breaks cost down by namespace and label, is the tool to name for making that visible.

Question 36

What is the difference between GKE and Cloud Run for a containerised service?

Accepted Answer

Cloud Run runs a stateless container with no cluster to manage, scales to zero, and bills per request-second — ideal for HTTP and event-driven services. GKE gives you full Kubernetes: sidecars, DaemonSets, custom controllers, StatefulSets, fine-grained scheduling and any protocol. GKE costs more operationally and has no scale-to-zero at the node level unless you engineer it. The good answer names the specific thing that forces GKE — a service mesh, a stateful workload, a long-running background process, GPU pinning, or an operator-based ecosystem component. Otherwise Cloud Run is the lower-cost, lower-risk default, and saying so is not a weakness.

Question 37

How do you implement a canary deployment on GKE?

Accepted Answer

Simplest is two Deployments behind one Service with replica counts controlling the split, though that ties traffic share to pod count. Better is Gateway API HTTPRoute weighting, or a service mesh with traffic-splitting rules, which decouple traffic percentage from replica count and allow header-based routing so you can canary to internal users first. Automate promotion and rollback on SLO metrics. The mature part is the promotion criterion: a canary is worthless without an automated signal — error rate and latency compared against the stable version — and an automatic rollback. Naming a tool like Cloud Deploy or a progressive-delivery controller shows you have run this rather than just read about it.

Question 38

What happens when a node fails in GKE?

Accepted Answer

The node controller marks the node NotReady after it stops heartbeating, and after a toleration period the pods on it are marked for deletion and rescheduled onto healthy nodes if their controller allows it. Node auto-repair, if enabled, recreates the failed node. Pods with zonal persistent disks in a failed zone cannot reschedule until the disk is available in a live zone. The eviction delay — five minutes by default from the default tolerations — is the number interviewers probe, because it explains why a "instant failover" expectation is wrong. The zonal-disk caveat is the second half that shows you have thought about stateful workloads.

Question 39

What is a GKE maintenance window and a maintenance exclusion?

Accepted Answer

A maintenance window restricts automatic control-plane and node upgrades to a recurring time range you choose. A maintenance exclusion blocks automatic maintenance entirely for a defined period — typically a peak trading window, a sale or a code freeze — with limits on how long you may exclude minor-version upgrades. The nuance worth adding: exclusions have maximum durations that vary by scope, so you cannot postpone upgrades indefinitely, and a cluster left behind will eventually be force-upgraded when its version leaves support. Planning upgrades is therefore not optional.

Question 40

Design a production-grade GKE platform for 30 microservices across three environments. What do you specify?

Accepted Answer

Separate projects per environment with a Shared VPC; regional private Autopilot clusters (or Standard with regional node pools) on the Regular release channel with maintenance windows; VPC-native networking with pod ranges sized for the target scale; Workload Identity for all GCP access; a default-deny NetworkPolicy baseline with Dataplane V2; namespaces per service with ResourceQuotas and LimitRanges; Gateway API for ingress with Cloud Armor; Artifact Registry with vulnerability scanning plus Binary Authorization; GitOps-based delivery with Cloud Deploy or Config Sync; and SLO-based alerting on Cloud Monitoring with Managed Prometheus. This is the standard closing architecture question. The signal is not the list — it is the ordering and the reasons. Naming the pod-range sizing decision and the Shared VPC up front shows you know which choices are irreversible, which is exactly what a senior interviewer is testing.

Google Kubernetes Engine (GKE) Interview Questions and Answers

How to use this set