How to Implement Feature Flags in ASP.NET Core 10 Using Azure App Configuration (2026)

Azure App Configuration lets an ASP.NET Core 10 application change a feature flag independently of a deployment. In this example, the checkout endpoint decides which response shape to select after it evaluates CheckoutV2. A rollout can start with an internal group or a small percentage of eligible users. Turning the flag off is a rollback lever, subject to the refresh behavior of each replica.

In this guide

1. What happens when a flag changes?
2. Prepare an App Configuration store
3. Add request-time evaluation
4. Roll out and verify changes
5. Choose the right rollout controls
6. Troubleshooting and FAQs

What happens when a flag changes?

An operator changes a flag. The application refreshes its cached configuration and evaluates the flag for each request.

Azure App Configuration stores flag definitions. The ASP.NET Core provider loads those definitions and keeps a local cache. Feature management evaluates the flag for the request, including the target identity when the targeting filter is configured. The request-driven middleware checks for refresh opportunities. The interval is a minimum between refresh checks, not a guarantee that all replicas switch at the same instant.

Azure configuration provider · .NET feature management reference

Prepare an App Configuration store

Create an Azure App Configuration store. Under Feature Manager, create CheckoutV2 without a label for this lab. Start disabled. Assign the application’s managed identity App Configuration Data Reader on the store. For local testing, sign in to a developer credential recognized by DefaultAzureCredential and grant that identity the same read access. Role propagation can take time. In a hosted environment consider selecting the intended managed identity explicitly to keep credential resolution predictable.

Create a .NET 10 minimal web project. Add Microsoft.Azure.AppConfiguration.AspNetCore, Microsoft.FeatureManagement.AspNetCore, Azure.Identity, and the .NET 10 line of Microsoft.AspNetCore.Authentication.JwtBearer. Use stable NuGet references. Set AppConfiguration__Endpoint to your store’s HTTPS endpoint. Set Auth__Authority and Auth__Audience for your test issuer and API.

Add request-time evaluation

Program.cs

using Azure.Identity;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.Extensions.Configuration.AzureAppConfiguration;
using Microsoft.FeatureManagement;

var b = WebApplication.CreateBuilder(args);
var endpoint = b.Configuration["AppConfiguration:Endpoint"]
    ?? throw new InvalidOperationException("Set AppConfiguration:Endpoint.");
b.Configuration.AddAzureAppConfiguration(options =>
    options.Connect(new Uri(endpoint), new DefaultAzureCredential())
        .UseFeatureFlags(flags => flags.SetRefreshInterval(TimeSpan.FromSeconds(30))));
b.Services.AddAzureAppConfiguration();
b.Services.AddFeatureManagement().WithTargeting();
b.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(o =>
{
    o.Authority = b.Configuration["Auth:Authority"];
    o.Audience = b.Configuration["Auth:Audience"];
});
b.Services.AddAuthorization();

var app = b.Build();
app.UseAzureAppConfiguration();
app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/checkout/summary", async (IVariantFeatureManagerSnapshot flags) =>
{
    var enabled = await flags.IsEnabledAsync("CheckoutV2");
    return Results.Ok(new { version = enabled ? "v2" : "v1" });
}).RequireAuthorization();

app.Run();

The feature manager snapshot keeps flag evaluation consistent within a request. The targeting accessor can use the current authenticated principal. Confirm your provider maps a stable principal name and group or role claims as expected, or supply a custom targeting context accessor that uses your application’s immutable user identifier. A feature flag controls exposure. Permission to call the checkout endpoint comes from authentication and authorization.

Roll out and verify changes

1. Run the application and send an authorized GET to /checkout/summary. With the flag disabled, expect {"version":"v1"}.
2. Enable the flag for everyone in the lab. Send traffic after the 30-second refresh interval and repeat the request. Expect {"version":"v2"} once the refresh takes effect.
3. Configure a targeting audience in Azure. Give an internal group full exposure and use a small default percentage outside that group. Compare two authorized test identities with stable IDs and verify the expected group behavior.
4. Turn the flag off. Recheck across replicas after refresh. Keep the v1 path operational until you have verified the rollback.

A request can initiate a refresh and still see the previous value, depending on when the refresh completes. A replica receiving no requests does not refresh through request middleware until traffic reaches it. For background work, use the provider’s documented refresher pattern. These are expected behaviors. Live Azure and identity tests were not run here.

Azure targeting tutorial

Choose the right rollout controls

Requirement	Approach
Internal preview	Target a verified group.
Stable percentage exposure	Use targeting with a stable user identifier.
Emergency disable	Keep a safe legacy path and verify refresh across replicas.
Different user experiences	Consider variants, with clear defaults and telemetry.
Permission for sensitive action	Enforce authorization on the operation itself.

Track the flag version or evaluated variant alongside latency, errors and business outcomes. Avoid putting user identifiers into unbounded metric tags. Clean up expired flags and keep a record of when a rollout moved forward or rolled back.

Troubleshooting and FAQs

Why does the provider fail with 403? Confirm the principal actually used by the credential chain and the store’s data-plane role. Network access rules can also block the request.

Why do two replicas disagree? Check store endpoints, selectors, deployment configuration, request traffic, and refresh timing. Review cached results before assuming a code change is missing.

Can I roll back a database schema change by flipping a flag? The flag switches application behavior. Keep database changes backward-compatible or deploy a separate rollback procedure.

Can flags replace application settings or a secret vault? Use flags for behavior controls. Use appropriate secret storage and protect all configuration access. The ASP.NET PB IIS deployment guide covers environment configuration separately.

A safe flag rollout has a testable baseline, a measurable target audience, and a rollback path that can still run against the current data.