Service Bus Queue Fault Tolerance and Auto-Scaling with Azure Functions
Your company deploys a microservices architecture on Azure Kubernetes Service (AKS). The application consists of a frontend service, an order service, and a payment service. The order service writes messages to an Azure Service Bus queue, and the payment service processes them. You need to ensure that the payment service can scale independently based on the queue length, and that the processing is fault-tolerant: if the payment service crashes during message processing, the message should not be lost and should be retried. You also need to minimize cost by reducing the number of idle instances. You configure the payment service as an Azure Function triggered by the Service Bus queue. Which configuration options should you set?
Quick Answer
The correct configuration is to set maxDeliveryCount to 5 on the Service Bus queue and configure the Azure Function’s scaling mode to “Scale based on the number of messages in the queue.” This combination directly addresses both fault tolerance and auto-scaling: the maxDeliveryCount ensures that if the payment service crashes mid-processing, the message is not lost but retried up to five times, while the scaling mode allows the function to dynamically adjust instance count based on queue length, minimizing idle instances and reducing cost. On the AZ-204 exam, this scenario tests your understanding of how Azure Functions integrate with Service Bus triggers for resilient microservices on AKS, often appearing as a trap where candidates confuse storage queues or fixed scaling. A common memory tip is “retry count for resilience, queue length for scale”—the maxDeliveryCount handles failures, and the scaling mode handles demand.
⚠ Common exam trap
Watch out — candidates often think fixed instance counts or disabling retries are simpler solutions, but they fail to meet both the fault-tolerance and cost-minimization requirements simultaneously, while D correctly leverages Service Bus's built-in retry mechanism and Azure Functions' dynamic scaling.
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 maxDeliveryCount to 5 in the Service Bus queue. Configure the Azure Function's scaling mode to 'Scale based on the number of messages in the queue'.
Setting maxDeliveryCount to 5 on the Service Bus queue ensures that if the payment service crashes during processing, the message is not lost and will be retried up to 5 times. Configuring the Azure Function's scaling mode to 'Scale based on the number of messages in the queue' allows the function to scale out dynamically based on queue length, minimizing idle instances and reducing cost. This combination provides fault-tolerant processing and cost-efficient scaling for the microservices architecture.
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 an Azure Storage Queue instead of Service Bus. Set the function's batchSize to 10.
Why it's wrong here
Storage queues don't support automatic scaling based on queue length as efficiently.
- ✗
Disable retries completely to avoid duplicate processing.
Why it's wrong here
Disabling retries would cause message loss on failure.
- ✗
Set the function to run on a fixed instance count of 3.
Why it's wrong here
Fixed instances would waste cost during low load and may be insufficient during high load.
- ✓
Set maxDeliveryCount to 5 in the Service Bus queue. Configure the Azure Function's scaling mode to 'Scale based on the number of messages in the queue'.
Why this is correct
maxDeliveryCount provides retries; scaling based on queue length optimizes cost.
Go deeper
Related to this question
Learn chapter
Azure Functions Development
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.
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.
About these practice questions
One of 881 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 →
Same concept, more angles
1 more way this is tested on AZ-204
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are designing a solution that requires asynchronous processing of messages from an Azure Service Bus queue. The solution must guarantee at-least-once delivery and handle poison messages automatically. Which combination of Service Bus features should you use?
hard- A.ReceiveAndDelete mode with a separate dead-letter queue
- B.ReceiveAndDelete mode with automatic forwarding
- C.PeekLock mode with sessions
- ✓ D.PeekLock mode with dead-letter queue
Why D: PeekLock mode is required for at-least-once delivery because it allows the consumer to process the message and then explicitly complete it, ensuring the message is not removed from the queue until processing succeeds. The dead-letter queue automatically handles poison messages by moving messages that exceed the maximum delivery count or fail processing, preventing them from blocking the queue.
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.