CKAD Application Observability and Maintenance Practice Question
You are a platform engineer for a large e-commerce site. The application is deployed on a Kubernetes cluster with 10 worker nodes. Recently, a new deployment 'checkout' was rolled out, and soon after, the cluster experienced network latency and intermittent connectivity issues between services. The 'checkout' pods are configured with a liveness probe that makes an HTTP request to an internal health endpoint. Upon investigation, you find that the kubelet on several nodes is consuming high CPU, and the number of iptables rules has increased significantly. You suspect that the 'checkout' deployment's configuration is causing excessive churn in the network rules. Which aspect of the deployment configuration is most likely the root cause?
⚠ Common exam trap
The trap here is that candidates may focus on the probe type (HTTP vs. TCP) or resource limits, but the root cause is the probe frequency and failure threshold causing rapid pod restarts and iptables churn, not the probe mechanism itself.
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 liveness probe is configured with a very short periodSeconds (e.g., 1) and a low failureThreshold.
A liveness probe with a very short `periodSeconds` (e.g., 1) and a low `failureThreshold` causes the kubelet to send HTTP requests to the health endpoint at a high frequency. Each probe failure triggers a pod restart, which in turn causes the kubelet to update iptables rules (e.g., for kube-proxy and network policies) to reflect the new pod IP. This rapid churn of pod restarts leads to a significant increase in iptables rules and high CPU consumption on the kubelet, as it must repeatedly reconcile the network state.
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 configured with a very short periodSeconds (e.g., 1) and a low failureThreshold.
Why this is correct
With periodSeconds set to 1 and failureThreshold to 1, the kubelet probes the container every second and restarts it after a single failure. This aggressive schedule causes rapid crash/restart cycles; each restart transitions the pod through NotReady and Ready states, toggling its membership in the Service endpoints. Every toggle notifies kube-proxy to recalculate and update the corresponding iptables DNAT/load-balancing rules, and in a large cluster this endpoint flapping produces substantial iptables churn on all nodes routing to that Service.
- ✗
The liveness probe uses a TCP socket check instead of an HTTP GET.
Why it's wrong here
Changing the liveness probe from an HTTP GET to a TCP socket check alters the mechanism of the probe but not its frequency, failure threshold, or restart consequences. A TCP check merely attempts to open a connection to a port, while an HTTP GET additionally verifies a path and response code, so at most it changes the resource footprint of each probe. It does not trigger endpoint changes or iptables updates by itself, and therefore cannot explain the observed iptables churn.
- ✗
The deployment sets resource requests and limits that are too low, causing pod throttling.
Why it's wrong here
Setting resource requests and limits too low causes the container's CPU to be throttled by the kubelet, which can make the application slower and possibly cause probe failures. However, CPU throttling does not directly modify service endpoints or iptables rules; those rules are updated only when the set of Ready pods changes. If throttling indirectly leads to restarts, the root cause of churn is still the probe configuration and restart policy, not the resource limits, so this option is irrelevant to the iptables issue.
- ✗
The deployment uses a large number of environment variables, causing slow container startup.
Why it's wrong here
A large number of environment variables increases the container's environment block, which can slow down the initial container startup and delay readiness. This is a one-time cost per pod and does not produce repeated changes to Service endpoints or iptables tables. Even during the extended startup, the pod is not yet an endpoint, so no iptables updates occur because of the environment variables themselves; they simply postpone readiness without causing the ongoing churn described.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-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.