Event Grid custom topics, filters, retries and dead-lettering
Lesson coming
Sample questions
Try each one before opening the answer. Every option is explained, with the Microsoft documentation page that proves it.
Question 1 · choose 1
Order events for many customers arrive on one Azure Service Bus queue. Events for the same customer must be processed in the order they were sent, while different customers' events are processed in parallel by several workers. The namespace is on the Standard tier. What do you implement?
AEnable duplicate detection and set MessageId to the customer ID
BEnable sessions on the queue and use the customer ID as the session ID
CReceive in ReceiveAndDelete mode with a single worker
DMove the namespace to the Basic tier and create one queue for each customer
Show the answer and why
AEnable duplicate detection and set MessageId to the customer ID
Incorrect
Duplicate detection only discards repeats of a message; it gives no ordering and would discard this customer's later events.
BEnable sessions on the queue and use the customer ID as the session ID
Correct
A session receiver locks all messages of one session and receives them in order, while other receivers handle other sessions.
CReceive in ReceiveAndDelete mode with a single worker
Incorrect
A single worker gives up the required parallelism, and this mode loses a message if the transfer fails.
DMove the namespace to the Basic tier and create one queue for each customer
Incorrect
The Basic tier doesn't support sessions, and a queue per customer doesn't scale.
Sessions give first-in, first-out processing of related messages. The sender sets the session ID; a receiver that accepts a session holds an exclusive lock on its messages. Sessions need the Standard or Premium tier.
A Python worker receives Service Bus messages in peek-lock mode, closes the receiver, and then completes each message after a slow processing step. Messages keep coming back and later appear in the dead-letter queue with the reason MaxDeliveryCountExceeded. What should you change?
ASettle each message while the receiver and its connection are still open
BRaise the queue's maximum delivery count to 100
CSwitch to ReceiveAndDelete mode to avoid locks
DDead-letter the messages yourself before closing the receiver
Show the answer and why
ASettle each message while the receiver and its connection are still open
Correct
Settlement sent after the receiver closes never reaches the service, so the lock expires and the message is redelivered.
BRaise the queue's maximum delivery count to 100
Incorrect
That only delays dead-lettering; the messages still never get completed.
CSwitch to ReceiveAndDelete mode to avoid locks
Incorrect
In that mode a message is gone as soon as it's sent, so a failure during the slow step loses it.
DDead-letter the messages yourself before closing the receiver
Incorrect
That moves every message to the dead-letter queue without processing it.
In peek-lock mode the lock belongs to the receiver and its connection. Settling after closing doesn't reach Service Bus; the lock expires, the delivery count rises, and past the maximum (10 by default) the message is dead-lettered with MaxDeliveryCountExceeded.
Thousands of messages have built up over several weeks in the dead-letter queue of a Service Bus subscription. The topic's messages have a 7-day time to live. How are these dead-lettered messages removed?
AThey expire after seven days, like other messages on the topic
BOnly by receiving them from the dead-letter queue and completing them
CThey're moved to a secondary dead-letter queue after the delivery count is exceeded
DBy deleting the dead-letter queue of the subscription
Show the answer and why
AThey expire after seven days, like other messages on the topic
Incorrect
Time to live isn't observed in the dead-letter queue.
BOnly by receiving them from the dead-letter queue and completing them
Correct
The dead-letter queue has no automatic cleanup; messages stay until they're received and completed.
CThey're moved to a secondary dead-letter queue after the delivery count is exceeded
Incorrect
You can't dead-letter a message from a dead-letter queue.
DBy deleting the dead-letter queue of the subscription
Incorrect
The dead-letter queue can't be deleted or managed independently of its subscription.
Every queue and subscription has a dead-letter subqueue, addressed as <topic>/Subscriptions/<subscription>/$deadletterqueue. Messages there ignore TTL and remain until an application retrieves and completes them.
A sender occasionally times out while sending to a Service Bus queue and retries, so the same order sometimes appears twice. Duplicate detection is enabled on the queue with a 10-minute window, but duplicates still get through. The sender builds a new message with a fresh GUID as MessageId on every attempt. What do you change?
ASet MessageId from the order ID so every retry of the same order carries the same value
BLengthen the duplicate detection window to seven days
CSet the session ID to the order ID instead of changing MessageId
DSend in batches so retries resend the whole batch
Show the answer and why
ASet MessageId from the order ID so every retry of the same order carries the same value
Correct
Duplicate detection compares only MessageId; a value derived from the business key repeats on retries and gets dropped.
BLengthen the duplicate detection window to seven days
Incorrect
A longer window doesn't help when every retry has a different MessageId.
CSet the session ID to the order ID instead of changing MessageId
Incorrect
Duplicate detection doesn't look at the session ID, so each retry would still count as a new message.
DSend in batches so retries resend the whole batch
Incorrect
Batching doesn't make retried messages share a MessageId.
With duplicate detection, Service Bus remembers each MessageId for the configured window and silently drops a later message with the same ID. The ID has to be application-controlled so a retry can reproduce it. Basic tier namespaces don't support the feature.
An Event Grid subscription to a webhook has a retry policy of 10 maximum delivery attempts and a 30-minute event time to live, and dead-lettering to a blob container is configured. The endpoint is down for two hours and returns 503 errors. What happens to an event published at the start of the outage?
AIt's dead-lettered after the tenth failed attempt
BIt's dead-lettered once its 30-minute time to live has expired
CIt's retried every 12 hours until the endpoint recovers
DIt's dropped at once, because Event Grid doesn't retry 503 Service Unavailable
Show the answer and why
AIt's dead-lettered after the tenth failed attempt
Incorrect
The 30-minute time to live expires before ten attempts can happen.
BIt's dead-lettered once its 30-minute time to live has expired
Correct
Event Grid stops at whichever limit is reached first; only about six attempts fit into 30 minutes, and the expired event is dead-lettered at its next scheduled attempt.
CIt's retried every 12 hours until the endpoint recovers
Incorrect
The retry policy here ends delivery after 30 minutes, not after 24 hours.
DIt's dropped at once, because Event Grid doesn't retry 503 Service Unavailable
Incorrect
Event Grid retries 503 errors; it skips retries for errors such as 400, 401, 403 and 413.
Event Grid retries with exponential backoff (10 s, 30 s, 1 min, 5 min, 10 min, 30 min and so on). Delivery ends when either the maximum attempts or the event time to live is reached, and the event is then dead-lettered if a dead-letter location is set, or dropped.
An Event Grid subscription on a storage account's system topic already filters on the Microsoft.Storage.BlobCreated event type. It must now deliver only events for PDF files uploaded to the container named contracts. Which two filter settings do you add? (Choose TWO.)
AsubjectBeginsWith set to /blobServices/default/containers/contracts/
BsubjectBeginsWith set to contracts/
CenableAdvancedFilteringOnArrays set to true
DsubjectEndsWith set to .pdf
EincludedEventTypes set to Microsoft.Storage.BlobDeleted
Show the answer and why
AsubjectBeginsWith set to /blobServices/default/containers/contracts/
Correct
Blob event subjects use the form /blobServices/default/containers/<container>/blobs/<blob>, so this prefix matches one container.
BsubjectBeginsWith set to contracts/
Incorrect
The subject starts with /blobServices/default/containers/, so this prefix never matches.
CenableAdvancedFilteringOnArrays set to true
Incorrect
This setting only allows advanced filters on array keys; it doesn't filter anything by itself.
DsubjectEndsWith set to .pdf
Correct
A suffix filter on the subject matches blobs by file extension.
EincludedEventTypes set to Microsoft.Storage.BlobDeleted
Incorrect
The subscription must deliver uploads, not deletions.
Subject filters are the simplest way to narrow blob events: begin with the container path to select a container (or a folder), and end with a suffix to select a file type. Advanced filters handle values inside the event data.
You create a Service Bus topic subscription and then add a SQL filter rule priority = 'high'. The subscription still receives every message sent to the topic. What's the cause?
AThe default rule with a true filter is still there, and rules are ORed
BSQL filters only test system properties, so the user property is ignored
CSQL filter conditions are case-insensitive, so every value matches
DA topic delivers every message to every subscription regardless of rules
Show the answer and why
AThe default rule with a true filter is still there, and rules are ORed
Correct
Every new subscription starts with a $Default rule that selects all messages; it must be removed for the SQL rule to narrow delivery.
BSQL filters only test system properties, so the user property is ignored
Incorrect
SQL filters evaluate both user-defined and system properties; system ones need the sys. prefix.
CSQL filter conditions are case-insensitive, so every value matches
Incorrect
Case handling doesn't make a filter on one property match all messages.
DA topic delivers every message to every subscription regardless of rules
Incorrect
Rules on a subscription decide which messages it receives.
Each new topic subscription has an initial default rule with a true filter. Rules without actions are ORed, so as long as the default rule exists every message matches. Delete the $Default rule, or create the subscription with your own rule in place of it.
A payment notification arrives on a Service Bus queue before its matching order exists. The worker defers the message and plans to process it once the order shows up. What must the worker do to get the message back later?
AReceive normally; deferred messages return to the front of the queue
BRead it from the queue's dead-letter subqueue
CKeep the message's sequence number and receive it by that number
DWait for its time to live to expire, which moves it back to active
Show the answer and why
AReceive normally; deferred messages return to the front of the queue
Incorrect
Regular receive operations no longer return a deferred message.
BRead it from the queue's dead-letter subqueue
Incorrect
Deferred messages stay in the main queue, not in the dead-letter queue.
CKeep the message's sequence number and receive it by that number
Correct
Deferred messages can't be received with regular receive calls; the owner must remember the sequence number.
DWait for its time to live to expire, which moves it back to active
Incorrect
Deferred messages don't expire into another state on their own; the expiry check happens when a client tries to receive them.
Deferral sets a message aside in the main queue for workflows that need to process messages in a different order than they arrive. If the app loses the sequence number, it can find deferred messages by peeking.
You turn on batched delivery for an Event Grid subscription with max events per batch set to 5,000. The webhook handler sometimes takes minutes to process a full batch, and whole batches get redelivered. What explains this, and what do you change?
ABatches of more than 1,000 events are invalid, so Event Grid splits and resends them
BBatches are all-or-none with a 30-second wait; request fewer events per batch
CThe preferred batch size in kilobytes is a hard limit that was exceeded
DEvent Grid delivers events in order, so one slow event blocks the batch
Show the answer and why
ABatches of more than 1,000 events are invalid, so Event Grid splits and resends them
Incorrect
Max events per batch can be anything from 1 to 5,000.
BBatches are all-or-none with a 30-second wait; request fewer events per batch
Correct
Event Grid doesn't support partial success of a batch, so ask only for as many events as you can handle in 30 seconds.
CThe preferred batch size in kilobytes is a hard limit that was exceeded
Incorrect
The preferred size is a best-effort target; a single larger event is still delivered in its own batch.
DEvent Grid delivers events in order, so one slow event blocks the batch
Incorrect
Event Grid doesn't guarantee delivery order at all.
Batching is off by default and is configured per subscription. Event Grid treats a batch as one delivery: if the endpoint doesn't respond in time, the whole batch is retried under the retry policy.
A topic subscription must receive only messages whose user property region equals EU and whose ContentType equals application/json. You use a correlation filter. Which two statements about it are true? (Choose TWO.)
AThe filter can use LIKE to match regions such as EU-West
BBoth conditions must match, because a correlation filter combines its properties with AND
CThe string comparison is case-sensitive, so eu wouldn't match EU
DThe filter combines its conditions with OR, so either match is enough
EThe filter must prefix ContentType with sys. as in SQL filters
Show the answer and why
AThe filter can use LIKE to match regions such as EU-West
Incorrect
Pattern matching with LIKE belongs to SQL filters.
BBoth conditions must match, because a correlation filter combines its properties with AND
Correct
When a correlation filter lists several properties, all of them must match.
CThe string comparison is case-sensitive, so eu wouldn't match EU
DThe filter combines its conditions with OR, so either match is enough
Incorrect
The properties of one correlation filter aren't alternatives; all of them must match.
EThe filter must prefix ContentType with sys. as in SQL filters
Incorrect
The sys. prefix is SQL filter syntax; correlation filters name the properties directly.
Correlation filters match on equality against system properties such as CorrelationId, ContentType or Label and on user-defined properties. They are a simpler alternative to SQL filters when exact matches are enough.
A subscription autoforwards its messages to a queue in the same namespace. Someone disabled the destination queue, and messages are missing from both entities. Where do you look for them?
AIn the subscription's transfer dead-letter queue, $Transfer/$DeadLetterQueue
BIn the destination queue's dead-letter queue
CIn the topic, which keeps messages that its subscriptions can't forward
DNowhere, because autoforward failures drop messages
Show the answer and why
AIn the subscription's transfer dead-letter queue, $Transfer/$DeadLetterQueue
Correct
Messages that can't be forwarded go to the transfer dead-letter queue of the source entity that did the forwarding.
BIn the destination queue's dead-letter queue
Incorrect
The destination never accepted the messages, so they aren't in its subqueues.
CIn the topic, which keeps messages that its subscriptions can't forward
Incorrect
Messages don't sit at the topic level; they're delivered to the subscriptions within milliseconds.
DNowhere, because autoforward failures drop messages
Incorrect
Failed forwards are kept in the source's transfer dead-letter queue.
Each forwarding queue or subscription has its own transfer dead-letter subqueue, addressed as <entity path>/$Transfer/$DeadLetterQueue. Chains of forwarding are limited to four hops, after which messages are dead-lettered with MaxTransferHopCountExceeded.