When a cooperative grower drops a harvest CSV into a Blob Storage container, a county Function should start processing immediately. Which trigger should the developer choose?
Select an answer to reveal the explanation.
Short Explanation
New file lands, function wakes—that’s a Blob trigger doing data-operation duty. Don’t babysit the container with a timer when Storage already rings the doorbell.
Full Explanation
A cooperative grower’s harvest CSV landing in Blob Storage is a classic data-operation event. A Blob Storage trigger that runs when a blob is created or updated in the watched path starts the county Function immediately from the upload itself, which is the AZ-204 pattern for reacting to new objects without polling.
A timer that lists the container every hour and ignores create events introduces delay and abandons the evented model Storage already provides. An HTTP trigger that the grower’s desktop app must call after every upload adds a second, fragile step: if the app uploads but forgets the callback, processing never starts even though the CSV is present. A Queue Storage trigger that never receives a message when the CSV lands cannot start work from the blob create event; queue messages are a different signal path.
Exam caveat: at high scale or for certain storage configurations, Event Grid–backed blob patterns may be preferred over classic poll-based blob triggers; still, the conceptual answer remains an evented blob reaction versus timer listing. Path filters and connection settings must match the grower’s container prefix. Operational check: upload a uniquely named CSV to the watched path and confirm the function invocation appears promptly with that blob name, without any manual HTTP call or waiting for the next timer tick.