5.1.2. Azure App Configuration
💡 First Principle: Configuration sprawl is a consistency problem: ten microservices each carrying their own copy of MaxRetries will eventually disagree. App Configuration makes configuration a service — one store, uniform key-values, environment labels, and change notification — so every service reads the same truth and reacts when it changes.
App Configuration organizes key-values with two axes: hierarchical key names (RagApi:Retrieval:TopK) and labels for environment variants — the same key holds 5 under label dev and 10 under label prod; the app selects its label at startup. Python access:
from azure.appconfiguration import AzureAppConfigurationClient
cfg = AzureAppConfigurationClient(base_url, DefaultAzureCredential())
topk = cfg.get_configuration_setting(key="RagApi:Retrieval:TopK", label="prod").value
Beyond plain values, two features carry exam weight. Key Vault references — a key-value whose content type marks it as a pointer to a vault secret — let applications read one configuration surface while App Configuration never stores or returns the secret itself; the client SDK (or App Service) resolves the reference against Key Vault using the app's own identity, completing the safe-and-binder model from 5.1. Feature flags are structured on/off switches with filters (percentage rollout, time window) — the standard way to dark-launch a new RAG ranking algorithm behind a flag and enable it for 10% of traffic, a software-level cousin of 3.2.1's canary revisions.
Dynamic refresh closes the loop: rather than polling every key, clients watch a sentinel key — one designated key-value bumped by operators after any batch of changes; when the sentinel changes, the client reloads all configuration. This gives near-real-time config changes without redeploys and without hammering the service.
The division of labor, in one table:
| Concern | App Configuration | Key Vault |
|---|---|---|
| Non-secret settings, feature flags | ✅ stores | ❌ wrong tool |
| Secrets (keys, connection strings) | pointer only (KV reference) | ✅ stores |
| Environment variants | labels | separate vaults or names |
| Change notification | sentinel key + refresh | new version + events |
| Access audit per read | ❌ | ✅ |
⚠️ Exam Trap: "Store the database connection string in App Configuration so all services share it" — wrong container. The connection string is a secret: Key Vault holds it; App Configuration holds the reference. Conversely, don't put TopK=10 in Key Vault — non-secrets in the vault add latency, throttling exposure, and audit noise for zero security gain.
Operational features worth knowing: snapshots capture an immutable, point-in-time view of a store's key-values — the configuration analogue of a git tag, useful for rollback and audit. az appconfig kv export and import move key-values between stores or to files, which is how dev-to-prod promotion pipelines diff and ship configuration. Content types drive interpretation: the Key Vault reference content type is what tells providers to resolve rather than return the value, and JSON content types let structured values deserialize cleanly. Client libraries expose a refresh interval alongside the sentinel watch, bounding how quickly changes propagate even when the sentinel bump is missed.
Reflection Question: Why does the sentinel-key pattern scale better than having every client watch every key — and what operational discipline does it demand from whoever changes configuration?
