AZ-204 Develop Azure compute solutions Practice Question
Your Azure Function app uses an event-driven architecture with Azure Event Hubs. You need to ensure that if the function fails to process an event, the event is retried up to three times and then sent to a dead-letter queue. What should you configure?
⚠ Common exam trap
Test-takers frequently confuse the retry policy configuration location (host.json for the function app) with properties on the Event Hubs namespace itself, or they overcomplicate the solution by choosing Durable Functions when a simple declarative setting suffices.
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
✓
Configure the retry policy in the function's host.json file.
Azure Functions for Event Hubs supports a built-in retry policy configured in the host.json file. This policy allows you to specify the maximum number of retries (e.g., 3) and, after exhausting those retries, the event is automatically sent to a dead-letter queue (DLQ) configured on the Event Hub. This approach is declarative and requires no custom code for retry or dead-lettering logic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Durable Functions to orchestrate retries and dead-lettering.
Why it's wrong here
Using Durable Functions for simple retries and dead-lettering introduces unnecessary architectural complexity. Durable Functions are designed for orchestrating long-running, stateful workflows across multiple function executions, not for handling transient faults of individual event-triggered functions. While they can implement retry logic, it's an overkill solution when a simpler, declarative retry policy is available and more appropriate for basic event processing failures.
- ✗
Implement a try-catch block in the function code and manually re-queue the event.
Why it's wrong here
Implementing a try-catch block to manually re-queue the event bypasses Event Hubs' built-in checkpointing and retry policies, failing to meet the requirement for a dead-letter queue after three retries. This approach is tempting because it mirrors a common pattern for transient fault handling in code, and would be correct in a queue-based system like Azure Queue Storage where manual dequeue and dead-letter logic is necessary.
- ✓
Configure the retry policy in the function's host.json file.
Why this is correct
Configuring the retry policy within the function's host.json file is the correct and most efficient approach for handling transient failures in event-driven Azure Functions. This declarative configuration allows you to define parameters like `maxRetryCount` and `retryStrategy` (e.g., fixed delay or exponential backoff) directly. For supported bindings like Event Hubs, it automatically integrates with dead-lettering mechanisms, ensuring events are moved to a dead-letter queue after the specified number of retries are exhausted.
- ✗
Set the 'enableRetry' property on the Event Hub namespace.
Why it's wrong here
Setting an 'enableRetry' property on the Event Hub namespace is incorrect because Event Hubs itself is a message broker and does not manage consumer-side retry logic. Event Hubs focuses on ingesting and distributing events, leaving the responsibility of processing, checkpointing, and implementing retry policies entirely to the consumer application, such as an Azure Function. Therefore, any retry mechanism must be configured within the consumer's environment, not on the Event Hubs service itself.
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 Event Hubs
Azure Event Hubs is a cloud-based service that ingests and processes millions of events per second from devices, applications, and services in real time.
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.
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.