You must specify compute for a bursty multi-agent workload: low traffic overnight, sharp peaks during business hours, strict per-tenant isolation goals, and cost sensitivity. Which compute approach best fits?
Select an answer to reveal the explanation.
Short Explanation
You need elastic Azure compute that scales out during business-hour peaks and scales in or to zero overnight, while keeping tenant isolation and cost allocation. Static always-on servers, oversized VMs, and laptop production traffic can't meet bursty multi-agent needs.
Full Explanation
Architects specify compute components that meet scalability, reliability, operational efficiency, security, and cost requirements. The elastic Azure compute approach suited to agent services—container apps/functions/AKS with autoscaling, or Foundry-managed hosting patterns as appropriate—fits because it scales for peak, scales to zero or in off-peak, and supports multi-tenant isolation and cost allocation. The single always-on bare-metal server in a colocation cage with no auto-scale, shared by all tenants, lacks elasticity and strong multi-tenant isolation. The unlimited free local laptop execution for production traffic is not a production architecture for enterprise multi-agent solutions. The one oversized dedicated VM per agent type at maximum SKU 24/7 with no monitoring wastes cost and ignores utilization-driven efficiency. Exam tip: Pair bursty load language with autoscaling compute and tenant isolation—not static overprovisioning alone.