AZ-204 Develop for Azure storage Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Queue trigger

  Why it's wrong here

  An Azure Functions Queue trigger is designed to activate a function whenever a new message is added to an Azure Storage Queue or Azure Service Bus Queue. It continuously polls the specified queue and processes messages in a FIFO manner. This trigger type is entirely decoupled from Cosmos DB's change feed mechanism and cannot directly monitor or react to document modifications within a Cosmos DB container, making it unsuitable for real-time data change detection.

• ✗

  Timer trigger

  Why it's wrong here

  An Azure Functions Timer trigger executes a function on a predefined, recurring schedule, specified using a CRON expression. While it could be configured to periodically query Cosmos DB for changes, it does not inherently leverage the real-time, push-based nature of the Cosmos DB change feed. This approach would introduce significant latency and require complex custom logic to track processed changes, making it inefficient for immediate reactions to data modifications.

• ✗

  HTTP trigger

  Why it's wrong here

  An HTTP trigger in Azure Functions makes a function callable via an HTTP request, acting as a standard web API endpoint. It waits for an external client to send an HTTP request (e.g., GET, POST) to its unique URL. This trigger type is entirely passive and cannot proactively monitor or react to internal data changes within a Cosmos DB container; it only responds when explicitly invoked by an external HTTP call, which is not the requirement here.

• ✓

  Cosmos DB trigger

  Why this is correct

  The Azure Cosmos DB trigger for Azure Functions is specifically engineered to listen for changes in an Azure Cosmos DB container's change feed. It automatically processes new inserts and updates (and optionally deletes, depending on configuration) in near real-time, invoking the function for each change. This trigger efficiently leverages the change feed processor library to manage leases and distribute processing across multiple function instances, ensuring reliable and scalable event-driven reactions to data modifications without polling.