Function scaling behavior in Azure - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the trigger type for an Azure Function.

Azure

public static void Run([[1]Trigger] string myQueueItem, ILogger log) {
    log.LogInformation($"Processing: {myQueueItem}");
}

Drag options to blanks, or click blank then click option'

AHttp

BBlob

CTimer

DQueue

Attempts:

3 left

💡 Hint

Common Mistakes

Using HttpTrigger when the function is triggered by a queue message.

Using BlobTrigger which is for blob storage events.

The Azure Function is triggered by a message in a queue, so the correct trigger attribute is QueueTrigger.

2fill in blank

medium

Complete the code to set the maximum number of function instances in host.json.

Azure

{
  "version": "2.0",
  "functionTimeout": "00:05:00",
  "concurrency": {
    "dynamicConcurrencyEnabled": true,
    "[1]": 5
  }
}

Drag options to blanks, or click blank then click option'

AmaxFunctionInstances

BmaxDegreeOfParallelism

CmaxInstances

DmaxConcurrentRequests

Attempts:

3 left

💡 Hint

Common Mistakes

Using maxDegreeOfParallelism which controls threads, not instances.

Using maxConcurrentRequests which is unrelated to scaling instances.

The maxInstances setting controls the maximum number of function instances that can run concurrently.

3fill in blank

hard

Fix the error in the Azure Function scale controller setting.

Azure

{
  "version": "2.0",
  "extensions": {
    "queues": {
      "batchSize": 16,
      "maxDequeueCount": [1]
    }
  }
}

Drag options to blanks, or click blank then click option'

A5

B"5"

C-1

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Using a string value instead of an integer.

Setting maxDequeueCount to zero or negative numbers.

The maxDequeueCount must be a positive integer. Using 5 is correct. Strings or negative numbers cause errors.

4fill in blank

hard

Fill both blanks to configure the function app to scale based on CPU and memory thresholds.

Azure

{
  "scaling": {
    "rules": [
      {
        "metricTrigger": {
          "metricName": "[1]",
          "threshold": 70
        },
        "scaleAction": {
          "direction": "Increase",
          "type": "ChangeCount",
          "value": "1"
        }
      },
      {
        "metricTrigger": {
          "metricName": "[2]",
          "threshold": 80
        },
        "scaleAction": {
          "direction": "Increase",
          "type": "ChangeCount",
          "value": "1"
        }
      }
    ]
  }
}

Drag options to blanks, or click blank then click option'

ACpuPercentage

BMemoryPercentage

CDiskQueueLength

DHttpQueueLength

Attempts:

3 left

💡 Hint

Common Mistakes

Using disk or HTTP queue metrics which are unrelated to CPU/memory scaling.

Mixing up the metric names.

The function app scales when CPU usage exceeds 70% and memory usage exceeds 80%, so the metric names are CpuPercentage and MemoryPercentage.

5fill in blank

hard

Fill all three blanks to define a scale rule that decreases instances when the queue length is low.

Azure

{
  "rules": [
    {
      "metricTrigger": {
        "metricName": "[1]",
        "threshold": [2],
        "timeAggregation": "Average"
      },
      "scaleAction": {
        "direction": "[3]",
        "type": "ChangeCount",
        "value": "1",
        "cooldown": "PT5M"
      }
    }
  ]
}

Drag options to blanks, or click blank then click option'

AQueueLength

B10

CDecrease

DIncrease

Attempts:

3 left

💡 Hint

Common Mistakes

Using Increase instead of Decrease for scaling down.

Using a threshold that is too high or unrelated metric names.

The scale rule triggers when the QueueLength metric average is below 10, causing the function app to Decrease instances.

Practice

1. What happens when an Azure Function experiences increased incoming requests?

easy

A. The function crashes due to overload without scaling.

B. The function stops processing new requests until manually scaled.

C. Azure Functions reduce the number of instances to save cost.

D. Azure Functions automatically scale out to handle more requests.

Solution

1. Step 1: Understand Azure Functions scaling

   Azure Functions are designed to automatically add more instances when workload increases.

2. Step 2: Analyze behavior on increased requests

   When more requests come in, Azure Functions scale out to maintain responsiveness.

3. Final Answer:

   Azure Functions automatically scale out to handle more requests. -> Option D

4. Quick Check:

   Automatic scaling = Azure Functions automatically scale out to handle more requests. [OK]

Hint: Azure Functions scale out automatically with more requests [OK]

Common Mistakes:

• Thinking scaling is manual only
• Assuming functions crash on load
• Believing scaling reduces instances on load

2. Which JSON file is used to configure scaling behavior for Azure Functions?

easy

A. function.json

B. appsettings.json

C. host.json

D. scaling.json

Solution

1. Step 1: Identify configuration files in Azure Functions

   Azure Functions use host.json to configure runtime behaviors including scaling.

2. Step 2: Match file to scaling configuration

   host.json contains settings for scaling and triggers, unlike function.json or appsettings.json.

3. Final Answer:

   host.json -> Option C

4. Quick Check:

   Scaling config file = host.json [OK]

Hint: Scaling settings are in host.json file [OK]

Common Mistakes:

• Confusing function.json with scaling config
• Thinking appsettings.json controls scaling
• Assuming scaling.json is a real file

3. Given this host.json snippet:

{
  "version": "2.0",
  "extensions": {
    "http": {
      "maxConcurrentRequests": 5
    }
  }
}

What is the effect on function scaling?

medium

A. Limits the function to 5 concurrent HTTP requests per instance.

B. Scales out to 5 instances regardless of load.

C. Allows unlimited concurrent requests per instance.

D. Disables HTTP triggers for the function.

Solution

1. Step 1: Interpret maxConcurrentRequests setting

   This setting limits how many HTTP requests a single function instance can handle at once.

2. Step 2: Understand scaling impact

   With max 5 concurrent requests per instance, Azure Functions may scale out to handle more requests beyond 5.

3. Final Answer:

   Limits the function to 5 concurrent HTTP requests per instance. -> Option A

4. Quick Check:

   maxConcurrentRequests = 5 per instance [OK]

Hint: maxConcurrentRequests limits requests per instance, not total instances [OK]

Common Mistakes:

• Thinking it fixes total instances to 5
• Assuming unlimited concurrency
• Believing it disables HTTP triggers

4. You notice your Azure Function is not scaling out despite high load. Which fix is most likely correct?

medium

A. Increase the maxConcurrentRequests in host.json to a higher number.

B. Check if the function app is set to a Consumption plan that supports scaling.

C. Reduce the function timeout to force faster scaling.

D. Disable all triggers to allow scaling.

Solution

1. Step 1: Identify scaling plan type

   Azure Functions scale automatically only on Consumption or Premium plans, not on fixed App Service plans.

2. Step 2: Verify plan supports scaling

   If the function app is on a plan without scaling, it won't scale out despite load.

3. Final Answer:

   Check if the function app is set to a Consumption plan that supports scaling. -> Option B

4. Quick Check:

   Scaling requires Consumption or Premium plan [OK]

Hint: Scaling needs correct plan type, check Consumption plan [OK]

Common Mistakes:

• Thinking maxConcurrentRequests controls scaling
• Believing timeout affects scaling directly
• Disabling triggers to fix scaling

5. You want to optimize cost and responsiveness for an Azure Function with unpredictable traffic spikes. Which approach best balances scaling?

hard

A. Use a Premium plan with pre-warmed instances and configure host.json for scaling limits.

B. Use a Consumption plan with no scaling limits and rely on default behavior.

C. Use a Dedicated App Service plan with manual scaling only.

D. Disable scaling and handle all requests on a single instance.

Solution

1. Step 1: Understand traffic pattern and cost needs

   Unpredictable spikes need fast scaling and cost control to avoid delays and high bills.

2. Step 2: Evaluate plan options

   Premium plan offers pre-warmed instances for instant response and configurable scaling limits to control cost.

3. Step 3: Compare other options

   Consumption plan scales but may have cold start delays; Dedicated plan lacks automatic scaling; disabling scaling hurts responsiveness.

4. Final Answer:

   Use a Premium plan with pre-warmed instances and configure host.json for scaling limits. -> Option A

5. Quick Check:

   Premium plan + scaling config = best balance [OK]

Hint: Premium plan with pre-warmed instances balances cost and speed [OK]

Common Mistakes:

• Choosing Consumption plan ignoring cold starts
• Using Dedicated plan without auto scaling
• Disabling scaling to save cost