Environment Variables vs Azure Key Vault Fallback for Production Secrets

Goal

Choose a production‑secret strategy that guarantees fail‑fast behavior when a required value is missing, while keeping local development simple.

Constraints & Uncertainty

• ASP.NET Core loads configuration providers in the order they are added; later providers override earlier ones.
• Environment‑variable naming differs locally (double underscore) versus production (colon), causing silent nulls.
• Azure Key Vault can be added after appsettings.json, but missing secrets fall back silently unless ValidateOnStart is enabled.
• IOptions<T>.ValidateOnStart behavior varies across .NET 6, 7, and 8 and depends on data‑annotation or custom validators.

Trade‑off

Relying solely on environment variables gives explicit precedence but demands consistent naming across environments. Using Key Vault with a JSON fallback centralizes secret storage but risks hidden fallbacks if validation is not enforced.

Which approach ensures fail‑fast on missing secrets without sacrificing local developer workflow? How should provider order be configured to guarantee environment variables override Key Vault in production? What validation strategy works across .NET 6/7/8 to surface missing configuration at startup?