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.

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.

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

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Tech stacks

Skill areas

Suggest an improvement