AZ-204 Develop Azure compute solutions Practice Question
Which THREE considerations are important when designing an Azure Function that uses Durable Functions for fan-out/fan-in pattern?
⚠ Common exam trap
Candidates often confuse the orchestrator's role with a regular function, thinking it can perform I/O directly or be triggered by HTTP, when in fact it must be stateless and deterministic, relying on activity functions for all I/O.
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
✓
The orchestrator function must be deterministic.
Option A is correct because Durable Functions orchestrator code must be deterministic: it is replayed from the orchestration history on each activation, so non-deterministic constructs like DateTime.Now, Guid.NewGuid(), or random values can cause replay divergence and inconsistent results. Option B is correct because orchestrators must not perform direct I/O (HTTP calls, database access, file operations); such work belongs in activity functions, since direct I/O during replay would be repeated and could produce incorrect or duplicated side effects. Option E is correct because Durable Functions require a backing storage account for the task hub, storing orchestration history, queues, and instance state, configured via a storage connection string such as AzureWebJobsStorage. Option C is incorrect because orchestration history is persisted durably in the task hub storage (Azure Storage tables/queues or the configured backend), not kept in memory for latency reduction. Option D is incorrect because orchestrators are not triggered directly by HTTP triggers; they are started by a durable client binding (for example, an HTTP-triggered starter function calling the orchestration client), and the orchestrator itself uses the orchestration trigger binding.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The orchestrator function must be deterministic.
Why this is correct
Durable Function orchestrators rely on event sourcing and replay to reconstruct their state after being unloaded from memory or after a host restart. For this replay mechanism to consistently produce the same state and output, the orchestrator's code must be deterministic. Non-deterministic operations, such as generating random numbers, getting the current date/time directly, or making direct HTTP calls, would lead to different execution paths and inconsistent state during replays, causing runtime errors or incorrect behavior.
- ✓
The orchestrator function should not perform any I/O operations directly.
Why this is correct
Direct I/O operations, such as database calls, file system access, or external API requests, introduce non-deterministic behavior into an orchestrator function. When an orchestrator is replayed, these operations would be re-executed, potentially leading to unintended side effects or different results each time. To maintain determinism and ensure reliable state reconstruction, all I/O and external interactions must be encapsulated within separate activity functions, which the orchestrator then calls using `context.callActivityAsync`.
- ✗
Orchestration history is stored in memory to reduce latency.
Why it's wrong here
This statement is incorrect because Durable Functions do not store orchestration history solely in memory. Instead, the entire execution history, including inputs, outputs, and events, is durably persisted in Azure Storage, specifically in Azure Table storage. This persistence ensures that orchestrations can reliably recover from host failures and continue execution from the last known state, even if the function app restarts, which would not be possible with in-memory storage.
- ✗
The orchestrator function should be triggered by an HTTP trigger directly.
Why it's wrong here
Orchestrator functions are not directly invoked by HTTP triggers. Instead, they are initiated by a separate "client" or "starter" function, which can be an HTTP-triggered function, a queue-triggered function, or another type of Azure Function. The starter function uses the Durable Functions client binding to start a new orchestration instance and returns a status HTTP response, allowing the orchestrator to run asynchronously in the background.
- ✓
The function app must have a storage account connection string configured.
Why this is correct
Durable Functions heavily rely on Azure Storage for their operational integrity and state management. This includes persisting orchestration history, storing entity states, managing internal queues for reliable message delivery between functions, and handling instance metadata. Therefore, a properly configured Azure Storage account connection string, typically specified via the `AzureWebJobsStorage` application setting, is absolutely essential for any Durable Functions app to function correctly.
Go deeper
Related to this question
About these practice questions
One of 883 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 →
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.