A 311 platform team wants the worker replica count expressed as desired state rather than scaling pods by hand during every storm surge. Which approach matches declarative IaC?

Declarative IaC expresses desired state and lets a controller reconcile reality to that declaration. For a 311 platform facing storm-surge load, declaring the worker replica count in a manifest (Deployment, ReplicaSet, or equivalent) tells the orchestrator what “enough capacity” means. The controller creates or terminates pods until the live count matches the declared count, without operators SSHing into workers or improvising process starts.

SSH into each worker and start extra processes until the queue clears is imperative, ephemeral, and invisible to the desired-state model; the next scheduler event or node reboot can undo the surge response. Pasting scale-up shell commands into a chat channel for overnight operators transfers tribal procedure into an unreliable runbook and leaves no machine-readable target. Keeping replica counts only in a spreadsheet updated after each incident documents history, not desired state—spreadsheets do not converge clusters.

Exam caveat: declarative does not mean “never change replicas.” It means changes go through the manifest (and usually Git) so the controller, not chat, owns convergence. Autoscaling policies are still declarative when they encode min/max and metrics rather than ad-hoc SSH. Mixing hand-started processes with declared replicas often produces phantom capacity that disappears under eviction.

Operational check: set the desired replica field in the 311 worker manifest, apply it, and confirm the controller reports Ready replicas equal to the declaration during a load test. Intentionally scale the live count with an imperative kubectl/ssh action, then re-apply or wait for reconcile and verify drift is corrected back to the manifest.