An ASP.NET Core setting has one value locally and another in production. How would you reason about configuration provider precedence and secret handling?

Configuration provider precedence and secret boundaries

Explains how later configuration providers override earlier values and keeps secrets, environment overrides, and diagnostics within explicit boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

When providers contain the same key, the provider added later normally wins. The default application builder typically combines JSON files, environment-specific JSON, development secrets, environment variables, and command-line arguments in an intentional order. Environment variables use conventions such as double underscores for nested keys. I keep non-secret defaults in source-controlled files, environment-specific values outside the artifact, and secrets in a managed secret source rather than ordinary JSON or logs.

Full answer below

Practice focus

Configuration sources, provider order, key normalization, environment variables, command-line overrides, secrets, diagnostics, and deployment traceability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
ASP.NET Core composes configuration from several providers into one key space. A correct value can still lose to a later provider, so debugging needs the source order as well as the final value.
When providers contain the same key, the provider added later normally wins. The default application builder typically combines JSON files, environment-specific JSON, development secrets, environment variables, and command-line arguments in an intentional order. Environment variables use conventions such as double underscores for nested keys. I keep non-secret defaults in source-controlled files, environment-specific values outside the artifact, and secrets in a managed secret source rather than ordinary JSON or logs.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I debug a mismatch by checking the exact normalized key, environment name, provider order, deployment slot, and whether the process restarted or reloaded after the change. I can inspect which providers are configured and whether a key exists without printing the sensitive value. A container or App Service environment variable may override a correct JSON value, while a command-line argument can override both. I keep a documented inventory of required keys so an accidental typo does not silently fall back to an unsafe default.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
Configuration is deployment input, so I want changes reviewed, attributable, and reversible like code changes. I distinguish secrets from ordinary operational settings: secret values need access control, rotation, and redaction, while feature flags need ownership and safe defaults. A secret reference can be present yet unusable because identity or network access is wrong, so startup or readiness checks validate the dependency without exposing the secret. In production I log provider names and configuration version where safe, compare desired and effective configuration metadata, and avoid endpoints that dump the full configuration tree. Tests exercise precedence with the same source types used by deployment rather than assuming local JSON matches production.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming appsettings.json always wins because it is the most visible file.
Logging the full configuration tree to find one mismatched key.
Storing production secrets in environment-specific JSON committed with the application.
Using permissive fallback values for settings required for security or data isolation.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Cannot list the effective providers or their order in the deployed host.
A missing secret silently redirects the application to a shared or local dependency.
Portal edits are the only record of production configuration changes.
Diagnostics prove the key value by revealing the key's secret content.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How are nested configuration keys represented in environment variables?
How would you diagnose a value without logging the secret?
Which settings require fail-fast behavior rather than a default?

Continue the section