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

Publish and consume Dataverse events

Answer Correct 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.

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

azure service bus dataverse dead-letter queue retry dataverse service endpoint

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.

Community Insight

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.

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.

Community Discussion (5 comments)

Juan0414 👍 1 Selected: A

Correct!

RavinBrissy 👍 1 Selected: 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.

greendend 👍 1 Selected: A

Looks like Yes Other solutions to this question are definitely No. But this one is most like Yes.

KucaStonojka 👍 3 Selected: 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.

sudoaptupgrade 👍 1 Selected: 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

Comments & Corrections

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

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

Related Analysis

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