A knotweed-dike message fails repeatedly and keeps looping through workers. Where should Service Bus place it after max delivery attempts?
Select an answer to reveal the explanation.
Short Explanation
Infinite worker retries are a hamster wheel. After max delivery (or an explicit DeadLetter), Service Bus parks the message on the dead-letter subqueue for inspection.
Full Explanation
After repeated failures, Service Bus stops the knotweed-dike hamster wheel by moving the message to the entity's dead-letter subqueue when max delivery count is exceeded or when the application explicitly dead-letters it. Operators can then inspect dead-letter reasons, fix data or code, and resubmit deliberately instead of burning worker cycles forever on a poison payload.
Sending the message back into the same queue forever with no delivery counter fails because unbounded retries hide poison messages and amplify load. Expecting the message to land in Event Grid's blob dead-letter container automatically fails conceptually: that destination belongs to Event Grid delivery failures, not Service Bus entity dead-lettering. Inventing a Storage poison-queue convention that Service Bus does not own fails because Service Bus already provides a first-class dead-letter subqueue on the queue or subscription.
Exam caveat: dead-lettered messages do not process themselves—someone must monitor the DLQ, or poison traffic silently accumulates. Operational check: set a low max delivery count in a test queue, fail processing repeatedly, and confirm the message appears on the dead-letter subqueue with a delivery-count reason.