AZ-204 Develop Azure compute solutions Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  CallActivityAsync with a try-catch loop that implements retry logic

  Why it's wrong here

  A manually written try-catch loop with `CallActivityAsync` lacks the built-in exponential backoff and retry count enforcement that the Durable Functions `CallActivityWithRetryAsync` method provides. The stem requires doubling the delay after each of up to three retries, which would demand custom timer logic and state management in a loop. This approach is tempting because `CallActivityAsync` is the standard method for invoking activity functions without retry concerns, and a try-catch loop is a natural pattern for handling transient failures in synchronous code. It would be correct only if the requirement were a simple, non-exponential retry with a fixed delay, where manual implementation is acceptable.

• ✓

  CallActivityWithRetryAsync with RetryOptions(maxAttempts: 3, firstRetryInterval: TimeSpan.FromSeconds(5), backoffCoefficient: 2)

  Why this is correct

  The `CallActivityWithRetryAsync` method is the native and most robust way to implement retry logic for activity function calls within a Durable Functions orchestration. By utilizing `RetryOptions`, developers can declaratively specify the exact retry policy, including `maxAttempts`, `firstRetryInterval`, and `backoffCoefficient`, which directly maps to the requirement of 3 attempts with an initial 5-second delay that doubles exponentially. This approach leverages Durable Functions' built-in state management and reliability features, ensuring that the retry logic persists across orchestrator rehydrations and host restarts without manual state tracking.

• ✗

  Use a timer trigger to schedule retries after failure

  Why it's wrong here

  Using a timer trigger to schedule retries after an activity failure is an inappropriate and overly complex solution for Durable Functions orchestrations. Timer triggers are designed to initiate new function executions on a predefined schedule, not to manage internal retry logic for specific failed operations within an ongoing orchestration instance. Implementing this would require external state management to track which activity failed, how many times it has been retried, and to correlate the timer-triggered function back to the specific orchestration instance, thereby undermining the inherent reliability and statefulness provided by Durable Functions.

• ✗

  Set the activity function's retry policy in the function.json file

  Why it's wrong here

  Setting an activity function's retry policy in its `function.json` file is incorrect because `function.json` primarily defines the bindings, triggers, and metadata for a single function's execution context, not its invocation behavior when called by an orchestrator. Retry policies for activity functions are a concern of the *orchestrator client* (the orchestration function itself) that invokes the activity, not the activity function's own definition. The `function.json` schema does not support defining retry policies for activity functions, as this logic is handled at the orchestration level via methods like `CallActivityWithRetryAsync`.

Go deeper

Related to this question