A city needs a simple single-service permits chatbot with event-driven scale and prefers managed revisions over operating a full Kubernetes control plane. Which hosting choice fits best?
Select an answer to reveal the explanation.
Short Explanation
For your single permits chatbot, event-driven scaling doesn’t require a six-lane freeway: Azure Container Apps gives you managed revisions and scaling without a full AKS control plane. It’s the proportionate fit for this service.
Full Explanation
Azure Container Apps fits a simple, single-service city permits chatbot that needs managed revisions and event-driven scale without operating a full Kubernetes control plane. It handles revisions, ingress, and KEDA-style scaling for an interactive API, avoiding the CNI customizations, node pools, and multi-operator overhead of a larger platform. Deploying a full multi-team AKS platform with custom CNI and dozens of operators for one chatbot fails by concept because it adds platform complexity beyond a single-service need; AKS is powerful but heavier than required. Hosting only as an unmanaged VM with Docker and no Azure container platform fails because it gives up the managed revisions, integrated event-driven scaling, and platform management the city prefers. Routing each permit question through a scheduled Azure Data Factory batch pipeline fails because interactive chatbot traffic calls for a live request/response API, not a scheduled ETL substitute. Exam caveat: AKS can suit complex, multi-service, policy-heavy, or Kubernetes-native platforms; this scenario is about fit for one simple service. Container Apps is managed, not automatically secure, so maintain sound identity, networking, and secret practices. Practical check: deploy the chatbot as a Container Apps revision with HTTP ingress, configure a relevant scale rule, validate behavior under load, and confirm the team is not maintaining an AKS control plane for this lone service.