Using Azure Service Bus and a dead-letter queue to retry failed REST API calls

PL-400 By islever Editorial Last updated Sep 25, 2026

Publish and consume Dataverse events

Short answer

A A Service Bus queue buffers messages for an Azure Function to reprocess; the dead-letter queue holds failures for retry, meeting the retry-on-500 need.

Question

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result these questions will not appear on the review screen. You are designing an integration that sends created records from a custom Dataverse table to an exposed REST API. When the REST API is unavailable, you must be able to retry if the response status code is 500. You need to select a solution that meets the requirement. Solution: Register a service endpoint for an Azure Service Bus queue. Use an Azure Function to process messages from the queue and forward them to the REST API. Redirect failed messages to the dead-letter queue. Does the solution meet the goal?

Yes Correct Answer
No

Key Takeaways

Service Bus decouples event delivery from processing: Dataverse posts the message, the queue persists it even when the API is down, the Azure Function retries, and messages that keep failing go to the dead-letter queue for later handling — exactly the required retry semantics.

The same integration must retry when the REST API returns 500. Registering a Service Bus service endpoint, processing messages with an Azure Function, and redirecting failed messages to the dead-letter queue provides durable buffering and retry, so the solution meets the goal.

Common mistake: Thinking a dead-letter queue means messages are 'lost.' A dead-letter queue is the retry/failure-handling mechanism itself: messages that cannot be delivered are isolated so they can be reprocessed after the underlying problem is fixed, not discarded.

Expert Analysis

Why the Answer Is Correct

Registering a Service Bus service endpoint lets Dataverse asynchronously deliver the created-record event to a queue. The Azure Function processes each message and calls the REST API; when the API returns 500, the message can be retried, and messages that ultimately fail are redirected to the dead-letter queue for manual or scheduled reprocessing. This durable, retryable pattern meets the requirement.

Why the Other Options Are Wrong

The contrasting option in this series (an async plug-in raising an exception) does not retry at all. Here, A is correct because the queue plus dead-letter design explicitly provides the retry capability the requirement demands.

Community Comment Notes

KucaStonojka (likes=3) describes how Dataverse sends messages to the Service Bus queue, which buffers them until the Function can process them even if the API is temporarily unavailable. RavinBrissy (likes=1) notes failed messages can be reprocessed from the dead-letter queue after fixing the root cause.

Official Reference

https://learn.microsoft.com/en-us/power-apps/developer/data-platform/azure-integration

This link opens the official vendor documentation in a new tab.

Community Votes

100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

KucaStonojka 👍 3 Answered A

Azure Service Bus Queue: Messages (e.g., created records) are sent to the Service Bus queue from Dataverse. The queue acts as a buffer, ensuring messages are stored until they can be processed, even if the downstream system (the REST API) is unavailable. Azure Function: An Azure Function reads messages from the queue and processes them. The function sends the data to the REST API. If the REST API responds with an HTTP 500 status code, the function can retry the request using its own retry logic or built-in retry mechanisms. Dead-Letter Queue (DLQ): If the retry attempts fail (e.g., the API remains unavailable), the message is automatically redirected to a dead-letter queue (DLQ). Messages in the DLQ can be inspected and reprocessed manually or with automated retry mechanisms later.
RavinBrissy 👍 1 Answered A

Handling failed messages: Depending on the situation, you might attempt to reprocess messages from the dead-letter queue after fixing the underlying problem, or you might need to take manual action to handle the failed data.
sudoaptupgrade 👍 1 Answered B

No, because sending failed messages to the dead-letter queue means that they are NOT processed again after failure. They are just sent to the dead-letter queue to die there
greendend 👍 1 Answered A

Looks like Yes Other solutions to this question are definitely No. But this one is most like Yes.
Juan0414 👍 1 Answered A

Correct!

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Practice All PL-400 Questions

Access 85 questions with complete answers and detailed explanations.

View Full PL-400 Practice Test →

← Back to PL-400 Study Guide