KCNA Cloud Native Application Delivery Practice Question
Your organization runs a microservices application on a Kubernetes cluster with 5 worker nodes (each with 4 vCPU, 16GB RAM). The application consists of 20 microservices, each deployed as a Deployment with 3 replicas. Recently, after a new microservice 'inventory' was deployed with resource requests of 2 CPU and 4GB memory per pod, the cluster started experiencing pod scheduling failures. Many existing pods are in 'Pending' state with events indicating 'Insufficient cpu' or 'Insufficient memory'. The cluster has cluster autoscaling enabled (node pool ranging from 3 to 10 nodes), but new nodes are not being added quickly enough, and the existing nodes are heavily utilized. You need to resolve the scheduling failures while ensuring the inventory service can scale. Which course of action should you take?
⚠ Common exam trap
A common mix-up: candidates think increasing cluster autoscaler limits or setting limits equal to requests will solve the problem, but they overlook that the autoscaler cannot instantaneously add nodes and that setting limits does not free up existing resources, while reducing requests directly addresses the immediate scheduling bottleneck.
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
✓
Reduce the CPU request of the inventory deployment to 1 CPU per pod to allow better packing on existing nodes while cluster autoscaler catches up.
Reducing the CPU request of the inventory deployment to 1 CPU per pod allows the scheduler to pack pods more efficiently on existing nodes, alleviating immediate 'Insufficient cpu' and 'Insufficient memory' failures while the cluster autoscaler provisions new nodes. This approach balances short-term scheduling needs with the ability to scale the inventory service later, as requests can be adjusted upward once the cluster has more capacity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the cluster autoscaler max nodes to 20 and set a 0-second scale-up delay.
Why it's wrong here
Does not solve the immediate packing issue; also 0-second delay may cause rapid scaling.
- ✗
Set resource limits equal to requests for all microservices to guarantee resources.
Why it's wrong here
Does not free up resources; may cause more contention if limits are high.
- ✓
Reduce the CPU request of the inventory deployment to 1 CPU per pod to allow better packing on existing nodes while cluster autoscaler catches up.
Why this is correct
Lowering requests improves packing and reduces pending status immediately.
- ✗
Delete all pending pods and recreate them manually.
Why it's wrong here
Temporary fix that does not address resource constraints.
Visual reference
Go deeper
Related to this question
Learn chapter
Kubernetes Overview and Core Components
Key term
Horizontal Pod Autoscaling
Horizontal Pod Autoscaling automatically adjusts the number of pod replicas in a Kubernetes cluster based on observed CPU, memory, or custom metrics.
Key term
ReplicaSet and Replication
A ReplicaSet ensures a specified number of identical pod instances are running at all times in Kubernetes, using replication to maintain availability and stability.
About these practice questions
One of 833 original KCNA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.