An HTTP donor-intake Azure Function must enqueue a work item for a later processor. Which approach matches the Functions bindings skill?
Select an answer to reveal the explanation.
Short Explanation
Need to drop a chore on the queue for later? Slap on a Queue Storage output binding and let the host send it—no handwritten client required for the skill. Traces and APIM detours are not that binding.
Full Explanation
The HTTP donor-intake Azure Function must enqueue a work item for a later processor using the Functions bindings skill. Add a Queue Storage output binding that writes the work item declaratively from the function. On successful completion, the host sends the message to the configured queue using binding metadata and the storage connection from application settings—no handwritten queue client required for the skill under test. The intake HTTP function stays thin: validate input, shape the work item, return, and let the output binding enqueue.
Calling Azure Service Bus only through API Management with no function configuration pushes messaging into a gateway and skips Functions output bindings entirely. Writing the work item to Application Insights traces and scraping logs later abuses telemetry as a queue; traces are not a reliable work-item transport. Requiring a Durable orchestration client for every simple queue handoff overkill a basic enqueue—Durable is for orchestrations and stateful workflows, not a mandatory wrapper around one queue message.
Exam caveat: output bindings typically commit on successful function completion—handle failures so you do not assume a message was enqueued when the function faults before completion. Operational check: invoke the donor-intake HTTP function with a test payload, inspect the target Azure Storage queue for the new message, and confirm the later processor can dequeue it without any APIM or App Insights scraping path.