Connect to and Consume Azure Services · Topic 2 of 2
Developing and Deploying Azure Functions
AI-200 Azure Functions: triggers and bindings, building serverless APIs, the Python programming model, hosting plans, app settings and deployment.
- 4 min
- One trigger per function; any number of input and output bindings.
- Python v2 model declares triggers and bindings with decorators.
- host.json applies to all functions; local.settings.json is local only.
What it is
Azure Functions runs small pieces of code in response to a trigger, such as an HTTP request, a queue message or a timer. Bindings connect the function to other services declaratively, so you read and write data without writing connection code. Functions are a common way to build serverless APIs and event handlers for AI back ends.
How it works
Triggers and bindings
| Kind | Examples |
|---|---|
| Trigger (exactly one per function) | HTTP, Timer, Service Bus, Event Grid, Blob Storage, Queue Storage, Cosmos DB |
| Input binding | Read a blob or a Cosmos DB document when the function runs |
| Output binding | Write to a queue, a blob or Cosmos DB by returning or setting a value |
In the Python v2 programming model, triggers and bindings are declared with decorators on the function in code, instead of a separate function.json file.
Serverless APIs
- An HTTP trigger turns a function into an API endpoint.
- The authorization level controls access: anonymous, function key or admin key. For stronger security, put the API behind App Service authentication (Microsoft Entra ID) or API Management.
- Keep HTTP functions quick: an HTTP-triggered function has at most 230 seconds to respond, whatever the timeout setting. For long AI jobs, accept the request, queue the work and return a status the client can check.
Configuration
| File or setting | Purpose |
|---|---|
| host.json | Settings for all functions in the app, such as logging and trigger behavior |
| local.settings.json | Local development settings only; not published unless you use the Core Tools --publish-local-settings option |
| App settings | Configuration in Azure, read as environment variables; can use Key Vault references |
| Identity-based connections | Connect bindings to services with a managed identity instead of connection strings |
Hosting plans
| Plan | Notes |
|---|---|
| Flex Consumption | Serverless, Linux only, scales to zero, fast per-function scaling, always-ready instances, virtual network integration; Microsoft's recommended serverless plan; no deployment slots |
| Consumption (legacy) | The original serverless plan; pay per execution, scales to zero, 10-minute maximum timeout. Linux Consumption is retiring (Python runs only on Linux), and Microsoft says to use Flex Consumption for new serverless apps |
| Premium | Prewarmed instances to avoid cold starts, virtual network integration, longer run times |
| Dedicated (App Service plan) | Runs on App Service instances you already pay for |
| Container Apps | Runs containerized function apps in an Azure Container Apps environment |
Deploying
- Publish from the command line with Azure Functions Core Tools, from VS Code, or from a CI/CD pipeline.
- Package deployment (zip deploy, or run from package) deploys the app as a single package.
- Use deployment slots where supported (not on Flex Consumption) to test before swapping to production.
A worked example: an upload API is an HTTP-triggered function. It validates the request, writes the document to Blob Storage with an output binding, and puts a message on a Service Bus queue. A second function with a Service Bus trigger generates embeddings and writes them to Cosmos DB with an output binding, using a managed identity for both connections.
When a question says "without writing code to connect to the queue", the answer is a binding.
How the exam asks about this
- "Run code every night at 2 AM." A timer trigger with a schedule expression.
- "Avoid cold starts and connect to a virtual network." The Premium plan, or Flex Consumption with always-ready instances.
- "Write the result to a queue without SDK code." An output binding.
What to remember for the exam
- One trigger per function; any number of input and output bindings.
- Python v2 model declares triggers and bindings with decorators.
- host.json applies to all functions; local.settings.json is local only.
- App settings are environment variables; use managed identities and Key Vault references.
- Plans: Flex Consumption, Consumption, Premium, Dedicated.
local.settings.json is not published by default. Settings the app needs in Azure must be added as app settings.
Common mistakes
Giving a function two triggers. Each function has exactly one trigger.
Expecting local.settings.json values in Azure. Configure app settings.
Running long AI jobs inside an HTTP request. Queue the work instead.
Check yourself
How many triggers can a function have?
Exactly one.
What is the difference between a trigger and a binding?
A trigger starts the function; bindings read or write data from other services declaratively.
Which file holds local development settings and is not published to Azure by default?
local.settings.json.
Topic 2 of 2 in Connect to and Consume Azure Services
Test yourself on Connect to and Consume Azure Services
The full Microsoft AI-200 question bank has 650 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Microsoft. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.