Modern cloud applications need to change behavior quickly without redeployments. Whether you’re adjusting timeout values, enabling new features for specific users, or rolling back problematic changes, Azure App Configuration provides the control plane you need to manage these changes safely and efficiently.
What is Azure App Configuration?
Azure App Configuration is a managed service that centralizes application settings and feature flags. Instead of hardcoding configuration values or scattering them across multiple files, you store them in a single, secure location that all your applications can access at runtime.
Key Benefits
- Eliminate Redeployments: Change application behavior by updating configuration values, not by deploying new code.
- Environment Consistency: Use labels to manage different values across dev, staging, and production while keeping the same configuration keys.
- Safe Rollbacks: Create immutable snapshots of your configuration that can be restored instantly if something goes wrong.
- Advanced Feature Control: Enable features for specific users, groups, or percentages of your user base without touching your codebase.
- Audit Trail: Track exactly when configuration changes happened and who made them.
Prerequisites
Before starting this tutorial, you’ll need:
- An active Azure subscription
- Azure CLI installed and configured
- Basic familiarity with Azure resources and JSON
- A text editor for creating configuration files
Optional but recommended: Read our comprehensive guide on why Azure App Configuration belongs in your cloud architecture for strategic context and best practices.
Tutorial Overview
In this tutorial, you’ll:
- Provision an Azure App Configuration store
- Import baseline configuration values
- Create snapshots for rollback scenarios
- Set up feature flags with user targeting
- Integrate feature flags into your application code
Let’s get started.
Part 1: Provisioning App Configuration and Creating Snapshots
The first step in using Azure App Configuration is to provision a store and load a baseline set of values. Once those values are in place, creating a snapshot locks them into an immutable, point-in-time record that can be used for rollback scenarios.
Step 1: Create the App Configuration store
az appconfig create \
--name MyAppConfigStore \
--resource-group MyResourceGroup \
--location eastusThis command provisions a new App Configuration instance in the specified resource group and region. The store becomes the central hub for application settings and feature flags.
Step 2: Import baseline configuration values
az appconfig kv import \
--name MyAppConfigStore \
--format json \
--label dev \
--path ./config.dev.jsonHere we import a JSON file containing environment-specific values. The –label dev flag ensures these values apply only to the development environment. You can repeat the process with labels like staging or prod to manage different environments consistently.
Step 3: Capture a snapshot
az appconfig snapshot create \
--name MyAppConfigStore \
--snapshot baseline-dev \
--filters "label=dev"This command captures all key-values with the dev label in a snapshot named baseline-dev. Snapshots are immutable, meaning they cannot be modified once created. This makes them a reliable recovery point.
How snapshots help with rollback
If a later configuration rollout introduces a problem, you do not edit keys by hand or scramble for redeployments. Instead, you point your applications to a known-good snapshot, which immediately restores stability. Once the issue is fixed, you can create a new snapshot and move forward.
Best practice: Snapshots should be captured automatically in your CI/CD pipeline every time configuration is promoted. This way, every environment always has a recent recovery point.
Part 2: Creating Feature Flags with User Targeting
Feature flags let you control application behavior without redeploying code. Instead of flipping switches in your codebase, you manage them centrally in App Configuration. This allows for safer rollouts, gradual exposure, and experimentation.
Step 1: Create the feature flag
az appconfig feature set \
--name MyAppConfigStore \
--feature "BetaFeature" \
--label "prod" \
--yes This command creates a new feature flag called BetaFeature in the App Configuration store, scoped to the prod label. The flag is defined but not yet targeted to any specific users or groups.
Step 2: Add a targeting filter
az appconfig feature filter add \
--name MyAppConfigStore \
--feature "BetaFeature" \
--label "prod" \
--filter-name "Microsoft.Targeting" \
--filter-parameters '{"Audience":{"Users":["someone@example.com"],"Groups":[{"Name":"Pilot","RolloutPercentage":25}]}}'Here we apply the Microsoft.Targeting filter, which enables fine-grained control over who sees the feature. In this example:
- The feature is explicitly turned on for the user someone@example.com.
- Members of the Pilot group get the feature with a 25% rollout percentage.
- Everyone else in production continues to see the default behavior.
Step 3: Consume the feature flag from your code
Once a feature flag is defined in App Configuration, the application checks it at runtime. In .NET you use the Feature Management libraries to evaluate flags and the Targeting filter to decide who sees a feature.
First, configure your application startup code to add App Configuration and Feature Management capabilities like this:
using Azure.Identity;
using Microsoft.Extensions.Hosting;
using Microsoft.FeatureManagement;
var host = new HostBuilder()
.ConfigureFunctionsWorkerDefaults()
.ConfigureAppConfiguration((ctx, cfg) =>
{
var built = cfg.Build();
cfg.AddAzureAppConfiguration(o =>
o.Connect(new Uri($"https://{built["AppConfig:Endpoint"]}"), new DefaultAzureCredential())
.UseFeatureFlags());
})
.ConfigureServices(s => s.AddFeatureManagement())
.Build();
await host.RunAsync(); Next, inject IFeatureManager into your class using Dependency Injection like this:
public class MyFunction
{
private readonly IFeatureManager _features;
private readonly ILogger<MyFunction> _logger;
public MyFunction(IFeatureManager features, ILogger<MyFunction> logger)
{
_features = features; // injected from DI
_logger = logger;
}
}Finally, use the FeatureManager instance to check if a feature is active or not:
bool enabled = await _features.IsEnabledAsync("BetaFeature");
if (enabled)
{
// run beta code
}
else
{
// run standard code
}Understanding Targeting Benefits
Targeting enables several powerful deployment strategies:
- Gradual Rollouts: Start with internal users, then expand to pilot groups, then increase percentage gradually as confidence grows.
- A/B Testing: Enable features for specific user segments to measure impact before full rollout.
- Instant Rollback: Disable flags immediately if issues arise—no code deployment required.
- User-Specific Features: Enable premium features for specific user tiers or experimental features for beta users.
Next Steps and Advanced Patterns
Now that you have App Configuration running with both settings and feature flags, consider these next steps:
Integration with CI/CD Pipelines
Automate configuration imports and snapshot creation in your deployment pipeline:
bash
# In your pipeline script
az appconfig kv import --name MyAppConfigStore --format json --label ${ENVIRONMENT} --path ./config.${ENVIRONMENT}.json
az appconfig snapshot create --name MyAppConfigStore --snapshot release-${BUILD_NUMBER} --filters "label=${ENVIRONMENT}"Environment-Specific Configuration
Create separate configuration files for each environment:
config.dev.json– Development settings with verbose loggingconfig.staging.json– Production-like settings for testingconfig.prod.json– Optimized production values
Dynamic Configuration Refresh
Implement configuration refresh in your applications so changes take effect without restarts:
csharp
cfg.AddAzureAppConfiguration(options =>
options.Connect(connectionString)
.ConfigureRefresh(refresh =>
refresh.Register("App:Sentinel", refreshAll: true)
.SetCacheExpiration(TimeSpan.FromMinutes(5))));Advanced Feature Flag Patterns
- Time-based activation: Enable features at specific dates/times
- Custom filters: Create business-specific targeting rules
- Variant flags: Return different values instead of just true/false
Conclusion
You’ve successfully set up Azure App Configuration with both configuration management and feature flags. Your applications can now:
- Change behavior without redeployments
- Roll back to known-good states instantly
- Enable features for specific users or groups
- Maintain consistency across environments
Important Considerations
As you expand your usage, keep these best practices in mind:
- Security: Never store secrets in App Configuration—use Azure Key Vault instead
- Performance: Implement local caching to avoid excessive API calls
- Change Management: Treat configuration changes like code changes with proper review processes
For deeper insights into Azure App Configuration strategy, observability patterns, and common pitfalls, read our comprehensive guide: Managing Change at Scale: Why Azure App Configuration Belongs in Your Cloud Architecture.
Insights By
Ready for Production?
This tutorial provides the foundation, but production deployments require additional considerations around security, networking, and governance.
Contact us to design a configuration strategy that aligns with your business goals.
