Build fluency in the vocabulary of scaling a deployment based on an external queue's backlog rather than CPU alone.
0 / 5 completed
1 / 5
At standup, a dev mentions scaling a Kubernetes deployment based on the depth of an external message queue rather than only on CPU or memory utilization. What tool is commonly used for this?
KEDA, or Kubernetes Event-Driven Autoscaling, scales a deployment based on the depth of an external message queue or another event source, rather than being limited to CPU or memory utilization alone. The built-in HorizontalPodAutoscaler using only CPU and memory has no visibility into how many messages are actually waiting in an external queue. This event-source-aware scaling is what lets KEDA scale a queue-processing workload accurately based on its real backlog.
2 / 5
During a design review, the team wants KEDA to scale a deployment down to zero replicas entirely when the event source has no pending work, rather than always keeping at least one replica running idle. Which capability supports this?
Scale-to-zero support lets KEDA scale a deployment down to zero replicas entirely when its event source has no pending work, rather than always keeping at least one replica running idle just in case. Always keeping a replica running regardless of pending work wastes resources during a genuinely quiet period. This scale-to-zero capability is one of KEDA's most distinctive features compared to the built-in HorizontalPodAutoscaler, which can't scale below one replica.
3 / 5
In a code review, a dev notices a KEDA ScaledObject is configured with a specific scaler type matching the exact external system, like a particular message broker, whose metric should drive the scaling decision. What does this represent?
A scaler configuration binds the ScaledObject to a specific external event source, like a particular message broker, so KEDA knows exactly which system's metric should drive the scaling decision. Configuring a ScaledObject with no specific scaler type leaves it ambiguous which external system's backlog KEDA is actually supposed to watch. This scaler configuration is what connects KEDA's generic autoscaling framework to a concrete, real-world event source.
4 / 5
An incident report shows a queue-processing deployment stayed scaled to a single idle replica around the clock even during long overnight periods with zero pending messages, driving up unnecessary compute cost. What practice would prevent this?
Configuring KEDA's scale-to-zero support lets the deployment scale down fully during a genuinely idle period, eliminating the unnecessary compute cost of an always-running idle replica. Relying on the built-in HorizontalPodAutoscaler, which can't scale below one replica, is exactly what left the idle replica running around the clock in this incident. This scale-to-zero capability is a key reason teams adopt KEDA specifically for a bursty, queue-driven workload.
5 / 5
During a PR review, a teammate asks why the team uses KEDA for a queue-processing deployment instead of the built-in HorizontalPodAutoscaler configured against CPU utilization alone. What is the reasoning?
CPU utilization alone doesn't reflect how much work is actually queued up externally, since a deployment can sit at low CPU usage while a large backlog of unprocessed messages waits in the queue. KEDA scales directly on the queue's own backlog metric and can scale all the way down to zero during a genuinely idle period. The tradeoff is the added operational dependency of installing and maintaining KEDA's own controller alongside the cluster's built-in autoscaling components.