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.

• ✗

  await context.CallActivityAsync("Activity", input);

  Why it's wrong here

  The `context.CallActivityAsync` method executes an activity function a single time without any built-in retry mechanism. If the called activity fails due to a transient error, the orchestration will either fail or require explicit, manual implementation of retry logic using a `try-catch` block and durable timers, which is less efficient and more verbose than using the dedicated retry API.

• ✓

  await context.CallActivityWithRetryAsync("Activity", new RetryOptions(TimeSpan.FromSeconds(5), 3), input);

  Why this is correct

  This is the correct and idiomatic approach for implementing built-in retry logic in Durable Functions orchestrations. The `context.CallActivityWithRetryAsync` method automatically handles transient failures by retrying the specified activity function based on the provided `RetryOptions`, which define the `FirstRetryInterval` (5 seconds) and `MaxNumberOfAttempts` (3), ensuring robustness without manual retry loops.

• ✗

  await context.CallActivityAsync("Activity", input, new RetryOptions(TimeSpan.FromSeconds(5), 3));

  Why it's wrong here

  This option is syntactically incorrect because the `context.CallActivityAsync` method does not have an overload that accepts `RetryOptions` as an argument. Attempting to pass `RetryOptions` to `CallActivityAsync` would result in a compilation error, as the method signature is not designed to incorporate built-in retry policies directly through this specific overload.

• ✗

  Use a durable timer and a loop to retry manually.

  Why it's wrong here

  A manual loop with a durable timer lacks the built-in retry policy that Durable Functions provides via `CallActivityWithRetryAsync`, which automatically manages exponential backoff and maximum attempt counts. This approach is tempting because it offers explicit control over timing and retry logic, and would be correct for custom retry patterns not supported by the built-in retry feature, such as non-standard delays or conditional retries based on activity output.