Liveness and readiness probes are two of the most commonly confused concepts on the Professional Cloud Architect exam. They sound similar, they both report health, and they both involve Kubernetes checking on your workloads. But they answer two completely different questions, and getting the distinction right matters for both the exam and for running anything real on GKE.
A liveness probe answers one question: is this container still working, or is it stuck? Kubernetes runs the check on a schedule. If the check fails enough times in a row, Kubernetes restarts the container. Notice the scope here. Liveness operates at the container level, not the Pod level. A Pod can have multiple containers, and each one can have its own liveness probe. When a liveness check fails, only that specific container restarts. The rest of the Pod keeps running.
The classic use case is a process that has gone into a deadlock or a tight loop. The container is technically alive from the operating system's perspective, but the application inside is not making progress. A health endpoint that returns 200 when the request loop is healthy will catch this, and the restart gives you a clean recovery without any human intervention.
A readiness probe answers a different question: is this Pod ready to serve traffic right now? When a readiness check fails, Kubernetes does not restart anything. It just removes the Pod from the service endpoints, so the load balancer stops sending requests to it. Once the Pod passes its readiness check again, it gets added back to the rotation.
Readiness operates at the Pod level. A Pod is either in the service or it is not. The most common scenarios are slow startup (an application that needs thirty seconds to load a model or warm a cache) and temporary unavailability (a database connection pool that is being recycled). In both cases, restarting the container would make the situation worse. You just want traffic paused until the Pod is genuinely ready.
The Professional Cloud Architect exam likes scenarios where you have to pick the right tool. If a candidate says the application takes a long time to start and you do not want users hitting it during startup, the answer is a readiness probe. If the candidate says the application occasionally deadlocks and needs to be restarted to recover, the answer is a liveness probe. If both conditions apply, you configure both probes on the same container.
A trap I see in practice and on the exam is using a liveness probe when a readiness probe is what you actually want. If you set a liveness probe with a short timeout on an application that takes a while to start up, Kubernetes will keep killing and restarting the container before it ever finishes initializing. The Pod ends up in a CrashLoopBackOff state for a reason that has nothing to do with the application being broken. The fix is either a readiness probe instead, or a liveness probe with a generous initialDelaySeconds that gives the container time to start before the liveness check kicks in.
Both probes are configured per container, in the Pod spec. Here is what a typical container with both probes looks like.
spec:
containers:
- name: web
image: gcr.io/my-project/web:1.0
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
The two endpoints typically do different work. /healthz returns 200 as long as the process is alive and the request handler is responsive. /ready returns 200 only when the application has finished initializing and all of its dependencies (database, cache, downstream services) are reachable. Splitting them this way means a transient downstream outage takes the Pod out of the load balancer without restarting the container, which is what you want.
Probes also support tcpSocket and exec styles for cases where an HTTP endpoint does not make sense. The exam usually focuses on the HTTP variant because that is what most workloads use.
The Professional Cloud Architect exam occasionally references startup probes, which were added to handle the slow-start case more cleanly. A startup probe runs first, and liveness and readiness probes are suspended until the startup probe passes. This lets you set aggressive liveness timeouts for steady-state operation without worrying about the initial boot time. If you see a question about a legacy application that takes several minutes to initialize, the right answer often involves a startup probe rather than padding initialDelaySeconds on a liveness probe.
My Professional Cloud Architect course covers liveness and readiness probes alongside the rest of the containers and serverless material.
