This chapter covers Azure Functions triggers and bindings, a core compute concept on the AZ-204 exam. Triggers define how a function is invoked, while bindings provide a declarative way to connect to data sources and sinks without writing boilerplate code. Approximately 15-20% of exam questions touch this area, often testing your ability to choose the correct trigger type, configure bindings in function.json or via attributes, and understand scaling behaviors. Mastering this topic is essential for passing the Azure Developer Associate exam.
Jump to a section
Imagine a corporate mailroom. A mailroom clerk (the Azure Functions runtime) processes incoming mail. Each piece of mail has a specific type: a letter, a package, or a courier delivery. The clerk has a set of rules (triggers) that define what to do when a specific type arrives. For example, when a courier delivery arrives (HTTP trigger), the clerk immediately calls the recipient. When a package arrives (Blob trigger), the clerk scans it and places it in a bin, then later a worker picks it up. The clerk also has a set of tools (bindings) that allow him to interact with the mail without manually handling it: a stamp (output binding) to mark the package as processed, a logbook (input binding) to look up the recipient's address. The clerk never touches the mail directly; he uses the stamp and logbook. In Azure Functions, triggers are like the mail type that initiates processing, and bindings are like the tools that provide data input or output automatically without writing code to connect to the source or destination. The runtime handles the connection details, just as the clerk uses the stamp without knowing the ink chemistry.
What Are Triggers and Bindings?
Azure Functions is a serverless compute service that lets you run code in response to events. A trigger is what starts the execution of a function. Every function must have exactly one trigger. Bindings are optional and provide a way to connect your function to other Azure services (like Azure Storage, Cosmos DB, Service Bus, etc.) without writing the connection code. Bindings can be input (data flows into the function) or output (data flows out of the function).
How They Work Internally
The Azure Functions runtime reads the function configuration (function.json for v1/v2 or attributes in code for v3+) to determine the trigger and bindings. At startup, the runtime creates a binding context that sets up connections to the specified services. When an event occurs (e.g., a new blob is uploaded), the trigger fires and the runtime invokes the function, passing the trigger data and any input bindings as parameters. Output bindings are written to after the function executes. The runtime manages the lifecycle of connections, retries, and scaling.
Types of Triggers
HTTP Trigger: Invoked by an HTTP request. Supports GET, POST, PUT, DELETE, etc. You can define authorization levels (anonymous, function, admin) and route templates. Key properties: authLevel, methods, route. Default timeout is 230 seconds (5 min for Premium plan).
Timer Trigger: Invoked on a schedule defined by a CRON expression. Uses a schedule property. CRON format: {second} {minute} {hour} {day} {month} {day-of-week}. For Azure Functions, the CRON expression includes six fields (seconds added). Example: 0 */5 * * * * runs every 5 minutes. Use %0 for immediate start? No, use true for runOnStartup.
Blob Trigger: Fires when a new or updated blob is detected in an Azure Storage container. Uses path property like samples-workitems/{name}. The runtime uses a polling mechanism (default 10 seconds) and checks for new blobs. There is a known limitation: blob triggers may fire multiple times for the same blob due to internal retries. Use LeaseDuration and LeaseState properties.
Queue Trigger: Fires when a new message arrives in an Azure Storage Queue. Properties: queueName, connection. Polling interval: default 16 times per second (exponential backoff). Batch size: 16 messages. Visibility timeout: default 30 seconds. Poison messages: after 5 failed attempts, message moves to a poison queue named {original-queue-name}-poison.
Event Grid Trigger: Fires when an Event Grid event is received. Requires an Event Grid subscription. Supports filtering by event type and subject. The function receives an array of events.
Event Hubs Trigger: Fires when events are sent to an Event Hub. Uses consumer group and event hub name. Supports checkpointing via Storage.
Service Bus Trigger: Fires when a message is received from a Service Bus queue or topic. Properties: queueName or topicName/subscriptionName, connection. Supports message sessions. Max message count: default 256 (can be increased). Lock duration: default 30 seconds.
Cosmos DB Trigger: Fires when there are changes in a Cosmos DB container (change feed). Requires a lease container. Uses databaseName, containerName, leaseContainerName. The function receives a batch of changed documents.
SignalR Trigger: Fires when a message is sent via Azure SignalR Service.
Types of Bindings
Bindings are declared in the function.json file (v1/v2) or using attributes in code (v3+). Each binding has a direction: in (input), out (output), or inout (for some like SignalR).
Input Bindings: Provide data to the function. Examples: Blob input, Cosmos DB input, Table input, SQL input (preview). The binding parameter is populated before the function runs.
Output Bindings: Write data from the function. Examples: Blob output, Cosmos DB output, Queue output, Table output, SendGrid, Twilio, Event Hubs output. The function returns a value or uses an IAsyncCollector to write multiple items.
Configuration
In the portal, you configure triggers and bindings via the Integrate tab. In code-first development (C# class library, JavaScript, Python, etc.), you use attributes or decorators. Example C#:
[FunctionName("MyFunction")]
public static void Run(
[HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
[Blob("samples-workitems/{query.id}", FileAccess.Read)] Stream myBlob,
[Queue("outqueue")] out string myQueueItem,
ILogger log)
{
// function code
}For JavaScript, function.json:
{
"bindings": [
{
"authLevel": "function",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": ["get"]
},
{
"type": "blob",
"direction": "in",
"name": "myBlob",
"path": "samples-workitems/{query.id}",
"connection": "AzureWebJobsStorage"
},
{
"type": "queue",
"direction": "out",
"name": "myQueueItem",
"queueName": "outqueue",
"connection": "AzureWebJobsStorage"
}
]
}Connection Strings and Identity
Bindings require a connection string or managed identity to access the service. For Storage, use AzureWebJobsStorage. For other services, use the connection property. In production, use managed identity instead of connection strings for security. The runtime reads the connection from the Values section of local.settings.json (local) or Application Settings (Azure).
Scaling and Performance
Consumption Plan: Functions scale out based on trigger events. For HTTP triggers, the number of instances can scale up to 200. For non-HTTP triggers, scaling is based on queue length, event rate, etc. There is a 5-minute timeout for HTTP triggers (230 seconds) and 10 minutes for all other triggers (configurable up to 10 min).
Premium Plan: Provides pre-warmed instances, unlimited execution duration (60 min default), and VNET connectivity.
Dedicated Plan: Functions run on a VM you manage.
Error Handling and Retries
Queue Trigger: If a function fails, the message is returned to the queue with a visibility timeout (default 0). After 5 retries, the message moves to poison queue.
Blob Trigger: If a function fails, the runtime retries up to 5 times with a 1-minute delay between attempts. After that, the blob is ignored.
Timer Trigger: If the function fails, the next scheduled run still occurs.
HTTP Trigger: The function returns an HTTP 500 status on failure.
Binding Expressions
You can use binding expressions in paths and properties. For example, {queueTrigger} refers to the queue message body, {date} is the current date, {rand-guid} generates a random GUID. These are resolved at runtime.
Supported Languages
Triggers and bindings are supported in C#, JavaScript, Python, Java, PowerShell, TypeScript, and F#. Not all bindings are available in all languages; check documentation.
Security
Authorization levels: anonymous (no key), function (function-specific key), admin (master key). Keys are stored in Azure and can be managed via portal or API.
For non-HTTP triggers, authentication is via connection strings or managed identity. Managed identity is recommended.
Monitoring
Use Application Insights to monitor function executions. Logs show trigger details, bindings used, and execution time. You can set up alerts on failures.
Common Pitfalls
Blob Trigger fires multiple times: Due to internal retries, ensure idempotency.
Queue Trigger batch size: Default 16; if processing takes long, reduce batch size.
Connection string missing: Runtime fails to load bindings.
Timer trigger CRON expression: Remember six fields, not five. Example: 0 0 8 * * 1-5 runs at 8:00 AM weekdays.
Binding name conflicts: The name property in function.json must match the parameter name in code.
Exam Tips
Know the default values: queue batch size 16, visibility timeout 30 sec, blob polling interval 10 sec.
Understand that every function must have exactly one trigger.
Be able to identify the correct trigger for a scenario: e.g., blob upload -> Blob trigger; scheduled task -> Timer trigger; message queue -> Queue trigger.
Know how to configure binding expressions: {queueTrigger}, {date}, {rand-guid}.
Recognize that output bindings can be used to write to multiple destinations.
Understand that input bindings are read before function execution.
Know the difference between in, out, and inout directions.
Be aware that some bindings are only available in certain plans (e.g., SignalR requires Premium plan).
Define function trigger type
First, determine what event should start your function. For example, if you want to process a file when it's uploaded to Blob Storage, choose Blob trigger. If you want to respond to an HTTP request, choose HTTP trigger. The trigger type determines how the function is invoked and what data is passed to it. Ensure that the trigger is appropriate for the event source; for instance, using a Timer trigger for a scheduled task. Each function can have only one trigger, so choose wisely.
Configure trigger properties
Set the required properties for your chosen trigger. For Blob trigger, specify the container path and optionally a pattern for blob names. For Queue trigger, specify the queue name and connection string. For Timer trigger, provide a CRON expression. For HTTP trigger, set authorization level, allowed HTTP methods, and route template. These properties are defined in the function.json file or via attributes. Incorrect configuration can cause the function to not fire or to fire unexpectedly.
Add input bindings (optional)
If your function needs to read data from another service before execution, add input bindings. For example, to read a blob that is referenced in the trigger, add a Blob input binding with the path containing a binding expression like `{name}`. The runtime will automatically fetch the data and pass it as a parameter to your function. Input bindings are read-only and are populated before the function code runs.
Add output bindings (optional)
If your function needs to write data to a service after execution, add output bindings. For example, to write a message to a queue, add a Queue output binding. In C#, you can use `out` parameters or `ICollector<T>`/`IAsyncCollector<T>` to write multiple items. In JavaScript, you use `context.bindings`. Output bindings are written after the function completes. You can have multiple output bindings.
Test and monitor the function
Deploy the function and test it by triggering the event. Use Application Insights to monitor executions, view logs, and identify failures. Check the trigger's behavior: for Blob trigger, ensure new blobs are detected; for Queue trigger, verify messages are processed. Monitor for duplicate executions or missed events. Adjust configuration if needed, such as increasing batch size or changing CRON schedule.
Scenario 1: Order Processing System
A company processes orders from an e-commerce site. When an order is placed, a message is sent to an Azure Storage Queue. An Azure Function with a Queue trigger reads the message, validates the order, writes order details to Cosmos DB (output binding), and sends a confirmation email via SendGrid (output binding). The function uses input bindings to look up customer details from a Table storage. This serverless architecture scales automatically with order volume. Common issues: if the queue message format changes, the function may fail; poison messages after 5 retries require monitoring. The team sets up dead-letter queue alerts.
Scenario 2: Image Processing Pipeline
A media company uploads images to Blob Storage. A Blob-triggered function resizes the image and stores thumbnails in another container. It uses an output binding to write the thumbnail. The function also logs processing details to a queue for further analysis. Challenges: blob triggers can fire multiple times for the same blob due to internal retries; the function must be idempotent (e.g., check if thumbnail already exists). The team uses a blob input binding to read the original image. They set the LeaseDuration to prevent concurrent processing.
Scenario 3: Scheduled Data Export
A financial institution needs to generate daily reports at 2:00 AM. A Timer-triggered function runs a CRON schedule 0 0 2 * * *. It queries a SQL database (using a SQL input binding) and writes the report to Blob Storage (output binding). The function uses managed identity to connect to SQL and Storage. Issues: if the function takes longer than 10 minutes (Consumption plan limit), it may timeout; they moved to Premium plan. They also handle time zone differences by using UTC in the CRON expression.
AZ-204 Objective Coverage
This chapter aligns with objective "1.1 - Create Azure Functions" and related sub-objectives. The exam tests your ability to:
Choose the correct trigger for a given scenario.
Configure bindings in function.json or via attributes.
Understand binding expressions.
Identify default values and limits.
Recognize scaling behaviors.
Troubleshoot common issues like poison messages.
Common Wrong Answers
Choosing HTTP trigger for blob upload: Candidates often select HTTP trigger because they think of webhooks, but the correct answer is Blob trigger. Blob trigger automatically detects new blobs.
Using Timer trigger for event-driven processing: When the event is a new message in a queue, the correct trigger is Queue trigger, not Timer. Timer is for scheduled tasks.
Confusing input and output bindings: Input bindings provide data to the function; output bindings write data. Exam questions may ask which direction to use for a given task.
Incorrect CRON expression: Remember that Azure Functions CRON includes seconds. A common trap: 0 0 8 * * * (every day at 8:00:00 AM) vs. 0 8 * * * (missing seconds field, invalid).
Forgetting that every function needs exactly one trigger: Some questions may present a function with two triggers; that is invalid.
Specific Numbers and Terms
Queue trigger default batch size: 16.
Queue trigger visibility timeout: 30 seconds.
Blob trigger polling interval: 10 seconds.
Timer CRON: 6 fields.
HTTP trigger timeout: 230 seconds (Consumption plan).
Poison queue suffix: -poison.
Retry count for queue: 5.
Binding directions: in, out, inout.
Authorization levels: anonymous, function, admin.
Edge Cases
Blob trigger with large blobs: If a blob is very large, the function may timeout. Consider using a queue trigger to process blob references.
Queue trigger with batch processing: The function receives an array of messages; ensure the code handles multiple messages.
Event Grid trigger: The function receives an array of events; the trigger fires once per event batch.
Binding expressions with `{queueTrigger}`: This resolves to the queue message content, not the message ID.
How to Eliminate Wrong Answers
Understand the event source: If the event is a file upload, eliminate HTTP and Timer triggers.
Check for required parameters: For HTTP trigger, the function must accept an HttpRequest; for Blob trigger, it must accept a Stream.
Verify binding directions: If the function needs to read data, look for direction: "in"; if it needs to write, direction: "out".
Look for default values: Exam questions may ask for the default batch size; if a question says "batch size of 32", it's wrong (default is 16).
Remember scaling limits: Consumption plan has a 10-minute max execution for non-HTTP triggers; Premium plan has 60 minutes.
Every Azure Function must have exactly one trigger; multiple triggers not allowed.
Timer trigger uses a 6-field CRON expression (seconds included).
Queue trigger default batch size is 16 messages; after 5 failed retries, message goes to poison queue.
Blob trigger polls every 10 seconds for new blobs; may fire multiple times for the same blob.
Input bindings provide data to the function before execution; output bindings write data after execution.
Binding expressions like {queueTrigger}, {date}, and {rand-guid} are resolved at runtime.
HTTP trigger timeout is 230 seconds on Consumption plan; non-HTTP triggers have 10-minute timeout.
Use managed identity instead of connection strings for secure access to Azure services.
Poison queue name format: {original-queue-name}-poison.
Event Grid trigger receives an array of events; the function fires per batch.
These come up on the exam all the time. Here's how to tell them apart.
HTTP Trigger
Invoked by an HTTP request (GET, POST, etc.)
Supports authorization levels: anonymous, function, admin
Can return HTTP responses (200, 400, etc.)
Scales based on HTTP request rate
Timeout: 230 seconds (Consumption plan)
Queue Trigger
Invoked when a new message is added to an Azure Storage Queue
No authorization; uses connection string for queue access
Does not return a direct response; can use output bindings
Scales based on queue length and message rate
Timeout: 10 minutes (Consumption plan, configurable)
Mistake
A function can have multiple triggers.
Correct
Each Azure Function can have exactly one trigger. You cannot have two triggers on the same function. If you need multiple event sources, consider separate functions or use a single trigger that listens to a common event hub.
Mistake
Timer trigger CRON expression uses 5 fields like Linux cron.
Correct
Azure Functions Timer trigger uses a 6-field CRON expression including seconds. Example: `0 0 8 * * *` (seconds, minutes, hours, day, month, day-of-week). A 5-field expression will cause an error.
Mistake
Blob trigger fires exactly once per blob.
Correct
Blob triggers may fire multiple times for the same blob due to internal retries and race conditions. Your function should be idempotent to handle duplicate invocations.
Mistake
Output bindings are only for writing a single item.
Correct
Output bindings can write multiple items using `ICollector<T>` or `IAsyncCollector<T>` in C#, or by calling `context.bindings` methods in JavaScript. You can also have multiple output bindings per function.
Mistake
HTTP trigger functions can run indefinitely.
Correct
HTTP triggers have a timeout of 230 seconds (about 4 minutes) on the Consumption plan. On Premium and Dedicated plans, the default is 30 minutes but can be configured up to 60 minutes (Premium) or unlimited (Dedicated).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An input binding provides data to your function from an external service before the function runs. For example, a Blob input binding reads a blob and passes it as a parameter. An output binding writes data from your function to an external service after the function runs, such as writing a message to a queue. Input bindings are read-only; output bindings are write-only.
Yes, you can have multiple output bindings in a single function. For example, you can write to a queue and a blob in the same function. In C#, you use `out` parameters or `ICollector<T>` for each binding. In JavaScript, you set properties on `context.bindings`.
If a queue trigger function fails to process a message after 5 attempts (default), the message is moved to a poison queue named `{original-queue-name}-poison`. You should monitor this queue and handle poison messages separately, perhaps by logging them or notifying an administrator. You can also set custom retry policies.
On the Consumption plan, HTTP-triggered functions have a timeout of 230 seconds (about 4 minutes). All other triggers have a maximum of 10 minutes (configurable up to 10 minutes). On the Premium plan, the default timeout is 30 minutes, configurable up to 60 minutes. On the Dedicated plan, you can set the timeout up to 10 minutes (default) or unlimited (by setting `functionTimeout` to -1).
Instead of using a connection string, you can configure the binding to use a managed identity. In the binding definition, set the `connection` property to a setting name that contains the identity configuration (e.g., `AzureWebJobsStorage__accountName`). Then assign the appropriate RBAC role to the function's managed identity (e.g., Storage Blob Data Contributor). This is more secure than connection strings.
No, each function can have only one trigger. To handle multiple event sources, you can create separate functions for each source, or use a single trigger that listens to a common event hub or queue that aggregates events.
The default batch size is 16 messages. This means the runtime retrieves up to 16 messages at a time and passes them to the function as an array. You can configure this in the `host.json` file by setting `batchSize` under `queues`.
You've just covered Azure Functions Triggers and Bindings — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?