A 311 ticket-triage worker on Azure Container Apps should scale based on Service Bus queue depth. Which scaling approach should the team implement?
Select an answer to reveal the explanation.
Short Explanation
When the 311 queue piles up like overnight work orders, you want more triage workers—not a clock that wakes them whether the queue is empty or overflowing. KEDA’s Service Bus scaler watches queue depth and grows Container Apps replicas to match.
Full Explanation
KEDA (Kubernetes Event-driven Autoscaling), integrated with Azure Container Apps, can scale replicas from external metrics such as Azure Service Bus queue depth. A 311 ticket-triage worker that processes queue messages should grow when depth rises and shrink when the queue drains. Configuring a Service Bus scaler binds municipal backlog to compute so residents’ tickets are processed promptly without permanently running maximum replicas. That event-driven approach matches queue-based worker architectures better than time-only schedules.
Scaling only on a fixed cron every hour regardless of queue depth fails responsiveness—empty queues still wake workers and deep backlogs may wait until the next hour. Ignoring the queue and always running the maximum replica count fails cost control. Scaling exclusively by randomly restarting pods when operators feel busy fails any deterministic autoscaling signal and destabilizes the triage worker.
Exam caveat: Container Apps scale rules wrap KEDA scalers; you configure the Service Bus scaler with queue name, connection (often via secret/managed identity patterns), and thresholds. Cron scalers exist but answer a different problem than queue-depth elasticity.
Operational check: Load the 311 Service Bus queue with test messages and confirm Container Apps replica count rises with depth, then drains as messages complete. Verify authentication to Service Bus for the scaler, and that min/max replica bounds prevent both scale-to-nothing during outages you still need and unbounded cost spikes.