Durable Functions for workflows in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

What happens when an activity function fails in a Durable Function orchestration?

Consider a Durable Function orchestration that calls multiple activity functions sequentially. If one activity function throws an exception, what is the default behavior of the orchestration?

A The orchestration retries the failed activity function based on configured retry policies, then fails if retries are exhausted.

B The orchestration immediately terminates and marks the entire workflow as failed.

C The orchestration retries the failed activity function indefinitely until it succeeds.

D The orchestration pauses and waits for manual intervention before continuing.

💡 Hint

Think about how Durable Functions handle transient failures with retry policies.

Durable Functions support retry policies for activity functions. When an activity fails, the orchestration retries it according to the policy. If retries are exhausted, the orchestration fails.

❓ Architecture

intermediate

Which pattern best describes Durable Functions orchestrations?

Durable Functions orchestrations are designed to manage workflows that require stateful coordination of multiple steps. Which architectural pattern do they best represent?

A Event-driven microservices pattern

B Monolithic application pattern

C Saga pattern for managing distributed transactions

D Client-server request-response pattern

💡 Hint

Consider how Durable Functions help manage long-running transactions and compensations.

Durable Functions orchestrations implement the Saga pattern, coordinating multiple steps and handling failures with compensations to maintain consistency.

❓ Configuration

advanced

What is the correct way to configure a retry policy for an activity function in Durable Functions?

You want to configure an activity function to retry up to 3 times with a 5-second delay between retries. Which code snippet correctly sets this retry policy in C#?

Azure

var retryOptions = new RetryOptions(TimeSpan.FromSeconds(5), 3);
await context.CallActivityWithRetryAsync("ActivityName", retryOptions, input);

A

var retryOptions = new RetryOptions(TimeSpan.FromSeconds(3), 5);
await context.CallActivityWithRetryAsync("ActivityName", retryOptions, input);

B

var retryOptions = new RetryOptions(TimeSpan.FromSeconds(5), 3);
await context.CallActivityWithRetryAsync("ActivityName", retryOptions, input);

C

var retryOptions = new RetryOptions(3, TimeSpan.FromSeconds(5));
await context.CallActivityWithRetryAsync("ActivityName", retryOptions, input);

D

var retryOptions = new RetryOptions(5, TimeSpan.FromSeconds(3));
await context.CallActivityWithRetryAsync("ActivityName", retryOptions, input);

💡 Hint

Check the order of parameters in the RetryOptions constructor: first delay, then max attempts.

The RetryOptions constructor takes the first parameter as the delay between retries and the second as the max number of attempts. Option B correctly sets 5 seconds delay and 3 retries.

❓ security

advanced

How should secrets be managed in Durable Functions to follow best security practices?

You have sensitive connection strings and API keys used by your Durable Functions. What is the best practice to manage these secrets securely?

A Use Azure Key Vault to store secrets and access them securely at runtime.

B Embed secrets in the Durable Function orchestration code as constants.

C Store secrets directly in the function app settings as plain text.

D Store secrets in a database table accessible by the Durable Function.

💡 Hint

Think about centralized secret management services designed for security.

Azure Key Vault is the recommended service to securely store and manage secrets. Durable Functions can access secrets at runtime without exposing them in code or app settings.

🧠 Conceptual

expert

What is the effect of the 'ContinueAsNew' method in a Durable Function orchestration?

In a long-running Durable Function orchestration, you call the method context.ContinueAsNew(input). What happens to the orchestration's state and execution?

A The orchestration saves its current state and continues execution without resetting or restarting.

B The orchestration pauses and waits for an external event before continuing with the same state.

C The orchestration forks a parallel execution path with the new input while keeping the original state intact.

D The orchestration completes immediately and triggers a new orchestration instance with the same instance ID and new input, resetting its state.

💡 Hint

Consider how to reset an orchestration's state while keeping the same instance ID.

The ContinueAsNew method ends the current orchestration and immediately starts a new one with the same instance ID but fresh state and new input. This helps avoid large history buildup.

Practice

1. What is the main purpose of Durable Functions in Azure?

easy

A. To create virtual machines

B. To store large amounts of data

C. To monitor network traffic

D. To manage long-running workflows reliably

Solution

1. Step 1: Understand Durable Functions role

   Durable Functions are designed to handle workflows that take a long time and need to be reliable.

2. Step 2: Compare options

   Options A, B, and D describe other Azure services, not Durable Functions.

3. Final Answer:

   To manage long-running workflows reliably -> Option D

4. Quick Check:

   Durable Functions = Manage workflows reliably [OK]

Hint: Durable Functions = reliable long workflows [OK]

Common Mistakes:

• Confusing Durable Functions with storage services
• Thinking Durable Functions create VMs
• Assuming Durable Functions monitor networks

2. Which of the following is the correct way to define an orchestrator function in Azure Durable Functions?

easy

A. function orchestrator(context) { /* workflow code */ }

B. function activity(context) { /* workflow code */ }

C. async function orchestrator(context) { /* workflow code */ }

D. async function activity(context) { /* workflow code */ }

Solution

1. Step 1: Identify orchestrator function syntax

   Orchestrator functions must be async to support awaiting activity calls.

2. Step 2: Differentiate activity and orchestrator functions

   Options C and D define activity functions, not orchestrators.

3. Final Answer:

   async function orchestrator(context) { /* workflow code */ } -> Option C

4. Quick Check:

   Orchestrator = async function [OK]

Hint: Orchestrators are async functions [OK]

Common Mistakes:

• Using non-async function for orchestrator
• Confusing activity function syntax with orchestrator
• Omitting async keyword

3. Given the following orchestrator code snippet, what will be the output if the activity function returns 'Hello'?

const result = yield context.callActivity('SayHello');
return result + ' World!';

medium

A. "Hello World!"

B. "World! Hello"

C. "Hello"

D. "World!"

Solution

1. Step 1: Understand callActivity result

   The activity function returns 'Hello', which is assigned to result.

2. Step 2: Concatenate strings

   The orchestrator returns result + ' World!', so 'Hello' + ' World!' = 'Hello World!'.

3. Final Answer:

   "Hello World!" -> Option A

4. Quick Check:

   Result + ' World!' = 'Hello World!' [OK]

Hint: callActivity returns value used in concatenation [OK]

Common Mistakes:

• Reversing string order
• Returning only activity result without addition
• Ignoring yield keyword effect

4. Identify the error in this orchestrator function code:

async function orchestrator(context) {
  const result = context.callActivity('Task');
  return result;
}

medium

A. Function should not be async

B. Missing await or yield before callActivity

C. Incorrect function name

D. callActivity should be called outside orchestrator

Solution

1. Step 1: Check callActivity usage

   callActivity returns a promise and must be awaited or yielded inside orchestrator.

2. Step 2: Identify missing await/yield

   The code calls callActivity without await or yield, causing incorrect behavior.

3. Final Answer:

   Missing await or yield before callActivity -> Option B

4. Quick Check:

   callActivity needs await/yield [OK]

Hint: Always await or yield callActivity in orchestrator [OK]

Common Mistakes:

• Forgetting await/yield on callActivity
• Thinking async keyword is wrong here
• Misplacing callActivity outside orchestrator

5. You want to create a workflow that calls two activity functions in sequence and combines their results. Which orchestrator code correctly implements this?

hard

A. const result1 = await context.callActivity('Activity1');
const result2 = await context.callActivity('Activity2');
return result1 + ' & ' + result2;

B. const result1 = context.callActivity('Activity1');
const result2 = context.callActivity('Activity2');
return result1 + ' & ' + result2;

C. const result1 = await context.callActivity('Activity1');
const result2 = context.callActivity('Activity2');
return result1 + ' & ' + result2;

D. const result1 = context.callActivity('Activity1');
const result2 = await context.callActivity('Activity2');
return result1 + ' & ' + result2;

Solution

1. Step 1: Understand sequential calls in orchestrator

   Each callActivity must be awaited to get the actual result before next call.

2. Step 2: Check options for proper await usage

   Only const result1 = await context.callActivity('Activity1'); const result2 = await context.callActivity('Activity2'); return result1 + ' & ' + result2; awaits both calls, ensuring correct sequence and result combination.

3. Final Answer:

   const result1 = await context.callActivity('Activity1');\nconst result2 = await context.callActivity('Activity2');\nreturn result1 + ' & ' + result2; -> Option A

4. Quick Check:

   Await both activities for correct sequence [OK]

Hint: Await each callActivity for sequential results [OK]

Common Mistakes:

• Not awaiting callActivity causing promises instead of results
• Mixing awaited and non-awaited calls
• Returning promises instead of strings