Start here. This is the direct spoken answer to practice first.
Why this question matters
Some configuration must remain with staging or production when App Service swaps code between slots. Classifying those values correctly prevents production traffic from inheriting staging databases, callbacks, secrets, or feature state.
Slot settings are configuration values that stay with a slot during a swap. I would mark environment-owned values as sticky, such as database connection strings, Key Vault references, auth callback URLs, staging-only feature flags, and webhook endpoints. Without that, a staging slot can accidentally bring staging configuration into production or point production traffic at the wrong dependency after swap.