Amazon Interview .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.

Razor Views are templates that combine HTML with C# using the Razor syntax to render dynamic HTML responses.

Razor is lightweight, fast, and avoids the heavy view state and page lifecycle of WebForms. Views are usually driven by strongly typed models, enabling clean separation of concerns between UI and logic.

Layouts define a shared page shell (e.g., header, footer, navigation) used across many views.

Partial Views are reusable view fragments for rendering common UI pieces (e.g., a login panel or a list of items).

View Components encapsulate both rendering logic and view; they behave like mini-controllers plus views and are ideal for widgets (menus, dashboards, notifications) that need their own logic and markup.

Tag Helpers let you apply server-side behavior to HTML elements using natural HTML syntax.

Examples include form, input, link, and environment helpers. They integrate tightly with routing, model binding, and validation, improving readability and tooling support (IntelliSense) compared to traditional HTML helpers.

ViewData and ViewBag are used to pass data from controllers to views within the same request.

• ViewData is a Dictionary<string, object>.
• ViewBag is a dynamic wrapper around ViewData.

TempData persists data across a single redirect and is cleared once read. It is backed by cookies or session and is ideal for messages (e.g., success notifications) that survive a redirect.

Anti-forgery protection defends against Cross-Site Request Forgery (CSRF) attacks.

ASP.NET Core generates a pair of correlated tokens: one stored in a cookie and one embedded in the form. On POST, both must be present and valid. This ensures that state-changing requests originate from the legitimate site and user, not from a malicious third-party page.

Static files (CSS, JavaScript, images, etc.) are served by the Static File Middleware, which is usually placed early in the pipeline.

When a request matches a static file in wwwroot (or another configured folder), the middleware serves it directly and short-circuits the pipeline, bypassing MVC and other components. This leads to better performance and avoids unnecessary computation for simple file requests.

Earlier ASP.NET Core versions used WebHost to configure web-specific hosting (Kestrel, IIS integration, MVC, etc.).

The newer Generic Host unifies hosting for all app types (web, background services, workers, gRPC, SignalR) under a single abstraction.

• Generic Host centralizes DI, configuration, and logging.
• It supports non-web workloads and multiple hosted services in the same process.
• For web apps, Generic Host wires in WebHost-like features such as Kestrel and endpoint routing under the hood.

IHostApplicationLifetime (renamed to IHostApplicationLifetime / IHostApplicationLifetime in newer versions) exposes three key notifications:

• ApplicationStarted – Fired when the app is fully started and ready to serve requests.
• ApplicationStopping – Fired when the app begins a graceful shutdown (e.g., SIGTERM in containers).
• ApplicationStopped – Fired when shutdown is complete and cleanup has finished.

These events are used to warm up caches, start or stop background tasks, flush logs, and release resources in cloud and container environments.

The Content Root is the base path for application code, views, and configuration files.

The Web Root (usually wwwroot) is the publicly exposed folder for static files such as CSS, JS, and images.

Separating them ensures that sensitive assets like configuration files, views, and binaries are not accidentally served over HTTP. Only files under Web Root are directly reachable by clients.

• Use – Adds middleware that can process the request and optionally call the next middleware via a next delegate.
• Run – Adds terminal middleware that does not call the next component; it ends the pipeline.
• Map – Branches the pipeline based on the request path, creating sub-pipelines for specific URL segments.

Together, they give fine-grained control over the shape and branching of the request pipeline.

ASP.NET Core supports named environments such as Development, Staging, and Production, typically controlled by the ASPNETCORE_ENVIRONMENT variable.

Environment controls:

• Which configuration files are loaded (e.g., appsettings.Development.json).
• Whether detailed error pages are shown.
• Which services or features are enabled (e.g., runtime compilation only in Development).

Environment-based configuration prevents debug info and dev-only behaviors from leaking into production.

User Secrets are a development-only feature for storing sensitive values (API keys, connection strings) outside the project tree.

• They are not checked into source control.
• They are only used for the Development environment.
• They override configuration from JSON files.

In production, secrets should come from environment variables, Azure Key Vault, or similar secure stores, not from JSON configuration files.

The Options Pattern binds configuration sections to strongly typed classes and injects them via IOptions<T>, IOptionsSnapshot<T>, or IOptionsMonitor<T>.

Benefits include:

• Centralized configuration mapping and validation.
• No magic strings scattered throughout the code.
• Ability to reload or react to config changes.
• Cleaner separation of configuration from business logic.

Razor View Compilation converts .cshtml files into C# classes and compiles them into assemblies.

• Runtime compilation – Views are compiled on first use; flexible but slower for initial requests.
• Precompilation – Views are compiled at build/publish time; improves startup and reduces CPU at runtime.

Production apps typically use precompiled views to improve startup time and performance.

The View Engine is responsible for locating and rendering views from templates.

Razor differs from older engines by:

• Using C# instead of server controls or code-behind pages.
• Eliminating view state and page lifecycle complexity.
• Producing clean HTML with async support.
• Providing strong tooling and compile-time checks.

Tag Helpers operate within the HTML element tree and can apply behavior to all nested content.

Scoped helpers like <environment> wrap child elements to conditionally render sets of tags based on environment, reducing duplication and improving structure.

They help apply consistent behavior (e.g., script loading, validation attributes) across entire sections of the UI.

• ViewData – A Dictionary<string, object> for passing data from controller to view in the same request.
• ViewBag – A dynamic wrapper around ViewData for more convenient syntax.
• TempData – Persists data across one redirect; cleared after it is read.

ViewData/ViewBag are for same-request communication; TempData is designed for redirect scenarios such as Post-Redirect-Get.

Endpoint Routing decouples route matching from endpoint execution.

• UseRouting() runs early, matches the request to an endpoint, and attaches endpoint metadata.
• Middleware such as authentication and authorization can inspect endpoint metadata.
• UseEndpoints() executes the matched endpoint (controller, Razor Page, minimal API).

This improves performance, centralizes routing, and makes it easier to apply policies based on endpoint metadata.

Value Providers are components in the model binding system that know how to fetch data from specific sources:

• Route values
• Query strings
• Form data
• Headers
• Cookies

Model binding queries these providers in order to construct complex models from the incoming HTTP request.

Custom Model Binding is used when default binding cannot map request data to models correctly.

Typical use cases:

• Non-standard data formats.
• Combining multiple values into a single complex object.
• Parsing custom header or route patterns.

Implementing IModelBinder or using custom attributes provides full control over how request data is translated into .NET types.

ModelState is a dictionary that stores the results of model binding and validation.

• It tracks whether binding succeeded for each field.
• It collects validation errors and messages.
• ModelState.IsValid indicates whether the model is safe to use.

Actions should check ModelState to avoid operating on invalid data and to return meaningful error messages to clients.

Filters plug into the MVC and Razor Pages lifecycle at well-defined points.

Common use cases:

• Authorization checks.
• Logging and diagnostics.
• Caching and response shaping.
• Exception handling and error translation.
• Pre/post action logic such as measuring execution time.

Exception middleware (e.g., UseExceptionHandler) sits high in the pipeline and can catch exceptions from the entire app, including non-MVC endpoints.

Exception Filters run only within the MVC pipeline and can convert exceptions to action results at the controller/action level.

Best practice is to use middleware for global exception handling and filters for MVC-specific customization.

View Components combine rendering logic and a view into a reusable UI block, with full support for DI and testability.

Partial Views are simple reusable view fragments with no independent logic; they rely on the parent view's model.

View Components are ideal when the UI fragment needs its own data retrieval and business logic.

The Anti-Forgery system protects against CSRF attacks by issuing two related tokens:

• A cookie token stored in the browser.
• A form/request token embedded in forms or headers.

On POST (or unsafe verbs), the server validates that both tokens are present and match. If not, the request is rejected. This ensures that only requests initiated from the legitimate site using the correct user context are accepted.

The Static Files Middleware serves files directly from the configured web root without invoking MVC or other higher-level components.

It should be placed early in the pipeline so that requests for static resources are short-circuited quickly, improving performance and avoiding unnecessary processing by downstream middleware or controllers.

The Application Model is MVC’s internal representation of controllers, actions, filters, route metadata, and parameters.

Enterprise systems customize it to enforce conventions like automatic versioning, uniform route naming, attribute injection, and cross-team architectural consistency.

View Components bundle UI logic + view together and do not run through the MVC pipeline.

They support DI, encapsulate logic, and provide reusable & testable UI widgets, unlike partial views which render only markup.

Feature Slicing groups features (Orders, Billing) instead of layers (Controllers, Views). It reduces folder noise, improves modularity, and scales better for large teams.

ASP.NET Core enforces request size limits, form limits, upload limits, and aborts oversized bodies. It uses streamed reading to avoid memory spikes.

RCL packages reusable UI components, views, layouts, and static files. Enterprises use it for shared branding, modular UI, and multi-project consistency.

Validation runs after model binding. Attributes and custom validators populate ModelState. MVC may short-circuit execution if validation fails.

Filter order: Authorization ? Resource ? Action ? Exception ? Result.

Each filter intercepts a specific phase of the MVC pipeline for cross-cutting behaviors.

Authentication identifies the user. Authorization decides what the user can access. ASP.NET Core uses modular auth handlers and policy-based authorization.

Views use a layout, layouts can inherit from parent layouts, and sections flow through the rendering chain to generate multi-layer UI structures.

ASP.NET Core supports culture-specific formatting, resource-based translations, and dynamic culture selection via query, cookie, header, or route.

Controllers use scoped services per request. Views should avoid heavy scoped logic. Middleware is singleton-like and must not directly depend on scoped services.

Razor parses .cshtml ? generates C# ? compiles to assembly ? caches output. Precompilation improves startup, reduces CPU usage, and enhances performance.

Page Filters wrap Razor Page lifecycle (handler selection, binding, execution). They are lighter and page-focused, unlike MVC-wide action filters.

View engines resolve, compile, and render views. Multiple engines coexist by searching in order; the first match handles rendering.

Application Parts allow MVC to discover controllers, views, and tag helpers from multiple assemblies, enabling plugin-based modular architectures.

CSRF protection uses synchronized cookie + request tokens. Both must match for valid POST. ASP.NET Core auto-validates and secures tokens.

Async frees threads, increases concurrency, prevents starvation, avoids deadlocks, and enables high-throughput Kestrel performance.

Razor Pages reduce routing overhead and grouping complexity. MVC handles large complex routing better. Both benefit from caching, precompiled views, and minimized layout nesting.

Metadata Providers supply display names, formatting rules, validation metadata, and UI hints for binding, validation, scaffolding, and rendering.

Razor uses buffered output, strategic flush points, efficient writers, and pre-encoded content to reduce allocations and improve rendering speed.

ASP.NET Core is a modern, cross-platform, high-performance framework for building web applications. It was created to replace the heavy, Windows-only ASP.NET Framework. ASP.NET Core offers modularity, built-in DI, a redesigned hosting model, lightweight runtime, and full Linux + container support.

The hosting model uses a unified Host that configures DI, logging, configuration, server startup, environment settings, and middleware pipeline creation. It initializes Kestrel, loads configuration, builds services, and finally runs the HTTP pipeline.

Kestrel is a fast, cross-platform, event-driven web server optimized for async I/O. It offers superior throughput, supports reverse proxies, and provides full control over the request pipeline. It is the default server in ASP.NET Core.

Middleware are ordered components processing every HTTP request sequentially. Each middleware can inspect/modify requests and responses, call the next middleware, or short-circuit the pipeline. The pipeline controls routing, authentication, logging, static files, and more.

Middleware executes in the order registered. Incorrect ordering may break authentication, routing, exception handling, and endpoint execution. ASP.NET Core gives full control to developers and does not auto-correct middleware ordering.

ASP.NET Core includes a built-in DI container for service registration, lifetime management, and constructor injection. It enables cleaner architecture, testability, and decoupling across the entire framework.

Transient: new instance each request.
Scoped: one instance per HTTP request.
Singleton: one instance for entire app lifetime. Choosing correct lifetime is crucial to avoid memory leaks and race conditions.

Configuration is layered: JSON files, environment variables, user secrets, key vaults, in-memory providers. Each source overrides the previous. Supports binding to objects, reload-on-change, and environment-based settings.

IOptions: One-time config snapshot at startup.
IOptionsSnapshot: Reloaded per request.
IOptionsMonitor: Real-time change tracking + callbacks. Used for dynamic config updates.

Routing maps URLs to endpoints (controllers/pages). Endpoint Routing performs early route matching and delays execution until UseEndpoints(). It allows metadata-driven policies (auth, CORS) and improves performance.

Conventional routing: Central route patterns. Good for large MVC apps.
Attribute routing: Defined on actions. Best for APIs and unique routes.

Model binding converts HTTP request data (query, form, route, headers) into .NET objects. Supports type conversion, collections, nested models, and custom binders.

Runs after binding and before action execution. Uses data annotations, custom validation attributes, and IValidatableObject. Validation results go into ModelState and must be checked before using the data.

Filters run at specific pipeline stages: authorization, resource, action, exception, result. Used for logging, caching, security, and cross-cutting concerns.

Razor is a lightweight HTML + C# templating engine. It avoids WebForms complexity and supports clean, fast, server-side rendering with async support and strong tooling.

Layouts: Master page structure.
Partial Views: Reusable HTML fragments.
View Components: Reusable UI with C# logic + view. Ideal for widgets/dashboards.

Tag Helpers enable server-side logic using HTML-like syntax. They improve readability, provide IntelliSense, enforce validation, and reduce C# noise in Razor.

ViewData / ViewBag: For same-request data.
TempData: Stores data across redirects and is removed after read. Backed by cookies or session.

Anti-forgery tokens prevent CSRF attacks by validating a cookie token + form token pair. ASP.NET Core automatically validates tokens for unsafe HTTP verbs like POST.

Static Files Middleware serves files directly from wwwroot with no MVC involvement, improving performance. Must be placed early to avoid being processed by routing or MVC.

The hosting model uses a Generic Host that configures DI, logging, configuration, environment settings, and Kestrel. Startup constructs middleware pipeline and endpoint routing. The flow is: Host ? Kestrel ? Middleware ? Routing ? Endpoint.

Kestrel is a high-performance cross-platform server optimized for asynchronous I/O. ASP.NET Core uses it because it offers superior throughput, low memory overhead, full platform portability, and seamless integration behind reverse proxies like Nginx/IIS.

Middleware components execute sequentially for every request. Each can inspect, modify, or short-circuit the pipeline. This modular pipeline replaces old HTTP modules/handlers and provides full control over request flow.

ASP.NET Core includes a first-class DI container used across the entire framework: controllers, middleware, services. It promotes testable, modular, and maintainable architecture without external frameworks.

Transient: New instance each request.
Scoped: One instance per HTTP request.
Singleton: One instance for entire app lifetime.

Wrong lifetimes cause concurrency bugs, memory leaks, or stale state.

The configuration system merges layered sources: appsettings.json, environment-specific JSON, env variables, command-line args, user secrets, and external sources. Binding and hot-reload supported.

IOptions: Singleton config.
IOptionsSnapshot: Reload per request.
IOptionsMonitor: Real-time config with change notifications.

Endpoint Routing maps URLs to endpoints. It performs early URL matching, supports metadata, improves performance with route tables, and centralizes routing logic.

Validation runs after binding and populates ModelState with errors. Action logic executes only after validation passes. Supports Data Annotations, custom validators, and IValidatableObject.

Filters run at specific pipeline stages: Authorization, Resource, Action, Exception, and Result filters. They implement cross-cutting concerns like logging, caching, or auditing.

Layouts: Master UI shell.
Partial Views: Shared HTML fragments.
View Components: Reusable components with logic + view.

ViewData/ViewBag: For same request only.
TempData: Persisted across redirects using cookies or session. Ideal for one-time messages.

ASP.NET Core uses a unified Host that manages configuration, logging, DI, environment, and pipeline. The flow:

• Host initializes runtime and services
• Kestrel web server starts
• Configuration sources load
• Services added to DI
• Middleware pipeline built
• The app starts listening for HTTP requests

The unified model gives fine-grained control of every system layer.

Middleware are sequential components that inspect, transform, route, or short-circuit HTTP requests. Each middleware can:

• Read request
• Modify response
• Call next middleware
• Handle the response entirely

The pipeline is flexible, efficient, and replaces legacy HTTP modules/handlers.

ASP.NET Core includes a built-in DI container to unify object creation, lifecycle management, and dependency resolution. DI improves maintainability, testing, modularity, and supports the framework's extensible design.

ASP.NET Core configuration is hierarchical and supports multiple providers:

• appsettings.json
• Environment-specific files
• Env variables
• Command-line arguments
• Secrets / Key Vault

Values bind to strongly-typed classes and support reload-on-change.

• IOptions: Singleton configuration, loaded once.
• IOptionsSnapshot: Per-request config, refreshed each request.
• IOptionsMonitor: Live config with change notifications.

Model Binding converts HTTP inputs (query, route, form, body, headers) into strongly-typed .NET objects. It abstracts away manual parsing.

Filters enable cross-cutting concerns such as logging, caching, authorization, and exception handling. Types include authorization, resource, action, exception, and result filters.

• Layouts: Master templates for shared UI.
• Partials: Reusable HTML fragments.
• View Components: Encapsulated logic + view, ideal for widgets.

Tag Helpers enable server-side processing of HTML elements. They provide compile-time checking, IntelliSense, clean syntax, and strong typing.

ViewData/ViewBag: Per-request data.

TempData: Persists across redirects until consumed. Backed by cookies or session.

The Static Files middleware serves CSS/JS/images directly without MVC involvement. It must be placed early in the pipeline to bypass unnecessary routing and processing.

Generic Host is the unified hosting model supporting all app types (web, workers, gRPC). Web Host was only for web apps. Generic Host centralizes DI, logging, config, and enables multi-service hosting.

Lifetime events:

• ApplicationStarted
• ApplicationStopping
• ApplicationStopped

They allow warm-ups, cache initialization, graceful shutdowns, and log flushing.

Content Root: Base path for code, views, and config files.

Web Root: Public folder (wwwroot) exposed to the web for static files.

This separation prevents accidental exposure of sensitive project files.

The CLR pipeline includes Roslyn compilation to IL, metadata creation, IL loading, verification, JIT compilation, and optimized native execution through tiered compilation and RyuJIT. Execution runs under GC, exception handling, and runtime type safety. Supports JIT, AOT, ReadyToRun, and NativeAOT modes.

The .NET Memory Model defines visibility, ordering, and synchronization rules. It allows reordering unless blocked by barriers. Volatile improves visibility; Interlocked and lock introduce memory fences. Handles tearing, cache coherency, ABA issues, and provides relaxed consistency similar but less strict than Java.'s model.

Value types are stored inline (stack or within objects). Reference types always reside on the heap. Boxing allocates objects with headers and method table pointers. Inline struct fields avoid indirection, improving cache locality and performance.

A .NET object layout includes: Method Table pointer, Sync Block index, aligned fields with padding, and metadata references. The Method Table stores vtable, type hierarchy, and GC tracking info.

Gen0 handles short-lived objects, Gen1 buffers promotions, and Gen2 manages long-lived objects. LOH (>=85 KB) is collected only during full GC. POH isolates pinned objects to avoid LOH fragmentation. GC modes include server, workstation, and background.

Tier 0 generates fast unoptimized code for quick startup; Tier 1 recompiles hot paths with optimizations. Tiered PGO enhances long-running performance. Together they balance startup speed and runtime throughput.

lock/Monitor for lightweight mutual exclusion; Mutex for cross-process locks; Semaphore limits concurrency; SpinLock for low-contention busy waits; ReaderWriterLockSlim for read-heavy workloads. Each has different contention and fairness characteristics.

Compiler rewrites async methods into state machines. Await posts continuations to SynchronizationContext or thread pool. Tasks represent operations and manage completion, cancellation, and exceptions. Avoid context capture for performance.

Intern pool stores unique literals for lifetime of the process. Reduces duplication but increases memory pressure. Interning user input is dangerous due to unbounded growth.

• Reflection: runtime inspection, slow
• Emit: dynamic IL generation
• Expression Trees: compile to delegates for fast execution
• Source Generators: compile-time code generation using Roslyn

ThreadPool uses global/per-thread queues, work stealing, and hill-climbing to adjust worker counts. Long-running tasks should use LongRunning to avoid blocking worker threads.

Delegates may be open/closed static or instance methods. Multicast delegates contain invocation lists. Closures create hidden classes. Invocation chain length affects performance.

Roslyn provides syntax trees, semantic models, analyzers, refactoring, and code generation. It is compiler-as-a-service, powering tooling and source generators.

Covariance (out) allows substituting derived for base. Contravariance (in) allows substituting base for derived. Applies to delegates, interfaces, and arrays (with runtime checks). Enables type-flexible APIs safely.

AppDomains offered isolation and unloading but were heavy and complex. .NET Core replaced them with AssemblyLoadContext for lighter, flexible loading and unloading models.

IL, CIL, and MSIL refer to the same CPU-independent intermediate instruction set executed by the CLR before JIT compilation.

Exception handling involves stack unwinding, handler search, first/second chance exceptions, managed/unmanaged boundary transitions, and finally/fault execution. Throwing is expensive due to metadata lookup and stack analysis.

Metadata includes type, method, field tables, attributes, signatures, and constraints. CLR uses it for JIT compilation, reflection, verification, and type loading.

• Excess allocations
• Boxing
• Heavy LINQ in hot paths
• Lambdas capturing hidden allocations
• Blocking async
• Excessive locking
• Exceptions for flow control

ASP.NET Core is a cross-platform, high-performance framework built to replace legacy ASP.NET limitations. It introduces modularity, DI, unified hosting, and lightweight request pipeline optimized for cloud and microservices.

Middleware executes sequentially and may process, modify, short-circuit, or delegate requests. Enables flexible, modular pipelines replacing old HttpModules/Handlers.

Middleware runs exactly in registration order. Incorrect ordering breaks authentication, routing, exception handling, and static file behavior.

ASP.NET Core is designed around DI for clean structure, testability, separation of concerns, and consistent service creation across middleware, controllers, and background services.

Configuration is layered: appsettings.json, environment configs, secrets, environment variables, command-line args. Supports reload-on-change and strongly typed bindings.

IOptions: singleton read. Snapshot: per-request reload. Monitor: real-time change notifications for long-running services.

Endpoint Routing maps URLs to endpoints with early matching, metadata support, and optimized execution. Supports attribute and conventional routes.

Controllers use scoped services per request, Razor Views should avoid heavy scoped logic, and Middleware must avoid scoped services because middleware is created once and would turn scoped dependencies into singletons.

This scope behavior prevents state leakage, concurrency bugs, and lifecycle misalignment across pipeline components.

Razor parses .cshtml into C# classes, compiles them into temporary assemblies, and caches them. Runtime compilation is slower but flexible; precompiled views dramatically improve startup performance and CPU usage.

View engines search for views, parse templates, generate executable output, and render HTML. Multiple engines coexist by being queried in order; the first match handles rendering.

Application Parts let MVC discover controllers, views, pages, and Tag Helpers from assemblies or Razor Class Libraries. They enable modular architectures, plugin systems, and dynamic feature loading.

Async frees threads during I/O waits, prevents thread starvation, improves scalability, and avoids deadlocks. ASP.NET Core is designed for async performance from MVC to Razor to middleware.

Metadata Providers supply display names, validation rules, formatting, and UI hints. They influence model binding, validation, scaffolding, and Tag Helpers, ensuring consistent UI rules across apps.

The Application Model describes controllers, actions, parameters, routes, and filters. Enterprises customize it to enforce conventions, apply automatic routing, add versioning, or inject policies globally.

View Components include logic, support DI, run independently of controllers, and provide isolated UI modules. They are ideal for dynamic widgets, reusable dashboard blocks, and modular UI design.

ASP.NET Core enforces limits on request size, form size, field count, and upload sizes. It aborts oversized requests and streams bodies to prevent memory exhaustion.

RCLs consolidate shared UI components, layouts, Tag Helpers, and styles across multiple applications. They support modular deployment, branding consistency, and reusable UI patterns.

After model binding, validation attributes run, errors populate the ModelState dictionary, and filters may stop execution. This ensures invalid data never reaches application logic.

Execution order: Authorization ? Resource ? Action ? Exception ? Result. Filters wrap different pipeline stages and are used for cross-cutting concerns like logging, auth, and caching.

Authentication verifies identity, while Authorization determines access rights. ASP.NET Core uses modular auth handlers and policy-based authorization for flexible security design.

Razor resolves the requested view, then the inner layout, then outer layouts, merging sections at each level. This supports multi-layered branding and UI composition.

ASP.NET Core uses culture providers, resource-based translations, and formatting rules for dates and numbers. It detects culture via headers, route values, cookies, or query strings.