AZ-204 Develop for Azure storage Practice Question
You are deploying an Azure Functions app that processes messages from an Azure Storage queue. The function must ensure that each message is processed at least once, and if processing fails, the message should be retried up to 5 times before being moved to a poison queue. Which configuration should you set?
⚠ Common exam trap
Many exam-takers confuse the `maxDequeueCount` property with other queue settings like visibility timeout or TTL, mistakenly thinking those control retry behavior, when in fact only `maxDequeueCount` governs the number of retries before poison queue escalation.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Set the maxDequeueCount property in the host.json for the queue trigger to 5.
The Azure Storage queue trigger's `maxDequeueCount` property in `host.json` controls the maximum number of times a message is dequeued for processing before it is moved to the poison queue. Setting it to 5 ensures that after 5 failed processing attempts, the message is automatically moved to the poison queue, satisfying the at-least-once processing and retry requirements without custom code.
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 maxDequeueCount property in the host.json for the queue trigger to 5.
Why this is correct
The `maxDequeueCount` property, configured within the `host.json` file for a queue trigger, directly controls the maximum number of times an Azure Function will attempt to process a specific queue message. If the function fails to successfully process the message (e.g., due to an unhandled exception) after this many attempts, the message is automatically moved to a designated poison queue. Setting this to 5 ensures the function will retry processing the message up to five times before it is considered unprocessable and moved for further investigation.
- ✗
Manually implement a retry loop in the function code.
Why it's wrong here
Manually implementing a retry loop within the function code is generally an anti-pattern for Azure Functions queue triggers. The Azure Functions runtime provides robust, built-in retry mechanisms through `maxDequeueCount` and configurable `retry` policies in `host.json`, which are more efficient and seamlessly integrate with the platform's error handling and poison message management. Custom retry logic can complicate the function, potentially interfere with native runtime behaviors, and often leads to less reliable or harder-to-maintain solutions compared to leveraging platform features.
- ✗
Set the visibility timeout to 5 minutes in the queue.
Why it's wrong here
The visibility timeout in an Azure Storage Queue determines the duration a message remains hidden from other consumers after it has been dequeued by a function. If a function fails to process a message and does not explicitly delete it, the message will reappear in the queue after this timeout expires, making it available for another attempt. While it influences *when* a message might be retried, it does not directly control the *total number* of retries before the message is considered poisoned; that specific control is provided by the `maxDequeueCount` property.
- ✗
Set the message time-to-live to 5 in the queue.
Why it's wrong here
The message time-to-live (TTL) in an Azure Storage Queue specifies the maximum duration a message can reside in the queue before it is automatically expired and permanently removed by the storage service. Setting the TTL to 5 (e.g., 5 seconds or minutes) would cause the message to disappear from the queue after that period, regardless of whether it has been processed or retried. This property is designed for message expiration, not for managing the number of processing retries, and setting it too low could lead to messages being lost before they can be successfully handled.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
Learn chapter
Azure Functions Development
Key term
Durable Functions
Durable Functions is an extension of Azure Functions that lets you write stateful workflows in code, managing complex sequences of tasks, retries, and delays automatically.
Key term
Azure Functions Bindings
Azure Functions Bindings are declarative connections that link your serverless function code to Azure services or external resources, handling input and output data automatically without writing extra networking or authentication code.
About these practice questions
Courseiva writes every AZ-204 question from scratch — 881 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.