11.3 Azure App Configuration for App Settings

Exam AI-200: Developing AI Cloud Solutions on Azure Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Audience Profile & Study Path

2 Chapter 1: Container Registry & App Service Hosting

1.1 ACR: Build, Store, Version & Manage Images 1.2 ACR Tasks: Build & Run Images 1.3 Deploy Containers to Azure App Service

3 Chapter 2: Azure Container Apps & KEDA Scaling

2.1 Azure Container Apps: Environments, Config & Revisions 2.2 KEDA Event-Driven Scaling in Container Apps

4 Chapter 3: AKS Manifests & Container Troubleshooting

3.1 Deploy & Manage Apps on AKS with Manifests 3.2 Monitor & Troubleshoot AKS and Container Apps

5 Chapter 4: Cosmos DB for NoSQL Fundamentals

4.1 Cosmos DB for NoSQL: SDK Connect & Queries 4.2 Optimize RUs: Indexing Policies & Consistency Levels

6 Chapter 5: Cosmos DB Vectors & Change Feed

5.1 Embeddings & Vector Similarity Search in Cosmos DB 5.2 Change Feed Processor for New/Updated Items

7 Chapter 6: Azure PostgreSQL Foundations for AI

6.1 Azure Database for PostgreSQL: Connect & Query with SDKs 6.2 Schema Design, Data Types & Indexing Strategies 6.3 pgvector Indexing: Latency & Compute Overhead

8 Chapter 7: PostgreSQL Vector Workloads & RAG

7.1 Configure Compute, Memory & Storage for Vector Workloads 7.2 Vector Search, Semantic Retrieval & RAG with Metadata Filters 7.3 Connection Optimization for Throughput & Latency

9 Chapter 8: Azure Managed Redis for AI Solutions

8.1 Azure Managed Redis: Caching, Expiration & Invalidation 8.2 Redis Vector Indexing for Similarity Search

10 Chapter 9: Service Bus & Event Grid for AI Pipelines

9.1 Service Bus Queues & Message Processing 9.2 Topics, Subscriptions & Dead-Letter Queues 9.3 Event Grid: Custom Events & Filters 9.4 Event Grid Retries & Event-Driven Workflows

11 Chapter 10: Azure Functions for Serverless AI Back Ends

10.1 Azure Functions: Triggers & Bindings 10.2 Build Serverless APIs with Functions 10.3 Configure & Deploy Function Apps

12 Chapter 11: Key Vault & App Configuration

11.1 Azure Key Vault: Secret Storage & Retrieval 11.2 Key Vault Secret Rotation Patterns 11.3 Azure App Configuration for App Settings

13 Chapter 12: OpenTelemetry & KQL Observability

12.1 Distributed Tracing with OpenTelemetry SDKs 12.2 Correlating Traces into Azure Monitoring 12.3 Write KQL Queries to Analyze Logs 12.4 KQL for Metrics & Troubleshooting Scenarios

11.3 Azure App Configuration for App Settings

Key Takeaways Explain This Topic AI

Azure App Configuration stores non-secret application settings as key-values that apps read at startup and can refresh dynamically without redeploying.

Labels let you variant the same key across environments, tenants, or rings (Dev/Test/Prod, canary) without inventing parallel key naming schemes.

Feature flags in App Configuration enable progressive delivery and kill switches evaluated in-process through feature management libraries.

Dynamic refresh uses a watch key or sentinel plus polling/push notification patterns so instances reload configuration after operators change values.

Keep secrets in Key Vault; App Configuration may hold Key Vault references for secret values while remaining the control plane for ordinary settings and flags.

Last updated: July 2026

11.3 Azure App Configuration for App Settings

Quick Answer: Use Azure App Configuration to store and dynamically refresh non-secret app settings and feature flags. Organize variants with labels, refresh instances with a sentinel key pattern, and keep true secrets in Key Vault—optionally referenced from App Configuration.

Key Vault solves secret storage and retrieval. Most application configuration is not secret: model deployment names, feature toggles, retry counts, cache TTLs, regional endpoint URLs, and UI thresholds. Azure App Configuration is the Azure service purpose-built to store, version, label, and dynamically distribute those settings to App Service, Container Apps, AKS, VMs, and other hosts.

Why App Configuration Exists Alongside Key Vault

Concern Prefer Key Vault Prefer App Configuration
Database password, API key, certificate Yes No (except as Key Vault reference)
Feature flag / kill switch No Yes
Non-secret endpoint URL, temperature, top-p defaults Unusual Yes
Centralized dynamic refresh without redeploy Limited Primary strength
RBAC-separated secret get auditing Primary strength Complements via references

A common AI-200 architecture: App Configuration holds AzureOpenAI:DeploymentName , Rag:TopK , and feature flags like EnableStreaming , while Key Vault holds AzureOpenAI--ApiKey or a connection string. The app loads both: configuration provider for App Configuration, secret resolution for Key Vault.

Key-Values: The Core Data Model

App Configuration stores key-value pairs:

Key — hierarchical string, often using : or / separators ( App:Search:IndexName ).

Value — string content interpreted by the app (numbers, JSON, booleans as strings).

Content type — optional metadata (for example, application/json ).

Label — optional variant dimension (discussed next).

ETag / last modified — concurrency and refresh markers.

Applications typically map keys into the standard configuration hierarchy used by .NET IConfiguration , Java Spring, or equivalent, so existing GetValue<int>("Rag:TopK") code works after the App Configuration provider is added.

Access control uses Microsoft Entra ID. Grant application managed identities App Configuration Data Reader for read-only consumption and App Configuration Data Owner (or narrower custom roles) for writers/operators. Prefer managed identity over read keys when possible; access keys exist but increase secret sprawl.

Labels for Environments and Rings

Without labels, teams often create keys like Prod-TopK and Dev-TopK . Labels keep the key name stable and vary the value by dimension:

Key Label Value
Rag:TopK Dev 5
Rag:TopK Prod 8
Rag:TopK Prod (canary override via different store or additional label strategy)

Clients select labels when loading configuration—for example, load Prod plus a private override label for a canary slot. This supports:

Environment separation — Dev/Test/Prod values without separate stores for every team (though separate stores remain valid for hard isolation).

Deployment rings — gradually move label targeting from canary to broad production.

Tenant or region variants — when the same app binary serves multiple configuration profiles.

Exam tip: Labels are not a substitute for Key Vault RBAC. They organize settings; they do not encrypt secrets.

Feature Flags

App Configuration includes a feature flag model consumed by feature management libraries (.NET Feature Management, analogous patterns in other stacks). Flags support:

Boolean on/off toggles ( BetaChatUi ).

Percentage rollouts and targeting filters (users, groups, time windows)—exact filter availability depends on the library and flag definition.

Central kill switches for risky AI behaviors (disable tool calling, disable web browsing plugin, force fallback model).

Operators flip flags in the App Configuration portal or via API without rebuilding images. For AI solutions, feature flags are ideal for progressive delivery of prompt versions, new retrieval pipelines, or UI experiences while keeping a fast rollback path.

Feature flags still belong in App Configuration rather than Key Vault because they are operational settings, not credentials—even when a flag gates access to a premium capability.

Dynamic Refresh

Static load-at-startup configuration forces redeploy or restart for every change. Dynamic refresh lets running instances pick up new key-values and flag states.

Typical .NET pattern:

Use a sentinel key (for example, App:ConfigVersion ) that operators increment after a batch of related changes.

The client polls on an interval; when the sentinel changes, it reloads the watched configuration set.

Middleware or a refresh service calls TryRefreshAsync so requests see updated values.

Refresh approach Behavior Use when
Polling watched keys / sentinel Periodic check for changes Most App Service and container apps
Push notifications (where configured) Faster reaction to changes Low-latency flag cutovers
Restart-only Picks up values on process start Rarely acceptable for feature flags

Dynamic refresh must be designed carefully for secrets referenced through App Configuration: refreshing may re-resolve Key Vault references, which is desirable after rotation but increases vault get traffic—cache thoughtfully.

Key Vault References Inside App Configuration

App Configuration can store a value that is a Key Vault reference , so non-secret and secret material appear in one configuration surface while the secret bytes remain in Key Vault. The application identity then needs:

Permission to read App Configuration key-values.

Permission to get the referenced Key Vault secret (Secrets User).

This hybrid model is popular on AI-200 architectures: one configuration bootstrap, clear separation of secret storage, and still central management of which secrets each environment uses.

Operational Practices for AI Apps

Separate stores or strict labels for production versus non-production to reduce blast radius of mistaken edits.

Soft delete / geo-replication options on the App Configuration store for resilience (match workload criticality).

Audit who changed flags —a flipped EnableCustomerDataLogging flag can be a compliance event.

Do not put passwords in plain App Configuration values ; use Key Vault references or read secrets directly from Key Vault.

Combine with rotation : after Key Vault rotation, either rely on reference re-resolution during refresh or update the referenced version and bump the App Configuration sentinel so all instances reload.

End-to-End Secure Configuration Picture

For the AI-200 domain Implement secure Azure solutions , remember the split of responsibilities:

Key Vault — secrets, keys, certificates; managed identity + RBAC; GetSecret / platform references; versioned rotation with dual validity.

App Configuration — key-values, labels, feature flags, dynamic refresh; optional Key Vault references for secret-backed settings.

Together they keep AI applications configurable without redeploying for every operational change and without scattering credentials across app settings files, container images, and source repositories.