KCNA Cloud Native Application Delivery Practice Question
A financial services company runs a critical trading application on Kubernetes. The application is deployed as a Deployment with 3 replicas. Each pod exposes metrics on port 8080 and uses a ConfigMap to load configuration. Recently, after a configuration change via a ConfigMap update, two of the three pods started crashing with an out-of-memory (OOM) error, while the third pod continues to run fine. The team verified that the ConfigMap was updated correctly and that the application code did not change. The pods have resource limits set: memory limit of 512Mi and request of 256Mi. The application's memory usage before the change was around 200Mi. The new configuration increases the in-memory cache size. The team suspects the issue is related to the configuration change. What is the best course of action?
⚠ Common exam trap
CNCF often tests the misconception that scaling replicas or removing limits solves resource exhaustion, when the correct approach is to adjust resource limits to match the application's new requirements.
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
✓
Increase the memory limit in the Deployment manifest to a higher value, such as 1Gi, and perform a rolling update.
The OOM errors are directly caused by the increased memory usage from the larger in-memory cache, which exceeds the current 512Mi memory limit. Increasing the limit to 1Gi accommodates the new cache size while preserving resource boundaries, and a rolling update applies the change without downtime. This aligns with Kubernetes best practices of setting realistic resource limits based on application requirements.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Scale the Deployment to 5 replicas to distribute the memory load.
Why it's wrong here
More replicas increase total memory usage; does not fix per-pod OOM.
- ✗
Remove the memory limit from the container spec to allow unlimited memory usage.
Why it's wrong here
Removing limits can cause nodes to run out of memory and affect other workloads.
- ✗
Revert the ConfigMap to the previous configuration and monitor memory usage.
Why it's wrong here
This avoids the issue but does not allow the new cache feature; not a long-term solution.
- ✓
Increase the memory limit in the Deployment manifest to a higher value, such as 1Gi, and perform a rolling update.
Why this is correct
This directly addresses the OOM caused by increased cache size.
Go deeper
Related to this question
About these practice questions
This KCNA question is part of Courseiva's 833-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 KCNA 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 KCNA exam.