ASP.NET Core MVC & Web API Interview Preparation Guide

Transient services are created every single time they are requested from the DI container, making them ideal for lightweight, stateless utility classes. Scoped services are created once per client HTTP request lifecycle, ensuring that all components handling the same request share the exact same instance (such as an Entity Framework Core DbContext). Singleton services are created once upon application startup and persist for the entire lifetime of the application process, shared globally across all concurrent requests. Choosing the wrong lifetime—such as injecting a Scoped service into a Singleton—creates captive dependencies, leading to memory leaks and dangerous thread safety violations.

Kestrel is a cross-platform, event-driven, asynchronous web server written specifically for .NET to handle raw socket connections and parse HTTP streams directly into managed memory. Traditional servers like IIS act as external reverse proxies that manage process lifecycles and forward requests to ASP.NET Core via out-of-process or in-process handlers (using ANCM). While Kestrel can run standalone exposed directly to the internet in modern Linux container deployments, it is frequently paired with a reverse proxy like Nginx or Yarp to handle advanced edge routing, static file caching, and SSL certificate termination at scale.

Calling blocking synchronous methods like .Result or .Wait() on asynchronous tasks blocks the calling thread while waiting for the operation to complete. In traditional ASP.NET environments with a SynchronizationContext, this caused immediate deadlocks because the continuation could not be posted back to the blocked thread. While modern ASP.NET Core lacks a synchronization context, blocking threads starves the thread pool, reduces application throughput under concurrent load, and can trigger thread pool exhaustion where incoming requests cannot be processed.

A captive dependency occurs when a service with a shorter lifetime (such as a Scoped Entity Framework Core DbContext) is injected into a service with a longer lifetime (such as a Singleton background worker or cache manager). The short-lived service is effectively 'captured' by the long-lived singleton, causing it to live indefinitely and share state across concurrent requests, leading to severe data corruption and memory leaks. ASP.NET Core prevents this at startup when builder.Host.UseDefaultServiceProvider(options => options.ValidateScopes = true) is enabled, throwing an InvalidOperationException if a singleton attempts to resolve a scoped dependency.

The [ApiController] attribute applies convention-based behaviors tailored specifically for RESTful Web APIs. It automatically enables attribute routing requirements, infers binding sources for action parameters from route data, query strings, or request bodies, and automatically triggers automatic model state validation returning a 400 Bad Request response when validation fails. Standard MVC controllers ([Controller]) are designed for server-side HTML rendering, requiring explicit binding attributes like [FromBody] or [FromQuery] and manual ModelState checks inside action methods.

Global exception handling is implemented by registering the ExceptionHandler middleware in Program.cs via app.UseExceptionHandler(). This middleware catches unhandled exceptions thrown anywhere in the request pipeline and redirects the request to a specified error handling endpoint or executes a lambda expression. Best practices dictate logging the exception details using structured logging frameworks like Serilog and returning a standardized RFC 7807 ProblemDetails JSON response containing a unique trace identifier for client debugging without leaking sensitive stack traces.

Middleware components are assembly classes or inline lambda delegates chained together to form the request pipeline. Each component can inspect, modify, or short-circuit incoming HTTP requests and outgoing responses, passing control to the next component via a RequestDelegate. Execution order is strictly determined by the sequence in which they are registered in Program.cs using methods like app.UseMiddleware<T>() or app.UseRouting(). Incorrect ordering—such as placing authorization middleware before routing—results in security policies failing to evaluate endpoint metadata.

System.Text.Json source generators should be used in high-performance or Native AOT (Ahead-Of-Time) compiled ASP.NET Core applications where startup latency, CPU overhead, and memory allocations must be strictly minimized. Traditional reflection-based serialization inspects object types at runtime, generating metadata overhead and memory allocations. Source generators analyze type structures at compile time, emitting optimized serialization code that eliminates reflection entirely, resulting in significantly faster serialization throughput and compatibility with trimmed native binaries.

Database transactions are typically managed using a Unit of Work pattern combined with Entity Framework Core's native database transaction APIs. Actions or service layers begin a transaction using await dbContext.Database.BeginTransactionAsync(), execute multiple persistence operations, and commit upon success or rollback upon exception. For cross-cutting transaction management without cluttering controller code, developers often implement custom asynchronous action filters or pipeline behaviors via MediatR pipeline decorators.

A CancellationToken allows ASP.NET Core to propagate request abortion signals from Kestrel down through action methods, Entity Framework Core queries, and outbound HttpClient calls. If a client disconnects or aborts an HTTP request while the server is executing a heavy database query or external API call, the cancellation token triggers, aborting the underlying operation immediately. This prevents wasted server CPU cycles, frees up database connection pools, and protects backend infrastructure from processing abandoned work.

Middleware components operate globally across the entire HTTP request pipeline, processing raw HttpContext instances before endpoint routing occurs. Action filters operate within the MVC execution pipeline specifically around controller action invocation, possessing direct access to action arguments, model state, and controller instances via ActionExecutingContext. Middleware is best for cross-cutting infrastructure concerns like authentication and compression, while action filters are ideal for endpoint-specific concerns like request validation, transaction wrapping, and result formatting.