During an incident, a municipal SRE needs to confirm whether an HPA has raised desired replicas and what its current status reports. Which approach best answers that?
Select an answer to reveal the explanation.
Short Explanation
When scale looks stuck, go look at the HPA object itself—desired vs current replicas and its conditions are right there. Guessing from Service IPs or bouncing kube-proxy will not tell you what the autoscaler decided.
Full Explanation
During an incident, a municipal SRE who needs to confirm whether an HPA has raised desired replicas and what its current status reports should describe or get the HorizontalPodAutoscaler and read desired versus current replicas and conditions. Those fields and conditions (for example AbleToScale and ScalingActive) are the authoritative status surface for whether autoscaling is working during a civic outage bridge call.
Deleting the Deployment and relying on etcd snapshots to infer scale history destroys the workload and is not a status check. Inspecting only the Service ClusterIP is wrong because HPA updates workload replica counts, not Service ClusterIP identity. Restarting kube-proxy on every node does not flush HPA status into iptables meaningfully for this question—kube-proxy is dataplane, not the HPA status API.
Exam caveat: pair HPA status with Deployment ready replicas to see whether scaled Pods became Ready. Operational check: kubectl get hpa / kubectl describe hpa during the incident, note desired vs current, and correlate with Deployment and Pod health for the municipal app. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.