Courseiva

AZ-204 Practice Question: Connect to and consume Azure services and third-party services

You are developing a serverless application using Azure Functions that processes orders. Each order must be validated by calling a third-party API. If the third-party API is unavailable, the function should retry with exponential backoff. How should you implement this?

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

Implement retry logic with exponential backoff and circuit breaker using Polly within the function

It uses the Polly library to implement retry logic with exponential backoff and circuit breaker, which is a lightweight and flexible approach. Option B is incorrect because the trigger binding's automatic retries are for infrastructure failures (e.g., message delivery), not for application-level errors like API unavailability. Option C is incorrect because a long timeout does not handle transient faults; it just waits. Option D is incorrect because, while Azure Durable Functions does support retry via CallActivityWithRetryAsync, it introduces unnecessary complexity (orchestration overhead) for a simple HTTP call that can be handled directly with a library like Polly.

Answer analysis

Option-by-option breakdown

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

  • Implement retry logic with exponential backoff and circuit breaker using Polly within the function

    Why this is correct

    Polly provides robust transient fault handling.

  • Enable automatic retries on the function's trigger binding

    Why it's wrong here

    Triggers like Service Bus have retries, but they are not designed for custom external calls.

  • Configure the function to have a long timeout and hope the API responds

    Why it's wrong here

    This does not handle failures.

  • Use Azure Durable Functions to orchestrate the retry

    Why it's wrong here

    Durable Functions provide a framework for orchestrating long-running workflows with built-in retry logic, but they introduce unnecessary complexity and state management overhead for a single retry requirement. The scenario only needs a simple retry with exponential backoff on one third-party call, which Azure Functions’ built-in retry policies (configured in `host.json` or via the `Retry` attribute) handle directly without an orchestration. This option is tempting because Durable Functions excel at coordinating multiple steps with retries across functions, making it correct for multi-step order processing where each step requires independent retry logic.

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

This AZ-204 question is part of Courseiva's 881-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.