10.1 Azure Functions: Triggers & Bindings

Azure Functions is Azure’s event-driven serverless compute platform. For AI-200, you use Functions as the glue between user requests, Azure AI services, storage, and messaging — without managing virtual machines. A Function App hosts one or more functions. Each function is a small unit of code that runs when something happens (a trigger) and optionally talks to other services through bindings.

Triggers vs bindings

A trigger is the reason your function runs. Every function has exactly one trigger. A binding is a declarative connection to another resource. Bindings do not start the function; they supply input data or accept output data after the function has started.

Why this matters for AI workloads: you want to keep orchestration thin. An HTTP trigger can accept a prompt, an input binding can load a prompt template from Blob Storage, your code calls Azure OpenAI or another AI service, and an output binding can write the result to Cosmos DB or a queue for downstream processing — with minimal connection-management code.

Core triggers for AI back ends

Memorize what each trigger listens to and when you would choose it for a serverless AI API or pipeline.

HTTP trigger

HTTP is the default choice for building serverless APIs. The platform maps a URL path and HTTP methods (GET, POST, etc.) to your function. Clients send JSON payloads (prompts, file URLs, session IDs); your function returns JSON responses. Pair HTTP with careful auth (covered below) and short timeouts — Consumption plan functions have execution time limits, so long-running model calls often need async patterns (queue + status polling) rather than a single blocking HTTP call.

Timer trigger

Timer triggers use an NCRONTAB expression (six fields including seconds). Example use cases: re-index knowledge bases nightly, purge expired conversation state, or poll an external system when Event Grid is unavailable. Timer functions are not request/response APIs; they are scheduled workers.

Queue Storage and Service Bus

Both are message-driven. Storage Queues are simple and cheap for high-volume, best-effort async AI work. Service Bus adds sessions, dead-letter queues, transactions, and topics/subscriptions — better when multiple consumers need the same event or when you need ordered processing. A common AI pattern: HTTP function enqueues a job; a queue-triggered function calls the model and writes results.

Event Grid

Event Grid delivers near-real-time events from Azure services (for example, Blob created in a container). For document intelligence pipelines, Event Grid → Function is cleaner than polling storage. The function receives an event envelope, downloads the blob (often via an input binding or SDK), and starts OCR, classification, or embedding generation.

Cosmos DB trigger

The Cosmos DB trigger uses the change feed. When documents are inserted or updated, your function runs with those documents. This fits retrieval-augmented generation (RAG) maintenance: new FAQ documents appear in Cosmos → function updates a search index or vector store. Remember: change feed reacts to creates/updates; deletes are handled differently depending on configuration and soft-delete patterns.

Input and output bindings

Bindings reduce boilerplate. Instead of writing full client code to open a blob or enqueue a message, you declare the binding and receive strongly typed parameters (or write to an output collector).

Bindings are optional. You can still use Azure SDKs inside the function for complex AI client calls (Azure OpenAI, Document Intelligence, Speech). Exam questions often contrast “use a binding” (declarative I/O) versus “use the SDK” (custom logic, streaming, multi-step AI calls).

Declaring bindings

• In-process (.NET legacy / some languages): function.json lists bindings with type, direction (in, out, or trigger), and connection settings.
• Isolated worker (.NET recommended): attributes such as [HttpTrigger], [BlobInput], [QueueOutput] on method parameters; the worker process hosts your app separately from the Functions host.
• Python / Node / Java / PowerShell: decorators or annotations map similarly to triggers and bindings.

You do not need to memorize every attribute name for AI-200, but you must know: one trigger, bindings are declarative, direction matters, and connection strings/managed identities live in app settings — not hard-coded in source.

Isolated worker vs in-process (high level)

For AI-200, if a question mentions modern .NET Functions or “isolated process,” choose Isolated worker. Language workers for Python and Node are already out-of-process relative to the host; the Isolated vs in-process distinction is especially important for .NET exam scenarios.

HTTP authorization levels

HTTP triggers support authorization levels that gate the endpoint:

Keys appear as query string code= or as the x-functions-key header. For production AI APIs facing browsers or mobile apps, prefer Azure API Management, Easy Auth / Microsoft Entra ID, or Front Door in front of Functions — function keys alone are not end-user identity. Exam focus: know the three levels and that function is the usual middle ground.

Putting it together for AI

A practical serverless AI back end often combines triggers:

1. HTTP function accepts a user request and validates input.
2. Optional input bindings load templates or configuration blobs.
3. Code calls Azure AI services with the SDK (not every AI call is a binding).
4. Output bindings write results to Cosmos DB or enqueue a Queue message.
5. A second Queue-triggered function handles long-running steps so the HTTP call stays fast.

If the pipeline starts from uploaded files, swap step 1 for Event Grid on blob creation. If work must run on a schedule, use Timer. If documents live in Cosmos and must stay in sync with a search index, use the Cosmos DB change feed trigger.

Key Takeaways

• One trigger starts the function; bindings handle optional input/output to Azure services.
• Know HTTP, Timer, Queue Storage, Service Bus, Event Grid, and Cosmos DB triggers and their AI use cases.
• Input bindings read; output bindings write; AI SDKs handle complex model calls.
• Isolated worker is the modern .NET hosting model versus legacy in-process.
• HTTP auth levels: anonymous, function, and admin — function keys gate most APIs.