ASP.NET Core interview questions

What a strong answer covers

• Define Middleware as components in the request pipeline, operating on `HttpContext` for all requests or specific paths, before and after the MVC/Razor Pages execution.
• Define Action Filters as attributes applied to controllers or actions, operating within the MVC pipeline, with access to `ActionContext` and `ControllerContext`.
• Highlight key differences: Middleware operates at a lower level (HTTP request/response), Filters operate at a higher level (MVC action execution). Middleware can short-circuit the pipeline, Filters can modify action arguments or results.
• Provide use cases: Middleware for cross-cutting concerns like logging, error handling, authentication, static files, routing. Filters for concerns specific to MVC actions like input validation, caching, authorization (e.g., `[Authorize]`), or modifying action results.
• Discuss how they can sometimes overlap (e.g., authorization can be done with both) but generally serve different purposes based on the scope of concern.

Where people lose the point

• ×Confusing their execution order or scope, e.g., thinking a filter runs before any middleware.
• ×Suggesting filters for concerns that apply to all requests regardless of MVC context (e.g., global logging).
• ×Not understanding that middleware has access to the raw `HttpContext` while filters operate on a more structured MVC context.

What a strong answer covers

• **Singleton**: A single instance of the service is created and shared across all requests and all users throughout the application's lifetime. Registered with `AddSingleton()`.
• **Scoped**: A new instance of the service is created once per client request (or scope). Within the same request, the same instance is reused. Registered with `AddScoped()`.
• **Transient**: A new instance of the service is created every time it is requested from the DI container. Registered with `AddTransient()`.
• Provide examples: Singleton for configuration objects, logging services, or in-memory caches. Scoped for `DbContext` instances in EF Core, or services that hold request-specific data. Transient for lightweight, stateless services that perform a single operation, like a simple data converter.

Where people lose the point

• ×Incorrectly stating that Scoped means one instance per user session (it's per request).
• ×Using Singleton for services that hold mutable, request-specific state, leading to concurrency issues.
• ×Using Transient for heavy objects that are frequently requested, leading to performance overhead.

What a strong answer covers

• `IActionResult` is an interface that represents the result of an action method. It allows an action to return various types of responses (e.g., `OkResult`, `NotFoundResult`, `BadRequestResult`, `JsonResult`, `ViewResult`), providing flexibility in controlling HTTP status codes and response bodies.
• `ActionResult<T>` is a union type introduced in ASP.NET Core 2.1. It allows an action method to return either an `IActionResult` (for status codes like 404, 400) or a specific type `T` (for successful 200 OK responses with a strongly typed body).
• Key difference: `ActionResult<T>` provides compile-time type safety for the success case, making it clearer what data type is expected in a successful response, while still allowing for `IActionResult` for error cases. `IActionResult` is more general and doesn't enforce a specific return type for success.
• Choose `IActionResult` when: you need maximum flexibility, your action might return many different types of results (e.g., a file, a redirect, various error types), or you're working with older ASP.NET Core versions. Choose `ActionResult<T>` when: you want compile-time type safety for successful responses, you primarily return a specific data model on success, and you want to leverage automatic OpenAPI/Swagger documentation generation more effectively.

Where people lose the point

• ×Believing `ActionResult<T>` completely replaces `IActionResult` (it still uses `IActionResult` internally for non-`T` results).
• ×Not understanding the compile-time type safety benefit of `ActionResult<T>`.
• ×Incorrectly stating that `IActionResult` cannot return data (it can, e.g., `JsonResult`).

What a strong answer covers

• ASP.NET Core uses a flexible configuration system built on key-value pairs, accessible via the `IConfiguration` interface. It aggregates settings from multiple sources, with later sources overriding earlier ones.
• **JSON File Provider**: Reads configuration from `.json` files (e.g., `appsettings.json`, `appsettings.Development.json`). Used for application-specific settings, environment-specific overrides, and structured data.
• **Environment Variables Provider**: Reads configuration from environment variables. Crucial for production deployments, containerized applications (Docker, Kubernetes), and CI/CD pipelines to inject environment-specific settings without rebuilding.
• **Command-line Arguments Provider**: Reads configuration from arguments passed when launching the application. Useful for quick overrides during development, debugging, or for specific deployment scenarios.
• Other providers: User Secrets (for development-time secrets), Azure Key Vault (for production secrets), XML/INI files, custom providers. The system is designed for extensibility and hierarchical configuration.

Where people lose the point

• ×Not understanding the hierarchical nature and override behavior of configuration sources.
• ×Suggesting storing sensitive production secrets directly in `appsettings.json`.
• ×Not mentioning the `IConfiguration` interface as the primary access point.

What a strong answer covers

• **Authentication** is the process of verifying a user's identity. It answers the question: 'Who are you?'. This typically involves checking credentials (username/password, token, certificate) against a stored identity.
• **Authorization** is the process of determining what an authenticated user is allowed to do. It answers the question: 'What can you do?'. This involves checking permissions, roles, or policies against the requested resource or action.
• Authentication must always happen before authorization. You cannot determine what someone can do if you don't know who they are.
• In ASP.NET Core, authentication is handled by authentication middleware (e.g., `app.UseAuthentication()`), while authorization is handled by authorization middleware (`app.UseAuthorization()`) and attributes like `[Authorize]`.

Where people lose the point

• ×Confusing the two concepts or using them interchangeably.
• ×Stating that authorization happens before authentication.
• ×Not being able to provide clear examples of each (e.g., login is authentication, checking if an admin can delete a user is authorization).

What a strong answer covers

• Model Binding is the process by which ASP.NET Core maps data from HTTP requests (e.g., route data, query strings, form fields, request body) to action method parameters or properties of a model object.
• It works by inspecting the action method's parameters and then searching for values in various request sources in a predefined order (e.g., route values, query string, form data, request body). It attempts to convert these string values into the target C# types.
• Benefits include: automatic data conversion (e.g., string to int, date), reduced boilerplate code for manually parsing request data, improved type safety, and integration with validation (e.g., `[Required]`, `[Range]`).
• It supports complex types, collections, and can be customized with attributes like `[FromQuery]`, `[FromBody]`, `[FromRoute]` to specify the source of the data.

Where people lose the point

• ×Thinking model binding only works for simple types or only from the request body.
• ×Not understanding that it handles type conversion automatically.
• ×Failing to mention its role in reducing manual parsing code.

What a strong answer covers

• **HTML Helpers** are C# methods (e.g., `@Html.TextBoxFor()`, `@Html.ActionLink()`) that generate HTML markup. They are invoked as methods within Razor views.
• **Tag Helpers** are server-side components that participate in creating and rendering HTML elements in Razor files. They look like standard HTML tags or attributes (e.g., `<input asp-for="Name" />`, `<a asp-controller="Home" asp-action="Index">`).
• **Key Differences**: Tag Helpers are more natural to HTML, improving readability and allowing front-end developers to work on views without deep C# knowledge. They offer better tooling support (IntelliSense) and can be composed more easily. HTML Helpers are C# methods, which can sometimes lead to less readable markup due to the mix of C# and HTML.
• **Preference**: Tag Helpers are generally preferred in modern ASP.NET Core development due to their HTML-friendly syntax, improved readability, and better integration with front-end workflows. HTML Helpers might still be used for very complex or highly dynamic scenarios where the programmatic control of C# methods is more suitable, or in legacy projects.

Where people lose the point

• ×Believing Tag Helpers are client-side JavaScript components.
• ×Not recognizing the readability and tooling benefits of Tag Helpers.
• ×Stating that HTML Helpers are deprecated (they are still supported, just less preferred).

What a strong answer covers

• A `DbContext` represents a session with the database and is responsible for querying and saving entity instances. It tracks changes to entities and manages the unit of work.
• In ASP.NET Core, `DbContext` instances are typically registered as **Scoped** services using `services.AddDbContext<T>()`. This means a new `DbContext` instance is created for each HTTP request and disposed of at the end of that request.
• **Lifecycle**: 1. Request starts. 2. DI container creates a new `DbContext` instance for the request. 3. `DbContext` is injected into controllers/services. 4. Database operations (queries, saves) are performed using this instance. 5. Request ends. 6. The `DbContext` instance is disposed of, releasing database connections and clearing its change tracker.
• **Why Scoped?**: This lifecycle prevents common issues like stale data (if a Singleton `DbContext` were used across many requests), memory leaks (if entities accumulate in a long-lived `DbContext`), and concurrency problems. Each request gets its own isolated unit of work, ensuring data consistency and proper resource management.

Where people lose the point

• ×Suggesting `DbContext` should be Singleton or Transient, without understanding the implications.
• ×Not mentioning the `DbContext`'s role as a unit of work and change tracker.
• ×Failing to explain the problems (stale data, memory leaks, concurrency) that a Scoped lifetime helps avoid.

What a strong answer covers

• **Kestrel** is a cross-platform web server for ASP.NET Core. It's lightweight, fast, and built on libuv (or Sockets in .NET Core 3.0+), making it highly performant. It's the default web server that hosts ASP.NET Core applications.
• In a production environment, Kestrel is typically run behind a **reverse proxy server** like IIS (on Windows) or Nginx/Apache (on Linux).
• **Interaction**: The reverse proxy receives client requests, forwards them to Kestrel, and then receives responses from Kestrel to send back to the client. This setup is called a 'reverse proxy configuration'.
• **Reasons for Reverse Proxy**: 1. **Security**: The reverse proxy can handle SSL termination, DDoS protection, and expose only necessary ports. 2. **Load Balancing**: Distribute requests across multiple Kestrel instances. 3. **Static File Serving**: Efficiently serve static content (images, CSS, JS) without involving Kestrel. 4. **Logging/Monitoring**: Centralized logging and monitoring. 5. **Process Management**: The reverse proxy can manage the Kestrel process, restarting it if it crashes.

Where people lose the point

• ×Believing Kestrel is only for development and cannot be used in production (it can, but usually with a reverse proxy).
• ×Not understanding the role of the reverse proxy in handling external requests and forwarding them.
• ×Failing to mention key benefits of using a reverse proxy (security, load balancing, static files).

What a strong answer covers

• ASP.NET Core Health Checks provide a way to monitor the health and availability of an application and its dependencies (e.g., databases, external APIs, message queues).
• They are implemented as middleware that exposes an endpoint (e.g., `/health`) which returns a status (Healthy, Degraded, Unhealthy) based on custom checks.
• **Importance**: 1. **Monitoring**: Used by monitoring systems (e.g., Prometheus, Azure Monitor) to track application status. 2. **Orchestration**: Container orchestrators (Kubernetes, Docker Swarm) use them for liveness and readiness probes to determine if an instance should receive traffic or be restarted. 3. **Troubleshooting**: Quickly diagnose issues with dependencies or the application itself. 4. **Load Balancing**: Remove unhealthy instances from a load balancer's pool.

Where people lose the point

• ×Confusing health checks with application logging or error handling (they are distinct monitoring tools).
• ×Not understanding their role in container orchestration and load balancing.
• ×Failing to mention that they can check external dependencies, not just the application itself.

What a strong answer covers

• Minimal APIs, introduced in .NET 6, provide a simplified way to build HTTP APIs with minimal dependencies and boilerplate code. They allow developers to define API endpoints directly in the `Program.cs` file using `app.MapGet()`, `app.MapPost()`, etc., without requiring controllers or explicit routing attributes.
• **Advantages**: 1. **Reduced Boilerplate**: Less code to write for simple APIs, leading to faster development. 2. **Improved Performance**: Potentially faster startup times and lower memory footprint due to fewer abstractions. 3. **Simplicity**: Easier to learn and understand for new developers or for building microservices with focused functionality. 4. **Flexibility**: Still supports dependency injection, authentication, authorization, and other ASP.NET Core features.
• **Use Cases**: Ideal for building small, focused microservices, serverless functions, or simple HTTP APIs where the full MVC controller pattern might be overkill. They are well-suited for scenarios where you need to expose a few endpoints quickly and efficiently.

Where people lose the point

• ×Believing Minimal APIs replace MVC controllers entirely (they are an alternative, not a replacement).
• ×Not understanding that they still leverage core ASP.NET Core features like DI and middleware.
• ×Suggesting them for highly complex APIs with many actions, views, and intricate business logic where MVC might still be more organized.

What a strong answer covers

• Global error handling ensures that unhandled exceptions are caught and processed gracefully, preventing sensitive information from being exposed and providing a consistent user experience.
• **1. `UseExceptionHandler` Middleware**: This is a common approach for production environments. You configure it in `Program.cs` (or `Startup.cs`) to catch exceptions and redirect to a specific error handling path (e.g., `/Error`). This path can then render a user-friendly error page or return a generic error API response. It's placed early in the pipeline to catch exceptions from subsequent middleware.
• **2. `UseDeveloperExceptionPage` Middleware**: This middleware is designed for development environments. It provides detailed exception information, including stack traces and request details, directly in the browser. It should *never* be used in production due to security risks. It's typically conditionally enabled using `if (app.Environment.IsDevelopment())`.
• **3. Custom Error Handling Middleware**: For more advanced or specific error handling logic, you can create your own custom middleware. This allows you to log exceptions, transform them into specific HTTP responses (e.g., Problem Details for APIs), or integrate with external error reporting services. This middleware would also be placed early in the pipeline.

Where people lose the point

• ×Using `UseDeveloperExceptionPage` in production.
• ×Not understanding the importance of placing error handling middleware early in the pipeline.
• ×Failing to mention the security implications of exposing raw exception details.

What a strong answer covers

• **Purpose**: Custom middleware allows you to inject application-specific logic into the request pipeline, such as logging, authentication, or request/response modification.
• **Structure**: A custom middleware class typically has: 1. A constructor that accepts `RequestDelegate` (the next middleware in the pipeline). 2. An `InvokeAsync` method that takes `HttpContext` and performs the middleware's logic. This method must call `_next(context)` to pass control to the next middleware, or short-circuit the pipeline.
• **Example Code**: Provide a simple example, e.g., a logging middleware that logs request path and execution time. Show the class definition and the `InvokeAsync` method.
• **Extension Method**: Explain that it's good practice to create an extension method on `IApplicationBuilder` (e.g., `app.UseMyCustomMiddleware()`) to make the middleware easy to register in `Program.cs`.
• **Registration**: Demonstrate how to register the custom middleware in `Program.cs` using `app.UseMyCustomMiddleware()`.

Where people lose the point

• ×Forgetting to inject `RequestDelegate` into the constructor or call `_next(context)` in `InvokeAsync`.
• ×Not understanding the `HttpContext` object as the primary way to interact with the request/response.
• ×Failing to explain the importance of the extension method for clean registration.

What a strong answer covers

• **Goal**: Unit testing controllers focuses on testing the controller's logic in isolation, without involving the full ASP.NET Core pipeline, database, or external services.
• **Principles**: 1. **Isolation**: Use mock objects or fakes for all dependencies (e.g., services injected via DI, `DbContext`, `IConfiguration`). 2. **Arrange-Act-Assert (AAA)**: Structure tests clearly. 3. **Focus**: Test one piece of functionality per test method.
• **Tools**: Use a testing framework (e.g., xUnit, NUnit, MSTest) and a mocking library (e.g., Moq, NSubstitute).
• **Steps**: 1. **Instantiate Controller**: Create an instance of the controller under test. 2. **Mock Dependencies**: Create mock objects for all services the controller depends on. 3. **Set up Mocks**: Configure mock objects to return specific values or throw exceptions when their methods are called. 4. **Set up `ControllerContext` (if needed)**: For features like `User` or `ModelState`, you might need to set up `ControllerContext` or `HttpContext` properties. 5. **Invoke Action**: Call the controller action method. 6. **Assert Results**: Verify the returned `IActionResult` (e.g., `OkObjectResult`, `NotFoundResult`), its status code, and the data it contains. Also, verify that mock methods were called as expected.

Where people lose the point

• ×Attempting to test the full HTTP pipeline or database interactions in a unit test (these are integration tests).
• ×Not using a mocking framework effectively or creating manual fakes that are too complex.
• ×Failing to assert both the type of `IActionResult` and the data within it.

What a strong answer covers

• **Problem without async/await**: When a controller action performs a synchronous I/O-bound operation (e.g., database query, external API call), the thread handling that request is blocked until the operation completes. This thread cannot serve other requests, leading to thread pool exhaustion and reduced scalability under heavy load.
• **How async/await helps**: When an `await` keyword is encountered in an `async` method, the thread is *returned to the thread pool* to handle other incoming requests. Once the awaited I/O operation completes, a thread (not necessarily the original one) picks up execution from where it left off.
• **Benefits**: 1. **Scalability**: Frees up threads to handle more concurrent requests, significantly improving application throughput and responsiveness under load. 2. **Resource Utilization**: Makes more efficient use of server resources by not blocking threads unnecessarily. 3. **Responsiveness**: While not directly impacting client-side responsiveness for a single request, it ensures the server remains responsive to *all* clients.
• **When to use**: Primarily for I/O-bound operations (database access, network calls, file I/O). It's generally not beneficial for CPU-bound operations unless offloaded to a separate thread pool.

Where people lose the point

• ×Believing `async/await` makes an operation faster (it doesn't, it just makes the server more scalable).
• ×Using `async/await` for purely CPU-bound operations without offloading, which can sometimes add overhead without benefit.
• ×Mixing `async` and synchronous code (e.g., `Task.Result` or `Task.Wait()`) which can lead to deadlocks or negate the benefits.

What a strong answer covers

• **CORS (Cross-Origin Resource Sharing)** is a security mechanism implemented by web browsers that restricts web pages from making requests to a different domain than the one that served the web page. This prevents malicious scripts from making unauthorized requests to other sites.
• When a web application (e.g., a JavaScript SPA) running on `domain-a.com` tries to make an HTTP request to an API on `domain-b.com`, the browser will block the request unless `domain-b.com` explicitly allows it via CORS headers.
• **Configuration in ASP.NET Core**: 1. **Add CORS services**: In `Program.cs` (or `Startup.cs`), call `services.AddCors()` to register the CORS services. 2. **Define CORS policies**: Use `services.AddCors(options => { options.AddPolicy("MyAllowSpecificOrigins", builder => { builder.WithOrigins("http://example.com", "http://www.contoso.com").AllowAnyHeader().AllowAnyMethod(); }); });` to define one or more policies specifying allowed origins, headers, and methods. 3. **Enable CORS middleware**: Call `app.UseCors()` in `Program.cs` (or `Startup.cs`) to add the CORS middleware to the request pipeline. This middleware must be placed after `UseRouting()` and before `UseAuthorization()`.
• You can apply policies globally or specifically to controllers/actions using the `[EnableCors("MyAllowSpecificOrigins")]` attribute.

Where people lose the point

• ×Not understanding that CORS is a browser-side security feature, not a server-side one that prevents requests from reaching the server.
• ×Forgetting to add both `services.AddCors()` and `app.UseCors()`.
• ×Placing `app.UseCors()` in the wrong order in the middleware pipeline (it needs to be after routing but before authorization).