AZ-204 Develop Azure compute solutions Practice Question
You are developing an Azure Functions app that processes messages from an Azure Service Bus queue. The function must ensure that if processing fails, the message is retried automatically and, after a maximum number of attempts, moved to a dead-letter queue. You want to minimize custom code. What should you configure?
⚠ Common exam trap
The trap here is assuming that function-level retry settings in host.json control Service Bus dead-lettering, when dead-lettering is governed by the queue's maxDeliveryCount property.
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 maxDeliveryCount property on the Service Bus queue to the desired number of retries and enable dead-lettering on the queue.
Service Bus queues natively support retry and dead-lettering through the maxDeliveryCount property. When a function fails to process a message and abandons it, the delivery count increases. After the maximum number of deliveries, Service Bus automatically moves the message to the dead-letter queue. This requires no custom code in the function, directly meeting the requirement to minimize 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.
- ✗
Enable the 'auto-dead-letter' setting on the function trigger binding and set the retry count in the function's application settings.
Why it's wrong here
There is no 'auto-dead-letter' setting on the Service Bus trigger binding in Azure Functions. Dead-lettering is configured on the Service Bus entity itself, not on the function trigger. Application settings do not control retry counts for Service Bus. This option describes a non-existent feature and would not achieve the required behavior.
- ✓
Set the maxDeliveryCount property on the Service Bus queue to the desired number of retries and enable dead-lettering on the queue.
Why this is correct
Service Bus queues have a maxDeliveryCount property that controls how many times a message can be delivered before it is automatically dead-lettered. When the function fails to process a message and abandons it, the delivery count increments. Once it exceeds maxDeliveryCount, Service Bus moves the message to the dead-letter queue. This requires no custom retry logic in the function.
- ✗
Configure the function's host.json to set maxRetries to the desired number and enable dead-lettering in the function code.
Why it's wrong here
The maxRetries setting in host.json controls the number of times the Functions runtime retries a failed invocation, but it does not interact with Service Bus dead-lettering. Dead-lettering is a Service Bus feature controlled by the queue's maxDeliveryCount. Using host.json alone would not move messages to the dead-letter queue after failures, and custom code would be needed.
- ✗
Use a Durable Functions orchestrator to call the processing activity and implement a retry policy with a maximum attempt count.
Why it's wrong here
Durable Functions can implement retry policies, but this adds significant complexity and custom orchestration code. The requirement is to minimize custom code, and Service Bus already provides built-in retry and dead-lettering through maxDeliveryCount. Using Durable Functions would be overengineering and would not leverage the native Service Bus dead-letter mechanism.
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
App Service Authentication (Easy Auth)
Key term
Azure Relay
Azure Relay is a cloud service that securely exposes on-premises web services to the public internet or other cloud applications without opening firewall ports.
Key term
Azure Service Bus
Azure Service Bus is a cloud-based message broker that allows applications, services, and devices to send and receive messages reliably, even when they are not all running at the same time.
About these practice questions
One of 883 original AZ-204 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.