ASP.NET Core interview questions covering logging, error handling & background services.
Open a question for the full answer, code and interview guidance.
Logging is the framework-supported mechanism for recording diagnostic and operational information about an application. ASP.NET Core provides the ILogger abstraction so application code can write logs without being tightly coupled to a particular logging provider.
ILogger<T> is a typed logging abstraction provided through dependency injection. The generic type normally identifies the class producing the log and becomes the logging category.
ASP.NET Core logging defines Trace, Debug, Information, Warning, Error, Critical, and None levels.
Logging configuration can be supplied through appsettings.json, environment-specific configuration, code, and provider-specific settings. Categories can have different minimum log levels.
A logging provider sends log events to a particular destination or logging system. Built-in and platform integrations can write to destinations such as the console, debug output, event sources, or operating-system logging facilities.
Structured logging records named properties alongside a message template instead of building one long formatted string. Those properties can be indexed and queried by log-management systems.
A logging scope attaches contextual information to a group of log entries produced during an operation. Providers that support scopes can include this context in every log event inside the scope.
When an exception is logged, pass the Exception object to the logging method so the provider can record its type, message, stack trace, and inner-exception information.
Centralized exception handling keeps repetitive try/catch blocks out of controllers and provides consistent responses for unhandled failures.
Problem Details is a standardized JSON format for describing HTTP API errors. It commonly contains fields such as type, title, status, detail, and instance, with optional extension properties.
BackgroundService is a base class for implementing long-running hosted services. A derived class overrides ExecuteAsync and performs work until the supplied cancellation token indicates that the host is shutting down.
IHostedService defines the contract for services whose lifetime is managed by the .NET host. It contains StartAsync and StopAsync methods.
Hosted services are normally registered with AddHostedService<T>(). The host creates and manages the service as part of application startup and shutdown.
A hosted BackgroundService is long-lived, whereas DbContext is normally scoped. Injecting the DbContext directly into the worker would create a lifetime mismatch.
CancellationToken allows asynchronous operations to stop cooperatively when work is no longer required. In HTTP processing, RequestAborted can signal that the client disconnected. In hosted services, the stopping token signals application shutdown.
Graceful shutdown allows the application to stop accepting new work and gives in-progress operations and hosted services an opportunity to finish or cancel cleanly.
Periodic work can be implemented with a BackgroundService and PeriodicTimer. Each iteration should observe the cancellation token, handle failures deliberately, and avoid overlapping executions unless concurrency is intentional.
An unhandled exception escaping a background service is a serious application failure. Host behavior is configurable, but modern .NET hosting commonly treats an unhandled BackgroundService exception as a reason to stop the host rather than silently leaving the application running without an expected worker.
Retries should be used only for failures that are plausibly transient, such as a temporary network or service outage. Permanent validation errors, authentication failures, or invalid business data should not be retried indefinitely.
A correlation ID is an identifier used to associate logs and operations that belong to the same request or distributed workflow.
Health checks expose application health information that infrastructure can use to determine whether an instance is functioning or ready to receive traffic.
A liveness check answers whether the application process is alive enough that restarting it may be appropriate when the check fails. It should usually avoid fragile dependency checks that could cause unnecessary restart loops.
Logs record discrete events and diagnostic details. Metrics are numerical measurements aggregated over time, such as request rate, error count, latency, memory usage, or queue depth. Traces follow the path and timing of an operation across components and services.
Sensitive information should not be logged unless there is a specific, justified, and protected requirement. Passwords, authentication tokens, secret keys, full connection strings, payment credentials, and other confidential values should never appear in ordinary application logs.
Use structured ILogger messages with meaningful properties and appropriate log levels. Centralize unhandled exception processing, return safe and consistent production errors, and preserve detailed diagnostics in protected logs rather than exposing them to users.