Typed options group related configuration and make its validation explicit. They do not make an invalid setting valid, secure a secret or guarantee that every configuration source reloads at runtime.

This .NET Core interview exercise uses a fictional outbound mail configuration. The server name is deliberately a non-deliverable example value. The example validates configuration without sending mail.

How can startup reject missing settings?

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOptions<MailOptions>()
    .Bind(builder.Configuration.GetSection("Mail"))
    .Validate(options => !string.IsNullOrWhiteSpace(options.Host),
        "Mail host is required.")
    .Validate(options => options.Port is >= 1 and <= 65535,
        "Mail port must be in range.")
    .ValidateOnStart();
var app = builder.Build();
app.MapGet("/health", () => Results.Ok());
app.Run();

sealed class MailOptions
{
    public string Host { get; set; } = "";
    public int Port { get; set; }
}
{
  "Mail": {
    "Host": "mail.example.invalid",
    "Port": 587
  }
}

Put the JSON in appsettings.json for the local exercise. Removing Host should cause startup validation to fail. ValidateOnStart moves this failure toward startup instead of allowing the first real operation to discover it later.

What is the difference between the options interfaces?

IOptions provides a simple options value without the same change-notification role as IOptionsMonitor. IOptionsSnapshot is scoped and can give a newly calculated value for a new scope. IOptionsMonitor supports obtaining current values and subscribing to changes.

Those interfaces do not promise that a particular source emits changes. Check the provider, file system and deployment environment. A service that copies a value once into a field will not magically refresh that copy when another object changes.

Which source wins?

Configuration providers are ordered. A later provider can override an earlier value for the same key. ASP.NET Core's default builder includes providers such as JSON files, environment variables and command-line arguments. Customizing the builder can change that order.

For a local test, set Mail__Port through an environment variable and inspect the bound value without printing secrets. The double underscore expresses a nested key in environment-variable configuration. Remove the test variable afterward so it does not affect another run.

Where should secrets go?

Keep production credentials out of committed appsettings files and examples. Use the deployment's supported secret store and identity mechanism. Development user secrets help avoid committing local secrets, but they are not a production vault.

Validation messages should name the missing setting without echoing its confidential value. A startup log can say a credential is missing without printing the credential. Treat configuration dumps as sensitive.

What tests are useful?

  • A complete configuration starts successfully.
  • A blank host fails validation.
  • Ports zero and above 65535 fail.
  • An override changes only the intended field.
  • A consumer handles the chosen reload policy consistently.

Also test the application composition. A class-level validator test cannot prove that the application actually registered that validator or called ValidateOnStart.

How to answer the interview question

Name the shape, binding source, validation timing and reload requirement. For example: “I would bind a Mail section, reject missing host settings at startup, inject the options interface that matches the service lifetime, and keep credentials in the supported secret store.” Each part corresponds to a real failure you can test.

References and next practice

learn.microsoft.com — net options

dotnet question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud