4.2. Azure Functions
💡 First Principle: A Function inverts the deployment unit: instead of an always-on service that contains event-handling code, you deploy the handler itself and rent execution per event. That inversion is what makes Functions the natural glue for this phase's services — the code that answers a Service Bus message, an Event Grid event, or an HTTP request without any server existing between invocations.
Why care? Beyond the direct syllabus bullets, Functions appear as the answer to other domains' questions: the DLQ repair job from 4.1.1, the secret-rotation handler coming in 5.1.1, the thin API in front of a RAG query. Recognizing "small, trigger-driven, no server management" as the Functions signature earns points across the whole exam.
The mental model: a Function is a doorbell wired to a workbench. The trigger is the doorbell — exactly one per function, defining what makes it run. Bindings are conveyor belts to and from the bench — declarative connections that deliver input data and carry output away, so your code never writes SDK boilerplate for services it merely touches.
⚠️ Common Misconception: "A function can have several triggers — HTTP for testing plus a queue for production." One trigger per function, always. Bindings can be plural; the trigger is singular. Two entry paths means two functions (which can share all their inner code).
For long multi-step orchestrations with state — approval chains, fan-out/fan-in over hundreds of items — Durable Functions extends this model with orchestrator and activity functions, letting the platform checkpoint progress between steps.
