ASP.NET Core Interview Questions

A curated set of ASP.NET Core interview questions covering the middleware pipeline, API styles, and dependency injection as they actually come up in technical interviews.

Middleware#

Q: Why does middleware order matter in ASP.NET Core? Each middleware wraps the rest of the pipeline: it can act before calling next() (on the way in) and after it returns (on the way out). Registering UseAuthorization() before UseRouting(), for example, means there's no matched endpoint yet to authorize against, so the check is meaningless — the documented, correct order (routing, then auth, then endpoint mapping) exists for exactly this reason.

Q: What's the difference between app.Use(...) and app.Run(...) in the middleware pipeline? app.Use(...) registers middleware that can call next() to continue the pipeline — it's a link in the chain. app.Run(...) (as a middleware registration, not the final app.Run() that starts the app) registers terminal middleware that never calls anything further — it always ends the pipeline there, so anything registered after it never executes.

API styles#

Q: When would you choose minimal APIs over MVC controllers, or vice versa? Minimal APIs suit small services, microservices, and simple CRUD endpoints where the low ceremony of an inline lambda per route is a net win. Controllers suit larger APIs with many related endpoints that benefit from shared conventions, filters, and the extra structure of full attribute routing — and tend to be easier to unit test as their own classes. Both run on the same underlying routing engine, so the choice is about project shape and team preference, not capability.

Q: What does the [ApiController] attribute actually change? It enables a bundle of API-oriented conventions: automatic 400 Bad Request responses when model validation fails (without writing that check yourself), requiring attribute-based routing instead of conventional routing, and inferring binding sources ([FromBody], [FromRoute], [FromQuery]) for action parameters automatically.

Dependency injection#

Q: How does dependency injection work in an ASP.NET Core controller? Controllers are resolved from the same IServiceCollection/IServiceProvider container used everywhere else in the app. Any service registered in Program.cs (builder.Services.Add...) can simply be added as a constructor parameter on a controller, and the framework supplies it automatically when it creates that controller instance to handle a request — no manual wiring needed.

Q: What HTTP request scope does a Scoped service correspond to in ASP.NET Core? Exactly one incoming HTTP request. A Scoped service is created once for that request (shared by every class asked for it while handling that request, including nested dependencies) and disposed at the end of it — the next request gets a brand-new instance.

Authentication, authorization, and deployment#

Q: What's the practical difference between cookie authentication and JWT bearer authentication? Cookie authentication is sent automatically by the browser and fits same-origin, server-rendered apps, but needs CSRF protection and typically some server-side session state. JWT bearer authentication is a self-contained, stateless token the client attaches manually to the Authorization header on each request — the usual choice for SPAs, mobile clients, and service-to-service calls, though revoking a single token before it expires is inherently harder than just deleting a cookie/session.

Q: What's the difference between a bare [Authorize] attribute and [Authorize(Roles = "Admin")]? A bare [Authorize] only requires the caller to be authenticated at all — any signed-in user satisfies it. Adding Roles (or Policy) layers an additional authorization requirement on top, rejecting an authenticated caller who doesn't hold the specified role, typically with a 403 Forbidden rather than a 401.

Q: Why does a production ASP.NET Core deployment typically put Kestrel behind a reverse proxy like Nginx or IIS? Kestrel can serve internet traffic directly, but a reverse proxy centralizes TLS certificate management, lets several applications share one public port, and provides connection hardening already solved at the proxy layer — along with the ability to see the app's real health via a /health endpoint the proxy or an orchestrator can poll independently of raw connectivity.