Azure App Configuration (`store: azure-appconfig`)

Resolves variable/feature values from an Azure App Configuration store — via the real Azure SDK (azure-appconfiguration), not the az CLI.

Prerequisites

An Azure App Configuration store with the keys you want to use already populated.
The identity strata runs as must have App Configuration Data Reader (or equivalent) access on that store — see Authentication below.

Authentication — ambient, via `DefaultAzureCredential`, never `spec.authentication`

Identical story to Azure Key Vault — kind: integration’s spec.authentication is not used here either, for the same reason (see docs/design/store-integration-configuration.md). DefaultAzureCredential chains through managed identity automatically, with nothing to declare in the common case.

Env var	Required	Purpose
`AZURE_APPCONFIG_ENDPOINT`	Yes	The store’s endpoint, e.g. `https://my-config.azconfig.io`
`AZURE_CLIENT_ID`	Only for a user-assigned managed identity	Picked up automatically by `DefaultAzureCredential` itself

Configuring the `kind: integration` document (optional)

Everything above already works with no kind: integration document at all — AZURE_APPCONFIG_ENDPOINT alone is enough. Declare one when you want the endpoint checked into the solution itself instead of living only in an env var:

apiVersion: strata.huybrechts.xyz/v2
kind: integration
meta:
  name: azure-appconfig-prod
spec:
  type: azure-appconfig
  capabilities: [variables, features]
  enabled: true
  endpoints:
    address: https://my-config.azconfig.io

Using it from an Environment

apiVersion: strata.huybrechts.xyz/v2
kind: environment
meta:
  name: prd
spec:
  variables:
    - key: API_HOST
      store: azure-appconfig
      value: api-host # the configuration key's own name in the store
  features:
    - key: ENABLE_NEW_UI
      store: azure-appconfig
      value: enable-new-ui

value is the configuration key’s own name inside the store — not a strata-declared key, and not a literal value.

Known limitation — feature flag values

Azure App Configuration stores a feature flag as a JSON blob ({"id": ..., "enabled": ..., ...}), not a plain true/false string. The resolver currently returns that blob verbatim rather than parsing out enabled — unaddressed so far because no production evidence yet shows a feature (as opposed to a plain variable) actually resolving through this store. If you hit this, that’s why; it isn’t specific to the configuration-binding design this guide otherwise describes.

Troubleshooting

“AZURE_APPCONFIG_ENDPOINT is not set” — neither the env var nor a kind: integration document’s endpoints.address resolved to an endpoint.
“no key named ‘…’ in the store” — the key doesn’t exist in that store; check for a typo or the wrong endpoint.
“could not resolve ‘…’: …” — usually an authentication/authorization failure; confirm the identity DefaultAzureCredential picked has read access on the store.
Multiple candidates named ‘…’ — set ‘integration:’ explicitly” (once the binding design is implemented) — more than one enabled kind: integration document declares type: azure-appconfig. Disable all but one — a store cannot name which one to use by itself.

Azure App Configuration (store: azure-appconfig)