AZ-204 Develop Azure compute solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Make the function idempotent

  Why this is correct

  When an Azure Function processes Event Hub messages, especially under high load or transient errors, messages can be delivered multiple times due to the at-least-once delivery guarantee. Implementing idempotency means designing the function's logic so that processing the same event multiple times produces the same result as processing it once, without adverse side effects. This typically involves using a unique identifier from the event to check if the operation has already been completed before performing it again, often by storing processing status in a durable store like Azure Cosmos DB or Table Storage.

• ✗

  Use Azure Queue Storage instead

  Why it's wrong here

  While Azure Queue Storage is excellent for reliable message delivery and decoupling, simply switching to it does not inherently solve the problem of duplicate processing if the underlying issue is related to retries or at-least-once delivery semantics. Queues themselves can also experience duplicate messages under certain failure scenarios, requiring similar deduplication strategies at the consumer level. Therefore, it's a different messaging service but doesn't automatically provide deduplication without additional application logic.

• ✗

  Enable checkpointing

  Why it's wrong here

  Checkpointing in Event Hubs (and by extension, Azure Functions with Event Hub triggers) is crucial for tracking the progress of a consumer group across partitions. It allows the function to resume processing from the last successfully processed event offset after a restart or failure, preventing reprocessing of *already committed* events. However, checkpointing does not prevent the Event Hub service from delivering the *same event* multiple times due to transient network issues or consumer failures *before* a successful checkpoint, which is where idempotency becomes vital.

• ✗

  Increase the batch size

  Why it's wrong here

  Increasing the batch size for an Event Hub trigger means the function will receive and process more events in a single invocation. While this can improve throughput and reduce the number of function invocations, it has no bearing on whether individual events within or across batches might be delivered multiple times by the Event Hub service. The core problem of at-least-once delivery and potential duplicates remains, regardless of how many events are processed concurrently in a batch.

Go deeper

Related to this question