Feature flags with Azure App Configuration
Implement feature flags by using Azure App Configuration Feature Manager
The vocabulary the docs define
- Feature flag — a variable with a binary state, on or off, with an associated code block. The flag's state decides whether that block runs.
- Feature manager (application-package concept) — an application package that handles the lifecycle of all flags in the application. This is distinct from the Azure portal's Feature manager UI.
- Feature filter — a condition evaluated to determine a flag's state, such as a time window or targeted audience.
Why it belongs in App Configuration
Storing flags centrally means one place to change behaviour across every instance and service, rather than a config file per deployment. The application reads flag state at runtime, so feature availability changes without redeploying code.
The five documented use cases
| Use case | What it enables |
|---|---|
| Code branch management | Dark deployment — ship unfinished features dormant, avoid long-lived branches |
| Test in production | Real production fidelity for internal users or beta testers |
| Flighting | Incremental rollout to a growing percentage |
| Instant kill switch | Disable without rebuild or redeploy |
| Selective activation | Segment users — e.g. one browser only |
Current App Configuration path
- Open the App Configuration store and choose Operations > Feature manager > Create.
- Choose Switch for a simple on/off control, Rollout for progressive audience exposure, or Experiment for variants and controlled comparison.
- Configure basics plus the relevant audience, conditions, allocation, or variants, then create the flag.
- Load and evaluate the flag through an App Configuration provider and the feature-management library for the application's platform.
Operational care
Configuration providers handle caching and dynamic updates, so observation time depends on provider configuration and application refresh activity. The .NET App Configuration provider defaults to a 30-second refresh interval, but that is not a cross-platform propagation SLA.
Flags add execution paths, testing load, and technical debt. Define a removal timeline when introducing a temporary flag and retire it when it becomes obsolete. Some flags deliberately persist; keep those paths tested and maintained.
Primary sources
- https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/az-400
- https://learn.microsoft.com/en-us/azure/azure-app-configuration/concept-feature-management
- https://learn.microsoft.com/en-us/azure/azure-app-configuration/manage-feature-flags
- https://learn.microsoft.com/en-us/azure/azure-app-configuration/howto-feature-filters
- https://learn.microsoft.com/en-us/azure/azure-app-configuration/feature-management-dotnet-reference
- https://learn.microsoft.com/en-us/azure/azure-app-configuration/reference-dotnet-provider
- https://learn.microsoft.com/en-us/training/modules/implement-blue-green-deployment-feature-toggles/5-describe-feature-toggle-maintenance
- https://learn.microsoft.com/en-us/devops/operate/progressive-experimentation-feature-flags