AZ-204 Develop Azure compute solutions Practice Question
You are developing an Azure Functions app that uses Durable Functions to orchestrate a long-running workflow. The workflow involves calling multiple external APIs. You need to ensure that the orchestration can survive a function app restart. Which feature should you use?
⚠ Common exam trap
Watch out — candidates often confuse logging (Application Insights) with state persistence, or assume retry policies or timeouts are sufficient for durability, when only the built-in checkpointing and replay mechanism guarantees survival across restarts.
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 default checkpointing and replay mechanism.
Durable Functions inherently use a checkpointing and replay mechanism to persist the orchestration state to a storage backend (Azure Storage queues, tables, and blobs). This ensures that after a function app restart, the orchestrator function can replay from the last checkpoint, restoring the exact execution context and continuing the workflow without data loss.
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 the default checkpointing and replay mechanism.
Why this is correct
Durable Functions inherently provides state persistence and reliability through its default checkpointing and replay mechanism. It automatically saves the orchestration's execution history to a storage provider (typically Azure Storage) after each await point. In the event of an app restart or host failure, the Durable Task Framework replays this stored history to reconstruct the orchestration's state exactly as it was before the interruption, ensuring seamless continuation. This built-in functionality is fundamental to Durable Functions' "durable" nature.
- ✗
Log orchestration state to Application Insights.
Why it's wrong here
Logging orchestration state to Application Insights provides valuable telemetry for monitoring, debugging, and analyzing the execution flow of your Durable Functions. However, Application Insights is a monitoring and diagnostics service, not a state persistence mechanism designed for fault tolerance and replay. While logs show what happened, they do not enable the Durable Task Framework to reconstruct and resume an orchestration's execution from a specific point after an app restart, which requires structured, replayable state.
- ✗
Implement retry policies on the activity functions.
Why it's wrong here
Implementing retry policies on activity functions is a crucial best practice for handling transient failures that might occur during the execution of individual activities. These policies allow an activity to be re-executed a specified number of times with back-off delays if it fails. However, retry policies operate at the activity level and address temporary issues within a single execution attempt; they do not provide a mechanism for an entire orchestration to resume its state from a previous point after the Durable Functions host itself has restarted.
- ✗
Set a high timeout on the orchestration.
Why it's wrong here
Setting a high timeout on an orchestration function merely defines the maximum duration an orchestration instance is allowed to run before it is automatically terminated. While it prevents an orchestration from running indefinitely, it does not contribute to state persistence or fault tolerance across application restarts. A timeout simply dictates when an orchestration should stop, it does not save its progress or enable it to resume from a previous state if the host process unexpectedly terminates and restarts.
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
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.
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.