AI-200 Azure Functions: Triggers, Bindings, Configuration and Deployment

In the Python v2 programming model, every function is a decorated Python function registered on a single func.FunctionApp object in function_app.py; the decorators declare the trigger and bindings, so there is no function.json file per function (that is the v1 model). The Python worker discovers functions by importing function_app.py when the host starts.

import azure.functions as func

app = func.FunctionApp(http_auth_level=func.AuthLevel.FUNCTION)

@app.route(route="health", methods=["GET"])
def health(req: func.HttpRequest) -> func.HttpResponse:
    return func.HttpResponse("ok")

• Organise large apps with blueprints. Declare related functions on a func.Blueprint() in another module, then call app.register_functions(bp) in function_app.py. The result is still one function app, one deployment and one set of app settings. A second FunctionApp object in another module is not how the model is extended.
• App-wide HTTP defaults. HTTP functions default to the function authorization level. Passing http_auth_level to func.FunctionApp changes the default for every HTTP function the app registers, including ones added later; auth_level on one @app.route overrides it for that function.
• A failed import hides every function. Because indexing imports function_app.py, a top-level import that raises ModuleNotFoundError stops indexing, and the app lists no functions at all, not just the new one. The usual cause is a package installed in the local virtual environment but missing from requirements.txt, which is all a remote build installs.

An HTTP trigger's route is a template relative to the app's route prefix, which is api by default, so route="customers/{customer_id}" is served at /api/customers/7. Never repeat api in the route.

• Route parameters appear in braces and are read from req.route_params; query-string values come from req.params.
• Route constraints such as {id:int}, {name:alpha} or an optional {id?} make the host match only values of that shape. A request that doesn't match gets a 404 before your code runs, so no validation code is needed for the shape.
• The prefix is app-wide configuration in host.json under extensions.http.routePrefix. Setting it to an empty string serves every function from the root without editing any route. local.settings.json is not the place: it never reaches Azure.
• Reserved paths. The host owns /admin and /runtime. With the default prefix your routes sit under /api and can't collide; with an empty prefix, a route whose first segment is a reserved name (for example runtime/status) falls into the host's space and returns 404. Choose a different first segment (or keep a prefix) — authorization level and methods are only checked after routing reaches the function.

@app.route(route="invoices/{number:int}/lines", methods=["GET"])
def list_lines(req: func.HttpRequest) -> func.HttpResponse:
    invoice_number = req.route_params.get("number")
    page = req.params.get("page", "1")
    ...

The authorization level decides which access key a request must carry; it is a shared-secret check, not user authentication. For signed-in users, turn on App Service Authentication; for browser callers on another origin, configure the app's CORS allowed origins.

• Key types. A function key is scoped to one function. A host key works for every function in the app at the function level, including functions added later. The master key (_master) is a host key with admin reach. System keys are created by extensions for their own endpoints under /runtime/webhooks (for example blobs_extension), not for your HTTP functions. Least privilege: a function key for a caller of one function, a host key for a caller of all of them, the master key for nobody who doesn't need admin APIs.
• Sending a key: the x-functions-key header or the code query parameter.
• Locally, keys aren't enforced. Core Tools (func start, outside a container) disables authorization whatever the level, so calls without a key succeed locally and then return 401 in Azure. The fix is to send a key, not to change the level.
• User identity. Keys can't tell you which employee is calling. Enable App Service Authentication with the Microsoft identity provider and require authentication: the platform validates the Microsoft Entra ID token before your code runs and passes the user's identity in headers such as X-MS-CLIENT-PRINCIPAL. Validating tokens yourself with a library works but is code you then own.
• CORS is enforced by browsers, which is why curl and server-side calls succeed while a single-page app on another origin is blocked. In Azure, add the origin to the function app's CORS allowed origins (portal or az functionapp cors add); the platform then returns Access-Control-Allow-Origin. Host.CORS in local.settings.json only configures the local Core Tools host.

Bindings connect a function to another service declaratively: an input binding reads data before your code runs, and an output binding writes data after it returns, so you write no SDK code for simple reads and writes.

• Output bindings. Either return the value (when the return isn't already the HTTP response) or declare a func.Out[T] parameter and call .set(value). Reassigning the parameter writes nothing. The runtime performs the write after the function finishes.
• You can't catch output-binding errors. Because the write happens after your code completes, a failure can't be caught in your code or turned into a response of your choosing. When the code must react to a failed write, use the service's SDK instead.
• Reuse SDK clients. An instance runs many invocations, and each client opens its own connections. Create clients such as CosmosClient once at module scope and reuse them; creating one per request exhausts outbound connections under load.

@app.route(route="feedback", methods=["POST"])
@app.queue_output(arg_name="note", queue_name="feedback-in",
                  connection="FeedbackStorage")
def capture_feedback(req: func.HttpRequest,
                     note: func.Out[str]) -> func.HttpResponse:
    note.set(req.get_body().decode())
    return func.HttpResponse("queued", status_code=202)

Binding expressions fill binding properties at run time:

A Cosmos DB input binding does a point read when it is given the item id and its partition_key value. Here the container is partitioned on /tenant, so the route carries both values:

@app.route(route="tenants/{tenant}/profiles/{profile_id}",
           methods=["GET"])
@app.cosmos_db_input(arg_name="profile", database_name="crm",
                     container_name="profiles",
                     connection="CrmCosmos",
                     id="{profile_id}", partition_key="{tenant}")

SDK type bindings let a Python v2 binding hand you an Azure SDK object instead of content. With the azurefunctions-extensions-bindings-blob package in requirements.txt (it pulls in azurefunctions-extensions-base), a blob trigger or input parameter can be typed as blob.BlobClient, blob.ContainerClient or blob.StorageStreamDownloader from azurefunctions.extensions.bindings.blob. A BlobClient streams large blobs instead of loading them into memory and exposes operations such as set_blob_metadata(), all through the binding's connection. func.InputStream and bytes are content-only. The extension bundle in host.json is a host-side setting and installs no Python modules.

These triggers start background work without an HTTP caller, and each has defaults that decide timing, retries and concurrency.

Timer trigger

• Schedules are six-field NCRONTAB expressions with a leading seconds field: {second} {minute} {hour} {day} {month} {day-of-week}. Daily at 04:15 is "0 15 4 * * *"; "0 */15 4 * * *" would fire four times in that hour.
• The default time zone is UTC. On Premium and Dedicated plans WEBSITE_TIME_ZONE (Windows) or TZ (Linux) can change it, but Flex Consumption doesn't support either, so convert to UTC yourself: 09:00 in India (UTC+5:30, no daylight saving) is 03:30 UTC, so "0 30 3 * * *".
• Scale-out doesn't multiply runs: the timer takes a lock in the host storage account so one instance runs each occurrence. The lock is per app (host ID), so a deployment slot is a second app and runs its own schedule.
• run_on_startup=True also fires the function whenever the runtime starts — on restarts and scale-out — which produces extra runs at unpredictable times; avoid it in production. use_monitor tracks occurrences to detect past-due schedules; it doesn't retry anything.

Storage queue trigger

• When the function raises, the message becomes visible again and is retried. After maxDequeueCount attempts (default 5) it moves to <queue>-poison. To log or alert on those messages, add a function (or other reader) on the poison queue. visibilityTimeout sets the delay between attempts.
• Concurrency per function per instance is batchSize + newBatchThreshold. The runtime fetches batchSize messages (default 16) and fetches another batch when in-flight messages drop to newBatchThreshold, whose default is N × batchSize / 2 for N vCPUs. To cap concurrency at a downstream limit of six, set batchSize 6 and newBatchThreshold 0. maxPollingInterval only governs polling of an empty queue.

{
  "version": "2.0",
  "extensions": {
    "queues": {
      "maxDequeueCount": 4,
      "visibilityTimeout": "00:02:00",
      "batchSize": 6,
      "newBatchThreshold": 0
    }
  }
}

Blob trigger: polling or Event Grid

• By default the blob trigger discovers new blobs by polling (storage logs plus periodic container scans), which gets slow on containers with millions of blobs. Queue polling settings, more instances or blob parallelism don't change that.
• The Event Grid source (source="EventGrid" on blob_trigger) receives a BlobCreated event per upload, giving low latency while keeping the blob trigger. It needs an Event Grid subscription on the storage account with a Web Hook endpoint at the blob extension's webhook: https://<app>.azurewebsites.net/runtime/webhooks/blobs?functionName=Host.Functions.<name>&code=<blobs_extension key>. The "Azure Function" endpoint type targets Event Grid triggers, not blob triggers.
• Flex Consumption supports only the Event Grid source, so a polling blob trigger moved to Flex never fires until both changes are made.
• The blob trigger also uses the same account's Queue service to track blobs that keep failing (poison blobs) — which matters when you move its connection to a managed identity (see below).

Runtime retry policies apply only to the Timer, Azure Cosmos DB, Event Hubs and Kafka triggers; every other trigger either retries on its own or not at all, and HTTP triggers never use retry policies.

@app.event_hub_message_trigger(arg_name="event",
                               event_hub_name="telemetry",
                               connection="TelemetryHub")
@app.retry(strategy="fixed_delay", max_retry_count="3",
           delay_interval="00:00:10")
def ingest(event: func.EventHubEvent) -> None:
    ...

A fixed_delay policy takes delay_interval; exponential_backoff takes minimum_interval and maximum_interval. max_retry_count="-1" retries indefinitely. That matters for Event Hubs: the trigger doesn't redeliver failed events, and without a policy the checkpoint advances and the batch is lost. With a policy, the checkpoint isn't written until the retries finish, so an unbounded policy holds the partition until the downstream store recovers. Service Bus dead-letter handling and Event Grid retry settings themselves belong to the messaging lesson.

Function app configuration lives in application settings, which the runtime exposes as environment variables (os.environ, os.getenv); a binding's connection property names a setting, or a group of settings with a shared prefix.

• local.settings.json is local only. Core Tools loads its Values into environment variables for func start; the file is never used in Azure, so code that works locally fails with a missing setting after publishing. Create the settings on the app: func azure functionapp publish <app> --publish-local-settings (-i) uploads them, or az functionapp config appsettings set --settings KEY=VALUE ... sets them (az functionapp config set is site configuration, and func settings add edits the local file).
• Identity-based connections replace a connection string with settings named <prefix>__<property>. The property depends on the service:

• A plain URL in the original single setting is parsed as a connection string and fails; the identity form always uses __ properties.
• The system-assigned identity is used by default. For a user-assigned identity add <prefix>__credential = managedidentity and either <prefix>__clientId or <prefix>__managedIdentityResourceId (never both). Managed identities have no client secret.
• Data-plane roles, least privilege: Azure Service Bus Data Receiver for a Service Bus trigger (Data Sender for output); for host storage Microsoft lists Storage Blob Data Owner as the minimum, which also covers the blob locks the timer trigger takes. Reader roles can't write, and management-plane roles such as Storage Account Contributor grant no data access. Key Vault references and App Configuration are covered in the security lesson.

For a new serverless app, Microsoft recommends the Flex Consumption plan: Linux, execution-based billing with scale to zero, virtual network integration, always ready instances and per-function scaling. Choose another plan when a requirement rules Flex out — most often deployment slots.

Flex Consumption scale settings

• Per-function scaling. All HTTP (and SignalR) triggers share the http group, Event Grid-based blob triggers the blob group and Durable triggers the durable group; every other function, such as a Service Bus trigger, scales on its own instances (function:<name>). A bursty background function therefore doesn't take capacity from the API — no app split needed.
• Always ready instances are set per group or per function (for example 2 for function:resize_images), which removes cold starts for that group only and bills a baseline only for it. Prewarmed instances are a Premium concept.
• Maximum instance count limits on-demand instances. Always ready instances don't count toward it, and it applies to each independently scaling group, not the app as a whole — so a maximum of 20 with 3 always ready for http can show 23 HTTP instances plus up to 20 for a separately scaling function.
• Instance memory (512, 2,048 or 4,096 MB) sets memory and CPU per instance; it doesn't change HTTP time limits.

Long-running HTTP work

functionTimeout in host.json limits how long an execution may run (default 30 minutes and unbounded maximum on Flex Consumption, Premium, Dedicated with Always On, and Container Apps; 5 and 10 minutes on legacy Consumption). Separately, an HTTP-triggered function must respond within 230 seconds on every plan because of the load balancer's idle timeout — the work continues, but the caller loses the response. Return quickly instead: the Durable Functions async HTTP API, or a queue message that a background function processes, with the result stored for the caller to fetch.

import azure.durable_functions as df
app = df.DFApp(http_auth_level=func.AuthLevel.FUNCTION)

@app.route(route="exports", methods=["POST"])
@app.durable_client_input(client_name="client")
async def start_export(req: func.HttpRequest, client):
    instance_id = await client.start_new(
        "export_orchestrator", None, req.get_json())
    return client.create_check_status_response(req, instance_id)

create_check_status_response returns 202 Accepted with statusQueryGetUri and the other management URLs; create_http_management_payload returns only the URLs as a dictionary.

Deploy a Python function app with Core Tools (func azure functionapp publish <app>), the Azure CLI or a CI/CD pipeline; the decisions that matter are where dependencies are built, where the package lives and how releases reach production.

• Remote build. Python apps run on Linux, so packages with compiled extensions must be built for Linux. A remote build (the Core Tools default for Python, or --build remote) installs requirements.txt in Azure's Linux build environment. Zipping a Windows virtual environment ships the wrong binaries; --build local builds on your machine. PYTHON_ISOLATE_WORKER_DEPENDENCIES only addresses clashes with the worker's own packages.
• Run from package. With WEBSITE_RUN_FROM_PACKAGE, the zip is mounted read-only as the app's content directory, including any folder inside it. Write scratch files to the temp directory (Python's tempfile); they don't persist across invocations or instances.
• Flex Consumption has one deployment path: the package is uploaded to a blob container in the app's deployment storage (by default the AzureWebJobsStorage account), and each instance loads it on startup. Azure Files content shares (WEBSITE_CONTENTSHARE) and Kudu file deployment belong to other plans.

Deployment slots (Premium and Dedicated)

• A slot is a live app with its own host name; swapping applies the target's settings to the source slot, warms its instances, then switches routing, so production traffic sees no cold start. The command is az functionapp deployment slot swap --slot staging --target-slot production.
• App settings move with the content on swap unless marked as deployment slot settings. Make environment-specific values (database endpoints, connection prefixes) sticky in both slots. Auto swap and swap with preview change when or how a swap happens, not which settings stay.
• Triggers run in every slot: a staging timer fires on its schedule, and the timer lock doesn't coordinate across slots. Disable it in staging with AzureWebJobs.<FUNCTION_NAME>.Disabled = true as a sticky slot setting, so it never moves to production.
• Flex Consumption and Container Apps hosting have no deployment slots; if a release process requires swaps, choose Elastic Premium or Dedicated.