Lab: roll out and roll back a feature flag

Outcome

Create an Azure App Configuration store, define a feature flag for a training application, roll it out to a named training ring, observe the application behavior, and disable it as a rollback. A flag changes behavior after deployment; it does not replace a safe deployment, a migration plan, or monitoring.

Before you begin

Use a non-production subscription. You need permission to create a resource group and App Configuration store, plus a data-plane role that permits feature-flag writes when using --auth-mode login. Store names are globally unique. Decide your rollback condition before release—for example, an error-rate increase above a documented training threshold for five minutes.

az group create --name rg-azlearn-flags --location <azure-region>
az appconfig create --name <unique-store-name> --resource-group rg-azlearn-flags --location <azure-region>

Do

1. In the App Configuration store, open Feature manager and create CheckoutBanner. Set its initial state to Off. Add a description that identifies the owning team, audience, and rollback condition.

2. Give the training application identity read-only data-plane access. Give the administrator only the writer role needed to change the flag. Do not put an App Configuration access key or connection string in a repository or pipeline log.

3. Create a ring0 label and use the portal to add a Targeting filter. Include a named training user or group, set the default rollout percentage to 0, and set the flag On. The targeting context is application-defined: the app must pass the same user/group identifier scheme that you configured.

4. Verify the stored configuration through the CLI using Entra sign-in rather than an access key:

   az appconfig feature list --name <unique-store-name> --auth-mode login \
     --fields key,label,state,conditions,description -o json
   az appconfig feature filter list --name <unique-store-name> \
     --feature CheckoutBanner --label ring0 --auth-mode login -o json

5. In a training application, place the new banner behind CheckoutBanner. Make two requests with the application’s ring0 and non-ring0 test identities. Record the timestamp, identity context, flag value, and visible result. The ring0 request should see the banner; the other request should not.

6. Expand only after the stated telemetry condition holds. Increase the ring0 percentage or add the next ring, record the decision, and watch the same health signals. A target percentage is a rollout choice, not a success metric.

Verify

Capture the flag’s key, label, state, targeting rule, application identity/read role, and one request from each side of the decision. You should now understand: a feature flag selects behavior at runtime; deployment controls which code is available; a rollback flag must be observable by the application before it can protect users.

Break and fix

1. On a training label, remove the application identity’s data-plane read role. The app should fail to refresh/read configuration. Capture the authorization error, restore only the reader role, and confirm the flag resumes evaluation.
2. Add a test identity to the wrong target group or use an application context identifier that does not match the targeting rule. The flag should remain off for that request. Correct the group/context mapping; do not change the default percentage merely to hide the mismatch.
3. Trigger the predeclared rollback condition with a harmless training signal, then disable CheckoutBanner for the active label. Confirm the next refresh no longer shows the banner and record the decision time.

Scenario practice

1. Configure: A database migration has already added a nullable column. Should a flag hide the new UI, prevent the migration, or both? Explain the order that keeps old and new application versions compatible.
2. Diagnose: Only one test user sees the new behavior. Which evidence separates a targeting-context mismatch from a stale configuration refresh or an application bug?
3. Distinguish: Contrast a feature flag rollback with redeploying a previous build. Which change is immediate at runtime, and which changes the deployed artifact?

Clean up

Disable and delete the training flag, remove training role assignments, then delete the resource group:

az group delete --name rg-azlearn-flags --yes --no-wait

Sources and re-audit

• Feature management concepts, checked 2026-08-22.
• Target a feature rollout, checked 2026-08-22.
• Azure CLI feature-flag commands, checked 2026-08-22.

Re-audit when feature filters, application SDK behavior, data-plane RBAC, or CLI arguments change.

Related

Feature flags · Workload · Managed identity · Release path · All labs