Tag: messaging

AI-200, azure, Azure AI, Cloud computing, Microsoft Certification

Queue and process back-end operations by using Azure Service Bus, including dead-letter queue handling, messages, topics, and subscriptions (AI-200 Exam Prep)

 
This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Connect to and consume Azure services (20–25%)
   --> Develop event- and message-based AI solutions
      --> Queue and process back-end operations by using Azure Service Bus, including dead-letter queue handling, messages, topics, and subscriptions

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

AI applications frequently perform operations that should not block a user’s request. Examples include processing documents, generating embeddings, running batch inference, sending notifications, executing long-running model operations, or enriching data.

Azure Service Bus provides reliable asynchronous messaging that allows application components to communicate without requiring them to be available or execute at the same time.

For the AI-200 exam, you should understand how to:

  • Use Service Bus queues for asynchronous point-to-point processing.
  • Use topics and subscriptions for publish/subscribe scenarios.
  • Design messages for AI workloads.
  • Process messages reliably.
  • Understand message settlement.
  • Use peek-lock processing.
  • Handle retries and poison messages.
  • Work with dead-letter queues (DLQs).
  • Understand message locks and delivery counts.
  • Choose between queues and topics based on application requirements.

The key architectural idea is decoupling.

Instead of:

AI application → immediately execute expensive operation

you can use:

AI application → Service Bus → worker → AI operation

This allows the producer and consumer to scale independently and protects downstream AI services from sudden workload spikes.

1. What Is Azure Service Bus?

Azure Service Bus is a fully managed enterprise message broker designed for reliable asynchronous communication between distributed applications.

A typical architecture might look like:

Client
   |
   v
AI API
   |
   v
Service Bus Queue
   |
   +------------------+
   |                  |
   v                  v
Worker 1            Worker 2
   |                  |
   +--------+---------+
            |
            v
       AI Service

The API does not have to wait for the worker to finish.

Instead, it places a message onto the queue and can return a response indicating that the operation has been accepted.

The worker processes the message later.

This provides several important architectural benefits.

Temporal decoupling

The producer and consumer do not have to be running simultaneously.

A producer can place a message into the queue even when the consumer is temporarily unavailable.

Load leveling

Suppose an application normally receives 100 AI requests per minute but occasionally receives 5,000 requests per minute.

Rather than requiring the AI processing infrastructure to immediately handle all 5,000 requests, the application can place requests into a queue.

Workers can process the backlog at a sustainable rate.

Incoming requests
       |
       v
+----------------+
| Service Bus    |
| Queue          |
+----------------+
       |
       v
+----------------+
| AI Workers     |
| 1  2  3  4 ... |
+----------------+

The queue acts as a buffer between the workload producer and the processing infrastructure.

Competing consumers

Multiple worker instances can consume messages from the same queue.

For example:

             +--> Worker 1
             |
Service Bus -+--> Worker 2
   Queue     |
             +--> Worker 3
             |
             +--> Worker 4

Each message is normally processed by only one competing consumer.

This allows the processing tier to scale horizontally.

2. Azure Service Bus Messaging Entities

The three primary messaging entities you need to understand are:

  1. Queues
  2. Topics
  3. Subscriptions

The most important distinction is:

EntityCommunication patternTypical use
QueuePoint-to-pointWork distribution
TopicPublish/subscribeBroadcasting events
SubscriptionReceiver attached to a topicIndependent consumers

3. Service Bus Queues

A queue is appropriate when a message represents a unit of work that should generally be processed by one consumer.

For example:

AI API
  |
  | Submit document-processing request
  v
Service Bus Queue
  |
  +---- Worker A
  |
  +---- Worker B
  |
  +---- Worker C

Although multiple workers can listen to the same queue, a particular message is delivered to one competing consumer for processing.

Example

Suppose an application accepts uploaded documents and needs to:

  1. Extract text.
  2. Generate embeddings.
  3. Store vectors.
  4. Update a search index.

The web application could put this message onto a queue:

{
  "operation": "process-document",
  "documentId": "12345",
  "blobUrl": "https://storage/.../document.pdf",
  "model": "embedding-model",
  "correlationId": "abc-123"
}

A worker receives the message and performs the processing.

This is preferable to making the user’s HTTP request wait for the entire AI pipeline.

4. Topics and Subscriptions

Queues are primarily for point-to-point processing.

Topics and subscriptions are designed for publish/subscribe scenarios.

A topic can have multiple subscriptions:

                 +--> Subscription A --> Consumer A
                 |
Publisher --> Topic
                 |
                 +--> Subscription B --> Consumer B
                 |
                 +--> Subscription C --> Consumer C

Each subscription can receive its own copy of a published message.

Example AI architecture

Imagine that a document is uploaded.

Several independent operations need to happen:

  • Generate embeddings.
  • Perform compliance analysis.
  • Extract metadata.
  • Notify an audit system.

A topic could be used:

                  +--> Embedding subscription
                  |
Document Event --> Topic
                  |
                  +--> Compliance subscription
                  |
                  +--> Metadata subscription
                  |
                  +--> Audit subscription

This is a classic fan-out architecture.

5. Queues vs. Topics

A common AI-200 exam scenario asks you to choose between a queue and a topic.

Use a queue when:

One processing path should handle each work item.

Use a topic with subscriptions when:

Multiple independent processing paths need to receive the event.

Example

Scenario A:

A document-processing request must be handled by one available worker.

Use: Queue.

Scenario B:

A document-created event must be independently consumed by the search, auditing, analytics, and notification systems.

Use: Topic with subscriptions.

6. Subscription Filters

Subscriptions can use rules and filters to determine which messages are delivered to a particular subscription.

For example, a topic might receive:

{
  "eventType": "DocumentUploaded",
  "department": "Finance"
}

A subscription could filter messages so that only Finance documents are delivered.

This allows a single topic to support multiple specialized consumers without requiring every consumer to receive every message.

This is particularly useful in event-driven AI architectures.

7. Designing Service Bus Messages for AI Workloads

A Service Bus message should generally contain the information necessary for a consumer to locate and process the work.

A useful AI message might contain:

{
  "operation": "generate-summary",
  "documentId": "98431",
  "storageUri": "https://storage.example/document.pdf",
  "model": "summary-model",
  "priority": "normal",
  "correlationId": "req-982734"
}

Important concepts include:

Message body

Contains the primary payload.

For AI applications, this might be JSON containing:

  • Operation name
  • Entity ID
  • Storage location
  • Model information
  • Processing parameters

Application properties

Application properties can contain metadata used for routing, correlation, filtering, or processing decisions.

Examples include:

  • eventType
  • tenantId
  • priority
  • correlationId
  • contentType

Message ID

A producer can assign a unique message ID.

This can be useful for duplicate detection and application-level idempotency.

Correlation ID

A correlation ID allows related operations to be tracked across distributed components.

For example:

HTTP request
    |
    | correlationId = ABC123
    v
Service Bus
    |
    v
AI worker
    |
    v
Azure AI service

Logging the same correlation ID throughout the workflow makes troubleshooting considerably easier.

8. Avoid Putting Large AI Payloads Directly in Messages

AI workloads can involve large documents, images, audio files, or other payloads.

Instead of putting a large file directly into the Service Bus message, a common architecture is the claim-check pattern.

The large payload is stored separately, such as in Azure Blob Storage.

The Service Bus message contains a reference:

{
  "documentId": "12345",
  "blobUri": "https://storage.example/document.pdf",
  "operation": "extract-text"
}

The consumer retrieves the payload from storage.

This keeps messages smaller and allows the messaging layer to focus on coordinating work rather than transporting large files.

9. Message Processing Modes

Service Bus provides different approaches for receiving messages.

The two important concepts for the AI-200 exam are:

  • Peek-lock
  • Receive-and-delete

10. Peek-Lock Mode

Peek-lock is generally the preferred mode when losing a message is unacceptable.

The processing model is approximately:

Receive message
      |
      v
Message is locked
      |
      v
Process message
      |
      v
Complete message

When the consumer receives a message in peek-lock mode, the message is temporarily locked so another consumer cannot simultaneously process it.

After successful processing, the consumer explicitly completes the message.

11. Message Settlement

When using peek-lock, the consumer must settle the message.

Important settlement operations include:

Complete

The operation succeeded.

The message is removed from the queue or subscription.

Process successfully
       |
       v
    Complete
       |
       v
Message removed

Abandon

The consumer cannot successfully process the message and wants it made available again.

Processing failure
       |
       v
    Abandon
       |
       v
Message becomes available again

Dead-letter

The message is considered unsuitable for normal processing and is moved to the dead-letter queue.

This is useful for poison messages or messages that cannot be successfully processed after repeated attempts.

Defer

The consumer can defer a message when processing cannot currently continue but the application wants to retrieve it later using its sequence number.

12. Why Peek-Lock Is Important

Consider this sequence:

1. Worker receives message.
2. Worker starts AI processing.
3. Worker crashes.
4. Message was never completed.

Because the message wasn’t completed, Service Bus can make it available again after the lock expires.

This provides an at-least-once processing behavior.

The important consequence is:

A message can potentially be processed more than once.

Therefore, AI workers should ideally be designed to be idempotent.

For example, before inserting an embedding, the application could check whether that document/version has already been processed.

13. Receive-and-Delete

In receive-and-delete mode, the message is removed as soon as it is received.

Receive
   |
   v
Message deleted
   |
   v
Process

This can provide simpler and potentially higher-throughput processing, but it introduces a major risk.

If the worker crashes after receiving the message but before completing the work, the message is already gone.

Therefore:

Use peek-lock when message loss is unacceptable.

Use receive-and-delete only when occasional message loss is acceptable.

14. Message Locks

When a message is received using peek-lock, it is temporarily locked.

The lock prevents another receiver from processing the same message simultaneously.

However, the lock has a limited duration.

If processing takes too long, the application can renew the lock where supported.

For long-running AI operations, this is important.

For example:

Receive
  |
  v
Lock acquired
  |
  +---- Process AI request
  |
  +---- Renew lock
  |
  +---- Renew lock
  |
  v
Complete

If the lock expires before the message is completed, the message can become available again.

This can result in duplicate processing.

15. Dead-Letter Queues

A dead-letter queue (DLQ) is a secondary subqueue associated with a Service Bus queue or topic subscription.

It stores messages that cannot be successfully processed or delivered.

Common causes include:

  • Exceeding the maximum delivery count.
  • Message expiration when dead-lettering on expiration is enabled.
  • Explicit application dead-lettering.
  • Certain forwarding or routing failures.
  • Invalid processing conditions.

The DLQ is therefore an important mechanism for handling poison messages.

16. What Is a Poison Message?

A poison message is a message that repeatedly fails processing.

For example:

Message received
      |
      v
AI worker fails
      |
      v
Message retried
      |
      v
AI worker fails
      |
      v
Message retried
      |
      v
...
      |
      v
Dead-letter queue

Without a DLQ, the same bad message could continuously consume processing capacity.

17. Maximum Delivery Count

Service Bus queues and topic subscriptions have a maximum delivery count.

The default value is commonly 10.

When a message is repeatedly delivered under peek-lock and the processing attempt fails—for example, because the message is abandoned or its lock expires—the delivery count increases.

Once the configured maximum is exceeded, Service Bus moves the message to the DLQ.

The important exam concept is:

Increasing the maximum delivery count does not fix a poison message. It only allows more failed delivery attempts before dead-lettering.

The appropriate value depends on the workload.

18. Handling the Dead-Letter Queue

A DLQ should not simply become a place where failed messages are forgotten.

A production application should monitor it.

A typical operational workflow is:

             Normal Queue
                  |
                  v
             AI Worker
                  |
             Processing
             /         \
          Success      Failure
             |           |
             v           v
          Complete      Retry
                         |
                         v
                    Max attempts
                         |
                         v
                       DLQ
                         |
                         v
                 Investigate
                         |
              +----------+----------+
              |                     |
           Correct                Reject
              |                     |
              v                     v
          Reprocess              Discard

The application or operations team can inspect DLQ messages, determine why processing failed, correct the underlying problem, and potentially resubmit appropriate messages.

Dead-lettered messages include dead-letter reason information that can help diagnose the failure.

19. Explicit Dead-Lettering

An application can explicitly dead-letter a message.

This is appropriate when the application determines that retrying will not solve the problem.

For example:

Message:
customerId = 123
operation = generate-report
format = "INVALID_FORMAT"

If the application knows that the message is permanently invalid, repeatedly retrying it is wasteful.

The worker can dead-letter the message instead.

This is different from a transient error such as:

AI service temporarily unavailable

A transient failure may justify retrying.

A permanently invalid message generally should not.

20. Retry vs. Dead-Letter

A useful exam distinction is:

SituationAppropriate response
Temporary network failureRetry
Temporary AI service throttlingRetry
Worker temporarily unavailableRetry
Invalid message structurePotentially dead-letter
Unsupported operationPotentially dead-letter
Poison messageDead-letter after appropriate retries
Processing repeatedly failsDead-letter
Successful processingComplete

The key is distinguishing transient failures from permanent failures.

21. Time to Live (TTL)

Messages can have a time-to-live (TTL).

TTL determines how long a message is considered valid.

For example:

Message created
      |
      |---------------- TTL ----------------|
      |                                      |
      v                                      v
   Valid                                 Expired

An expired message should generally no longer be processed.

If dead-lettering on message expiration is enabled for the entity, expired messages can be moved to the DLQ.

This can be useful when stale AI requests are no longer useful.

For example, an AI recommendation request that is several hours old may no longer have business value.

22. Idempotent AI Processing

At-least-once delivery means that duplicate processing is possible.

Consider:

Worker receives message
      |
      v
Generate embedding
      |
      v
Store embedding
      |
      X
Worker crashes before Complete

The message may be delivered again.

The worker might generate and store the embedding again.

A robust application should therefore make important operations idempotent.

One strategy is to use a deterministic identifier:

documentId + documentVersion

The worker can check whether that specific version has already been processed.

Another approach is to use Service Bus duplicate-detection capabilities where appropriate, combined with application-level safeguards.

Do not assume that messaging infrastructure alone eliminates every duplicate-processing scenario.

23. Sessions and Ordered Processing

Some applications require related messages to be processed in order.

Service Bus supports sessions for this purpose.

A session groups related messages using a session identifier.

For example:

Session: Customer-1001
Message 1
Message 2
Message 3
Message 4

A session-enabled consumer can process the messages associated with the session as an ordered sequence.

Sessions are useful when an AI workflow contains stateful or order-dependent operations.

For example:

Document uploaded
       |
       v
Text extracted
       |
       v
Embedding generated
       |
       v
Index updated

If later operations depend on earlier ones, ordering can become important.

24. Service Bus in an AI Architecture

A common AI architecture might look like:

                +----------------+
                | Client         |
                +-------+--------+
                        |
                        v
                +----------------+
                | AI API         |
                +-------+--------+
                        |
                        v
                +----------------+
                | Service Bus    |
                | Queue          |
                +-------+--------+
                        |
             +----------+----------+
             |          |          |
             v          v          v
          Worker 1   Worker 2   Worker 3
             |          |          |
             +----------+----------+
                        |
                        v
                +----------------+
                | Azure AI       |
                | Services       |
                +----------------+

This design provides:

  • Asynchronous processing.
  • Load leveling.
  • Horizontal scalability.
  • Failure isolation.
  • Retry capabilities.
  • Durable message storage.
  • Better control of downstream AI workloads.

25. Service Bus Topics in AI Event Architectures

Topics are especially useful when one AI event needs to trigger multiple independent workflows.

For example:

                    +--> Embedding pipeline
                    |
DocumentUploaded -->+--> Classification pipeline
                    |
                    +--> Audit pipeline
                    |
                    +--> Notification pipeline

Each pipeline can have its own subscription.

This avoids tightly coupling the document-uploading application to every downstream service.

26. Monitoring Service Bus Workloads

Operational monitoring is important because messaging problems can be difficult to see from the front-end application alone.

Useful indicators include:

  • Active message count.
  • Dead-letter message count.
  • Message processing failures.
  • Message age.
  • Processing latency.
  • Receiver throughput.
  • Queue backlog.
  • Delivery counts.

A growing active-message count can indicate that producers are generating messages faster than consumers can process them.

A growing DLQ count can indicate a processing or data-quality problem.

For AI workloads, also monitor downstream dependencies such as model-service throttling and latency.

27. Common AI-200 Exam Traps

Trap 1: Choosing a topic when only one worker should process each message

Use a queue for a competing-consumer workload.

Trap 2: Choosing a queue when multiple independent consumers need every event

Use a topic with subscriptions.

Trap 3: Assuming peek-lock means exactly-once processing

Peek-lock supports reliable processing, but duplicate processing can still occur.

Design consumers to be idempotent.

Trap 4: Using receive-and-delete for critical workloads

The message is removed before processing completes.

If the worker fails, the message can be lost.

Trap 5: Treating the DLQ as a retry queue

A DLQ is primarily a place to isolate messages that cannot be successfully processed or delivered.

Investigate the cause before reprocessing them.

Trap 6: Increasing MaxDeliveryCount to solve permanent failures

If the message itself is invalid, more retries simply waste resources.

Trap 7: Putting large documents directly into Service Bus messages

Consider storing large payloads in Blob Storage and placing a reference in the message.

Trap 8: Forgetting duplicate processing

At-least-once processing means consumers should tolerate duplicates.

28. Quick Decision Guide

Use this mental model for the exam:

Need asynchronous processing?
            |
            v
       Azure Service Bus
            |
      +-----+------+
      |            |
   One path      Many paths
      |            |
      v            v
    Queue        Topic
                   |
                   v
             Subscriptions

For message processing:

Critical message?
      |
      +---- Yes ---> Peek-lock
      |
      +---- No ----> Receive-and-delete may be acceptable

For processing failures:

Failure
  |
  +--> Temporary? ----> Retry
  |
  +--> Permanent? ----> Dead-letter
  |
  +--> Repeated failure? ----> DLQ

For large AI payloads:

Large file
    |
    v
Blob Storage
    |
    v
Service Bus message
(reference + metadata)

29. Key Takeaways

For AI-200, remember these concepts:

  1. Queues provide point-to-point messaging and competing-consumer processing.
  2. Topics provide publish/subscribe messaging.
  3. Subscriptions allow independent consumers to receive copies of topic messages.
  4. Peek-lock is appropriate when message loss is unacceptable.
  5. Receive-and-delete removes a message before processing completes and can result in message loss.
  6. Complete removes a successfully processed message.
  7. Abandon makes a message available for another delivery attempt.
  8. Dead-letter moves a message into the DLQ for isolation and investigation.
  9. At-least-once processing means duplicate processing is possible.
  10. AI workers should be designed to be idempotent where duplicate execution is possible.
  11. Maximum delivery count controls how many delivery attempts occur before dead-lettering.
  12. TTL controls message lifetime.
  13. Topics are ideal for fan-out scenarios.
  14. Subscription filters can selectively route messages.
  15. Correlation IDs are valuable for distributed tracing and troubleshooting.
  16. Large payloads should generally be stored externally, with a reference in the Service Bus message.
  17. Sessions can be used when ordered, stateful message processing is required.
  18. A growing DLQ is an operational signal that requires investigation.
  19. A growing active-message backlog can indicate insufficient consumer capacity.
  20. Service Bus is particularly valuable in AI architectures because it decouples request ingestion from potentially expensive or long-running AI processing.

Practice Exam Questions

Question 1

An AI application receives document-processing requests through an HTTP API. Each request should be processed by exactly one available worker. Multiple worker instances must be able to process requests concurrently.

Which Azure Service Bus entity should you use?

A. Queue

B. Topic with one subscription

C. Topic with multiple subscriptions

D. Event Grid topic

Answer: A. Queue

Explanation

A Service Bus queue is designed for point-to-point communication and competing consumers. Multiple workers can receive messages from the same queue while each message is processed by one consumer.

A topic is more appropriate when the same event needs to be delivered independently to multiple subscribers. Event Grid is primarily designed for event notification and event-driven architectures rather than work-queue semantics.

Question 2

An AI application publishes a DocumentUploaded event. Three independent services must receive the event: an embedding service, an auditing service, and a notification service.

Which Service Bus design should you use?

A. Three separate queues with the application sending the message to each queue

B. One queue with three competing consumers

C. One topic with three subscriptions

D. One subscription attached to three queues

Answer: C. One topic with three subscriptions

Explanation

A Service Bus topic with multiple subscriptions implements a publish/subscribe pattern. Each subscription can independently receive a copy of the event.

Using a queue with multiple competing consumers would not guarantee that all three services receive the message because competing consumers process a message rather than each receiving an independent copy.

Question 3

An AI worker receives a message using peek-lock mode. The worker successfully completes the AI operation but crashes before completing the Service Bus message.

What can happen?

A. The message is permanently deleted

B. The message can become available for redelivery

C. The message is automatically moved to another subscription

D. The message is converted into a scheduled message

Answer: B. The message can become available for redelivery

Explanation

With peek-lock, the message is not removed until the consumer successfully settles it, typically by completing it.

If the lock expires before completion, Service Bus can make the message available again. This creates the possibility of duplicate processing and is why consumers should be designed to be idempotent.

Question 4

An AI worker repeatedly receives a malformed message that cannot ever be processed successfully. The application should prevent the message from continually consuming worker capacity.

What is the most appropriate action?

A. Increase the message TTL

B. Dead-letter the message

C. Schedule the message for later

D. Extend the message lock indefinitely

Answer: B. Dead-letter the message

Explanation

A permanently invalid message is a good candidate for dead-lettering. The DLQ isolates the message from normal processing while allowing operators or application logic to investigate it.

Increasing retries or extending locks does not solve a permanent data problem.

Question 5

An AI application processes messages that occasionally fail because an external AI service is temporarily unavailable. What should the application generally do first?

A. Retry the operation

B. Immediately delete the message

C. Immediately dead-letter every message

D. Disable the Service Bus queue

Answer: A. Retry the operation

Explanation

A temporary service outage is a transient failure. Retrying the operation is generally appropriate, assuming the retry strategy is bounded and incorporates appropriate delay/backoff.

Permanent failures should generally be dead-lettered rather than repeatedly retried.

Question 6

An AI application uses Service Bus to process critical inference requests. The application must minimize the possibility of losing a request if a worker crashes while processing it.

Which receive mode should be used?

A. Receive-and-delete

B. Peek-lock

C. Browse-only

D. Scheduled delivery

Answer: B. Peek-lock

Explanation

Peek-lock allows the worker to receive and lock the message without immediately removing it. The worker completes the message after successful processing.

If the worker crashes before completion, the message can become available for redelivery after the lock expires.

Receive-and-delete removes the message as soon as it is received, so a worker failure can result in message loss.

Question 7

A document-processing AI solution needs to pass a 20-MB document to a background worker. The development team wants to avoid putting the entire document into the Service Bus message.

What is the best design?

A. Store the document in Blob Storage and place a reference to it in the Service Bus message

B. Convert the document to Base64 and place it directly in the message

C. Split the document into hundreds of unrelated messages

D. Store the document in the message’s correlation ID

Answer: A. Store the document in Blob Storage and place a reference to it in the Service Bus message

Explanation

The claim-check pattern is appropriate for large payloads. The document can be stored in Blob Storage while the Service Bus message contains the document identifier or URI plus relevant metadata.

This keeps the messaging layer focused on coordinating work rather than transporting large payloads.

Question 8

A Service Bus queue has a configured maximum delivery count of 10. A worker receives a message but repeatedly abandons it because processing fails.

What eventually happens when the message exceeds the configured delivery limit?

A. The message is automatically copied to every topic

B. The message is permanently deleted without any record

C. The message is moved to the dead-letter queue

D. The message is automatically sent to Event Grid

Answer: C. The message is moved to the dead-letter queue

Explanation

When a message repeatedly fails processing and exceeds the configured maximum delivery count, Service Bus moves it to the DLQ.

The DLQ provides a separate location where the message can be investigated and, when appropriate, corrected and reprocessed.

Question 9

An AI system publishes messages describing uploaded documents. The application has separate consumers for compliance, analytics, and embedding generation. Each consumer should receive its own copy of applicable messages.

Which feature should the developer use to route only relevant messages to each consumer?

A. Queue sessions

B. Topic subscription filters

C. Message lock renewal

D. Receive-and-delete mode

Answer: B. Topic subscription filters

Explanation

Topic subscriptions can use filters to determine which messages are delivered to each subscription.

For example, a compliance subscription could receive only documents belonging to a particular business category while an embedding subscription receives all document events.

Question 10

An AI worker processes a message successfully and writes the result to a database. Before the worker completes the Service Bus message, it crashes. The message is subsequently delivered again.

What is the best way for the application to handle this possibility?

A. Assume Service Bus guarantees exactly-once application processing

B. Disable message retries

C. Design the processing operation to be idempotent

D. Use receive-and-delete mode

Answer: C. Design the processing operation to be idempotent

Explanation

Peek-lock processing provides reliable message handling but does not eliminate the possibility of duplicate processing. A worker can successfully perform its business operation and then fail before completing the Service Bus message.

The message may therefore be delivered again.

An idempotent application can safely recognize that the operation has already been performed—for example, by using a document ID and version as an idempotency key—rather than creating duplicate results.

Receive-and-delete would actually increase the risk of losing messages if the worker fails before completing its work.

This exam topic is especially worth mastering for AI-200 because exam scenarios often combine Service Bus + asynchronous AI processing + retries + competing consumers + DLQs rather than asking about those features in isolation.

Go to the AI-200 Exam Prep Hub main page