A city GIS narrative agent on AKS must add pods during map-season CPU spikes. Which Kubernetes construct should they apply?
Select an answer to reveal the explanation.
Short Explanation
Map season can turn your GIS narrative agent into rush-hour traffic. A HorizontalPodAutoscaler watches CPU and adds pods to the Deployment, like opening more service windows, so you don’t have to spot a red chart and intervene by hand.
Full Explanation
A HorizontalPodAutoscaler (HPA) adjusts the replica count of the GIS agent Deployment using metrics such as CPU utilization. When map-season demand pushes CPU utilization up, the HPA can add pods to serve more narrative traffic; when demand falls, it can scale in within configured bounds. This is the Kubernetes-native horizontal scaling construct for seasonal load on AKS. A single ReplicaSet fixed at one pod with no autoscaling object cannot add capacity as demand rises. Manually deleting pods when CPU looks high does not automate scaling and can reduce available capacity precisely when load is greatest. Resizing AKS control-plane VMs while leaving the workload pods unchanged does not add GIS agent pods to serve residents; control-plane size does not determine the Deployment’s replica count. Exam caveat: an HPA needs metrics to be available, such as through Metrics Server, and sensible minimum and maximum replica settings. CPU utilization is the classic exam metric, though other supported metrics may be used. Operational check: configure a CPU target and a map-season-appropriate maximum for the GIS agent Deployment, then load-test or monitor seasonal CPU and confirm that the replica count rises. Verify that the Service distributes traffic to the new pods and that the minimum replica count still covers off-season demand.