Work items for a city permits desk already land on an Azure Storage queue from another function’s output binding. The processor Function should run when a message appears. Which trigger fits?

When work items for a city permits desk already arrive on an Azure Storage queue from another function’s output binding, the processor should use a Queue Storage trigger. That trigger invokes the function for each message as it appears, completing the producer-consumer pattern on Storage queues without inventing a different messaging platform.

Redesigning everything as a Service Bus session-enabled topic subscription may be valid architecture in other designs, but it is not required when messages already land on a Storage queue and the question asks which trigger fits that queue. A timer that peeks queue length but never receives messages observes backlog without processing work and can leave messages invisible to consumers that actually dequeue. A Cosmos DB trigger on an unrelated inventory container reacts to document changes, not to permits queue messages.

Exam caveat: distinguish Storage queues from Service Bus queues/topics—both have Functions triggers, but connection strings, sessions, and scaling behaviors differ; do not assume features like sessions exist on Storage queues. Operational check: have the producer function enqueue a test permit message, confirm the processor function runs once per message, and verify poison-message handling (dequeue count / poison queue) for a deliberately failing payload.