Connect to and consume Azure services practice questions

Topics and subscriptions are Service Bus publish/subscribe: every subscription gets a copy of each message.

A queue gives each message to one receiver. A topic forwards every message to each of its subscriptions, which behave like independent queues, so each service keeps its own backlog while offline. New consumers only need a new subscription, so the publisher is unchanged. Sending to several queues works only until a new consumer arrives, and sessions are about ordering, not fan-out.

1. Every consumer needs every message, so this is publish/subscribe.
2. Each consumer must buffer while offline, which a subscription does.
3. Adding consumers without touching the sender rules out sender-side fan-out.

Exam tip: One receiver per message: queue. Every consumer gets a copy: topic plus one subscription per consumer.

In peek-lock mode the lock must outlast processing; long work renews the lock rather than relying on a longer lock duration.

The lock expires after 1 minute, so the message becomes visible again, another receiver processes it (duplicates), and the original receiver's complete_message fails with MessageLockLostError. The lock duration can be raised only to 5 minutes, still short of 12. AutoLockRenewer (or renew_message_lock) extends the lock for as long as processing needs while keeping peek-lock's crash safety. Receive-and-delete would lose messages on a crash, and the delivery count does not affect lock expiry.

1. Diagnose: lock-lost on complete plus duplicates means the lock expired mid-processing.
2. Recall the 5-minute maximum lock duration, which rules out simply raising it.
3. Keep peek-lock for crash safety and renew the lock in the background.

Exam tip: Processing longer than the 5-minute lock maximum needs lock renewal (AutoLockRenewer), not receive-and-delete.

Peek-lock settlement methods decide what happens next to a message: complete, abandon, defer or dead-letter.

abandon_message gives up the lock at once, so the message returns to the queue for any receiver, and the delivery count goes up; after the maximum delivery count the broker dead-letters it. Completing removes it, deferring hides it until it is fetched by sequence number, and dead-lettering moves it out of normal processing.

1. The failure is transient, so the message should be retried.
2. Retry by any worker, now, means returning the message to the queue.
3. Abandon does that and counts toward the delivery limit.

Exam tip: abandon = try again now (counts toward max delivery); defer = set aside for later lookup by sequence number.

Message deferral sets a received message aside so the application can retrieve that specific message later by its sequence number.

defer_message leaves the message in the queue in a deferred state; it is no longer returned by ordinary receives, and the application keeps the sequence number to call receive_deferred_messages when the prerequisite completes. Abandon redelivers at once, scheduling requires knowing the time in advance, and the dead-letter queue is for failed messages, not for parking work.

1. The message must be kept but hidden, then fetched on demand.
2. The time is unknown, which rules out scheduling.
3. Deferral plus the saved sequence number gives on-demand retrieval.

Exam tip: Unknown 'later' for a specific message: defer it and keep its sequence number; known 'later': schedule it.

Each queue and subscription has a dead-letter subqueue; the Python SDK reaches it with sub_queue=ServiceBusSubQueue.DEAD_LETTER.

Messages that exceed the maximum delivery count are moved to the entity's dead-letter subqueue with the reason MaxDeliveryCountExceeded. In azure-servicebus you create a receiver for the same queue (or subscription) and pass sub_queue=ServiceBusSubQueue.DEAD_LETTER; messages there are read and completed like any others and stay until you remove them. TRANSFER_DEAD_LETTER is a different subqueue for failed forwarding, and the other arguments read the main queue.

1. Identify where over-delivered messages go: the dead-letter subqueue.
2. Recall the SDK addresses subqueues with the sub_queue argument.
3. Pick DEAD_LETTER rather than TRANSFER_DEAD_LETTER, which is only for forwarding failures.

Exam tip: Python: get_queue_receiver(queue, sub_queue=ServiceBusSubQueue.DEAD_LETTER) reads the DLQ; complete each message to remove it.

Expired Service Bus messages are dropped unless dead-lettering on expiration is enabled, and the dead-letter subqueue is never cleaned automatically.

By default an expired message is simply removed. Enabling dead-lettering on message expiration moves it to the dead-letter subqueue with the reason TTLExpiredException. Messages there do not expire and are not cleaned up, so recovery needs code (or Service Bus Explorer) that reads them, resends them to the main queue and completes the dead-lettered copies. Delivery count does not affect expiry, and a TTL on the DLQ does not exist.

1. First fact: expiry drops messages unless dead-lettering on expiration is on.
2. Second fact: the DLQ keeps messages indefinitely; reprocessing is your job.
3. Discard options that confuse delivery count, or that rely on DLQ expiry.

Exam tip: To keep expired messages, enable dead-lettering on expiration; to reprocess them, resend and complete from the DLQ yourself.