CKAD Application Observability and Maintenance Practice Question
You are a platform engineer at a company that runs a microservices architecture on Kubernetes. The application consists of a frontend service (Node.js), a backend API (Go), and a PostgreSQL database. All components are deployed in the same namespace 'production'. Recently, the backend API has been experiencing intermittent 503 errors from the frontend. The backend API Pods have CPU limits set to 500m and memory limits to 256Mi. The backend API exposes metrics at /metrics and has a liveness probe (HTTP GET /healthz) and a readiness probe (HTTP GET /ready). You notice that during traffic spikes, the backend API Pods are restarted frequently. You examine the metrics and see that memory usage spikes to 250Mi during high load. What is the most likely cause of the restarts and 503 errors?
⚠ Common exam trap
It's easy for candidates to confuse CPU throttling (which causes slowness and timeouts) with OOM kills (which cause restarts), and they may overlook that memory limits are a hard cap enforced by the kernel, while CPU limits are a soft cap enforced by the scheduler.
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
✓
The memory limit is set too low; the container is being OOMKilled during traffic spikes.
The backend API Pods are being restarted frequently because the memory limit of 256Mi is too close to the observed memory usage of 250Mi during traffic spikes. When memory usage hits the limit, the Linux kernel's OOM killer terminates the container (OOMKilled), causing the Pod to restart. This restart leads to temporary unavailability, which the frontend sees as 503 errors.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The liveness probe is misconfigured and should use a TCP check instead.
Why it's wrong here
A liveness probe only determines whether to restart the container based on HTTP response; it does not prevent the kernel from killing a process that exceeds its cgroup memory limit. Even switching to a TCP check would only alter how liveness is evaluated, leaving the memory constraint unchanged. The observed restarts are OOM kills, not probe failures, so the probe type is irrelevant to this issue.
- ✓
The memory limit is set too low; the container is being OOMKilled during traffic spikes.
Why this is correct
The container's memory limit is 256Mi, yet during traffic spikes memory reaches roughly 250Mi plus cache overhead, which pushes usage over the cgroup limit. When that limit is breached, the kernel OOM killer terminates the container, and restartPolicy causes the observed restarts. The liveness probe is not involved because the kernel acts independently of any probe status.
- ✗
The readiness probe is failing because the application is not ready, but the liveness probe keeps it alive.
Why it's wrong here
A failing readiness probe removes the pod from service load balancers and returns 503s, but it never triggers a container restart; kubelet only restarts on liveness failure or OOM kill. The notion that liveness keeps it alive is also off: a successful liveness probe doesn't override the kernel's OOM killer. Since the restart count matches memory-limit termination, readiness probe behavior is not the cause.
- ✗
The CPU limit is too low, causing the container to be throttled and timeout.
Why it's wrong here
CPU limits apply CFS throttling, which restricts how much CPU time the container gets but does not terminate the process. If the application needs more CPU, it simply waits in runnable state, causing latency or HTTP timeouts, yet the container remains alive. Restarts require a terminal event like OOMKill, and memory pressure—not CPU throttling—is what produces the observed container resets.
Go deeper
Related to this question
Learn chapter
Kubernetes Core Concepts and Architecture
Key term
Liveness Probes
A liveness probe is a Kubernetes health check that tells the system whether a container is running properly and should be kept alive or restarted.
Key term
Readiness Probes
A Kubernetes mechanism that checks if a container is ready to start accepting traffic and serve requests.
About these practice questions
This CKAD question is part of Courseiva's 160-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKAD exam.