A festival Azure Function should run on a schedule, read a blob, and write a Cosmos DB item. How should the developer assign trigger and binding roles?
Select an answer to reveal the explanation.
Short Explanation
One doorbell (trigger), then as many mail slots (bindings) as you need. Timer wakes the festival job; blob is input; Cosmos is output. Calling all three “triggers” breaks the one-trigger rule.
Full Explanation
The festival Azure Function should run on a schedule, read a blob, and write a Cosmos DB item. Assign roles correctly: timer as the trigger, blob as an input binding, and Cosmos DB as an output binding. A function has exactly one trigger that starts execution; input bindings supply additional data without starting the function; output bindings write results when the function completes successfully. That role split matches the schedule-driven festival job pattern without inventing multiple doorbells.
Treating the timer, blob, and Cosmos DB pieces as three separate triggers on one function violates the one-trigger rule and mislabels bindings as triggers. Using Cosmos DB as the only trigger and ignoring timer and blob configuration starts on Cosmos change feed or similar, not on the required schedule, and drops the blob read role. Using blob as the trigger, timer as an output binding, and Cosmos as a second trigger both invents an invalid dual-trigger shape and treats timer as an output, which is not how timer works.
Exam caveat: binding direction and type names in function.json or attributes must match—marking Cosmos as an input when you meant output is a silent logic bug. Operational check: deploy with timer trigger metadata, blob input binding, and Cosmos output binding; advance or wait for the schedule, confirm the blob is read, and confirm a Cosmos item is written without defining extra triggers.