An open-data portal team sees CPU-bound app pods and wants the Horizontal Pod Autoscaler to fix capacity. What does HPA actually change?
Select an answer to reveal the explanation.
Short Explanation
Think of HPA like adding more cashiers at a busy counter—not building a bigger store. It scales how many Pod copies run, not how many machines are in the cluster. Node count is a different autoscaler problem.
Full Explanation
An open-data portal team seeing CPU-bound app pods and wanting the Horizontal Pod Autoscaler to fix capacity should understand what HPA actually changes: it increases or decreases the number of Pod replicas for the target workload. HPA does not grow the worker node pool by itself; it adjusts desired replicas on a Deployment, ReplicaSet, or similar scale target so more Pods share the CPU-bound open-data traffic. Node capacity remains a separate concern for cluster autoscaling or manual node adds.
Adding or removing Kubernetes worker nodes is cluster/node autoscaling, not what HPA does. Rewriting the cluster CNI MTU does not add application capacity for CPU-bound pods. Permanently raising every node's kubelet MaxPods setting only changes how many Pods a node will accept; it is not HPA replica scaling.
Exam caveat: if nodes are already full, HPA may raise desired replicas while Pods stay Pending—scale nodes or free capacity as a follow-on. Operational check: kubectl get hpa and deploy for the portal, confirm desired replicas rise with CPU, and watch whether new Pods actually schedule onto Ready nodes. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.