Azure App Configuration: Centralised Settings

What App Configuration is — and how it differs from Key Vault

Simple explanation

Azure App Configuration is the home for non-secret config. Things like the model name, the log level, the feature flags, the default temperature for the LLM. Stuff you change a lot, want to share between services, and don’t need to encrypt with HSMs.

Key Vault stores secrets; App Configuration stores everything else. Together they cover the full surface — the typical pattern is App Configuration with Key Vault references for the values that ARE secret.

Two killer features for AI-200:

Labels — the same key can have different values per environment (dev, staging, prod) using labels.
Feature flags — turn features on/off in production without a redeploy. Roll out to a percentage of users; turn off if something breaks.

Keys, values, labels

Key                              Label      Value
app:settings:LogLevel            (none)     Information
app:settings:LogLevel            staging    Debug
app:settings:LogLevel            prod       Warning
app:settings:ModelName           (none)     gpt-4o-mini
app:settings:ModelName           prod       gpt-4o
features:NewRagPipeline          (none)     {"enabled":false}
features:NewRagPipeline          prod       {"enabled":true}

A SDK reads with both key and label. The same code with different labels gets different config:

from azure.appconfiguration import AzureAppConfigurationClient
from azure.identity import DefaultAzureCredential

client = AzureAppConfigurationClient(
    base_url="https://roo-config.azconfig.io",
    credential=DefaultAzureCredential(),
)

setting = client.get_configuration_setting(
    key="app:settings:LogLevel",
    label="prod",
)
print(setting.value)   # "Warning"

Key Vault references — the integration

App Configuration values can reference Key Vault secrets. The value type is application/vnd.microsoft.appconfig.keyvaultref+json;charset=utf-8:

{
  "uri": "https://roo-kv.vault.azure.net/secrets/OpenAIKey"
}

When the SDK reads this key it follows the URI to Key Vault (using the consumer’s identity, not App Configuration’s). So you get a single read surface for all config — secret and non-secret — without duplicating Key Vault references in every app’s settings.

# When the SDK loads config, Key Vault references resolve to actual secrets
config = client.list_configuration_settings(label_filter="prod")
for s in config:
    print(s.key, "->", s.value)   # secrets resolved to live values

Feature flags

Feature flags let you turn behaviour on or off without redeploying.

{
  "id": "NewRagPipeline",
  "description": "Use the new pgvector RAG pipeline",
  "enabled": false,
  "conditions": {
    "client_filters": [
      {
        "name": "Microsoft.Targeting",
        "parameters": {
          "Audience": {
            "Users": ["alpha@contoso.com"],
            "Groups": [{"Name": "InternalTesters", "RolloutPercentage": 100}],
            "DefaultRolloutPercentage": 5
          }
        }
      }
    ]
  }
}

Three targeting filters built in:

Filter	What it does
Targeting	Specific users, groups, or rollout percentages
TimeWindow	Enable between two dates / times
Percentage	Random % of traffic — A/B test gate

from featuremanagement import FeatureManager

manager = FeatureManager(...)
if await manager.is_enabled("NewRagPipeline", user_context):
    use_new_pipeline()
else:
    use_old_pipeline()

Real-world example: Mira's gradual rollout

Mira launches a new vision model. Strategy:

Feature flag EnableNewVisionModel set to 5% rollout in production
Watch error rate, latency, accuracy in App Insights for 24 hours
Bump to 25%, monitor 24 hours
50%, 100%
If anything goes wrong at any stage, set the flag to 0% — instant kill switch, no redeploy

The feature flag value lives in App Configuration; the worker code is unchanged across the rollout.

Snapshots — point-in-time config

App Configuration supports snapshots — frozen, named copies of a label’s config at a moment in time. Useful for:

Pinning a deployment to a specific config version
Auditing what production was configured to on a particular date
Promoting config from dev to prod atomically (snapshot the dev label, copy as a prod label)

Authentication and authorisation

Mode	Use
Connection string	Quick start; legacy
Microsoft Entra RBAC	Recommended — `App Configuration Data Reader` for read-only consumers

az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "App Configuration Data Reader" \
  --scope $(az appconfig show -n roo-config --query id -o tsv)

Built-in roles you’ll see:

Role	Permissions
App Configuration Data Reader	Read keys, values, labels, feature flags
App Configuration Data Owner	Read + write
App Configuration Reader (control plane)	Manage the resource itself

Refresh strategies

App Configuration provides three refresh patterns in SDKs:

Pattern	How	Use for
Automatic refresh	SDK polls a sentinel key; on change, refreshes config	Most apps — sentinel key changes whenever any config does
Push refresh via Event Grid	Event Grid fires `Microsoft.AppConfiguration.KeyValueModified`; your app subscribes and refreshes	Lower-latency invalidation for critical settings
Manual refresh	App calls `refresh()` on the configuration provider on demand	Custom rollouts

Polling intervals are configurable; default is 30 seconds for most SDKs. Don’t poll too aggressively — it costs requests and barely helps.

When NOT to use App Configuration

Some configuration genuinely belongs at app-level:

Type	Where it belongs
Connection strings to databases	App Configuration with Key Vault references for the password
API keys	Key Vault, referenced from App Configuration
Feature flags	App Configuration
Per-environment URLs (e.g., OpenAI deployment name)	App Configuration
Local-only paths or build-time constants	App Settings or env vars