ASP.NET Core middleware runs as an ordered pipeline. Code before next runs on the way toward an endpoint. Code after an awaited next runs as control returns. A component can also stop the pipeline by not calling next.

The search phrase .NET Core interview questions is still common, but modern releases use the name .NET. This example targets ASP.NET Core on .NET 10. It is a local teaching application, not a recommended complete production pipeline.

Can you trace the order?

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Use(async (context, next) =>
{
    Console.WriteLine("A enter");
    await next(context);
    Console.WriteLine("A exit");
});
app.Use(async (context, next) =>
{
    Console.WriteLine("B enter");
    await next(context);
    Console.WriteLine("B exit");
});
app.MapGet("/trace", () =>
{
    Console.WriteLine("Endpoint");
    return Results.Ok("done");
});
app.Run();

For a successful request to /trace, the log order is A enter, B enter, Endpoint, B exit, A exit. Awaiting next matters. If you start downstream work without awaiting it, later code may run before that work completes, and failures become harder to handle correctly.

What is short-circuiting?

A middleware component can write a response and return without invoking the next component. Static file handling, redirects and certain rejection paths can do this. Components later in that branch do not execute for that request.

For a practice variation, add a path check in B that writes “stopped” and returns. A still resumes after its awaited next finishes. The endpoint and B's later statements are skipped if the return happened before them.

Where does exception handling belong?

An exception boundary must surround the downstream work it should catch. Placing it after a component cannot catch an exception thrown before execution reaches it. Put the application's exception handling early enough to cover the intended pipeline.

When you need completion logging even on an exception, use try/finally around awaited next. Do not assume ordinary statements after next always run. Avoid writing a second response after the first response has already started.

Why does authentication order matter?

Authentication establishes the caller's identity. Authorization evaluates access rules using that identity and endpoint information. In an explicitly arranged pipeline, authentication precedes authorization. Routing, CORS, forwarded headers and rate limiting introduce their own requirements.

Do not memorize one universal pipeline for every host. Explain which components depend on routing or identity, then check the framework guidance for the chosen hosting setup. Minimal hosting can add some middleware automatically; explicit placement can still matter.

How would you verify a changed pipeline?

  • Call a successful endpoint and record entry and exit order.
  • Call a deliberately short-circuited path and confirm the endpoint is absent.
  • Trigger a controlled downstream exception and check the error boundary.
  • Check anonymous and authenticated access independently.
  • Inspect status, headers and body rather than only console output.

Use per-request log context in real applications. A global list that mixes concurrent requests is not a reliable trace. Never put credentials or private request bodies into this teaching log.

Interview answer to practice

Explain one request all the way through, including where it can stop and what happens if it throws. That demonstrates the model more clearly than naming middleware methods in an unexplained sequence.

References and next practice

learn.microsoft.com — net middleware

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