Entry .NET Core Interview Questions

One class derives behavior from another using 

class Dog : Animal { }

ASP.NET Core is a modern, high-performance, cross-platform framework for building web applications and APIs that can run on Windows, Linux, and macOS.

It was created to overcome limitations of the old ASP.NET Framework such as heavy runtime dependency on the full .NET Framework, tight coupling to IIS, poor modularity, and difficulty integrating with modern CI/CD and containerized environments.

ASP.NET Core introduces a lightweight runtime, a fully modular component system, built-in dependency injection, a unified hosting model, and a redesigned request pipeline focused on speed, flexibility, and cloud readiness.

ASP.NET Core uses a unified Host (Generic Host / Web Host) that wires together configuration, logging, dependency injection, environment, and the HTTP pipeline.

• The host sets up configuration (appsettings, environment variables, command line, etc.).
• It constructs the DI container and registers application services.
• It configures and starts Kestrel as the web server.
• It builds the middleware pipeline and endpoint routing (MVC, Razor Pages, minimal APIs).

The high-level flow is: Host ? Kestrel ? Middleware pipeline ? MVC / Razor ? View or JSON result. This gives full low-level control over startup and behavior.

Kestrel is the built-in, cross-platform, high-performance web server for ASP.NET Core.

It is optimized for asynchronous I/O, low memory overhead, and extremely fast request handling, making it suitable for both self-hosted scenarios and running behind reverse proxies such as Nginx, Apache, or IIS.

ASP.NET Core uses Kestrel because it delivers excellent throughput, works on all supported platforms, integrates deeply with the middleware pipeline, and gives developers full control over how requests are processed.

Middleware are components that process HTTP requests and responses in a sequence known as the request pipeline.

• Each middleware can inspect or modify the incoming request.
• It may call the next middleware in the pipeline or short-circuit and generate a response.
• On the way back, it can also modify the outgoing response.

The pipeline is used to implement cross-cutting concerns such as authentication, logging, routing, static file handling, CORS, and endpoint execution. This model replaces the older HTTP modules/handlers, offering a more flexible and composable design.

Middleware executes in the exact order in which it is registered. Because each middleware can decide whether to pass control to the next component, incorrect ordering can break critical behaviors.

For example:

• Exception-handling middleware must be early in the pipeline to catch downstream errors.
• Authentication must run before authorization and MVC.
• Static file middleware should run before MVC to avoid unnecessary controller execution.

ASP.NET Core does not automatically correct the order, so developers are responsible for composing the pipeline correctly.

Dependency Injection (DI) in ASP.NET Core is the built-in mechanism for constructing and wiring application services.

The framework provides a first-class DI container that:

• Creates and manages service lifetimes.
• Resolves dependencies for controllers, Razor Pages, middleware, and other components.
• Encourages testable, loosely coupled code.

Having DI built-in removes the need for static helpers or service locators and standardizes how dependencies are managed across the whole stack.

ASP.NET Core's DI container supports three main lifetimes:

• Transient – A new instance is created every time it is requested. Best for lightweight, stateless services.
• Scoped – One instance per HTTP request. Ideal for services that work with per-request data such as unit-of-work or context services.
• Singleton – A single instance is created and shared for the lifetime of the application. Must be thread-safe and used carefully around shared state.

Choosing the wrong lifetime can lead to concurrency bugs, memory leaks, or stale data.

ASP.NET Core uses a flexible, layered configuration system where multiple providers are combined to produce the final configuration.

Common sources include:

• appsettings.json and appsettings.{Environment}.json
• Environment variables
• Command-line arguments
• User Secrets and Azure Key Vault
• In-memory configuration

Later providers override earlier ones, enabling environment-specific overrides and secure storage of secrets. Configuration values can be bound directly to strongly typed options classes.

These abstractions implement the Options pattern for working with configuration-bound classes.

• IOptions<T> – A singleton snapshot of configuration, read once at startup.
• IOptionsSnapshot<T> – A scoped snapshot that is recalculated per request; useful for web apps where config might change between requests.
• IOptionsMonitor<T> – Supports change notifications and is ideal for long-lived components that need to react to configuration changes at runtime.

They allow strongly typed configuration without scattering configuration reads throughout the codebase.

Routing maps incoming HTTP requests (URL + HTTP method) to application endpoints such as controllers, actions, Razor Pages, or minimal APIs.

ASP.NET Core uses Endpoint Routing, which matches routes early in the pipeline, attaches metadata (like authorization policies), and then later executes the matched endpoint. It supports route templates, constraints, defaults, and custom route patterns.

Conventional routing defines route patterns centrally (e.g., {controller}/{action}/{id?}), which are then applied to many controllers and actions following a naming convention. It is useful for large apps with predictable URL structures.

Attribute routing defines routes directly on controllers and actions via attributes such as [Route], [HttpGet], etc. It is more expressive and better suited for APIs or scenarios where each endpoint may have unique or non-standard URL patterns.

Model binding is the process of converting HTTP request data into .NET objects that are used as parameters to controller actions or Razor Page handlers.

It pulls values from sources like route data, query strings, form fields, headers, and cookies, then converts and populates complex types, collections, and nested objects. This lets you work with rich, strongly typed parameters instead of manually parsing the request.

Model validation runs immediately after model binding and before the action method executes.

• Validation rules are typically expressed via data annotations (e.g., [Required], [Range]).
• Errors are added to ModelState.
• Controllers or Razor Pages check ModelState.IsValid to decide whether to continue or return validation errors.

Validation can also be implemented via IValidatableObject or custom validators, ensuring that only valid data reaches business logic.

Filters are extensibility points in the MVC and Razor Pages pipeline that allow code to run before or after critical stages.

Types of filters include:

• Authorization filters
• Resource filters
• Action filters
• Exception filters
• Result filters

They are ideal for cross-cutting concerns like logging, caching, auditing, authorization, and exception handling without polluting controller or page logic.