ExamFinch.com My Study

Study guide

10.1 Azure Functions: Triggers & Bindings

Practice this exam

Exam AI-200: Developing AI Cloud Solutions on Azure Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Audience Profile & Study Path

2 Chapter 1: Container Registry & App Service Hosting

1.1 ACR: Build, Store, Version & Manage Images 1.2 ACR Tasks: Build & Run Images 1.3 Deploy Containers to Azure App Service

3 Chapter 2: Azure Container Apps & KEDA Scaling

2.1 Azure Container Apps: Environments, Config & Revisions 2.2 KEDA Event-Driven Scaling in Container Apps

4 Chapter 3: AKS Manifests & Container Troubleshooting

3.1 Deploy & Manage Apps on AKS with Manifests 3.2 Monitor & Troubleshoot AKS and Container Apps

5 Chapter 4: Cosmos DB for NoSQL Fundamentals

4.1 Cosmos DB for NoSQL: SDK Connect & Queries 4.2 Optimize RUs: Indexing Policies & Consistency Levels

6 Chapter 5: Cosmos DB Vectors & Change Feed

5.1 Embeddings & Vector Similarity Search in Cosmos DB 5.2 Change Feed Processor for New/Updated Items

7 Chapter 6: Azure PostgreSQL Foundations for AI

6.1 Azure Database for PostgreSQL: Connect & Query with SDKs 6.2 Schema Design, Data Types & Indexing Strategies 6.3 pgvector Indexing: Latency & Compute Overhead

8 Chapter 7: PostgreSQL Vector Workloads & RAG

7.1 Configure Compute, Memory & Storage for Vector Workloads 7.2 Vector Search, Semantic Retrieval & RAG with Metadata Filters 7.3 Connection Optimization for Throughput & Latency

9 Chapter 8: Azure Managed Redis for AI Solutions

8.1 Azure Managed Redis: Caching, Expiration & Invalidation 8.2 Redis Vector Indexing for Similarity Search

10 Chapter 9: Service Bus & Event Grid for AI Pipelines

9.1 Service Bus Queues & Message Processing 9.2 Topics, Subscriptions & Dead-Letter Queues 9.3 Event Grid: Custom Events & Filters 9.4 Event Grid Retries & Event-Driven Workflows

11 Chapter 10: Azure Functions for Serverless AI Back Ends

10.1 Azure Functions: Triggers & Bindings 10.2 Build Serverless APIs with Functions 10.3 Configure & Deploy Function Apps

12 Chapter 11: Key Vault & App Configuration

11.1 Azure Key Vault: Secret Storage & Retrieval 11.2 Key Vault Secret Rotation Patterns 11.3 Azure App Configuration for App Settings

13 Chapter 12: OpenTelemetry & KQL Observability

12.1 Distributed Tracing with OpenTelemetry SDKs 12.2 Correlating Traces into Azure Monitoring 12.3 Write KQL Queries to Analyze Logs 12.4 KQL for Metrics & Troubleshooting Scenarios

10.1 Azure Functions: Triggers & Bindings

Key Takeaways Explain This Topic AI

Every Azure Function has exactly one trigger that starts execution; bindings declare how the function reads from or writes to Azure services without manual SDK boilerplate

HTTP, Timer, Queue Storage, Service Bus, Event Grid, and Cosmos DB triggers cover the main AI back-end event sources on AI-200

Input bindings pull data into the function; output bindings push results out — both are declared in function.json (in-process) or via attributes/decorators (isolated worker)

Isolated worker process is the recommended model for .NET; in-process runs in the Functions host process and is legacy for new .NET apps

HTTP authorization levels (anonymous, function, admin) control who can invoke an HTTP-triggered function endpoint

Last updated: July 2026

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.

  • Concept Role Count per function
  • Trigger Starts execution Exactly one
  • Input binding Reads data into the function Zero or more
  • Output binding Writes data from the function Zero or more

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.

  • Trigger Source Typical AI back-end use
  • HTTP HTTP/HTTPS request to the function URL Synchronous inference APIs, chat backends, webhook receivers
  • Timer CRON schedule (NCRONTAB) Nightly embedding refresh, model-usage reports, cache warm-ups
  • Queue Storage Azure Storage queue message Async jobs after upload: transcription, summarization, batch scoring
  • Service Bus Queue or topic subscription Reliable enterprise messaging between microservices and AI workers

Event Grid Event Grid event (Blob created, custom topics, etc.) React when a document lands in storage — kick off OCR + LLM pipeline

  • Cosmos DB Change feed on a container Near-real-time reactions to new/updated documents (RAG index updates)
  • 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).

  • Binding direction Examples AI scenario
  • Input Blob, Cosmos DB document, Table row Load a system prompt file; fetch conversation history

Output Queue message, Blob, Cosmos DB, SendGrid, SignalR Store model output; enqueue follow-up work; notify clients

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)

Model How it runs Exam takeaway

In-process Function code loads into the Functions host process Older .NET model; tighter coupling to host version

Isolated worker Your app runs in a separate worker process; host communicates over gRPC Preferred for new .NET Function Apps; clearer dependency isolation

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:

  • Level Who can call Notes
  • anonymous Anyone with the URL Use only for public health checks or deliberately public APIs
  • function Requires a function-specific key Default for most APIs; keys managed at function or host level
  • admin Requires the host master key Powerful; treat like a root secret

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:

HTTP function accepts a user request and validates input.

Optional input bindings load templates or configuration blobs.

Code calls Azure AI services with the SDK (not every AI call is a binding).

Output bindings write results to Cosmos DB or enqueue a Queue message.

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.