CKA Workloads and Scheduling Practice Question
Which two statements about HorizontalPodAutoscaler (HPA) are correct?
⚠ Common exam trap
It's easy for candidates to assume HPA requires the metrics-server for all metric types, but the CKA exam tests the understanding that HPA can use custom and external metrics without the metrics-server, and that scaling to zero is not a native HPA feature.
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
✓
HPA is a namespaced resource
HorizontalPodAutoscaler (HPA) is a namespaced resource in Kubernetes, meaning it exists within a specific namespace and can only target resources (like Deployments or StatefulSets) in that same namespace. This is defined in the Kubernetes API under the `autoscaling/v2` group, where HPA objects are scoped to a namespace, not cluster-wide.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
HPA is a namespaced resource
Why this is correct
The HorizontalPodAutoscaler (HPA) is indeed a namespaced resource in Kubernetes. It lives in a specific namespace, and its name must be unique within that namespace but can be reused across different namespaces. When you create an HPA, it can only target workloads (such as Deployments or StatefulSets) that exist in the same namespace, and it reads the scale subresource of that target through the namespaced API path.
- ✓
HPA can scale based on custom metrics
Why this is correct
HPA supports scaling based on custom metrics, not just CPU and memory. Custom metrics are exposed via the custom.metrics.k8s.io API, often provided by adapters like the Prometheus Adapter, and can represent application-specific signals such as requests per second or queue length. An HPA can reference multiple metrics and combines them, scaling the workload when any configured target is exceeded, which makes it highly flexible for autoscaling beyond basic resource utilization.
- ✗
HPA can only target Deployments
Why it's wrong here
The claim that HPA can only target Deployments is false. HPA is designed to work with any resource that exposes a scale subresource, which includes Deployments, ReplicaSets, StatefulSets, and even custom resources that implement the scale subresource. This generality is why kubectl scale works uniformly across these resources, and the HPA controller uses the same scale interface to adjust replica counts regardless of the underlying controller.
- ✗
HPA requires the metrics-server to be installed
Why it's wrong here
HPA does not strictly require the metrics-server to be installed. While metrics-server is the standard source for resource metrics like CPU and memory through the metrics.k8s.io API, HPA can also obtain metrics from other adapters that implement the custom.metrics.k8s.io or external.metrics.k8s.io APIs, such as the Prometheus Adapter or a cloud-provider-specific adapter. The requirement is simply that some metrics source is available; metrics-server is common and sufficient for basic resource metrics, but it is not mandatory.
- ✗
HPA can scale down to zero replicas
Why it's wrong here
HPA cannot scale down to zero replicas by default. In standard Kubernetes, the minReplicas field is optional and defaults to 1, meaning the HPA controller will never scale below one replica unless minReplicas is explicitly set to 0, which is generally disallowed unless a feature gate like HPAScaleToZero is enabled and the target supports it. Even then, certain metrics types and controller-runtime versions impose restrictions, so scaling to zero is not a general-purpose capability of the HPA out of the box.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Deployments
A Kubernetes resource that manages a set of identical Pods, ensuring they run the correct number of replicas and can be updated or rolled back without downtime.
Key term
StatefulSets
A Kubernetes resource that manages stateful applications by providing stable network identities and persistent storage for each pod.
About these practice questions
This CKA question is part of Courseiva's 302-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 CKA 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 CKA exam.