A global retailer needs multi-agent compute that scales for Black Friday traffic spikes, isolates noisy neighbor batches, meets reliability targets, and controls cost during quiet hours. Which compute specification direction best balances these concerns?
Select an answer to reveal the explanation.
Short Explanation
You want elastic Azure compute with autoscale, isolation between batch and interactive agents, redundancy that matches SLAs, and scale-to-zero or right-sizing when quiet. That lets you absorb Black Friday spikes, keep noisy batches from hurting interactive traffic, and cut idle cost. A single fat VM, laptops, or free tiers won't cut it.
Full Explanation
Selecting elastic Azure compute options with autoscale, workload isolation for batch versus interactive agents, reliability/SLA-aligned redundancy, and scale-to-zero or right-size policies for idle periods is correct. Technology component selection for multi-agent solutions includes compute that meets scalability, reliability, operational efficiency, security, and cost requirements—typically elastic platform services with isolation and idle cost controls. Running all agents on a single always-on oversized VM with no autoscale and no isolation is incorrect because it wastes cost at idle, risks single-host failure, and offers poor noisy-neighbor isolation. Scheduling production inference only on developer laptops overnight is incorrect because developer laptops cannot meet global retail reliability, security, or capacity needs. Placing production agents only on unsupported personal cloud free tiers is incorrect because unsupported free tiers lack enterprise SLA, security, and capacity guarantees.