Courseiva
Develop Azure compute solutionshardMultiple SelectObjective-mapped

AZ-204 Develop Azure compute solutions Practice Question

An Azure Functions document rendering job processes Service Bus messages. The function sometimes fails after partially completing work. Which two practices improve correctness?

⚠ Common exam trap

A common mix-up: candidates think disabling retries (Option C) prevents duplicate processing, but they overlook that retries are essential for transient fault tolerance, and the correct approach is to combine idempotency with dead-letter handling for permanent failures.

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 dead-letter handling for repeatedly failing messages

Azure Functions can use dead-letter queues (DLQ) to isolate messages that repeatedly fail processing, preventing them from blocking the queue and allowing investigation without data loss. Option B is correct because making the handler idempotent ensures that if a message is retried after a partial failure (e.g., the function crashes mid-execution), reprocessing the same message does not cause duplicate or inconsistent state, which is critical for correctness in a Service Bus triggered function.

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 dead-letter handling for repeatedly failing messages

    Why this is correct

    Using dead-letter handling is a critical practice for robust message processing in Azure Functions. When a message repeatedly fails to process after a configured number of retries, perhaps due to malformed data or an unrecoverable external dependency issue, it should be moved to a dead-letter queue. This prevents "poison messages" from endlessly blocking the main queue and allows for subsequent manual inspection, debugging, or automated reprocessing logic without losing the message entirely.

  • Make the handler idempotent

    Why this is correct

    Making the handler idempotent is essential for reliability in distributed systems like Azure Functions processing Service Bus messages. Idempotency ensures that executing the document rendering operation multiple times with the same input will produce the exact same result and not cause unintended side effects, such as duplicate documents or corrupted state. This design pattern is crucial because transient failures and retries are common, and the handler must safely withstand repeated invocations.

  • Disable retries for all messages

    Why it's wrong here

    Disabling retries for all messages significantly increases the risk of message loss and reduces system resilience. Transient failures, such as temporary network glitches, database connection issues, or service throttling, are common in cloud environments. Without retries, any message encountering such a temporary issue would immediately fail and either be lost or prematurely moved to a dead-letter queue, requiring manual intervention for easily recoverable errors.

  • Store connection strings in source code

    Why it's wrong here

    Storing connection strings directly in source code is a severe security vulnerability and offers no benefit to the correctness or reliability of message processing. Hardcoding sensitive credentials exposes them to anyone with access to the code repository and makes credential rotation difficult and error-prone. Best practices dictate using secure configuration management services like Azure Key Vault or Azure App Configuration, often combined with Managed Identities, to securely access resources.

Quick reference

Cloud Service Model Comparison

ModelYou ManageProvider ManagesExamples
IaaSOS, runtime, apps, dataHardware, hypervisor, networkingEC2, Azure VMs, GCP Compute Engine
PaaSApps and dataOS, runtime, middleware, hardwareElastic Beanstalk, Azure App Service
SaaSData and settings onlyEverything elseMicrosoft 365, Salesforce, Workday
FaaS / ServerlessFunction code onlyInfra, scaling, runtimeLambda, Azure Functions, Cloud Run
CaaSContainers and appsKubernetes, OS, hardwareEKS, AKS, GKE

Go deeper

Related to this question

About these practice questions

One of 881 original AZ-204 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.