For the AZ-204 exam, you need to clearly distinguish between trigger and binding concepts in Azure Functions, the differences between hosting plans, and Durable Functions patterns.
What Is Azure Functions?
Imagine a vending machine. A drink comes out only when you insert a coin (an event), and nothing operates while you are just waiting. Azure Functions works the same way. Code runs only when an event occurs, and no cost is incurred the rest of the time. This approach is called serverless.
Serverless does not mean there are no servers. It means developers do not need to manage servers directly. Azure prepares, runs, and manages the servers on your behalf.
Triggers
A trigger is an event that causes a function to execute. Each function must have exactly one trigger. Think of a doorbell. Someone must press the doorbell (trigger) for the sound to ring inside (function execution). Just as two doorbells cannot be connected to one house at the same time, only one trigger is allowed per function.
| Trigger | Description | Use Example | |---------|-------------|------------| | HTTP | Fires when an HTTP request arrives | REST API, webhook handling | | Timer | Fires on a set schedule (cron expression) | Generate reports at midnight every day | | Blob Storage | Fires when a Blob file is uploaded or modified | Resize image after upload | | Queue Storage | Fires when a message enters a queue | Process asynchronous work items | | Event Grid | Fires when an Event Grid event occurs | Respond to various Azure events | | Service Bus | Fires when a Service Bus message arrives | Enterprise message processing | | Cosmos DB | Fires on Cosmos DB change feed | Process DB changes in real time |
Key rule: Only one trigger per function.
Bindings
Bindings are how a function reads from or writes to other services without writing SDK or client library code. Like a USB charger, you do not need to understand complex electrical circuits — you just plug it in and it works.
Input Binding: Automatically reads external data when the function starts Output Binding: Automatically writes the function result to an external service
Example: Receive a request via HTTP trigger → read data with a Cosmos DB input binding → send results to a queue with a Queue Storage output binding. At no point do you need to initialize an SDK or manage connections manually.
| Type | Description | Example | |------|-------------|---------| | Trigger | What causes the function to run (exactly one required) | HTTP request, queue message arrival | | Input Binding | Read data during function execution (multiple allowed) | Read Blob file, query Cosmos DB document | | Output Binding | Write data after function execution (multiple allowed) | Send message to queue, save Blob file |
Hosting Plans
This determines how your function is executed. You must choose one of three options.
Consumption Plan
The most basic serverless option. It is like a prepaid transit card where you only pay when you ride — no money comes out while you wait, only when you board the bus (when the function executes).
Billed by execution count and execution duration Autoscaling: Automatically scales instances as traffic increases Cold start may occur: If a function is not used for a while, the first execution may have a delay Execution timeout: Maximum 10 minutes (default 5 minutes)
Premium Plan
An improved version of the Consumption Plan that eliminates cold starts. Pre-warmed instances are always on standby, enabling immediate execution.
No cold start: Pre-warmed instances are always ready VNet integration: Access resources in private networks Unlimited execution duration More powerful CPU and memory options
Dedicated Plan (App Service Plan)
Runs functions on top of an existing App Service Plan. Useful when you already have an App Service Plan and want to run functions without additional cost.
Always running: Instances are always active Can leverage existing App Service Plan Predictable costs
| Plan | Cold Start | Billing Model | VNet Support | |------|-----------|--------------|-------------| | Consumption | Yes | Execution-based | No | | Premium | No | Always-on + execution-based | Yes | | Dedicated | No | App Service Plan rate | Yes |
!3 Azure Functions hosting plans
Durable Functions
Regular Functions are best for one-off tasks. But what if you need to run multiple steps in sequence, or run several tasks in parallel and wait until all of them finish? Durable Functions handles these complex workflows while maintaining state.
Durable Functions Patterns
Function Chaining
Runs multiple functions in sequence. Like a cooking recipe with step 1, step 2, step 3 in order — the result of each step is passed to the next.
Use example: File upload, virus scan, image conversion, save
Fan-out / Fan-in
Runs multiple tasks in parallel, waits for all of them to finish, and then aggregates the results. Like contacting multiple people simultaneously when preparing for a meeting, and waiting until everyone has replied.
Use example: Simultaneously query weather data from multiple regions, then aggregate results
Async HTTP API
Starts a long-running task and lets the client check the status later. Similar to package tracking — you do not stand at the door waiting immediately after shipping starts, but check the status later using the tracking number.
Monitor
Repeatedly checks until a certain condition is met. Like repeatedly checking the departure board at an airport while waiting for your flight.
Human Interaction
A workflow that waits for a human to approve. Like an approval chain, a person must manually approve before the workflow moves to the next step. If no approval comes within a time limit, an alternative process (escalation) automatically proceeds.
| Pattern | Key Feature | Use Example | |---------|------------|------------| | Chaining | Sequential execution, pass previous result to next step | Data pipeline | | Fan-out / Fan-in | Parallel execution then aggregate | Call multiple APIs simultaneously | | Async HTTP API | Track long-running task progress | Large file processing | | Monitor | Repeat check until condition is met | Status polling | | Human Interaction | Wait for human approval | Approval workflow |
Exam Key Points
"The event that makes a function execute, exactly one allowed" -- Trigger
"Read data without writing SDK code" -- Input Binding
"Write data without writing SDK code" -- Output Binding
"Pay only when executed, cold starts possible" -- Consumption Plan
"No cold start, always-ready instances" -- Premium Plan
"Run on top of existing App Service Plan" -- Dedicated Plan
"Execute multiple functions in sequence" -- Durable Functions Chaining
"Run tasks in parallel and wait for all to complete" -- Durable Functions Fan-out / Fan-in
"Track the status of a long-running task" -- Durable Functions Async HTTP API
"Workflow that waits for a person to approve" -- Durable Functions Human Interaction
"Trigger that fires on a scheduled time" -- Timer Trigger (cron expression)
"Automatically fires when a Blob is uploaded" -- Blob Storage Trigger