AZ-204 Develop Azure compute solutions Practice Question
You are designing a serverless application using Azure Functions that processes high-volume events from Azure Event Hubs. The events are then written to Azure Cosmos DB. The function must guarantee at-least-once delivery and be resilient to failures. The Cosmos DB account uses the SQL API and is configured with a single write region. You need to design the function to handle transient failures when writing to Cosmos DB without losing events. What should you do?
⚠ Common exam trap
Candidates often think manual checkpointing gives them more control, but it actually introduces a window for data loss if the checkpoint occurs before the write is confirmed, whereas the output binding's built-in retry and automatic checkpointing on success provide a safer, more reliable pattern.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use the Cosmos DB output binding with built-in retry policy and configure the trigger to checkpoint only after successful writes.
Using the Cosmos DB output binding with its built-in retry policy automatically handles transient failures by retrying writes. By configuring the Event Hubs trigger to checkpoint only after a successful write, you ensure that events are not acknowledged until they are durably stored in Cosmos DB, guaranteeing at-least-once delivery and resilience to failures.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the Event Hubs trigger's batch size to reduce the number of writes.
Why it's wrong here
Increasing the Event Hubs trigger's batch size processes more events per function invocation but does not inherently improve the reliability of individual writes to Cosmos DB. While it might reduce the number of function invocations, it does not provide built-in retry mechanisms for Cosmos DB operations or guarantee that all events within a batch will be successfully written before checkpointing. Therefore, this approach does not directly address the requirement for reliable, at-least-once processing.
- ✗
Implement a poison message queue to store failed events and reprocess them later.
Why it's wrong here
Implementing a poison message queue typically involves dead-lettering events after all configured retries for the function execution have been exhausted. While this allows for later reprocessing, the original Event Hubs event might still be checkpointed as processed, leading to potential data loss if the event is only moved to the poison queue and not successfully written to Cosmos DB. This mechanism doesn't inherently ensure at-least-once delivery from the Event Hubs perspective without careful coordination.
- ✗
In the function code, manually write to Cosmos DB and then manually checkpoint the Event Hubs partition.
Why it's wrong here
Manually writing to Cosmos DB and then manually checkpointing the Event Hubs partition introduces a significant risk of data loss. If the function checkpoints the Event Hubs partition before the Cosmos DB write successfully completes, and the function subsequently crashes or fails, the event will be marked as processed in Event Hubs but never persisted to Cosmos DB, violating the at-least-once guarantee. This manual approach lacks the transactional safety needed for reliable processing.
- ✓
Use the Cosmos DB output binding with built-in retry policy and configure the trigger to checkpoint only after successful writes.
Why this is correct
Utilizing the Cosmos DB output binding provides built-in retry capabilities, automatically attempting to write data multiple times in case of transient failures, significantly improving reliability. Crucially, configuring the Event Hubs trigger to checkpoint only after successful writes ensures that an event is not marked as processed in Event Hubs until it has been durably persisted to Cosmos DB. This combination guarantees at-least-once delivery, preventing data loss even if the function encounters transient issues.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
Learn chapter
Azure Functions Development
Key term
Azure Functions Bindings
Azure Functions Bindings are declarative connections that link your serverless function code to Azure services or external resources, handling input and output data automatically without writing extra networking or authentication code.
Key term
Durable Functions
Durable Functions is an extension of Azure Functions that lets you write stateful workflows in code, managing complex sequences of tasks, retries, and delays automatically.
About these practice questions
Courseiva writes every AZ-204 question from scratch — 881 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.