A blood-bank App Service site stores DbPassword in a text file on the worker and CatalogEndpoint in source code. How should the developer store that configuration instead?

App Service application settings and typed connection strings inject as environment variables at runtime without rebuilding the blood-bank site. Place DbPassword and CatalogEndpoint there—preferably with Key Vault references for the password—instead of a plaintext text file on the worker and hard-coded values in source. Think of app settings as labeled mail slots: drop in new values per environment or slot and the process picks them up without a rebuild.

Keeping secrets in the worker text file and committing endpoints to the repository blocks clean slot overrides and leaks configuration into source control. Baking both values into a custom base image layer forces an image rebuild for every environment change and couples config to artifacts. Moving configuration only into Azure DNS TXT records and reading them at startup over the public Internet exposes values broadly and is not an App Service configuration pattern.

Exam caveat: slot-sticky settings behave differently from settings that swap with the slot; mark secrets and endpoints appropriately when using deployment slots. Key Vault references keep secret values out of the settings blade as plaintext while still surfacing them as environment variables to the app.

Operational check: move DbPassword and CatalogEndpoint into application settings or connection strings (with a Key Vault reference for the password), remove the worker text file and hard-coded endpoint, restart or swap a slot, and confirm the app reads the new environment variables without a code or image rebuild.