Production engineering
Reveal answer and reasoning
Startup validation and runtime configuration publication are different events. This external project loads runtime-settings.json with reloadOnChange enabled, binds LiveSettings and reads CurrentValue through IOptionsMonitor. A valid owned-file update can therefore become visible without restarting the host. The experiment also returns a hasSecret Boolean instead of the secret string. That is a deliberately narrow exposure rule, not a secret-store integration or evidence that every log, file and operator has appropriate access.
The central contract is what the running consumer observes after a valid update, while invalid-update handling and credential rotation remain separate application responsibilities.
Program.cs adds the owned JSON file as a required reloadable configuration source. AddOptions binds the Live section, validates a nonblank Label and a Maximum from one through ten, and requests startup validation. SecurityLabs maps /configuration to monitor.CurrentValue, returning only Label, Maximum and hasSecret. The supplied endpoint catches OptionsValidationException during that access, but invalid reload can also involve validation callbacks elsewhere in the options pipeline.
Its catch is not a complete process-wide fallback policy. The verified external exercise changes the file to another valid label and maximum, then polls for those values without claiming an exact notification delay.
What a strong answer covers
- Startup validation and runtime configuration publication are different events.
- Program.cs adds the owned JSON file as a required reloadable configuration source.
- File notification, parsing, option construction, validation and consumer access are distinct steps with their own failures.
Common pitfall
File notification, parsing, option construction, validation and consumer access are distinct steps with their own failures. A valid reload test does not establish that an invalid update retains the previous valid object or consistently produces503. Provider ordering also determines which configuration source wins; this example should be read as its actual configured source graph rather than a universal precedence recipe. The demonstration secret is explicitly not a credential. Reporting hasSecret still discloses presence, and excluding the string from one response does not remove it from the local file, memory or an unrelated logging pipeline.
Follow-up questions
- How would two processes prove they are using the same accepted configuration revision during a staged rollout?
- Why would a catch around CurrentValue not establish that every invalid reload callback is handled safely?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.