A wrack-line cleanup API stuffed connection strings, feature flags, and the storage account key into one checked-in JSON file. How should the developer split those values?

Configuration and secrets are different classes of data. For the wrack-line cleanup API, non-secret settings and feature flags belong in Azure App Configuration so operators can change URLs, toggles, and thresholds without redeploying. Secrets such as storage account keys and connection strings belong in Azure Key Vault, retrieved via references or the Key Vault SDK under the app's identity. Splitting this way keeps the municipal bulletin-board values editable and the locked-drawer values out of git.

Dumping every value—including the storage key—into Application Insights custom dimensions fails because Insights is telemetry, not a configuration store; custom dimensions can leak secrets into logs and queries. Putting secrets in Azure Cache for Redis while leaving feature flags in the Git repo forever fails both security and operations: Redis is a cache with its own exposure model, and flags stuck in source still force redeploys. Placing the storage key in a public Blob and flags in Azure Front Door rules fails confidentiality and product fit—anonymous Blob read publishes the key, and Front Door rules are routing/WAF configuration, not an application settings service.

Exam caveat: App Configuration can hold Key Vault references so one configuration provider resolves both layers without copying secret plaintext into the config store. Operational check: remove connection strings from the checked-in JSON, point the API at App Configuration plus Key Vault references, rotate the storage key in the vault, and confirm the cleanup job still starts while git history no longer contains the key material.