Top 60 ASP.NET Interview Questions (2026)

ASP.NET is Microsoft's open-source framework for building web applications, services, and APIs on the .NET runtime, written mostly in C#. It handles routing, request processing, security, and rendering so you focus on your app's logic.

It's used for server-rendered sites (MVC, Razor Pages), REST and gRPC APIs (Web API, Minimal APIs), and real-time apps (SignalR). The modern version is ASP.NET Core, which runs cross-platform.

ASP.NET (the classic version) runs only on Windows on the .NET Framework. ASP.NET Core is a rewrite that runs cross-platform on Windows, Linux, and macOS, is open-source, and is faster.

Core also unifies MVC, Web API, and Razor Pages under one model, has built-in dependency injection, and uses a modern middleware pipeline. All new work targets Core; classic ASP.NET is in maintenance for legacy apps.

Middleware is a component that sits in the request pipeline. Each piece can inspect or change the request, then either pass it to the next component or short-circuit and return a response early.

You register middleware in order with app.Use..., and order matters: exception handling first, then routing, authentication, authorization, and finally your endpoints. Middleware is how logging, CORS, and auth plug in.

The request pipeline is the ordered chain of middleware every HTTP request passes through before a response goes back. A request enters, flows through each middleware in registration order, reaches an endpoint, then flows back out in reverse.

You build it in Program.cs. Common stages: exception handling, HTTPS redirection, static files, routing, authentication, authorization, then endpoint execution.

ASP.NET uses C#, a statically typed, object-oriented language that compiles to run on the .NET runtime. You can also use F# or VB.NET, but C# is the default and by far the most common.

C# gives you strong typing, async/await, LINQ for querying collections, generics, and garbage collection. Knowing the language matters because ASP.NET questions often blend framework and C# concepts.

MVC splits a web app into three parts: the Model (data and business logic), the View (the HTML the user sees), and the Controller (handles requests, calls the model, picks a view). It keeps concerns separated so code stays testable and organized.

In ASP.NET Core, a controller is a class with action methods; routing maps a URL to an action; the action returns a view or data. Web API uses the same controller model but returns data instead of HTML.

A controller is a class that groups related request handlers. An action method is a public method on that controller that responds to a specific route, for example GET /products/5 maps to a Get(int id) action.

Actions return results: a view, JSON, a file, or a status code. Routing decides which action runs based on the URL, HTTP verb, and route templates.

Routing maps an incoming URL to the code that handles it. ASP.NET Core matches the request path and HTTP verb against route templates and picks an endpoint (a controller action, Razor Page, or minimal-API handler).

Attribute routing (putting [Route] and [HttpGet] on actions) is the norm for APIs. Conventional routing (a central pattern like {controller}/{action}/{id?}) is common in MVC views.

Web API is the part of ASP.NET Core for building HTTP services that return data (usually JSON) instead of HTML. It's how you build REST backends for mobile apps, single-page apps, and other services.

Controllers inherit from ControllerBase, carry the [ApiController] attribute, and return data or IActionResult. The framework handles content negotiation, so the same action can return JSON or XML based on the request.

GET retrieves data and should not change server state; its parameters come from the route or query string. POST sends data to create or change something, and its payload comes from the request body.

In ASP.NET Core you mark them with [HttpGet] and [HttpPost]. GET is safe and idempotent by convention; POST is neither, which is why forms and API creates use POST.

Razor is the templating syntax that mixes C# with HTML in .cshtml files using the @ symbol. It renders dynamic HTML on the server, so you can loop over data or show values inline.

Razor Pages is a page-focused model where each page has its own .cshtml view and a PageModel code file. It's simpler than MVC for page-centric sites because the handler lives right next to the markup.

Dependency injection means a class receives the objects it needs (its dependencies) from outside instead of creating them itself. That makes code loosely coupled and easy to test with fakes.

ASP.NET Core has DI built in. You register services in the container, then declare them as constructor parameters and the framework supplies them. No third-party container is needed for most apps.

Program.cs is the entry point. It creates a builder, registers services in the DI container, builds the app, wires up the middleware pipeline, and calls Run() to start the server.

Since .NET 6 it uses minimal hosting: one file, top-level statements, no separate Startup class. The two halves to know are 'add services' (before Build) and 'configure the pipeline' (after Build).

Model binding maps incoming request data onto your action-method parameters. It reads values from the route, query string, form, and request body, then fills in parameters and model objects automatically.

You can guide it with attributes like [FromBody], [FromQuery], and [FromRoute] when the source isn't obvious. With [ApiController], binding sources are inferred for you.

IActionResult is the return type that lets one action return different HTTP responses depending on logic: Ok(data) for 200, NotFound() for 404, BadRequest() for 400, and so on.

It decouples the action from a single result shape. If you always return the same data type you can return that type directly, but IActionResult is right when the status code varies.

Entity Framework Core (EF Core) is Microsoft's object-relational mapper. It maps C# classes to database tables so you query and save data with LINQ and objects instead of writing raw SQL.

You define a DbContext with DbSet properties for each table, then query with LINQ. EF Core translates that to SQL, tracks changes, and saves them when you call SaveChanges.

appsettings.json holds configuration: connection strings, logging levels, feature flags, and app settings, as JSON. ASP.NET Core reads it at startup and merges it with environment variables and other sources.

You read values through the IConfiguration service or, better, bind a section to a typed options class. Environment-specific files like appsettings.Production.json override the base file.

A ViewModel is a class shaped for a specific view or response, carrying exactly the data that screen needs. It keeps your database entities separate from what you send to the UI or client.

Using ViewModels (or DTOs for APIs) avoids over-posting bugs, hides internal fields, and lets the view and the database schema change independently.

Tag Helpers let you write HTML-like tags that the server processes into real markup, so forms, links, and inputs stay readable while binding to your model. asp-for, asp-action, and asp-controller are common ones.

They replace the older HTML Helper methods with cleaner syntax that looks like plain HTML, which designers and editors find easier to read.

200 OK for a successful read, 201 Created after creating a resource, 204 No Content for a successful delete or update with nothing to return, 400 Bad Request for invalid input, 401/403 for auth failures, 404 Not Found for a missing resource, and 500 for server errors.

Returning the right code matters because clients branch on it. Helper methods like Ok(), Created(), NotFound(), and BadRequest() map directly to these.

CORS (Cross-Origin Resource Sharing) is a browser security rule that blocks a page on one origin from calling an API on a different origin unless the API opts in. You hit it when a front-end on one domain calls your API on another.

In ASP.NET Core you register a CORS policy and apply it with middleware, naming the allowed origins, methods, and headers.

Kestrel is the cross-platform web server built into ASP.NET Core. It listens for HTTP requests and hands them to your pipeline. It's fast and runs the same on Windows, Linux, and macOS.

In production Kestrel often sits behind a reverse proxy like IIS, Nginx, or a cloud load balancer that handles TLS termination and static files, though Kestrel can also face the internet directly.

async marks a method that can pause; await pauses at an I/O call (a database query, an HTTP request) and releases the thread back to the pool until the result is ready. That thread serves other requests meanwhile.

The payoff is throughput: one server handles far more concurrent requests because threads aren't blocked waiting on I/O. Use async all the way down and prefer the ...Async methods EF Core and HttpClient provide.

Transient creates a new instance every time the service is requested. Scoped creates one instance per HTTP request, shared within that request. Singleton creates one instance for the entire app lifetime, shared across all requests.

Pick Scoped for things like a DbContext or a per-request unit of work, Singleton for stateless shared services (config, caches), and Transient for lightweight, stateless helpers.

A captive dependency happens when a longer-lived service holds a reference to a shorter-lived one, for example a Singleton that injects a Scoped DbContext. The Scoped service gets captured and effectively becomes a Singleton, living far longer than intended.

That breaks correctness (a DbContext isn't thread-safe and shouldn't outlive a request) and causes subtle data and concurrency bugs. The fix is to resolve the short-lived service per operation, often via IServiceScopeFactory.

Middleware runs top to bottom on the way in and bottom to top on the way out, so a component only sees requests handled after it and responses handled before it. Put things in the wrong order and features silently break.

The classic mistake is calling UseAuthorization before UseAuthentication, or putting UseRouting after the endpoints. Authentication must run before authorization, and routing must run before the endpoints it feeds.

You write a class with an InvokeAsync(HttpContext context) method that does its work, then calls the next delegate to continue the pipeline. Register it with app.UseMiddleware<T>(). For quick cases, an inline app.Use lambda works too.

Custom middleware is the right place for cross-cutting concerns that touch every request: correlation IDs, request logging, custom headers, timing.

Filters run inside the MVC pipeline, around action execution, and have access to MVC context like the action arguments and the result. Types include authorization, resource, action, exception, and result filters. Middleware runs earlier, around the whole request, and only knows about HttpContext.

Use a filter when you need MVC-specific context (validating a model, wrapping a result, catching exceptions per action). Use middleware for things that apply to every request regardless of MVC.

MVC fits large server-rendered apps with many routes and shared views. Razor Pages fits page-focused sites where each page owns its logic. Web API (controllers) fits data services with cross-cutting concerns and many endpoints. Minimal APIs fit small, fast services and microservices with little ceremony.

They share the same runtime, so the choice is about structure and team preference, not capability. A common answer: Razor Pages for content sites, Web API for larger backends, Minimal APIs for lean microservices.

A Minimal API defines endpoints as lambdas directly in Program.cs with app.MapGet, app.MapPost, and so on, no controller class needed. It cuts boilerplate and starts fast, which suits small services.

Controllers give you more structure: attribute conventions, filters, model binding features, and easier organization for large surfaces. Minimal APIs have closed much of that gap but still favor smaller apps.

You annotate model properties with data-annotation attributes ([Required], [Range], [EmailAddress], [StringLength]) and the framework validates incoming data during model binding. ModelState.IsValid tells you the result.

With [ApiController], an invalid model returns a 400 with error details automatically, so you don't check ModelState by hand. For complex rules, implement IValidatableObject or use a library like FluentValidation.

By default EF Core tracks the entities it returns so it can detect changes and save them. That costs memory and setup. AsNoTracking() skips the change tracker, returning entities faster and lighter.

Use tracking when you'll modify and save the entities. Use AsNoTracking for read-only queries, especially list pages and API reads, where you never write the results back.

Eager loading pulls related data in the same query with Include(). Lazy loading fetches related data automatically when you first access the navigation property. Explicit loading loads related data on demand with a manual call.

Eager is usually best because it avoids the N+1 problem, where a loop over parents fires one query per child. Lazy loading is convenient but easy to trigger accidentally in a loop.

The N+1 problem is when loading a list of N parents triggers one extra query per parent to fetch its children, so you run N+1 queries instead of one or two. It quietly kills performance under load.

The fix is eager loading with Include (or a projection with Select) so the related data comes back in a single round trip. Profiling the SQL EF Core generates is how you catch it.

Authentication verifies who you are: checking a token, cookie, or credentials to establish identity. Authorization decides what you're allowed to do: whether that identity can access a resource or action.

In ASP.NET Core, UseAuthentication runs first to set the user identity, then UseAuthorization enforces policies and [Authorize] attributes. Getting them in that order is required.

A JWT (JSON Web Token) is a signed token carrying claims about the user. The client sends it in the Authorization header; the JWT bearer middleware validates the signature and expiry, then builds the user identity from the claims.

You configure it with AddAuthentication().AddJwtBearer(...), setting the issuer, audience, and signing key. JWTs are stateless, so the server doesn't store sessions, which suits APIs and microservices.

[Authorize] blocks a controller or action unless the request is authenticated. Add roles ([Authorize(Roles = "Admin")]) or a named policy to require more than just being logged in. [AllowAnonymous] opts a specific action back out.

Policies are named rules you register in DI, each combining requirements (a claim, a role, custom logic). They keep authorization declarative and reusable instead of scattering checks through action bodies.

The options pattern binds a section of configuration to a strongly typed class, then injects it with IOptions<T>. Instead of reading loose strings from IConfiguration everywhere, you get a typed object with validation.

Use IOptions for values fixed at startup, IOptionsSnapshot for per-request reloads, and IOptionsMonitor for change notifications in singletons. Binding plus validation catches bad config at startup.

ASP.NET Core has a built-in logging abstraction: you inject ILogger<T> and call methods like LogInformation, LogWarning, and LogError. Providers (console, debug, or third-party like Serilog) decide where logs go.

Log levels and filters are set in configuration, so you can raise verbosity in development and quiet it in production. Structured logging (named placeholders) makes logs searchable.

Use exception-handling middleware: UseExceptionHandler points to an error endpoint or a handler that turns exceptions into clean responses. In .NET 8+ you can register an IExceptionHandler for structured handling. This keeps try/catch out of every action.

For APIs, return a consistent ProblemDetails payload so clients get a predictable error shape. UseDeveloperExceptionPage is for development only; never expose stack traces in production.

Creating a new HttpClient per call exhausts sockets under load, and a single static HttpClient doesn't pick up DNS changes. IHttpClientFactory manages a pool of handlers with proper lifetimes, fixing both problems.

It also lets you configure named or typed clients with base addresses, default headers, and resilience policies (retries, timeouts) in one place. It's the recommended way to make outbound HTTP calls.

DbContext should be Scoped: one per request. AddDbContext registers it as Scoped by default. A DbContext isn't thread-safe and tracks changes, so sharing one across requests or threads causes concurrency errors and stale tracking.

For background services or parallel work, create a fresh context per unit of work, often via a DbContextFactory. Never make a DbContext a Singleton.

Value types (int, bool, struct, enum) hold their data directly and copy by value on assignment. Reference types (class, string, array, most objects) hold a reference to data on the heap and copy the reference, so two variables can point at the same object.

This shows up in ASP.NET when a mutation to a passed object is visible to the caller, and in nullability: reference types can be null, which is why nullable reference types and null checks matter for avoiding NullReferenceException.

The generic host boots the app, builds the DI container, and starts Kestrel. Kestrel accepts a connection, parses the HTTP request into an HttpContext, and runs it through the middleware pipeline. Routing selects an endpoint, the endpoint executes, and the response flows back out.

In front of Kestrel there's often a reverse proxy (IIS with the ASP.NET Core Module, Nginx, or a cloud LB) doing TLS and load balancing. Knowing where forwarded headers, TLS termination, and process lifetime fit is the senior detail.

In classic ASP.NET, blocking on an async call (calling .Result or .Wait() from a request thread) could deadlock because the captured synchronization context needed that same thread to resume. ASP.NET Core has no synchronization context, so that specific deadlock is gone.

The rule still holds: don't block on async code. Use async all the way down. ConfigureAwait(false) matters in libraries to avoid capturing a context, though in ASP.NET Core app code it has little effect since there's no context to capture.

Endpoint routing runs UseRouting to match the request to an endpoint early, stores the chosen endpoint on the HttpContext, then lets middleware between routing and the endpoint (like authorization) inspect metadata such as [Authorize] before the endpoint executes at UseEndpoints or MapControllers.

The split exists so authorization and other middleware can make decisions based on which endpoint was matched without running it. That's why UseAuthorization sits between UseRouting and the endpoint mapping.

Response caching stores full responses keyed by URL and headers, good for anonymous GETs. Output caching (added in .NET 7) is a more controllable server-side cache with tag-based invalidation. IMemoryCache caches arbitrary objects in process; IDistributedCache (Redis, SQL) shares a cache across instances.

The judgment call: in-memory for single-instance or per-node data, distributed for scaled-out apps that must share state, and HTTP response or output caching for cacheable endpoints. Always plan invalidation before adding a cache.

Keep the app stateless so any instance can serve any request: no in-memory session tied to one node, no local file state. Move session and cache to a distributed store (Redis), put shared files in blob storage, and let a load balancer spread traffic.

Data protection keys (used for cookies and antiforgery) must be shared across instances too, or cookies issued by one node fail on another. That shared-keyring detail is a common production gotcha worth naming.

When the default binding can't express your input: parsing a composite value from multiple sources, decoding a custom header or token into a rich object, or binding a format the framework doesn't handle. You implement IModelBinder and register it via a provider or [ModelBinder] attribute.

The honest answer includes reaching for simpler options first: a [FromBody] DTO plus a small mapping, or a TypeConverter, often solves the problem without a full custom binder.

Generate migrations in development with dotnet ef migrations add, The generated SQL, and apply them as a deliberate deploy step: an idempotent SQL script run by your pipeline, or a controlled migration bundle, rather than auto-migrating on app startup matters.

For zero-downtime, use expand-and-contract: add nullable columns and new tables first, deploy code that writes both old and new, backfill, then drop the old shape in a later migration. Auto-migrate-on-startup is fine for demos, risky for real traffic.

Use optimistic concurrency: add a rowversion or concurrency token to the entity. EF Core includes it in the UPDATE's WHERE clause, so if another transaction changed the row first, zero rows update and EF throws DbUpdateConcurrencyException, which you catch and resolve.

Resolution options are last-write-wins, first-write-wins, or merging and re-prompting the user. Pessimistic locking (SELECT FOR UPDATE) is the alternative when conflicts are frequent, at the cost of throughput.

Implement IHostedService or derive from BackgroundService for long-running loops, registered with AddHostedService. The host starts and stops them with the app. Inside, create a DI scope per unit of work to resolve scoped services like DbContext.

For real queues and retries, hand work to a durable queue (a message broker or a library like Hangfire) rather than an in-process loop, because an in-process worker dies with the process and loses unstarted work.

Add the API versioning package and pick a strategy: URL segment (/v1/products), a query string, or a header. URL versioning is the most visible and cache-friendly; header versioning keeps URLs clean but is harder to test by hand.

The point is a contract: existing clients keep working when you ship v2. Pair versioning with a deprecation policy and clear docs so old versions eventually retire.

gRPC uses HTTP/2 and Protocol Buffers, giving you a strict contract, smaller payloads, streaming, and lower latency, which suits service-to-service calls inside your own system. REST with JSON wins for public APIs, browser clients, and easy human debugging.

The trade-off is reach and tooling: gRPC needs code generation and isn't natively callable from browsers without gRPC-Web, while REST works everywhere. Pick gRPC for internal high-throughput links, REST for broad external consumption.

SignalR is ASP.NET Core's library for real-time, two-way communication between server and clients: chat, live dashboards, notifications. Clients to a hub, and the server can push messages connects to one client, a group, or everyone.

It negotiates the best transport, preferring WebSockets and falling back to server-sent events or long polling. For scale-out across servers, you add a backplane (Redis or Azure SignalR) so a message on one node reaches clients connected to another.

Three pillars: structured logging (ILogger with a sink like Serilog or OpenTelemetry), metrics (request rate, latency, error rate via OpenTelemetry or Prometheus), and distributed tracing so a request can be followed across services. Add health checks (AddHealthChecks) for liveness and readiness probes.

The goal is to answer 'is it up, is it slow, and why' without redeploying. Correlation IDs threaded through logs and traces are what tie a single user's request together across the system.

Parameterized queries or EF Core stop SQL injection; Razor's automatic encoding and a Content Security Policy blunt XSS; antiforgery tokens defend cookie-based forms against CSRF; enforce HTTPS with HSTS; and validate and bind input with DTOs to prevent over-posting.

Beyond code: keep secrets out of the repo (secret managers, not appsettings), patch dependencies, set security headers, and apply least-privilege on the database account. Naming the attack and its specific mitigation is what this question checks.

A middleware short-circuits by writing a response and not calling the next delegate, so nothing further in the pipeline runs. Rate limiting, a cached-response hit, an auth rejection, or a maintenance gate all short-circuit deliberately.

The care point is ordering and cleanup: short-circuiting before authentication skips it entirely, and any using or logging that wraps next won't see the request the way you expect. Short-circuit on purpose, near the top, with a clear response.

Unit-test business logic in isolation with a framework like xUnit and mocks for dependencies. Integration-test the real pipeline with WebApplicationFactory<T>, which spins up an in-memory server so you can send HTTP requests and assert on responses, routing, auth, and serialization end to end.

The judgment is where to draw the line: mock external boundaries (payment gateways, email), but use a real or in-memory database for integration tests so EF Core mappings and migrations are exercised. Test behavior, not implementation.

Observe first: check logs, metrics, and traces around the slow or failing path, and correlate with recent deploys. Is it CPU, memory, blocked threads, or waiting on a downstream (database, external API)? Thread-pool starvation from blocking async is a common culprit; N+1 queries and missing timeouts are others.

Then reproduce at a smaller scale, form a hypothesis, fix at the right layer, and confirm with a measurement. The structure, observe, hypothesize, verify, fix, confirm, matters more than any single tool.