A school district attaches HPA to a gradebook Deployment. What operational practice avoids fighting the autoscaler?
Select an answer to reveal the explanation.
Short Explanation
If the cruise control is on, do not keep stomping the gas and brake by hand. When HPA owns replica count, stop wrestling it with constant manual scale patches.
Full Explanation
A school district attaching HPA to a gradebook Deployment should let HPA manage the replica count and avoid conflicting manual replica edits. When HPA is active, it continually reconciles desired replicas from metrics. Manual patches to Deployment replicas fight that loop, causing thrash, confusion in audits, and unstable gradebook capacity during enrollment peaks. The operational practice is one owner of replica count: the autoscaler, or temporarily disable or remove HPA if you must pin replicas for an incident.
Manually patching replicas every few minutes to random values while HPA is active is the anti-pattern that creates flapping. Deleting the Deployment whenever HPA scales destroys the workload instead of stabilizing ReplicaSets. Disabling the scheduler so HPA-created Pods never bind to nodes breaks scheduling cluster-wide and does not peacefully coexist with autoscaling.
Exam caveat: if you must take manual control during an incident, pause or remove HPA or understand it will overwrite replica fields again. Operational check: kubectl get hpa and deploy for the gradebook; avoid kubectl scale battles; use HPA min/max and metrics tuning instead of ad-hoc replica patches. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.