Courseiva
Application Deployment →mediumMultiple Select

CKAD Application Deployment Practice Question

Which THREE of the following are valid reasons to use a HorizontalPodAutoscaler (HPA) with a Deployment?

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

✓

To scale replicas based on the number of incoming HTTP requests per second.

Options B, C, and E are valid uses of a HorizontalPodAutoscaler (HPA). HPA can scale based on custom metrics (e.g., HTTP requests per second) via the 'custom' or 'external' metric types, making B and C correct. Option E is correct because HPA can scale based on average CPU utilization using the 'ResourceMetric' type with 'targetAverageUtilization'. Option A is incorrect: HPA scales up when CPU exceeds the target, not down; also, the deprecated 'targetCPUUtilizationPercentage' field has been replaced by a metrics array. Option D is incorrect: HPA does not enforce resource requests; it only uses them as a basis for metric calculation.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    To set a fixed 'targetCPUUtilizationPercentage' that scales down the deployment when exceeded.

    Why it's wrong here

    HPA does not scale down when a CPU utilization target is exceeded; it scales up to reduce per-pod load. Moreover, `targetCPUUtilizationPercentage` is a deprecated field in the `autoscaling/v2` API, replaced by the metric spec that targets a specific metric value. HPA's goal is to maintain or reduce high utilization by adding replicas, not by removing them.

  • ✓

    To scale replicas based on the number of incoming HTTP requests per second.

    Why this is correct

    This is a valid use case for HPA, implemented through custom metrics. By exposing HTTP request counters from the application (e.g., via Prometheus) and registering a custom metrics adapter, HPA can query a metric like `http_requests_per_second` and scale replicas proportionally. The `autoscaling/v2` API allows referencing this custom metric via the `type: Object` or `type: Pods` metric source, making request-driven scaling a common real-world pattern.

  • ✓

    To scale replicas based on custom metrics exposed by the application.

    Why this is correct

    HPA explicitly supports scaling based on custom metrics exposed by the application, as defined in the `custom.metrics.k8s.io` API. These metrics can be any application-specific value, such as queue length, in-flight requests, or error rate, as long as they are exposed via a supported metrics adapter like Prometheus Adapter or Datadog Cluster Agent. This allows HPA to react to business-oriented signals beyond the basic CPU and memory metrics, which is a key advantage of custom-metric autoscaling.

  • ✗

    To ensure that each pod has at least a certain amount of CPU resources reserved.

    Why it's wrong here

    This is incorrect because resource requests are a static property of a Pod's container specification, set in the deployment or pod template under `spec.containers[].resources.requests`. HPA does not reserve or allocate CPU resources; it only observes and reacts to utilization. While HPA's CPU-based calculations rely on the requests values to compute utilization percentage, it does not enforce any minimum resource guarantee—that is the Kubernetes scheduler's job.

  • ✓

    To automatically scale the number of replicas based on average CPU utilization across pods.

    Why this is correct

    CPU-based autoscaling is indeed one of the primary reasons to use an HPA. The HorizontalPodAutoscaler periodically checks the average CPU utilization across all pods in the target workload and calculates the desired replica count with the formula `ceil(currentReplicas * currentUtilization / targetUtilization)`. This works even without custom metrics, using the built-in `metrics.k8s.io` resource metrics API, provided the workload's pods have CPU resource requests set.

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 →

How Courseiva writes practice questions · Editorial policy

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.