A bluff-erosion pin API uses the same App Configuration key ApiUrl for test and production. How should environments stay separated without overwriting each other?
Select an answer to reveal the explanation.
Short Explanation
Same key, different worlds: labels (or another store) keep test and prod ApiUrl apart. Overwriting one shared value is how yesterday’s test URL sneaks into production.
Full Explanation
App Configuration keys can be disambiguated with labels (or entirely separate stores). For the bluff-erosion pin API, keep the logical key ApiUrl but attach environment labels such as test and prod—or use distinct configuration stores—so each host loads only its labelled value. That prevents yesterday's test endpoint from becoming today's production traffic without daily overwrite rituals.
Overwriting a single shared ApiUrl in place daily fails under concurrency: any still-running test host or delayed deploy will race production and create hard-to-diagnose cross-environment calls. Storing ApiUrl only inside Application Insights smart detection rules fails because smart detection analyzes anomalies in telemetry; it is not an application configuration authority. Putting ApiUrl in a Service Bus topic filter and subscribing by environment name fails product fit—subscription filters select messages, they do not supply HTTP base addresses to your API at startup.
Exam caveat: code must set the label (or connection) explicitly when building the configuration client; forgetting the label often silently binds every environment to the unlabelled key. Operational check: deploy one test and one prod instance pointed at the same store with different labels, change only the test ApiUrl, and verify production traffic and dependency telemetry still target the production URL.