Google ACE Practice Question: A GKE Deployment is running 3 replicas and…

A GKE Deployment is running 3 replicas and receiving steady traffic. A junior engineer runs `kubectl scale deployment api-service --replicas=0` to 'stop it temporarily'. What happens to traffic during and after this command?

⚠ Common exam trap

Google Cloud often tests the misconception that Kubernetes Services can queue or buffer traffic during scaling events, when in reality they are stateless and rely on real-time endpoint availability.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

All Pods are terminated immediately; the Service has no backends and requests fail until replicas are restored

When you scale a Deployment to 0 replicas, `kubectl` immediately terminates all Pods. The associated Kubernetes Service continues to exist but has no healthy endpoints, so any traffic directed to the Service’s ClusterIP or external load balancer will be dropped or result in a connection refusal (TCP RST) or HTTP 503. Traffic is not queued or buffered; it simply fails until new Pods are created by scaling the Deployment back up.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Traffic is paused and queued by the Service until replicas are restored
Why it's wrong here
Kubernetes Services do not buffer or queue network traffic; they act as a stable virtual IP backed by a set of healthy endpoints. When `scaled to 0` removes all Pods, the Service's endpoint slices become empty, so kube-proxy has no forwarding targets. New connections to the Service ClusterIP are rejected with connection refused errors or time out, and any underlying load balancer health checks begin failing until healthy backends exist again.
✓
All Pods are terminated immediately; the Service has no backends and requests fail until replicas are restored
Why this is correct
Running `kubectl scale deployment --replicas=0` directly patches the Deployment's `.spec.replicas` to 0, which signals the ReplicaSet controller to terminate every Pod immediately. The corresponding EndpointSlice objects are updated to have no ready addresses, leaving the Service with zero backends and causing all client requests to fail until the replicas are restored. Reapplying `kubectl scale --replicas=3` recreates Pods, repopulates endpoints, and resumes normal traffic.
✗
GKE detects the replica count is 0 and automatically restores it to maintain high availability
Why it's wrong here
GKE does not override explicit scaling commands because the Deployment's desired state is exactly what the user set. The Deployment controller continuously reconciles the actual number of replicas to match the `.spec.replicas` field; when that field is 0, all Pods are deleted and remain deleted. GKE's self-healing only maintains the declared replica count, so it will not resurrect Pods unless the desired count is increased again.
✗
The Deployment is paused but Pods continue running until the next rollout
Why it's wrong here
Stopping a Deployment by scaling to 0 is not the same as pausing a rollout; `scale --replicas=0` forces an immediate reconciliation to delete all running Pods, not a freeze of the current state. `kubectl rollout pause` only prevents new rollout steps from advancing, but existing Pods from the current ReplicaSet continue running normally. A paused Deployment with a non-zero replica count will keep its Pods alive, whereas scaling to zero terminates them.

Go deeper

Google ACE Practice Question: A GKE Deployment is running 3 replicas and…

Why each option matters

Option-by-option breakdown

Related to this question