This chapter covers Azure App Configuration Service, a managed service for centralizing application configuration and feature management. For the AZ-204 exam, this topic appears in approximately 5-8% of questions, primarily in the 'Implement Azure Security' domain (objective 3.2). You will be tested on how to create and configure App Configuration stores, manage key-values and feature flags, use labels and snapshots, and integrate with Azure Key Vault for secrets. Mastering these concepts is critical for building cloud-native applications that are dynamic, resilient, and secure.
Jump to a section
Imagine a large hotel with hundreds of rooms, each with different amenities and services. The hotel has a central concierge desk that maintains a master list of all room-specific settings: minibar prices, wake-up call times, preferred language, etc. When a guest checks in, the front desk gives them a keycard that references their room number. Instead of storing all settings on the keycard (which would be bulky and hard to update), the keycard simply contains the room number. Whenever the guest wants to know a setting, they call the concierge, who looks up the room number in the master list and provides the current value. If the hotel decides to change minibar prices, they update the master list once, and all guests instantly see the new prices. The concierge also supports a feature called 'feature flags': for example, a 'pillow menu' service might be enabled only for VIP floors. The concierge checks the feature flag for each room before offering the service. This central, dynamic, and versioned configuration store mirrors Azure App Configuration: applications reference a connection string (the keycard), retrieve settings on demand (call concierge), and automatically get updates without redeployment. The concierge's log of changes is like the configuration store's history, and the ability to label settings (e.g., 'production' vs 'test') is like the hotel having different wings with different policies.
What is Azure App Configuration?
Azure App Configuration is a fully managed service that provides a centralized repository for application configuration settings and feature flags. It is designed to complement Azure Key Vault by storing non-secret configuration data (like connection strings to non-sensitive resources, feature flags, and application settings) while Key Vault handles secrets. The service is region-specific and can be accessed via REST API, SDKs (.NET, Java, Python, JavaScript, and more), or ARM templates.
Why It Exists
Traditional configuration management often relies on configuration files (appsettings.json, web.config) that are bundled with the application. This approach has several drawbacks:
Configuration changes require redeployment.
Different environments (dev, test, production) need separate files or build configurations.
Feature toggles (feature flags) are hard to implement without code changes.
No audit trail of who changed what and when.
Azure App Configuration solves these by decoupling configuration from code, allowing dynamic updates, environment-specific labels, and built-in feature management.
Key Components
#### Configuration Store A dedicated Azure resource that holds your configuration data. It has a unique endpoint URL (e.g., https://myappconfig.azconfig.io) and access keys (read-only or read-write). You can create a store via Azure Portal, CLI, or ARM.
#### Key-Values Each configuration entry consists of a key (hierarchical, e.g., AppSettings:Database:ConnectionString) and a value (string). Keys can be organized using a colon (:) or forward slash (/) as delimiter for logical grouping. By default, keys are case-sensitive, but you can enable case-insensitive comparison via the store's settings.
#### Labels Labels allow you to have multiple versions of the same key for different environments or contexts. For example, you can have the same key 'AppSettings:Database:ConnectionString' with label 'Development' and another with label 'Production'. The application specifies which label to use at runtime.
#### Feature Flags
A feature flag is a key-value pair with a special structure. The key follows the pattern .appconfig.featureflag/{flagName} and the value is a JSON object containing id, description, enabled, and conditions. Conditions can include client filters (e.g., percentage rollout, user groups). The service provides a UI for managing feature flags without writing code.
#### Snapshots Snapshots capture a point-in-time view of the configuration store's key-values. They are immutable and can be used for compliance, rollback, or to compare changes over time. You can create a snapshot manually or on a schedule.
How It Works Internally
When an application uses Azure App Configuration, it typically does the following:
1. Establish Connection: The application uses a connection string (or managed identity) to authenticate to the App Configuration store. The connection string contains the endpoint, the access key, and an optional label filter.
2. Load Configuration: At startup, the application can pull all key-values (optionally filtered by label) and cache them locally. The SDKs (e.g., Microsoft.Extensions.Configuration.AzureAppConfiguration for .NET) integrate with the standard configuration pipeline.
3. Dynamic Refresh: The SDK can be configured to poll for changes at a configurable interval (default 30 seconds). If a change is detected, the configuration is refreshed without restarting the application. This uses ETags for efficient change detection.
4. Feature Flag Evaluation: Feature flags are evaluated client-side. The SDK caches the flag state and can be configured to refresh dynamically. The flags can be used to conditionally enable code paths.
Configuration and Verification Commands
#### Create an App Configuration Store using Azure CLI:
az appconfig create --name MyAppConfigStore --resource-group MyResourceGroup --location eastus --sku standard#### Import key-values from a JSON file:
az appconfig kv import --name MyAppConfigStore --source file --path config.json --format json --label Development#### List all key-values:
az appconfig kv list --name MyAppConfigStore#### Set a feature flag:
az appconfig feature set --name MyAppConfigStore --feature MyFeature --label Production --enable#### Export configuration to a file:
az appconfig kv export --name MyAppConfigStore --destination file --path export.json --format jsonIntegration with Azure Key Vault
Azure App Configuration can reference secrets stored in Azure Key Vault. Instead of storing the secret value directly, you store a Key Vault reference URI. The App Configuration SDK automatically resolves the reference and fetches the secret from Key Vault at runtime. This ensures that secrets are not exposed in configuration files or logs.
To create a Key Vault reference:
az appconfig kv set-keyvault --name MyAppConfigStore --key AppSettings:Database:Password --secret-identifier https://mykeyvault.vault.azure.net/secrets/DbPasswordSecurity and Access Control
Access to the App Configuration store is controlled via: - Access Keys: Two read-write and two read-only keys per store. These are long-lived and should be rotated regularly. - Managed Identity: Preferred for Azure-hosted applications (App Service, Functions, VMs). The identity is assigned to the resource and granted access via RBAC. - RBAC Roles: Built-in roles like 'App Configuration Data Owner' (full access) and 'App Configuration Data Reader' (read-only).
Pricing Tiers
Free Tier: 1 store per subscription, 1,000 key-values, 1,000 requests per day, 500 MB storage.
Standard Tier: Unlimited stores, unlimited key-values (billed per 10,000), unlimited requests (billed per 10,000), 1 GB storage included.
Monitoring and Alerts
You can monitor request count, latency, and throttling via Azure Monitor. Alerts can be set for when request rates approach the limit. The service throttles at 1,000 requests per second per store (standard tier) under normal conditions.
Create App Configuration Store
Use Azure Portal, CLI, or ARM to create a new App Configuration store. Choose a globally unique name (e.g., 'myappconfig123'), select a region close to your application, and pick a pricing tier (Free or Standard). For production, Standard is recommended. The store endpoint will be https://<name>.azconfig.io. After creation, note the access keys under Settings > Access Keys. You will need one of the read-write keys to configure your application.
Configure Application Connection
In your application code, add the App Configuration SDK. For .NET, install the NuGet package 'Microsoft.Extensions.Configuration.AzureAppConfiguration'. Then, in your startup code (e.g., Program.cs), call `builder.Configuration.AddAzureAppConfiguration(options => options.Connect(connectionString))`. The connection string is available from the Azure portal. Optionally, you can use managed identity by calling `options.Connect(new Uri(endpoint), new DefaultAzureCredential())`. This eliminates the need to store connection strings in code.
Define Key-Values and Feature Flags
In the App Configuration store, create key-values for your application settings. For example, create a key 'AppSettings:MaxItems' with value '100'. Use labels to differentiate environments (e.g., label 'Development' vs 'Production'). For feature flags, use the 'Feature Manager' blade in the portal. Define a flag like 'NewCheckout' with a description, enable it, and optionally add conditions like percentage rollout or user groups. The SDK will evaluate these flags at runtime.
Enable Dynamic Refresh
To automatically pick up configuration changes without restarting the app, configure dynamic refresh. In .NET, after `AddAzureAppConfiguration`, call `.ConfigureRefresh(refreshOptions => refreshOptions.Register(key: "AppSettings:MaxItems", refreshAll: true).SetCacheExpiration(TimeSpan.FromMinutes(5)))`. This tells the SDK to poll for changes every 5 minutes. You must also call `app.UseAzureAppConfiguration()` in the middleware pipeline to trigger refresh on requests. For feature flags, use `UseFeatureFlags()`.
Secure Secrets with Key Vault References
For sensitive values like database passwords, use Key Vault references. In the App Configuration store, create a key 'AppSettings:DbPassword' with a special value that is a Key Vault reference URI, e.g., `@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/DbPassword/)`. The SDK will automatically resolve this reference at runtime. Ensure the application's identity (managed identity or service principal) has 'Get' permission on the Key Vault secrets.
Scenario 1: Multi-Environment Microservices Deployment
A large e-commerce company runs hundreds of microservices across multiple environments (dev, test, staging, production). Before App Configuration, they maintained separate configuration files for each environment, leading to inconsistencies and configuration drift. They deployed App Configuration stores per environment, each with labels for different service tiers. Each microservice uses a single connection string to its environment's store and retrieves settings filtered by a label that identifies the service. Changes to database connection strings or API endpoints are pushed to the store and automatically propagated to all instances within seconds. The company also uses feature flags to gradually roll out new features to a subset of users. With App Configuration, they reduced deployment failures by 80% and eliminated configuration drift.
Scenario 2: Compliance and Audit Requirements
A financial services firm needs to track every configuration change for compliance. They use App Configuration's snapshots to capture configuration state before each deployment. If a production issue occurs, they can compare the current configuration with a snapshot to identify changes. The built-in audit logs (Azure Monitor) record who changed what and when. They also use RBAC to restrict write access to a small team of DevOps engineers. The firm stores all secrets in Key Vault and references them from App Configuration, ensuring that secrets are never exposed in logs or configuration files. This setup passed their SOC 2 audit with no findings.
Common Pitfalls
Throttling: In high-traffic scenarios, if every request triggers a configuration refresh, the store can be throttled. Always use caching (default 30 seconds for feature flags, configurable for key-values).
Label Misconfiguration: If an application uses the wrong label, it may get stale or incorrect settings. Always validate label usage in non-production environments.
Key Vault Reference Errors: If the managed identity does not have permissions to Key Vault, the application will fail to resolve references. Test with a dummy secret first.
Snapshot Overuse: Creating too many snapshots can increase storage costs. Use snapshots only for critical checkpoints (e.g., before major releases).
What AZ-204 Tests
This topic falls under objective 3.2: 'Implement Azure App Configuration'. The exam expects you to:
Create and manage App Configuration stores (including access keys, RBAC, and managed identity).
Import and export configuration data (using CLI, portal, or ARM).
Implement feature flags with conditions (percentage rollout, user groups).
Use Key Vault references for secrets.
Configure dynamic refresh and understand caching behavior.
Understand the difference between App Configuration and Key Vault.
Common Wrong Answers
'Use Key Vault for all configuration': Candidates often think Key Vault is the only option for secure configuration. However, App Configuration is designed for non-secret config, and Key Vault is for secrets. The exam tests when to use each.
'Feature flags require a separate service': Some candidates believe feature flags need a custom implementation or a third-party service. In reality, Azure App Configuration has built-in feature management.
'Dynamic refresh happens instantly': The default refresh interval is 30 seconds for feature flags and configurable for key-values. It is not real-time. Candidates might think changes are immediate.
'Connection strings must be stored in code': Managed identity can replace connection strings. The exam tests this best practice.
Specific Exam Numbers
Default cache expiration for key-values: 30 seconds (configurable).
Default cache expiration for feature flags: 30 seconds.
Maximum number of access keys per store: 4 (2 read-write, 2 read-only).
Free tier limits: 1 store, 1,000 key-values, 1,000 requests/day.
Standard tier request limit: 1,000 requests/second per store (soft limit).
Edge Cases
Case sensitivity: By default, keys are case-sensitive. You can enable case-insensitive comparison, but this is a store-level setting that cannot be changed after creation.
Snapshot immutability: Once created, snapshots cannot be deleted or modified. They are retained for the lifetime of the store.
Label inheritance: If an application requests a key without a label, it gets the key with no label (empty label). If a key with a specific label exists, it takes precedence over the unlabeled version.
How to Eliminate Wrong Answers
If the question mentions 'secrets' (passwords, keys), the answer likely involves Key Vault, not App Configuration.
If the question asks for 'dynamic updates without redeployment', look for App Configuration with refresh.
If the question involves 'feature toggles', look for 'feature flags' in App Configuration.
If the question mentions 'environment-specific settings', think of labels.
Azure App Configuration centralizes non-secret configuration and feature flags, separate from Key Vault.
Use labels to differentiate environments (dev, test, prod) without creating separate stores.
Feature flags are stored under the key prefix `.appconfig.featureflag/` and support conditions like percentage rollout.
Dynamic refresh uses polling with a default cache expiration of 30 seconds; configure via `SetCacheExpiration`.
Managed identity is the preferred authentication method over access keys for Azure-hosted apps.
Key Vault references allow App Configuration to securely reference secrets without exposing them.
Snapshots provide immutable point-in-time copies of configuration for compliance and rollback.
Free tier is limited to 1 store, 1,000 key-values, and 1,000 requests per day.
These come up on the exam all the time. Here's how to tell them apart.
Azure App Configuration
Designed for non-secret configuration data like feature flags and app settings.
Supports hierarchical keys with labels for environment separation.
Built-in feature management with percentage rollout and user groups.
Dynamic refresh without application restart (polling).
Supports Key Vault references to fetch secrets at runtime.
Azure Key Vault
Designed for secrets like passwords, API keys, and certificates.
Stores secrets as flat key-value pairs with no hierarchical structure.
No feature management capabilities.
Secrets are cached and refreshed on demand, but no automatic polling for changes.
Secrets can be referenced by App Configuration, but not vice versa.
Mistake
Azure App Configuration can store secrets securely.
Correct
App Configuration does not encrypt values at rest with customer-managed keys by default. It is not designed for secrets. Use Azure Key Vault for secrets and reference them from App Configuration.
Mistake
Feature flags in App Configuration require code changes to evaluate.
Correct
The SDK provides built-in methods like `IsEnabled("MyFlag")` and integrates with ASP.NET Core's `IFeatureManager`. No custom code is needed.
Mistake
Dynamic refresh is real-time; changes appear immediately.
Correct
The default cache expiration is 30 seconds. Changes are polled, not pushed. You can reduce the interval but at the cost of increased requests.
Mistake
App Configuration is only for .NET applications.
Correct
SDKs are available for Java, Python, JavaScript, and others. The REST API can be used from any language.
Mistake
Labels are optional and rarely used.
Correct
Labels are essential for multi-environment deployments. Without labels, all environments share the same configuration, which is rarely desired.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use managed identity when possible, which eliminates the need for connection strings. For on-premises apps, use access keys but rotate them regularly. Always use HTTPS. Additionally, restrict network access using private endpoints or service tags.
Yes, App Configuration exposes a REST API that can be consumed from any language. Official SDKs are available for .NET, Java, Python, JavaScript, and Go. Community SDKs exist for other languages.
The SDK caches configuration locally. If the store is unavailable, the application continues to use the cached values. You can configure the cache expiration to control staleness. For critical settings, consider a fallback configuration file.
If you have a snapshot from before the change, you can restore it by exporting the snapshot and importing it back into the store. Alternatively, you can manually revert individual key-values. There is no built-in 'rollback' button.
Yes, you can use the Azure App Configuration Kubernetes Provider to sync configuration into ConfigMaps and Secrets. This allows your Kubernetes workloads to consume configuration from App Configuration.
A feature flag is a special key with a structured JSON value that includes conditions (e.g., percentage rollout, user groups). The SDK provides a feature manager to evaluate flags. Regular key-values are simple string pairs without built-in evaluation logic.
There is no hard limit on the number of labels per key. However, each unique combination of key and label counts as a separate key-value in the store's quota. Use labels judiciously to avoid hitting the store limit.
You've just covered Azure App Configuration Service — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?