.NET Interview Questions — Practice With Real Questions

Minimal APIs, introduced in .NET 6, let you register endpoints directly on IEndpointRouteBuilder via methods like MapGet and MapPost, passing a delegate as the handler. No controller class is needed, unlike the traditional MVC/web-api controller pattern.

Minimal APIs use model binding conventions: a route parameter like {id} is automatically bound to a handler parameter named id (case-insensitive) without explicit attributes, as long as the name matches.

Middleware is registered on the IApplicationBuilder via the Use* family of extension methods (e.g., UseRouting, UseAuthentication, UseAuthorization, UseEndpoints). Add* methods belong to the service-container configuration phase (IServiceCollection), not the pipeline. Map* methods branch the pipeline rather than registering a linear middleware component. There is no standard Configure* extension family for pipeline registration.

app.Run adds a terminal middleware delegate — it receives only the HttpContext (no next parameter) and therefore cannot invoke the next middleware. Execution ends at that delegate, so anything registered after it never runs. app.Use is the method that provides a next delegate for chaining. Map branches the pipeline, and background services are registered via AddHostedService, not app.Run.

The middleware pipeline behaves like a stack (onion model). On the way in, each component's code before await next() executes in the order the components were registered (top-to-bottom). On the way out, after next() returns, each component's remaining code executes in the reverse order (bottom-to-top) as the stack unwinds.

The route template on line 5 defines a parameter named {id}, but the action method parameter on line 6 is named productId. ASP.NET Core binds route values to action parameters by name, so the route value id is never matched to productId, which defaults to 0. Renaming the parameter to int id (or adding [FromRoute(Name = "id")]) fixes the binding.

ASP.NET Core only recognizes the exact token [controller] (with both r's) and replaces it with the controller's name minus the Controller suffix. Because [controler] is misspelled, the framework treats it as a literal path segment, so the actual route becomes api/[controler] — not api/products. The misspelled [controler] option is correct. The other options describe non-existent problems: [ApiController] works fine with attribute routing, [HttpGet] without a template matches the base controller route, and action method names do not need to start with an HTTP verb when attribute routing is used.

The ASP.NET Core MVC filter pipeline defines a fixed stage order for these four filter types: Authorization filters run first (to gate access), then Resource filters (which wrap model binding and the rest of the pipeline), then Action filters (which wrap the action method execution), and finally Result filters (which wrap the action result execution, such as view rendering). Exception filters are intentionally excluded from this ordering because they do not occupy a single linear position — they apply to exceptions thrown during both the action and the result stages, wrapping both rather than sitting between them.

In Minimal APIs, endpoints are registered by calling extension methods like MapGet, MapPost, MapPut, and MapDelete on the WebApplication (or IEndpointRouteBuilder) instance. To handle GET requests at /products you call app.MapGet("/products", handler).

ASP.NET Core MVC processes a request in a fixed sequence: routing first selects the action, then model binding populates parameters, the action method runs and produces an IActionResult, the result executes (which for a ViewResult locates the view), and finally the Razor view is rendered into the response body.

Per the official ASP.NET Core filter pipeline, the 'before' phases execute in this order: authorization filters run first (short-circuiting the rest if denied), then resource filters (wrapping most of the pipeline), then action filters (immediately before the action method), and finally result filters (immediately before the action result executes). Exception filters are triggered only when an unhandled exception occurs and are not part of this sequential 'before' ordering.

MapControllerRoute is an extension method on IEndpointRouteBuilder, typically called on app (the WebApplication) inside the top-level statements of Program.cs. It accepts a route name and a route pattern, making it the standard way to register a named conventional route. By contrast, MapDefaultControllerRoute takes no arguments and uses a hard-coded default pattern, while MapControllers is used for attribute-routed controllers only.

The [Route] attribute is the core attribute-routing marker in ASP.NET Core. Placing it on a controller sets a base template, and placing it on an action method sets (or combines with) that action's template. [HttpGet], [HttpPost], etc. also accept templates but [Route] is the general-purpose attribute for defining a route template regardless of HTTP verb.

The colon syntax inside a route parameter ({param:constraint}) applies a route constraint. int is a built-in constraint that only matches the segment when it can be parsed as an integer. Constraints are evaluated during URL matching; if the segment does not satisfy the constraint, that route is not selected.

Every Minimal API endpoint filter implements IEndpointFilter, which defines one method: ValueTask<object?> InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next). The ValueTask<object?> return type allows the filter to either short-circuit by returning a result directly or call next to continue the pipeline. Knowing the return type is important because it differs from the MVC action-filter Task<IActionResult> pattern.

Results.Ok(...) returns IResult, erasing the payload type at compile time, so the compiler cannot verify that the handler returns the declared shape and OpenAPI cannot infer the response body schema without manual annotations. TypedResults.Ok<T>(value) returns Ok<T>, a concrete generic IResult implementation, giving compile-time type checking on the response payload and enabling automatic OpenAPI response schema generation directly from the handler's return type signature.

app.Run() registers a terminal delegate — it does not receive or call a next, so nothing after it runs (the statement about app.Run() is true). app.Use() provides a Func<HttpContext, RequestDelegate, Task>, letting you call next() (or await next(context) in older APIs) to continue, or omit the call to short-circuit (the statement about app.Use() is true). app.Map performs a path-prefix branch; the matched branch runs to completion and the parent pipeline's subsequent middleware is not executed for those requests (the statement about app.Map is true). Middleware sees the request in registration order but the response in reverse order, so the first-registered component is the last to observe the response on the way back (the statement about middleware execution order is false).

The request path /api/search/hello/2 has two route segments after the controller prefix (hello and 2). The Search action template {query} expects one segment and the GetById action template {id:int} also expects one segment, so neither can match. The Paged action template {query:alpha}/{page:int} matches two segments: "hello" satisfies the :alpha constraint (letters only) and "2" satisfies the :int constraint. Content("P:hello:2") returns that string as the response body with content type text/plain.

Both classes live in Microsoft.AspNetCore.Http and produce the same HTTP 200 response at runtime, but they differ in static typing. TypedResults exposes strongly-typed generic result types (e.g., TypedResults.Ok<TValue>) so the return type of the handler is a concrete closed generic. This lets the Roslyn analyzer infer exact response schemas, enables route handler delegate signature validation at compile time, and produces accurate OpenAPI documents without extra hints. Results returns an IResult whose concrete payload type is not visible in the handler signature, so schema inference falls back to runtime reflection or explicit metadata. The ASP.NET Core team recommends TypedResults for all new Minimal API code for these reasons.

Minimal API endpoint filters follow the same nested-middleware pattern as ASP.NET Core middleware. The first filter registered wraps all subsequent filters and the handler. When the first filter calls next(context), execution enters the second filter, and so on, until the terminal handler runs. On the return path, unwinding happens in reverse order — the last filter's post-handler code runs first, then the second-to-last, and finally the first filter's post-handler code. This means the first-registered filter has the broadest scope (earliest entry, latest exit) and is the correct place for concerns like global exception handling or timing, while the last filter sits closest to the handler.

RequestDelegateFactory is the runtime bridge between a developer-authored lambda and the RequestDelegate that ASP.NET Core's routing infrastructure invokes. It reads the lambda's parameter list, infers each parameter's binding source, generates code to populate parameters from HttpContext, and generates response serialization — all at runtime via reflection and dynamic IL. RequestDelegateGenerator is a separate component (packaged in Microsoft.AspNetCore.Http.RequestDelegateGenerator, not Microsoft.AspNetCore.OpenApi) that performs the same transformation at compile time, emitting static C# into the assembly. This eliminates runtime reflection, makes the code trim-safe, and is required for Native AOT publishing.

UseRouting must precede UseAuthorization because the authorization middleware reads IEndpointMetadataProvider metadata from the matched endpoint. UseAuthentication must precede UseAuthorization so the ClaimsPrincipal is set on HttpContext before authorization evaluates policies. Endpoint middleware (MapGet, MapPost, etc.) is terminal: when a route matches it writes the response and does not call _next, so nothing later in the pipeline runs. UseStaticFiles does not depend on endpoint routing and is conventionally placed early, before UseRouting, for performance; routing does not handle static files, so the claim that UseStaticFiles must be placed after UseRouting is false. UseExceptionHandler should be one of the first components registered so its try/catch wraps every subsequent middleware in the pipeline.

Map creates a branch that does NOT rejoin the main pipeline; it is terminal once entered (the claim that a Map branch rejoins the main pipeline is false). MapWhen similarly creates a terminal branch that does not call back into the main pipeline (the claim that MapWhen branches are terminal is true). UseWhen, by contrast, creates a branch that rejoins the main pipeline — it wraps the remaining pipeline so that after the branch middleware completes, execution continues with the next middleware in the main pipeline (the claim that UseWhen branches rejoin the main pipeline is true). Run registers a terminal middleware delegate that does not receive or call a next delegate (the claim that Run automatically calls await next() is false). When Map matches a path prefix such as "/api", it prepends that segment to Request.PathBase and removes it from Request.Path so branch middleware sees the remainder (the claim about Map splitting Request.Path and Request.PathBase is true).

In Start, TempData["Step"]="Start" and TempData["Count"]=1 are both set (unmarked for deletion) and survive the redirect. In Process, reading TempData["Step"] returns "Start" and marks Step for deletion; reading TempData["Count"] returns "1" and marks Count for deletion. Then TempData["Step"]="Process" reassigns Step, which removes it from the deletion set. TempData.Keep("Count") also removes Count from the deletion set. Both values survive the redirect to Confirm. In Confirm, TempData["Step"] reads "Process" and TempData["Count"] reads "1", so Content writes exactly Step=Process, Count=1.

The middleware pipeline is built as a chain of nested delegates: each Use call receives the next delegate and wraps it. When A calls await next(context), control flows to B; when B calls await next(context), control flows to C. C completes first, then B's post-next code runs, then A's post-next code runs. The first-registered middleware is the first to see the request and the last to see the response, producing strict LIFO ordering on the response path.