AZ-204 Develop Azure compute solutions 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.

• ✗

  Use a singleton attribute on the function to ensure only one instance runs.

  Why it's wrong here

  The `[Singleton]` attribute ensures only one instance of a specific function executes across all scale units at a time. While it prevents concurrent function instances, it does not inherently throttle the *rate* at which that single instance makes calls to an external API. A single, long-running function execution could still rapidly exceed a per-second rate limit if its internal logic is not explicitly designed for throttling.

• ✗

  Use a static SemaphoreSlim in the function code to limit concurrent calls.

  Why it's wrong here

  A `static SemaphoreSlim` within a function's code limits concurrent calls *within that specific application instance*. However, Azure Functions on a Consumption plan can scale out to multiple, independent instances across different virtual machines. Each instance would possess its own distinct static `SemaphoreSlim`, failing to coordinate a global rate limit across the entire distributed function app.

• ✗

  Configure the function's host.json to limit concurrency to 1.

  Why it's wrong here

  Configuring `maxConcurrentCalls` to 1 in `host.json` for a specific trigger ensures only one execution of that function is processed at a time *per host instance*. While this prevents parallel executions, it does not inherently control the *frequency* or *rate* of API calls made *within* that single, active execution. A single function execution could still make numerous rapid calls to the external API, easily exceeding a 10-calls-per-second rate limit.

• ✓

  Use a queue-based load leveling pattern with an Azure Storage Queue.

  Why this is correct

  The queue-based load leveling pattern is ideal for managing external API rate limits. Incoming requests are placed into an Azure Storage Queue, decoupling the ingestion rate from the processing rate. A separate function, triggered by the queue, then processes these messages at a controlled pace, implementing throttling mechanisms like deliberate delays between API calls or batch processing with pauses, ensuring the external API's rate limit is consistently respected regardless of the function app's scale.