Google ACE Practice Question: A team wants to automatically restart any GKE Pod…

Answer analysis

Option-by-option breakdown

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

• ✗

  readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3

  Why it's wrong here

  A readinessProbe controls whether a pod receives traffic by adding or removing it from Service endpoints, but it does not initiate a container restart. If the /healthz check fails, the pod is simply marked NotReady and its IP is removed from the load-balancing set, leaving the container running and possibly in a stuck state. Therefore, even with the same httpGet, delay, period, and threshold values, this probe would not satisfy the requirement to restart the container.

• ✓

  livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3

  Why this is correct

  This is the correct configuration because a livenessProbe is the Kubernetes mechanism that determines whether a container is still healthy after it has started. The httpGet hits /healthz on port 8080 after a 30-second initial delay, then every 10 seconds; when the probe fails three consecutive times, the kubelet kills the container and restarts it according to the pod's restartPolicy. That exactly matches the requirement to restart a container that is running but has become unhealthy.

• ✗

  startupProbe: httpGet: path: /healthz port: 8080 failureThreshold: 3

  Why it's wrong here

  A startupProbe is evaluated only during the initial startup phase, not continuously throughout the container's lifetime. Its purpose is to delay liveness and readiness probes for slow-starting applications; once it succeeds, it is disabled. While a failing startupProbe could trigger a restart, it would catch problems that occur before the app is ready, not the later unresponsiveness described in the scenario. Using it here would misclassify the failure and not provide ongoing health checks.

• ✗

  lifecycle: postStart: httpGet: path: /healthz port: 8080

  Why it's wrong here

  A postStart lifecycle hook executes exactly once, immediately after the container is created, to perform an initialization action. An HTTP GET to /healthz at that single moment cannot provide continuous health monitoring, and even if the request fails, Kubernetes does not restart the container based on a lifecycle hook result. This option is therefore unrelated to detecting an unresponsive application during runtime.

Go deeper

Related to this question