City Power & Light is choosing compute for a multi-agent outage-response system. Requirements: burst scale during storms, isolate long-running planner jobs from low-latency chat agents, maintain reliability with health probes, and control cost during calm weather. Which compute specification is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
You want chat-facing agents on autoscaling containers with strict latency targets, long-running planners on separate jobs, queues, or workers, and scale-to-zero or min-replica policies when demand is calm. That keeps storms from hurting chat latency, isolates failures, and controls cost.
Full Explanation
Architects must specify compute that meets scalability, reliability, operational efficiency, security, and cost requirements. Autoscaling container or Kubernetes chat with strict latency SLOs, separate jobs, queues, or workers for long-running planners, and scale-to-zero or min-replica policies separates latency-sensitive and long-running workloads, enables elastic scale for storm bursts, isolates reliability, and reduces cost at idle. The single always-on 128-core VM with shared process memory creates one single point of failure, noisy-neighbor risk, and poor cost elasticity. Browser-only scripts are not a production control plane for critical outage response and fail offline or unmanaged device realities. Fixed single-AZ capacity at last year's average ignores burst demand and multi-AZ or region reliability patterns. Exam tip: Heterogeneous agent workloads usually need heterogeneous compute profiles, not one VM for everything.