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.

• ✗

  Set the message time-to-live (TTL) to 5.

  Why it's wrong here

  Setting the message Time-To-Live (TTL) to 5 (e.g., 5 seconds, minutes, or days) dictates how long a message remains in the queue before it automatically expires and is removed, regardless of whether it has been processed. This mechanism is for message expiration, not for controlling the number of processing retries by a consumer function. A message with a TTL of 5 would simply disappear after that duration if not successfully processed, without triggering a retry count for processing attempts.

• ✗

  Implement a custom retry policy in the function code with a maximum of 5 retries.

  Why it's wrong here

  Implementing a custom retry policy directly within the Azure Function code primarily addresses transient errors that occur *during* the function's execution, such as temporary database connection issues or external API timeouts. While useful for internal resilience, this policy does not govern the fundamental mechanism of how many times an Azure Queue Storage message is *dequeued* and made available for processing by the function. The queue itself manages the dequeue count, not the function's internal retry logic for a single execution attempt.

• ✓

  Use the default queue poison message handling with 'maxDequeueCount' set to 5.

  Why this is correct

  The 'maxDequeueCount' property, configurable for Azure Queue Storage bindings in Azure Functions, directly controls the maximum number of times a message can be dequeued and attempted for processing before it is automatically moved to a designated poison queue. Setting 'maxDequeueCount' to 5 ensures that if a function consistently fails to process a message, it will be retried up to four additional times (five total attempts) before being sent to the poison queue for manual inspection or dead-letter processing. This is the standard, built-in mechanism for handling message processing failures and retries.

• ✗

  Set the visibility timeout to 5 minutes.

  Why it's wrong here

  The visibility timeout determines the duration for which a dequeued message remains invisible to other consumers after it has been retrieved by a function. Its primary purpose is to prevent multiple instances of a function from processing the same message concurrently. While a message becomes visible again if not successfully processed within this timeout, leading to another dequeue attempt, the visibility timeout itself does not directly set or limit the *total number* of retries; 'maxDequeueCount' handles that.

Go deeper

Related to this question