Function App Settings and Configuration

Azure Functions is a serverless compute service that lets you run event-driven code without managing infrastructure. A Function App is the container that hosts one or more individual functions. The settings of a Function App control its runtime behavior, connectivity to other Azure services, security, performance, and deployment mechanics. They are the knobs and levers that turn a generic hosting container into a tailored execution environment.

On the AZ-204 exam, you must know which settings are available, their default values, how to configure them, and the impact of changing them. The exam tests not just recall but the ability to troubleshoot and choose the correct configuration for a given scenario.

When you create a Function App in Azure, the platform provisions a dedicated App Service plan (consumption, premium, or dedicated) or runs on a Linux/Windows container. The settings you configure are stored in two places:

At startup, the Functions host (the process that manages function execution) reads the configuration from the local appsettings.json file and then overlays it with values from Azure. The final effective configuration is a merge: Azure settings override local ones. This allows you to have different configurations for development, staging, and production without changing code.

#### FUNCTIONS_WORKER_RUNTIME - Purpose: Specifies the language runtime for the function app. - Valid values: dotnet (for .NET, C#), dotnet-isolated (for .NET 8+ isolated process), node (JavaScript), python, java, powershell. - Default: None — must be explicitly set when creating the app. - Exam trap: If you omit this setting, the Functions host will fail to start. The exam may present a scenario where a function app is created via CLI without --functions-worker-runtime and then the app doesn't work.

#### AzureWebJobsStorage - Purpose: Connection string to an Azure Storage account used by the Functions runtime for internal operations: managing triggers (blob, queue, timer), storing execution state, and coordinating scaling. - Default: None — must be provided. For consumption plan, this is mandatory. - Exam trap: The exam loves to ask what happens if this setting is missing. Answer: The function app will fail to start or will not process triggers correctly. For timer triggers, it will not fire.

#### WEBSITE_RUN_FROM_PACKAGE - Purpose: Tells the runtime to run the function app from a deployment package (a .zip file) stored in Azure Blob Storage or a URL. This is the recommended deployment method for production. - Valid values: 1 (enable from the package URL specified in WEBSITE_RUN_FROM_PACKAGE_URL), 0 (disable), or a URL directly. - Default: 0. - Mechanism: When enabled, the runtime downloads the package to local storage (under D:\home\data\SitePackages) and mounts it as the read-only app root. This eliminates file locking issues and improves cold-start performance. - Exam trap: If you set WEBSITE_RUN_FROM_PACKAGE=1 but don't provide a URL, the app will fail. Also, if you update the package but the app still uses the old version, you may need to restart the app.

#### FUNCTIONS_EXTENSION_VERSION - Purpose: Controls the version of the Azure Functions runtime host. - Valid values: ~4 (latest 4.x), ~3 (deprecated), ~2 (deprecated). - Default: ~4 when creating via portal. - Exam trap: The exam may ask which version to use for new apps. Always ~4. Also, if you need a specific minor version, you can pin to a full version like 4.0.13120.

#### WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE - Purpose: Used in consumption and premium plans to store function app content on Azure Files. The connection string points to a storage account, and the share name is the file share where the app content is stored. - Default: Automatically generated when creating via portal. - Exam trap: If you delete the storage account or the file share, the function app will become unresponsive. The exam may present a scenario where the app stops working after storage cleanup.

#### FUNCTIONS_WORKER_PROCESS_COUNT - Purpose: For .NET isolated process, specifies the number of worker processes to use. Default is 1. This is used for process-level parallelism. - Exam relevance: Less common but may appear in advanced scenarios.

#### APPINSIGHTS_INSTRUMENTATIONKEY - Purpose: Enables integration with Application Insights for monitoring. - Default: None. - Exam trap: Without this, you lose telemetry. The exam may ask how to enable logging — answer: add this setting with the instrumentation key.

You can configure settings using Azure CLI, PowerShell, ARM templates, or the portal. Key CLI commands:

# Create a function app with settings
az functionapp create --name MyFunctionApp --storage-account MyStorage --resource-group MyRG --consumption-plan-location westus --runtime dotnet --functions-version 4

# List all settings
az functionapp config appsettings list --name MyFunctionApp --resource-group MyRG

# Set a setting
az functionapp config appsettings set --name MyFunctionApp --resource-group MyRG --settings "FUNCTIONS_EXTENSION_VERSION=~4" "AzureWebJobsStorage=DefaultEndpointsProtocol=https;AccountName=..."

# Delete a setting
az functionapp config appsettings delete --name MyFunctionApp --resource-group MyRG --setting-names "MySetting"

For ARM templates, settings are defined under properties.siteConfig.appSettings:

{
  "type": "Microsoft.Web/sites/config",
  "apiVersion": "2022-03-01",
  "name": "appsettings",
  "properties": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "AzureWebJobsStorage": "[concat('DefaultEndpointsProtocol=https;AccountName=', parameters('storageAccountName'), ';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName')), '2021-02-01').keys[0].value)]"
  }
}

When using deployment slots, you can mark certain app settings as "sticky" (slot-specific). These settings stay with the slot during swaps. For example, you might have a staging slot with a different AzureWebJobsStorage pointing to a test storage account. To make a setting sticky, use the --slot-settings flag in CLI or the slotConfigNames property in ARM.

az functionapp config appsettings set --name MyFunctionApp --resource-group MyRG --slot-settings "MyStickySetting=value"

You can view the effective environment variables by navigating to https://<functionappname>.scm.azurewebsites.net/Env.cshtml. This is useful for debugging configuration issues.

| Setting | Default | Mandatory? | |---|---|---| | FUNCTIONS_WORKER_RUNTIME | None | Yes | | AzureWebJobsStorage | None | Yes (consumption) | | FUNCTIONS_EXTENSION_VERSION | ~4 | Yes | | WEBSITE_RUN_FROM_PACKAGE | 0 | No | | APPINSIGHTS_INSTRUMENTATIONKEY | None | No (recommended) |

The exam often presents a scenario where a function app was created but is not working. You check the logs and see an error like "No job functions found. Try making your job classes public." This is often due to missing FUNCTIONS_WORKER_RUNTIME. Another common error: "The 'AzureWebJobsStorage' connection string is not set." Always check these two first.

public static void Run([TimerTrigger("0 */5 * * * *")] TimerInfo myTimer, ILogger log)
{
    string storageConnection = Environment.GetEnvironmentVariable("AzureWebJobsStorage");
    log.LogInformation($"Storage connection: {storageConnection}");
}

For .NET isolated, use IConfiguration:

public class Function1
{
    private readonly IConfiguration _configuration;
    public Function1(IConfiguration configuration)
    {
        _configuration = configuration;
    }
    [Function("Function1")]
    public void Run([TimerTrigger("0 */5 * * * *")] TimerInfo myTimer, FunctionContext context)
    {
        string value = _configuration["MySetting"];
    }
}

This covers the core explanation of Function App settings and configuration. The next sections will solidify your understanding with step-by-step procedures, real-world scenarios, and exam-focused insights.

A large e-commerce company uses Azure Functions to process orders as they arrive from a web frontend. The function app runs on a consumption plan and uses blob triggers to process new order files. The team configured AzureWebJobsStorage to point to a general-purpose v2 storage account in the same region as the function app to minimize latency. They also set WEBSITE_RUN_FROM_PACKAGE=1 to ensure consistent deployments across thousands of instances during peak shopping seasons. The APPINSIGHTS_INSTRUMENTATIONKEY was set to monitor execution times and error rates. One day, orders stopped processing. The team discovered that the storage account key had been rotated, but the AzureWebJobsStorage setting still held the old key. They updated it via the portal and restarted the app. The lesson: always use Key Vault references for connection strings to avoid manual updates. In production, they also enabled slot-specific settings for staging vs production, using sticky settings for AzureWebJobsStorage to prevent the staging slot from accidentally processing production orders during a swap.

A financial services firm uses Durable Functions to orchestrate complex workflows for loan approvals. Each function app hosts multiple orchestrator and activity functions. They needed to scale out to handle thousands of concurrent orchestrations. They configured FUNCTIONS_WORKER_PROCESS_COUNT=4 for the .NET isolated process to utilize multiple cores. They also set FUNCTIONS_EXTENSION_VERSION=~4 to use the latest runtime. The AzureWebJobsStorage was a premium storage account to handle high throughput. They used WEBSITE_RUN_FROM_PACKAGE with a SAS URL that included a short expiry to ensure security. During a performance test, they noticed that cold starts were causing delays. They mitigated by enabling a premium plan with pre-warmed instances. The team learned that while settings can be changed on the fly, some changes (like switching from consumption to premium) require recreating the function app. They also used deployment slots to test configuration changes before production.