Amazon EKS — Scaling Practice Questions
Test your understanding of EKS scaling — Cluster Autoscaler, Karpenter, HPA, VPA, and KEDA.
Question 1
What triggers Cluster Autoscaler to add a new node?
A) High CPU utilization on existing nodes
B) Pods in Pending state due to insufficient resources
C) HPA reaching maxReplicas
D) CloudWatch alarm for high network traffic
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | CA doesn’t monitor node utilization for scale-up — it watches for unschedulable pods |
| B | Cluster Autoscaler detects pods that can’t be scheduled (Pending) because no node has sufficient resources, then increases the ASG desired count |
| C | HPA reaching maxReplicas doesn’t directly trigger CA — it’s the resulting Pending pods that do |
| D | CA doesn’t integrate with CloudWatch alarms — it watches the Kubernetes scheduler |
Question 2
What is Karpenter’s primary advantage over Cluster Autoscaler?
A) Karpenter is free while Cluster Autoscaler costs money
B) Karpenter provisions EC2 instances directly with optimal type/size per workload
C) Karpenter supports more AWS regions
D) Karpenter doesn’t require IAM permissions
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Both are free and open-source |
| B | Karpenter bypasses ASGs and calls EC2 RunInstances directly, choosing the optimal instance type and size based on the actual pod requirements — resulting in faster scaling and better cost efficiency |
| C | Both are available in all EKS-supported regions |
| D | Karpenter requires IAM permissions for EC2, IAM, and SSM |
Question 3
What happens when you use HPA and VPA on the same metric (CPU)?
A) VPA takes precedence
B) HPA takes precedence
C) They conflict — both try to control CPU, leading to unpredictable behavior
D) They work together seamlessly
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Neither takes explicit precedence — they operate independently |
| B | Neither takes explicit precedence |
| C | HPA scales replicas based on CPU utilization, while VPA changes CPU requests — VPA changing requests alters HPA’s utilization calculation, causing a feedback loop and unpredictable scaling |
| D | They explicitly conflict when targeting the same resource metric |
Question 4
What unique capability does KEDA provide over standard HPA?
A) Faster scaling response time
B) Ability to scale to zero replicas
C) Support for CPU-based scaling
D) Integration with Kubernetes scheduler
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | KEDA uses HPA under the hood — scaling speed is similar |
| B | KEDA can scale deployments to zero replicas when there are no events/messages — HPA requires at least 1 replica minimum |
| C | HPA already supports CPU-based scaling natively |
| D | Neither HPA nor KEDA directly integrate with the scheduler |
Question 5
Which Karpenter feature actively reduces costs by replacing underutilized nodes?
A) Drift detection
B) Consolidation
C) Expiration
D) Interruption handling
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Drift detection replaces nodes when configuration changes (AMI, security group) — not for cost optimization |
| B | Consolidation evaluates node utilization and replaces underutilized nodes with fewer, smaller, or cheaper instances — directly reducing costs |
| C | Expiration recycles nodes after a time period — for patching, not cost optimization |
| D | Interruption handling responds to Spot interruptions — reliability, not cost |
Question 6
What must be installed for HPA to function?
A) Prometheus
B) CloudWatch Agent
C) Metrics Server
D) Karpenter
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Prometheus is optional — only needed for custom metrics via Prometheus Adapter |
| B | CloudWatch Agent provides AWS-level metrics, not the K8s metrics API |
| C | Metrics Server provides the metrics.k8s.io API that HPA uses to get pod CPU and memory utilization |
| D | Karpenter handles node scaling, not pod scaling — HPA works independently |
Question 7
You have an SQS queue processing application. During off-hours, the queue is empty. What’s the most cost-effective scaling configuration?
A) HPA with minReplicas: 1
B) KEDA with minReplicaCount: 0
C) Fixed replica count of 3
D) Cluster Autoscaler with min nodes: 1
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | HPA minimum is 1 replica — still consuming resources when queue is empty |
| B | KEDA with minReplicaCount: 0 scales the deployment to zero when the SQS queue is empty, then scales up when messages arrive — no wasted compute |
| C | Fixed replicas waste resources when there’s no work |
| D | CA manages nodes, not pods — you still need pod-level scaling for the application |
Question 8
What VPA update mode should you use in production for a critical application?
A) Auto
B) Recreate
C) Off
D) Initial
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Auto mode restarts pods to apply new resource requests — risky for critical production workloads |
| B | Recreate is not a VPA update mode |
| C | Off mode provides recommendations only — you review and apply changes manually during planned maintenance windows, avoiding unexpected pod restarts |
| D | Initial only sets requests at pod creation — existing pods don’t get updated, limiting usefulness |
Question 9
What does expireAfter: 720h in a Karpenter NodePool do?
A) Deletes the NodePool after 720 hours
B) Scales down idle nodes after 720 hours
C) Recycles (terminates and replaces) nodes after 720 hours of uptime
D) Disables the NodePool after 720 hours
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | NodePool is a CRD — expireAfter applies to nodes, not the pool |
| B | Idle node scale-down is handled by consolidation, not expiration |
| C | expireAfter triggers node recycling after 720 hours (30 days) — Karpenter drains and terminates the node, then provisions a fresh replacement with the latest AMI and config |
| D | NodePools don’t get disabled — they continue provisioning new nodes |
Question 10
HPA’s behavior.scaleDown.stabilizationWindowSeconds: 300 means:
A) HPA waits 300 seconds before its first scale-down ever
B) HPA looks at the highest recommended replica count in the last 300 seconds before scaling down
C) HPA scales down at most once every 300 seconds
D) Pods have 300 seconds to gracefully terminate
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | It applies to every scale-down decision, not just the first |
| B | The stabilization window prevents flapping by looking at the highest recommended replica count within the window duration — HPA won’t scale below that count until the window passes |
| C | The periodSeconds controls how often policy evaluations happen, not stabilization |
| D | Grace period for pod termination is terminationGracePeriodSeconds — different setting |
