Functions and data events
Place in the route
This module follows runtime deployment and data access. It explains how an application turns an incoming request, schedule, or data mutation into a controlled unit of work.
Outcomes
You should be able to distinguish a Function trigger from a binding, choose a binding or SDK call deliberately, identify the execution and retry boundary, and explain how a Cosmos DB change feed differs from an event stream or notification bus.
Functions mechanics
A Function App hosts one or more functions on a Functions runtime. A trigger is the one input that starts an invocation: examples include HTTP requests, a timer, a queue message, a blob change, or an event. An input or output binding declares a connection between the function and another service so common data movement does not require boilerplate client code. A binding does not itself start a function; that is the trigger’s job. An SDK call is explicit application code and is preferable when the operation needs a feature or transaction the binding does not expose.
The invocation boundary includes deserialization, identity, dependency access, execution time, retries, and idempotency. A queue-triggered function can run again when processing fails or the message is not settled. Therefore handlers should tolerate duplicate delivery and send poison work to a controlled failure path. A timer trigger expresses schedule, not durable business state; the application must store state when it needs a durable workflow.
Change feed and event boundaries
The Cosmos DB change feed records an ordered view of item changes within logical partitions. A change-feed processor consumes those changes to project data, invoke downstream work, or maintain a search index. It is a data-derived stream, not a general-purpose notification that an arbitrary service may publish. Event Grid announces discrete events; Event Hubs carries a partitioned event stream; Service Bus carries enterprise messages with brokered delivery semantics. Select the boundary from the required ordering, replay, delivery, and consumer model.
Worked scenario and checkpoint
When a blob upload should start image processing, use a blob trigger or an event-driven handoff; use an SDK when the handler must control conditional writes or a feature unavailable through a binding. When a Cosmos item changes, have a change-feed processor update a projection. Explain why a change feed can replay changes for a consumer while a simple notification may only announce that something happened. Predict the outcome of a handler that performs a side effect and then crashes before acknowledging work.
Hands-on / what to try
Read a local pseudo-configuration containing an HTTP trigger, a queue output binding, a managed-identity reference, and a retry policy. Trace the invocation, identify the data-plane calls, and mark the steps that must be idempotent. Then compare a change-feed consumer with an Event Grid subscriber using ordering, replay, and consumer ownership as the test criteria. No Azure resource is required.
Sources and re-audit
- AZ-204 study guide, final skills measured 2026-01-14, checked 2026-08-31.
- Azure Functions triggers and bindings, checked 2026-08-31.
- Cosmos DB change feed, checked 2026-08-31.
AZ-204 is retired; this module preserves its application-development concepts. Re-audit when trigger, binding, retry, or change-feed behavior changes.