In a redelivery policy, what happens when redelivery attempts are exhausted?

• A. The message is discarded.
• B. Logs the message for auditing.
• C. The connector raises an exception and publishes the message to the DLQ.
• D. The message is moved to the processing queue.

Answer: (C)

When redelivery attempts are exhausted, the system treats the message as an unprocessable failure and moves it into a Dead Letter Queue. The reason this is the right behavior is that it preserves reliability and observability: instead of silently discarding the message, it surfaces the failure by raising an exception and routes the problematic payload to a DLQ where it can be inspected, analyzed, and remediated without blocking or losing data. This also plays nicely with Mule flows’ error handling, so you can implement specific on-error logic or alerting for such failed messages.

Other options miss the reliability and traceability benefits: discarding would lose the data, logging alone doesn’t provide a durable place to review or recover the message, and moving back to a processing queue would just reintroduce the failure without a clear remediation path. The DLQ approach gives a safe, auditable way to handle messages that can’t be delivered after retries.