Parks chatbot tools need a lightweight internal HTTP API for lookup actions. Which Azure Functions trigger should host that API?
Select an answer to reveal the explanation.
Short Explanation
An HTTP-triggered Function is the tiny parks help desk window—chatbot tools knock with a request, get a quick answer, and nobody spins up a whole campground of servers for a lookup.
Full Explanation
Parks chatbot tools that need a lightweight internal HTTP API for lookup actions map cleanly to Azure Functions HTTP triggers. The Function app exposes HTTPS endpoints the agent or orchestrator calls for catalog lookups, hours, or similar tool actions, with auth (keys, Easy Auth, managed identity patterns, or API Management in front) appropriate to an internal municipal tool surface. Serverless HTTP fits bursty chatbot traffic without standing up a full cluster for simple lookups.
Using only a timer trigger fails because timers cannot accept inbound HTTP tool calls from the chatbot at request time. Requiring a full AKS cluster solely to answer simple tool HTTP lookups fails on operational weight: Kubernetes is powerful but unnecessary overhead for a small serverless API surface when Functions meet the need. Exposing raw Service Bus management endpoints directly to the chatbot front end fails security and abstraction: management planes are not tool APIs, and front ends should not manipulate queues as a substitute for a purpose-built lookup contract.
Exam caveat: HTTP-triggered tool APIs still need authentication, input validation, and timeouts aligned with the agent’s tool budget; “internal” does not mean anonymous on the public internet. Operational check: call the Function URL with a representative parks lookup payload, confirm auth rejects anonymous callers, and verify the chatbot tool definition points at the Function (or APIM) URL rather than at Service Bus management APIs.