Azure Functions Trigger Types: HTTP, Timer, Blob, Queue

Azure Functions is a serverless compute service that lets you run code in response to events without managing infrastructure. A trigger is what causes a function to execute. Each function must have exactly one trigger. The trigger defines how the function is invoked and carries associated data (the input payload). There are four primary trigger types covered in AZ-204: HTTP, Timer, Blob, and Queue. Each is designed for different scenarios and has specific configuration parameters, scaling behaviors, and limitations.

HTTP triggers allow a function to be invoked via an HTTP request. This is the most common trigger for building REST APIs, webhooks, and integrating with other services that can make HTTP calls.

How it works: When an HTTP request arrives at the function endpoint, the Azure Functions runtime deserializes the request into an HttpRequestData object (for .NET isolated) or HttpRequest (for in-process). The function processes the request and returns an HttpResponseData or IActionResult. The trigger supports GET, POST, PUT, DELETE, and other HTTP methods. You can define routes using route templates, e.g., api/orders/{id}.

Key configuration: - Authorization level: Determines whether the request requires a key. Options are anonymous, function, admin. function requires a function-specific key. admin requires the master key. - Route template: Defines the URL pattern, including parameters. - Allowed HTTP methods: Can restrict to specific methods.

Security: By default, HTTP triggers require a function key or admin key unless set to anonymous. The keys are stored in the function app settings and can be managed via the portal or CLI. The master key provides full access and should be protected.

Scaling: HTTP triggers scale out based on the number of incoming requests. Each instance can handle multiple requests concurrently. The consumption plan scales from 0 to 200 instances by default (configurable).

Limitations: The maximum request body size is 100 MB (for Functions runtime 3.x+). The function execution has a timeout of 5 minutes on the Consumption plan (configurable up to 10 minutes) and 30 minutes on Premium/App Service plans. For longer operations, use Durable Functions or async patterns.

Timer triggers execute a function on a schedule. This is useful for periodic tasks like data cleanup, report generation, or health checks.

How it works: The trigger uses a cron expression to define the schedule. The cron expression is a string of six fields: {second} {minute} {hour} {day} {month} {day-of-week}. For example, 0 0 */1 * * * means every hour at the start of the hour. The timer trigger is driven by a singleton timer that runs in the function host. When the timer fires, the runtime invokes the function with a TimerInfo object that contains the schedule and past due information.

Key configuration: - Schedule: A cron expression (e.g., 0 0 9 * * 1-5 for weekdays at 9 AM). - Run on startup: A boolean that if true, runs the function immediately when the host starts, then follows the schedule. - Use monitor: When true (default), the runtime keeps track of schedule times and can compensate for missed executions if the host was down.

Scaling: Timer triggers run on a single instance. If the function app scales out, only one instance will execute the timer trigger to avoid duplicate runs. This is handled by the runtime using distributed locking (blob leases).

Limitations: The minimum interval is 1 second (cron * * * * * *). However, for practical purposes, intervals less than a minute are rarely used because the timer might not be precise due to host load. The maximum execution time is same as the function timeout.

Cron expression details: - 0 */5 * * * * = every 5 minutes - 0 0 0 * * * = daily at midnight - 0 0 0 1 * * = first day of every month at midnight - 0 0 9-17 * * 1-5 = every hour from 9 AM to 5 PM on weekdays

Blob triggers execute a function when a new blob is created or updated in an Azure Storage container. This is ideal for processing file uploads, image resizing, log analysis, etc.

How it works: The trigger polls Azure Storage for new or updated blobs. It uses a queue internally (Azure Storage queue) to track blobs that need processing. When a blob is added/updated, the storage account writes a message to a queue (the azure-webjobs-hosts container). The function runtime reads from this queue and invokes the function with the blob content and metadata. This polling mechanism introduces a small delay (typically seconds) but provides at-least-once delivery.

Key configuration: - Path: The container and optional blob path pattern, e.g., samples-workitems/{name}. The {name} binds to the blob name. - Connection: The storage account connection string (must be a general-purpose v2 or BlobStorage account). - Source: EventGrid (preferred for low latency) or BlobTrigger (polling). For EventGrid, you configure an event subscription.

Scaling: Blob triggers scale out based on the number of blobs being processed. Each function instance can process multiple blobs concurrently. The runtime uses a load-balancing algorithm to distribute blobs across instances.

Limitations: - The trigger cannot process blobs in the $logs or $web containers. - There is a 10-minute timeout for blob processing (can be extended with Premium plan). - If a function fails to process a blob, it retries up to 5 times by default (configurable via maxDequeueCount). - Blob trigger can miss blobs if the storage account is behind a firewall or has network restrictions, because the polling mechanism uses the storage queue which may not be accessible.

Best practice: For low-latency scenarios, use Event Grid-based blob triggers (Blob Storage events). This provides near-real-time triggering without polling.

Queue triggers execute a function when a new message is added to an Azure Storage queue. This is used for decoupled processing, task scheduling, and building reliable message-based architectures.

How it works: The trigger polls the specified Azure Storage queue for messages. When a message is found, it deletes the message from the queue (to prevent other instances from picking it up) and invokes the function with the message content. If the function fails, the message is returned to the queue (based on visibility timeout) for retry. After a specified number of failed attempts, the message can be moved to a poison queue.

Key configuration: - Queue name: The name of the queue (must be lowercase). - Connection: The storage account connection string. - Visibility timeout: The time a message is invisible after being dequeued (default 30 seconds). - Batch size: The number of messages to retrieve simultaneously (default 16, max 32). - Max dequeue count: Number of times to retry before moving to poison queue (default 5). - Polling interval: How often to check for messages (can be set via newBatchThreshold).

Scaling: Queue triggers scale based on the queue length. Each instance polls the queue and processes messages. The runtime uses a technique called "target-based scaling" to adjust the number of instances based on the queue length. In the Consumption plan, scaling can go up to 200 instances.

Limitations: - The maximum message size is 64 KB (base64 encoded). For larger payloads, store the data in a blob and pass the blob reference in the queue message. - The queue must be in the same storage account as the function app (or accessible via connection string). - The function must complete processing within the visibility timeout; otherwise, the message becomes visible again and may be processed by another instance (causing duplicate processing).

Poison queue handling: If a message fails processing maxDequeueCount times, it is moved to a queue named {originalqueuename}-poison. You can create a separate function triggered on the poison queue to handle or log failures.

Triggers work together with input and output bindings. For example, an HTTP trigger can use an output binding to write to a queue. A queue trigger can use an input binding to read a blob. Bindings reduce the amount of boilerplate code needed to connect to Azure services.

Use Application Insights to monitor function executions, failures, and performance. Enable logging for the specific trigger to see when blobs are polled or queue messages are dequeued. The host.json file contains global configuration for triggers, such as singleton for timer triggers and queues for queue triggers.

Azure Functions triggers are the entry point for serverless execution. Each trigger type serves a specific purpose and has unique configuration parameters. Understanding these triggers is critical for designing scalable, event-driven solutions on Azure. The AZ-204 exam tests not only the basics but also the nuances like scaling behavior, security, and integration with other services.

An e-commerce platform uses Azure Functions to process incoming orders. When a customer places an order, the front-end sends an HTTP POST request to an HTTP-triggered function that validates the order and writes a message to an Azure Storage queue. A separate queue-triggered function then processes the order: it charges the credit card (via another service), updates the inventory, and sends a confirmation email. This decoupling allows the system to handle spikes in traffic (e.g., Black Friday) without overwhelming the database. The queue acts as a buffer; if the processing function is slow, messages accumulate in the queue, and the function scales out automatically. A timer-triggered function runs daily to generate sales reports and clean up old data. In production, the team configured the queue trigger with a batch size of 32 and a max dequeue count of 3 to reduce retries. They also set up a poison queue handler to log failed orders for manual review. Scaling was set to a maximum of 50 instances to control costs.

A media company uploads millions of images daily to Azure Blob Storage. Each image needs to be resized, watermarked, and thumbnailed. An Event Grid-based blob trigger function (preferred over blob trigger for low latency) is triggered on blob creation. The function reads the image, performs processing, and writes the output to a different container. To handle large files (up to 500 MB), the function runs on Premium plan with no timeout. If processing fails (e.g., corrupted file), the function logs the error and moves the blob to a quarantine container. The team uses a timer-triggered function to periodically clean up temporary files older than 24 hours. They also use a queue-triggered function to handle metadata extraction asynchronously. Misconfiguration: Initially, they used the blob trigger (polling) which introduced a 5-10 second delay, unacceptable for real-time processing. Switching to Event Grid reduced latency to under 1 second. Another issue was that the blob trigger could not process blobs in containers with hierarchical namespace (Azure Data Lake Storage Gen2) — they had to use Event Grid with blob storage accounts.

A financial services company needs to synchronize data between on-premises SQL Server and Azure SQL Database every hour. They use a timer-triggered function (cron: 0 0 * * * *) that runs on a Premium plan with VNET integration to access on-premises resources. The function queries the on-premises database for changes since last run (using a watermark), then upserts the data into Azure SQL. If the sync fails, the function logs the error and sends an alert via an HTTP trigger to a monitoring dashboard. The timer trigger ensures only one instance runs the sync, preventing duplicate updates. They set useMonitor to true so that if the function app restarts, it doesn't miss a scheduled run. A common pitfall: the timer trigger's cron expression uses UTC, so they had to adjust for timezone differences. They also discovered that if the function execution takes longer than the interval, the next scheduled run is skipped by default (the timer doesn't queue overlapping executions). They mitigated by setting schedule to less frequent than the execution time.