This covers the full ground a .NET Core interview loop tends to draw from — CLI and project mechanics, ASP.NET Core web fundamentals, EF Core and data access, testing, security, deployment, cloud/Kubernetes, design patterns, and where the platform is headed. Organized the way most interview question banks organize it, by topic, so jump to whichever section you need. Every answer is written to explain the reasoning, not just name-drop the term — with real code, a few diagrams, and a mock test at the end.

.NET Core Fundamentals

Q1. What is .NET Core and how does it differ from the .NET Framework?

.NET Core (renamed simply ".NET" from version 5 onward) is Microsoft's open-source, cross-platform rewrite of the .NET stack — runnable on Windows, Linux, and macOS, versioned and deployed side-by-side per application instead of one machine-wide install, and built from modular NuGet packages instead of one giant framework blob. .NET Framework, by contrast, is Windows-only, closed-source (until late in its life), ships one version per machine via Windows Update, and carries legacy technology — Web Forms, WCF services, System.Web — that .NET Core deliberately left behind in favor of leaner, faster equivalents (ASP.NET Core, gRPC/CoreWCF, Kestrel).

Q2. Describe the cross-platform capabilities of .NET Core.

Cross-platform is a first-class design goal, not a porting afterthought: the same C#/F#/VB code, the same SDK, and the same dotnet CLI run identically on Windows, Linux, and macOS (x64 and ARM64). The runtime (CoreCLR), the base class library, and the JIT are all built to abstract over the OS, so a web API written and tested on Windows will run unmodified on a Linux container in production — which is exactly the deployment story most .NET Core apps use today: build once, ship a Linux container.

Q3. What are the main components of the .NET Core architecture?

Four pieces work together: CoreCLR is the runtime — the JIT compiler, the garbage collector, and the type system that actually executes your code. The Base Class Library (BCL) is the set of fundamental types (collections, I/O, string handling, LINQ) every app builds on. The SDK bundles the compilers (Roslyn for C#/VB, F# compiler), MSBuild, and the dotnet CLI used to create, build, and publish projects. And on top of all of that sit the application frameworks — ASP.NET Core for web, EF Core for data, WinForms/WPF/MAUI for clients — which are just NuGet packages, not baked into the runtime.

• CoreCLR — the runtime: JIT compiler, garbage collector, type loader
• BCL (Base Class Library) — System.* fundamentals: collections, I/O, LINQ, threading
• SDK — compilers, MSBuild, and the dotnet CLI (installed separately from the runtime)
• Application frameworks — ASP.NET Core, EF Core, WinForms/WPF/MAUI — layered on top as NuGet packages

Q4. Explain the .NET Core CLI and its primary functions.

The dotnet CLI is the single entry point for the entire lifecycle of a .NET project — scaffolding, restoring dependencies, building, running, testing, and publishing — and it's the same command whether you're on Windows, Linux, or macOS, or inside CI. IDEs like Visual Studio or Rider are ultimately calling the same CLI underneath their UI.

Q5. How do you create a new .NET Core project using the CLI?

dotnet new webapi -n MyApi -o MyApi
cd MyApi
dotnet run

# other common templates:
dotnet new console -n MyConsoleApp
dotnet new classlib -n MyLibrary
dotnet new xunit -n MyApi.Tests
dotnet new sln -n MySolution && dotnet sln add MyApi MyApi.Tests

Q6. Discuss the purpose and use of a csproj file in a .NET Core project.

The .csproj file is the project's MSBuild manifest — the target framework, package references, build settings, and file inclusion rules. .NET Core's "SDK-style" csproj is dramatically smaller than the old .NET Framework version because it implicitly globs source files (every .cs file under the folder is included by default) instead of listing each one explicitly.

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="8.0.0" />
  </ItemGroup>

</Project>

Q7. What is the runtime and SDK in .NET Core?

The runtime is only what's needed to run an already-built app — CoreCLR plus the base libraries. The SDK is everything needed to build one: the runtime, plus the compilers, MSBuild, and the CLI. Production servers typically only need the (smaller) runtime installed; developer machines and CI build agents need the full SDK.

Q8. How would you manage different versions of the .NET Core SDK on the same machine?

Multiple SDK versions can be installed side-by-side with no conflict — dotnet --list-sdks shows what's present. Per-project (or per-repo) pinning is what global.json is for: it tells the CLI which SDK version this folder tree must build with, which is exactly what keeps a CI agent and a laptop from silently building against different compilers.

dotnet --list-sdks
dotnet --list-runtimes
dotnet --version   # respects global.json if one is present

Q9. What is the purpose of the global.json file?

{
  "sdk": {
    "version": "8.0.100",
    "rollForward": "latestMinor"
  }
}

Placed at a repo's root, this pins exactly which installed SDK the dotnet CLI must use for every project under that folder — critical for reproducible builds across a team and CI, since "works on my machine" is often just a different SDK minor version doing something subtly different.

Q10. Can you explain the directory structure of a typical .NET Core project?

• Program.cs — the entry point; in modern .NET this also configures services and the middleware pipeline (minimal hosting model)
• *.csproj — the MSBuild project file
• appsettings.json / appsettings.{Environment}.json — configuration, layered per environment
• wwwroot/ — static files served directly to the browser (CSS, JS, images)
• Controllers/, Pages/, or Components/ — MVC controllers, Razor Pages, or Blazor components
• Properties/launchSettings.json — local run profiles and environment variables for `dotnet run`
• bin/ and obj/ — build output and intermediate files (never checked into source control)

.NET Core Dependencies and Libraries

Q11. How do you add and manage NuGet packages in a .NET Core project?

dotnet add package Newtonsoft.Json
dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 8.0.0
dotnet remove package Newtonsoft.Json
dotnet restore
dotnet list package --outdated

Each `dotnet add package` writes a `<PackageReference>` into the csproj; there's no separate packages.config file to keep in sync the way classic .NET Framework projects needed. `dotnet restore` (which also runs implicitly before build/run) resolves the whole dependency graph and downloads what's missing into the local NuGet cache.

Q12. Explain the role of the NuGet package manager.

NuGet is .NET's package manager and public registry (nuget.org) — the equivalent of npm for Node or pip for Python. It resolves transitive dependencies, handles version ranges and conflicts, and lets teams host their own private feeds (Azure Artifacts, GitHub Packages) alongside the public one for internal libraries.

Q13. Describe the process of publishing a .NET Core application.

# Framework-dependent: needs the matching runtime installed on the target
dotnet publish -c Release -o ./publish

# Self-contained: bundles the runtime itself, larger output, no install needed
dotnet publish -c Release -r linux-x64 --self-contained true -o ./publish

# Single-file, trimmed self-contained executable
dotnet publish -c Release -r linux-x64 --self-contained true -p:PublishSingleFile=true -p:PublishTrimmed=true

Publishing compiles in Release mode and lays out everything the app needs to run outside the dev environment. The framework-dependent vs. self-contained choice is the key trade-off: framework-dependent output is small but requires the right runtime pre-installed on the target machine; self-contained bundles the runtime, so it's larger but runs anywhere, which is exactly why it's the default choice for container images.

Q14. What is .NET Standard and how does it relate to .NET Core?

.NET Standard was a specification, not a runtime — a common API surface that .NET Framework, .NET Core, Mono, and Xamarin could all promise to implement, so a class library built against .NET Standard 2.0 could be consumed from any of them. Since .NET 5 unified the ecosystem into one continuously-updated platform, .NET Standard is effectively retired for new libraries — you target a specific .NET version (or multi-target several) instead, and only reach for netstandard2.0 today if a library genuinely still needs to support .NET Framework consumers.

Q15. How do you create a class library in .NET Core?

dotnet new classlib -n MyCompany.Shared -o src/MyCompany.Shared
dotnet add src/MyApi/MyApi.csproj reference src/MyCompany.Shared/MyCompany.Shared.csproj

.NET Core Web Development

Q16. Describe the MVC pattern in .NET Core.

MVC splits a web app into three responsibilities: the Model holds and validates data, the View renders HTML (Razor syntax), and the Controller receives the HTTP request, talks to the model/services, and picks which view (or JSON result) to return. ASP.NET Core MVC still supports this fully, but it now sits alongside two lighter-weight alternatives — Razor Pages (page-centric, no separate controller) and minimal APIs (no MVC ceremony at all) — so MVC today is a choice for apps with genuinely complex, shared controller logic rather than the only option.

Q17. How do you set up a Web API in a .NET Core project?

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

app.Run();

That's the classic controller-based setup. Since .NET 6, the same API can be written even leaner with minimal APIs — no controller class at all, just route-to-delegate mappings directly on the app builder, which is now the default template for small services.

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

app.MapGet("/products/{id}", (int id, IProductService svc) => svc.GetById(id));
app.MapPost("/products", (Product p, IProductService svc) => svc.Create(p));

app.Run();

Q18. What are middleware components in .NET Core?

Middleware are the building blocks of the request pipeline — small pieces of code, each wired up with app.Use…(), that can inspect or modify a request, decide whether to pass it to the next piece, and inspect or modify the response on the way back out. Order matters enormously: authentication middleware has to run before authorization, and both have to run before the endpoint that needs them, because each middleware wraps everything registered after it.

app.Use(async (context, next) =>
{
    var sw = System.Diagnostics.Stopwatch.StartNew();
    await next(context);           // hand off to the next middleware
    Console.WriteLine($"{context.Request.Path} took {sw.ElapsedMilliseconds}ms");
});

Q19. Explain how static files are served in a .NET Core web application.

Files placed in the wwwroot/ folder — CSS, JavaScript, images, client-side libraries — are served directly, bypassing routing and controllers entirely, once the static files middleware is registered.

app.UseStaticFiles(); // serves everything under wwwroot/ at the site root

Q20. Discuss the use and configuration of the appsettings.json file.

{
  "ConnectionStrings": {
    "Default": "Server=.;Database=Orders;Trusted_Connection=True;"
  },
  "Logging": {
    "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" }
  },
  "Jwt": { "Issuer": "my-api", "ExpiryMinutes": 60 }
}

appsettings.json is the base configuration; appsettings.Development.json / appsettings.Production.json layer on top of it based on the ASPNETCORE_ENVIRONMENT variable, and environment variables or command-line arguments can override any of it again on top of that — all without touching code or rebuilding.

Q21. What is Dependency Injection (DI) in .NET Core?

Dependency Injection means a class declares what it needs (via its constructor) instead of constructing those dependencies itself — the framework's built-in IoC container resolves and supplies them at runtime. It's baked directly into ASP.NET Core (no third-party container required, though Autofac/others can still be plugged in), which is why virtually every ASP.NET Core class — controllers, middleware, services — takes its dependencies as constructor parameters.

Q22. How do you implement custom services and use DI in .NET Core?

public interface IOrderService
{
    Task<Order> GetAsync(int id);
}

public class OrderService : IOrderService
{
    private readonly AppDbContext _db;
    public OrderService(AppDbContext db) => _db = db;

    public Task<Order> GetAsync(int id) => _db.Orders.FindAsync(id).AsTask();
}

// Registration:
builder.Services.AddScoped<IOrderService, OrderService>();

// Consumption — the container supplies it automatically:
public class OrdersController : ControllerBase
{
    private readonly IOrderService _orders;
    public OrdersController(IOrderService orders) => _orders = orders;
}

Q23. What are environment variables and how do they work in .NET Core?

Environment variables are one of the configuration providers ASP.NET Core reads at startup, and — by default provider order — they override values from appsettings.json. ASPNETCORE_ENVIRONMENT specifically controls which appsettings.{env}.json layer loads and what app.Environment.IsDevelopment()/IsProduction() report. For nested settings, the double-underscore is the separator: Jwt__ExpiryMinutes sets Jwt:ExpiryMinutes.

export ASPNETCORE_ENVIRONMENT=Production
export Jwt__ExpiryMinutes=30

Q24. How does routing work in a .NET Core MVC application?

Routing maps an incoming URL to a controller action (or minimal API delegate). Attribute routing — decorating actions directly with [HttpGet("products/{id}")] — is the modern default and coexists fine with older convention-based routing (a single MapControllerRoute pattern applied app-wide).

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet("{id:int}")]
    public IActionResult GetById(int id) => Ok(new { id });
}

Q25. What are Razor Pages in .NET Core?

Razor Pages is a page-centric alternative to MVC — each page is a self-contained .cshtml file paired with its own PageModel code-behind class (OnGet/OnPost handlers), with no separate controller routing requests to it. It suits content- and form-heavy sites (CRUD screens, admin panels) where MVC's controller-and-multiple-views indirection is more ceremony than the page actually needs.

.NET Core Advanced Topics

Q26. Explain the concept of Tag Helpers in ASP.NET Core.

Tag Helpers let server-side C# logic participate in otherwise-plain HTML tags inside a Razor view, via asp-* attributes — no @Html.ActionLink()-style helper-method syntax required. They read as normal HTML in the markup, which is what makes them easier for a front-end-leaning developer to work with than the old HTML Helpers.

<a asp-controller="Products" asp-action="Details" asp-route-id="@product.Id">View</a>
<form asp-action="Create" method="post">
  <input asp-for="Name" class="form-control" />
  <span asp-validation-for="Name"></span>
</form>

Q27. How do you ensure the security of a .NET Core application?

• Enforce HTTPS everywhere (UseHttpsRedirection + HSTS) and never send secrets over plain HTTP
• Use ASP.NET Core Identity or a token-based scheme (JWT / OpenID Connect) for authentication
• Apply the principle of least privilege with policy-based [Authorize] attributes, not one blanket check
• Keep secrets out of source control — user-secrets locally, Key Vault / environment variables in production
• Validate and encode all user input (model validation + Razor's automatic HTML encoding) to prevent XSS/injection
• Keep the SDK, runtime, and NuGet packages patched — `dotnet list package --vulnerable` flags known CVEs

Q28. What is an EF Core and how do you use it with .NET Core?

Entity Framework Core is Microsoft's official object-relational mapper — it lets you query and update a database using LINQ against C# classes instead of hand-written SQL, tracks changes to loaded entities, and generates the SQL (and, via migrations, the schema) for you. You define a DbContext with DbSet<T> properties, register it with DI, and query it like any in-memory collection.

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }
    public DbSet<Order> Orders => Set<Order>();
}

// Program.cs
builder.Services.AddDbContext<AppDbContext>(opt =>
    opt.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

// Usage
var recentOrders = await db.Orders
    .Where(o => o.CreatedAt > DateTime.UtcNow.AddDays(-7))
    .ToListAsync();

Q29. How do you handle migrations in EF Core?

dotnet tool install --global dotnet-ef
dotnet ef migrations add InitialCreate
dotnet ef database update
dotnet ef migrations remove          # undo the last, unapplied migration
dotnet ef migrations script          # generate raw SQL for a DBA/CI to run

Q30. Describe how to cache data in a .NET Core web application.

Q31. What are SignalR and its use cases in .NET Core?

SignalR is ASP.NET Core's real-time communication library — it abstracts over WebSockets, Server-Sent Events, and long-polling, automatically falling back to whichever the client/network actually supports, and gives you a simple Hub class to call methods on connected clients from the server (and vice versa). It's the go-to for live dashboards, chat, collaborative editing, and live notifications.

Q32. How can you build real-time applications using .NET Core?

Define a Hub, register SignalR in DI, map the hub to an endpoint, and call client methods from anywhere on the server (even outside a request, via IHubContext<T>) — the client library handles reconnection and transport negotiation for you.

public class ChatHub : Hub
{
    public async Task SendMessage(string user, string message) =>
        await Clients.All.SendAsync("ReceiveMessage", user, message);
}

// Program.cs
builder.Services.AddSignalR();
app.MapHub<ChatHub>("/chatHub");

Q33. Explain the role of a Kestrel server in .NET Core.

Kestrel is the cross-platform, built-in web server every ASP.NET Core app runs on — fast enough that it's often run directly as the internet-facing server today, though many production setups still put it behind a reverse proxy (Nginx, IIS, or Azure App Service's own front end / YARP) for things like TLS termination at the edge, static-file offload, or hosting several apps behind one IP.

Q34. What is Blazor and how does it integrate with .NET Core?

Blazor lets you build interactive web UI in C# and Razor syntax instead of JavaScript, running either on the server (Blazor Server — UI diffs pushed over a SignalR connection) or in the browser via WebAssembly (Blazor WebAssembly — the whole .NET runtime downloaded and run client-side). .NET 8 unified both under one "Blazor Web App" model where render mode can be chosen per component.

Q35. How do you perform logging in .NET Core?

public class OrderService
{
    private readonly ILogger<OrderService> _logger;
    public OrderService(ILogger<OrderService> logger) => _logger = logger;

    public void Process(int orderId)
    {
        _logger.LogInformation("Processing order {OrderId}", orderId);
    }
}

ILogger<T> is injected via DI and built into the framework — the {OrderId} placeholder is structured logging, not string interpolation, so the value stays queryable as its own field once shipped to a provider like Application Insights, Seq, or Elasticsearch (commonly via Serilog, the most popular third-party provider). Log levels (Trace through Critical) are configured per-namespace in appsettings.json so you can, say, silence noisy framework logs while keeping your own at Information.

.NET Core Performance and Optimization

Q36. What features does .NET Core include to improve application performance?

• Tiered compilation & ReadyToRun — start fast with a quick JIT pass, recompile hot paths more aggressively later
• Server GC with multiple heaps — scales garbage collection across cores for throughput-heavy workloads
• Span<T> / Memory<T> — slice arrays and strings without allocating copies
• System.Text.Json — a faster, lower-allocation JSON serializer than the older Newtonsoft.Json default
• Minimal APIs — less framework overhead per request than full MVC for simple endpoints
• Native AOT (.NET 7+) — compile straight to native code, near-instant startup, no JIT at runtime

Q37. How can you monitor performance in a .NET Core application?

dotnet-counters gives a live view of CPU, GC, and request-rate metrics from a running process without attaching a debugger; Application Insights (or an OpenTelemetry-based equivalent) adds distributed tracing and request telemetry in production; and built-in Health Checks (Microsoft.Extensions.Diagnostics.HealthChecks) expose a /health endpoint that load balancers and Kubernetes probes can poll.

Q38. Discuss performance profiling tools suitable for .NET Core.

Q39. What is the purpose of asynchronous programming in .NET Core?

async/await frees a thread to serve other requests while waiting on I/O (a database call, an HTTP request, a file read) instead of blocking it, which is what lets a small thread pool handle a huge number of concurrent connections — the entire reason ASP.NET Core scales as well as it does under load. It's a throughput technique for I/O-bound work, not a way to make CPU-bound code faster.

public async Task<Order> GetOrderAsync(int id)
{
    // Thread returns to the pool while the DB round-trip is in flight
    var order = await _db.Orders.FindAsync(id);
    return order;
}

Q40. How do you identify and resolve memory leaks in a .NET Core application?

The usual suspects are event handlers or delegates subscribed but never unsubscribed (which keeps the subscriber alive via a reference from the publisher), static collections that only ever grow, undisposed IDisposable resources (especially DbContext, HttpClient, and file/stream handles), and closures that capture more than intended. Take a heap snapshot with dotnet-gcdump (or the Visual Studio memory profiler) before and after the suspected leak, and diff object counts by type to see what's actually accumulating — guessing rarely beats measuring here.

.NET Core Testing and Debugging

Q41. How do you write unit tests in a .NET Core application?

public class DiscountCalculatorTests
{
    [Fact]
    public void AppliesTenPercentOff_WhenOrderExceedsThreshold()
    {
        var calculator = new DiscountCalculator(threshold: 100);

        var result = calculator.Apply(150);

        Assert.Equal(135, result);
    }
}

Create a separate test project (dotnet new xunit), reference the project under test, and use the Arrange-Act-Assert shape: set up inputs, call the method, assert on the result. `dotnet test` discovers and runs every test in the solution.

Q42. Describe the use of xUnit, NUnit, and MSTest frameworks.

Q43. What are Integration Tests and how do they differ from Unit Tests?

A unit test isolates one piece of logic (usually with dependencies mocked/faked) and should run in milliseconds with no external system involved. An integration test exercises real collaboration between pieces — the actual HTTP pipeline, a real (or realistic in-memory/test-container) database — to catch the bugs that only show up at the seams: wrong routing, misconfigured DI, a middleware ordering mistake. ASP.NET Core's WebApplicationFactory<TEntryPoint> spins up the whole app in-memory specifically for this.

public class ProductsApiTests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;
    public ProductsApiTests(WebApplicationFactory<Program> factory) =>
        _client = factory.CreateClient();

    [Fact]
    public async Task GetProducts_ReturnsOk()
    {
        var response = await _client.GetAsync("/api/products");
        response.EnsureSuccessStatusCode();
    }
}

Q44. Explain the use of the logging API for troubleshooting.

Structured logs (via ILogger<T>) are the primary trail for diagnosing production issues you can't reproduce locally — logging at entry/exit of key operations, on every caught exception, and around external calls (DB, third-party APIs) turns a bug report into a timeline you can actually follow. Correlating logs by a request/trace ID (built into ASP.NET Core's activity tracing) is what lets you follow one request across multiple log lines, or even multiple services.

Q45. What is the TDD approach and how can it be implemented in .NET Core development?

Test-Driven Development flips the usual order: write a failing test for behavior that doesn't exist yet (red), write the minimum code to make it pass (green), then clean the implementation up without changing behavior (refactor) — repeat. In .NET Core this is just xUnit/NUnit tests written before the corresponding class or method, run continuously with `dotnet watch test` for instant feedback on each change.

.NET Core Deployment and Configuration

Q46. What is Docker and how can it be used with .NET Core?

Docker packages an app with everything it needs to run — runtime, dependencies, config — into a portable container image, so "works on my machine" becomes "works in this exact container, everywhere." Microsoft publishes official .NET base images (mcr.microsoft.com/dotnet/sdk for building, mcr.microsoft.com/dotnet/aspnet for running), and a multi-stage Dockerfile keeps the final image small by discarding the heavier SDK once the build is done.

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "MyApi.dll"]

Q47. How can you deploy a .NET Core application to the cloud (e.g., Azure)?

Azure App Service is the simplest path for a straightforward web app — push a build via `az webapp up`, a GitHub Action, or an Azure DevOps pipeline, and Azure handles the underlying VM/OS patching. For containerized workloads, Azure Container Apps or AKS (managed Kubernetes) give more control; for event-driven, pay-per-execution code, Azure Functions. All of them accept the same publish output — a self-contained or framework-dependent build, or a container image.

Q48. What are some common security considerations when deploying a .NET Core application?

• Never bake secrets (connection strings, API keys) into the image or source — inject via environment variables or a managed vault (Azure Key Vault, AWS Secrets Manager)
• Terminate TLS somewhere in the chain and enforce HTTPS/HSTS end-to-end, not just at the edge
• Run the container as a non-root user, and keep base images patched (rebuild regularly, don't assume a pinned tag stays secure)
• Restrict outbound/inbound network rules to only what the app actually needs
• Rotate credentials and JWT signing keys on a schedule, not only when something leaks

Q49. Discuss the strategies for scaling .NET Core applications.

Horizontal scaling (more instances behind a load balancer) is the default strategy, which is exactly why ASP.NET Core apps are pushed toward being stateless — session state, cache, and SignalR connections all need to move to something shared (Redis, a distributed cache) once you're running more than one instance, or a request that lands on a different instance won't see the same in-memory state. Vertical scaling (bigger machine) buys time but doesn't remove the eventual need to go horizontal, and autoscaling rules (CPU/memory/queue-depth triggers) tie the two together in Azure/Kubernetes.

Q50. How do you configure HTTPS and SSL in a .NET Core Web Application?

builder.Services.AddHsts(options =>
{
    options.MaxAge = TimeSpan.FromDays(365);
    options.IncludeSubDomains = true;
});

app.UseHttpsRedirection();  // 301-redirects any http:// request to https://
app.UseHsts();              // tells browsers to skip http:// entirely next time

In development, Kestrel uses a self-signed dev certificate (`dotnet dev-certs https --trust`); in production, TLS is usually terminated either directly on Kestrel with a real certificate configured in appsettings.json/Kestrel options, or at a reverse proxy/load balancer in front of it, with Kestrel only serving plain HTTP internally.

.NET Core and Cloud Integration

Q51. Explain how you can integrate Azure services into a .NET Core application.

Almost every Azure service has an official .NET SDK NuGet package (Azure.Storage.Blobs, Azure.Messaging.ServiceBus, Azure.Identity, and so on), registered and configured through the same DI container as everything else. Azure.Identity in particular is the modern glue — it lets an app authenticate to other Azure services using its own managed identity, with no connection string or secret to manage at all.

Q52. How do you use Azure DevOps for CI/CD with a .NET Core project?

trigger: [ main ]

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: UseDotNet@2
    inputs: { version: '8.0.x' }
  - script: dotnet restore
  - script: dotnet build --configuration Release
  - script: dotnet test --configuration Release
  - script: dotnet publish -c Release -o $(Build.ArtifactStagingDirectory)
  - publish: $(Build.ArtifactStagingDirectory)
    artifact: drop

An azure-pipelines.yml (or the GitHub Actions equivalent) automates exactly the steps a developer would run by hand — restore, build, test, publish — on every push, with a release/deployment stage after it that pushes the artifact to App Service, AKS, or wherever it's hosted.

Q53. What are the best practices for building a microservices architecture in .NET Core?

• One service, one bounded context, one database — no sharing a database across services
• Communicate over well-defined APIs (REST/gRPC) for synchronous calls, a message broker (RabbitMQ, Azure Service Bus, Kafka) for async/eventual-consistency flows
• Design for failure: retries with backoff and circuit breakers (Polly) instead of assuming every call succeeds
• Centralize cross-cutting concerns — auth, rate limiting, routing — in an API gateway (YARP, Ocelot) rather than duplicating them per service
• Instrument with distributed tracing (OpenTelemetry) from day one — you cannot debug a multi-service request by log-grepping alone

Q54. How does .NET Core work with container orchestration tools like Kubernetes?

A .NET Core app ships as a Docker image, and Kubernetes handles the rest — scheduling pods across nodes, restarting failed ones, and scaling replica counts. The framework side of the contract is the /health endpoint from Microsoft.Extensions.Diagnostics.HealthChecks, which Kubernetes' liveness and readiness probes poll to decide whether a pod should keep receiving traffic or be restarted; configuration flows in via ConfigMaps and Secrets mounted as environment variables, which ASP.NET Core's configuration system reads exactly like any other env var.

Q55. Describe serverless computing with .NET Core on platforms like AWS Lambda.

Serverless runs your code on-demand, per-invocation, with the platform handling all provisioning and scaling — you pay per execution, not for an always-on server. .NET Core has first-class support on both major clouds: Azure Functions (with an isolated-worker process model as the modern recommendation) and AWS Lambda via Amazon's official .NET Lambda runtime/base images. Cold start (the delay spinning up a fresh instance) is the main .NET-specific concern, which Native AOT compilation significantly reduces by skipping JIT warm-up entirely.

.NET Core Data Access

Q56. How do you work with databases using Entity Framework Core?

You model tables as C# classes, expose them as DbSet<T> properties on a DbContext, and query/update them with LINQ — EF Core translates that LINQ into SQL, tracks which loaded entities changed, and turns SaveChangesAsync() into the right INSERT/UPDATE/DELETE statements in one round trip.

Q57. What is the purpose of the DbContext in EF Core?

DbContext is the unit-of-work and change-tracker: it represents one logical database session, holds the entities you've loaded or added, knows what changed since they were loaded, and turns that into SQL when you call SaveChanges(). It's registered as a scoped service (one per HTTP request) precisely because sharing one across requests or threads isn't safe — it's not thread-safe by design.

Q58. Explain the Code-First and Database-First approaches in EF Core.

Q59. How do you handle database transactions in .NET Core?

using var transaction = await db.Database.BeginTransactionAsync();
try
{
    db.Orders.Add(order);
    await db.SaveChangesAsync();

    db.InventoryLog.Add(new InventoryLog(order));
    await db.SaveChangesAsync();

    await transaction.CommitAsync();
}
catch
{
    await transaction.RollbackAsync();
    throw;
}

A single SaveChangesAsync() call is already wrapped in an implicit transaction, so this is only needed when multiple SaveChanges calls (or raw SQL alongside EF Core calls) must succeed or fail together as one atomic unit.

Q60. Discuss using Dapper as an alternative to Entity Framework in .NET Core applications.

using var connection = new SqlConnection(connectionString);
var orders = await connection.QueryAsync<Order>(
    "SELECT * FROM Orders WHERE CustomerId = @CustomerId",
    new { CustomerId = customerId });

.NET Core Design Patterns and Practices

Q61. What are some popular design patterns used in .NET Core applications?

• Dependency Injection — baked into the framework itself, not just "a pattern you can use"
• Repository / Unit of Work — abstracting data access behind an interface
• CQRS — separating the read and write models, often via MediatR
• Options pattern — strongly-typed configuration via IOptions<T>
• Factory pattern — for runtime-selected implementations (e.g. a payment gateway chosen by config)
• Decorator — wrapping a service to add cross-cutting behavior (caching, logging) without changing it

Q62. How do you implement Repository and Unit of Work patterns in .NET Core?

public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(int id);
    void Add(Order order);
}

public class OrderRepository : IOrderRepository
{
    private readonly AppDbContext _db;
    public OrderRepository(AppDbContext db) => _db = db;

    public Task<Order?> GetByIdAsync(int id) => _db.Orders.FindAsync(id).AsTask();
    public void Add(Order order) => _db.Orders.Add(order);
}

// AppDbContext itself already tracks changes across repositories and commits
// them together on SaveChangesAsync() — it IS the Unit of Work here.
public interface IUnitOfWork
{
    IOrderRepository Orders { get; }
    Task<int> CompleteAsync();
}

Worth saying plainly in an interview: DbContext already implements both patterns to a large extent (DbSet<T> is a repository, SaveChanges is the unit of work), so an extra explicit layer is a deliberate trade-off — decoupling from EF Core specifically and making data access easier to unit-test with fakes — not a requirement.

Q63. Explain CQRS and how it applies to .NET Core.

Command Query Responsibility Segregation splits reads and writes into separate models: commands change state and return little or nothing, queries return data and change nothing — instead of one service class doing both. In .NET Core this is usually implemented with the MediatR library: each command/query is a small class, each has a dedicated handler, and a controller just sends the request into the mediator instead of calling a fat service method directly.

public record CreateOrderCommand(int CustomerId, List<int> ProductIds) : IRequest<int>;

public class CreateOrderHandler : IRequestHandler<CreateOrderCommand, int>
{
    public async Task<int> Handle(CreateOrderCommand cmd, CancellationToken ct)
    {
        // create the order, persist it, return its new id
        return newOrderId;
    }
}

// Controller:
var orderId = await _mediator.Send(new CreateOrderCommand(customerId, productIds));

Q64. Discuss the importance of domain-driven design (DDD) in .NET Core.

DDD pushes business rules into rich domain objects (entities, value objects, aggregates that enforce their own invariants) instead of scattering "if" checks across services and controllers — an Order object should make an invalid state (like negative quantity) impossible to construct, not just validated against after the fact. It matters most in genuinely complex domains (insurance, finance, logistics); a simple CRUD app usually doesn't need the ceremony of aggregates and bounded contexts DDD brings.

Q65. How does .NET Core support the SOLID principles in software development?

.NET Core Interoperability and Legacy Systems

Q66. How can you integrate a .NET Core application with legacy .NET Framework apps?

The cleanest boundary is a network call — expose the legacy app's functionality over HTTP/gRPC and consume it from the new .NET Core service, so nothing about how the old code runs has to change. Where a shared library is unavoidable, targeting .NET Standard 2.0 for that library lets both a .NET Framework and a .NET Core project reference the exact same DLL.

Q67. Can you consume COM objects in .NET Core?

Yes, but only on Windows — .NET Core added COM interop support specifically for Windows-hosted scenarios (via <EnableComHosting> and related project settings), but it's narrower than .NET Framework's support and doesn't extend to Linux/macOS, since COM itself is a Windows technology. If a dependency is COM-only and cross-platform matters, that's usually a sign to isolate it behind its own Windows-only service rather than fight the interop layer everywhere.

Q68. Discuss strategies for migrating from .NET Framework to .NET Core.

• Run the .NET Upgrade Assistant first — it automates a large share of the mechanical csproj/API changes
• Migrate class libraries before the web/UI layer — they usually have fewer platform-specific dependencies
• Replace Framework-only technology deliberately: Web Forms has no direct successor (rewrite as Razor Pages/MVC), WCF services move to CoreWCF or gRPC
• Prefer an incremental, strangler-fig approach for large apps — run old and new side-by-side behind a gateway rather than one big-bang rewrite
• Audit every third-party NuGet dependency for .NET Core / .NET Standard support before committing to a timeline

Q69. What are the challenges associated with interoperability in .NET Core?

The big three: missing Windows-only APIs (System.Web, WCF server-side, some registry/COM access) that have no drop-in replacement; third-party libraries that never shipped a .NET Core/Standard-compatible build; and subtle runtime behavior differences (reflection, serialization defaults, culture handling) that can silently change behavior even when code compiles unchanged.

.NET Core CLI and Tools

Q70. How do you manage user secrets in development with the .NET Core CLI?

dotnet user-secrets init
dotnet user-secrets set "Jwt:SigningKey" "super-secret-dev-only-value"
dotnet user-secrets list
dotnet user-secrets remove "Jwt:SigningKey"

User secrets are stored outside the project folder (in a per-user profile directory keyed by a GUID in the csproj), so they never accidentally get committed to source control, and they're automatically layered into IConfiguration in the Development environment with no extra code.

Q71. What is the watch command in the .NET Core CLI and when would you use it?

dotnet watch run
dotnet watch test

`dotnet watch` monitors source files and automatically rebuilds and restarts (or hot-reloads, where supported) the app on save — the everyday inner-loop command during active development, so you're not manually stopping/rebuilding/restarting after every change.

Q72. Explain the dotnet ef CLI tool and its primary uses.

`dotnet ef` is EF Core's design-time CLI tool (installed globally or as a local tool), used for everything migration-related: generating migrations from model changes, applying them to a database, scaffolding a DbContext + entities from an existing database, and generating raw SQL scripts for a DBA to review before running against production.

Q73. Describe the use of scaffolding in .NET Core.

dotnet tool install -g dotnet-aspnet-codegenerator
dotnet aspnet-codegenerator controller -name ProductsController -m Product -dc AppDbContext -api

Scaffolding generates boilerplate CRUD code (controllers, views, sometimes Identity UI) from a model class, so you start from working code and customize it instead of typing every action method by hand — most valuable for quick prototypes and admin-style CRUD screens.

Q74. How do you use the CLI to run and debug .NET Core applications?

`dotnet run` builds (if stale) and runs the app directly from the CLI; for real debugging (breakpoints, step-through, variable inspection) you attach a debugger from an IDE — Visual Studio, VS Code, or Rider all support "attach to process" against a `dotnet run` process, or launch-and-debug directly via launchSettings.json. `dotnet-dump`/`dotnet-trace` cover the harder case: debugging a process in production where you can't attach a live debugger at all.

.NET Core Configuration and Settings

Q75. How do you manage configurations and settings in .NET Core for multiple environments?

appsettings.json                # base config, always loaded
appsettings.Development.json    # loaded when ASPNETCORE_ENVIRONMENT=Development
appsettings.Production.json     # loaded when ASPNETCORE_ENVIRONMENT=Production

Each environment-specific file only needs to contain the keys that differ from the base file — the configuration system merges them, with the environment-specific file winning on conflicts, and environment variables/command-line args winning over both of those again.

Q76. What is an IOptions pattern and how can it be used for configuration?

public class JwtSettings
{
    public string Issuer { get; set; } = "";
    public int ExpiryMinutes { get; set; }
}

builder.Services.Configure<JwtSettings>(builder.Configuration.GetSection("Jwt"));

public class TokenService
{
    private readonly JwtSettings _settings;
    public TokenService(IOptions<JwtSettings> options) => _settings = options.Value;
}

Q77. Describe the role and configuration of middleware in .NET Core.

Middleware is configured once, in order, in Program.cs — that registration order is the actual execution order of the request pipeline, which is why exception-handling middleware is registered first (so it can catch errors from everything after it) and routing/endpoint middleware last (as the terminal step that actually produces a response).

Q78. Explain how Configuration Builders are used in .NET Core.

WebApplication.CreateBuilder(args) wires up a chain of configuration providers automatically — appsettings.json, the environment-specific file, environment variables, and command-line args, in that override order — and you can add more (Azure Key Vault, an Azure App Configuration store, a custom provider) with a single AddXyz() call on builder.Configuration before Build() is called. Every provider feeds the same flattened IConfiguration your services read from, regardless of where a given key actually came from.

Q79. How do you read command-line arguments in a .NET Core application?

var builder = WebApplication.CreateBuilder(args); // args flow straight into IConfiguration

// dotnet run -- --Port=8080  ->  builder.Configuration["Port"] == "8080"
var port = builder.Configuration["Port"];

.NET Core and Security

Q80. How does .NET Core handle authentication and authorization?

They're deliberately separate concerns wired in as middleware: authentication (UseAuthentication) establishes who the caller is — via cookies, JWT bearer tokens, OAuth/OpenID Connect, or an external identity provider — and populates a ClaimsPrincipal on the request; authorization (UseAuthorization) then decides what that identity is allowed to do, via [Authorize] attributes and policies that check roles or claims. Authentication always has to run before authorization in the pipeline, since authorization has nothing to check permissions against otherwise.

Q81. What is the Identity system in .NET Core?

ASP.NET Core Identity is the built-in membership system — user accounts, password hashing, email confirmation, two-factor auth, external login providers (Google, Microsoft, etc.) — backed by EF Core by default, so it plugs into the same database as the rest of the app. It's the right default for apps that own their own user accounts; for pure API-to-API or SPA-backend scenarios, plain JWT bearer auth without full Identity is often simpler.

Q82. Describe how to implement JWT authentication in .NET Core.

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = config["Jwt:Issuer"],
            ValidAudience = config["Jwt:Audience"],
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(config["Jwt:SigningKey"]!)),
        };
    });

builder.Services.AddAuthorization();
// ...
app.UseAuthentication();
app.UseAuthorization();

Q83. Discuss the use of HTTPS redirection and HSTS in .NET Core apps.

UseHttpsRedirection() issues a 301 redirect from any plain HTTP request to its HTTPS equivalent — but that first request still went out unencrypted. UseHsts() closes that gap by telling the browser (via the Strict-Transport-Security header) to never attempt plain HTTP again for a given duration, so even the first request on a returning visit goes straight to HTTPS.

Q84. How can you secure API endpoints in .NET Core?

• Require authentication by default and opt individual endpoints out ([AllowAnonymous]), not the other way around
• Use policy-based [Authorize(Policy = "...")] for anything beyond a simple role check
• Rate-limit sensitive or expensive endpoints (built-in System.Threading.RateLimiting middleware since .NET 7)
• Validate every input model — [ApiController] already triggers automatic model validation and a 400 on failure
• Return generic error messages for auth failures — don't leak whether a username exists vs. the password was wrong

Contemporary .NET Core

Q85. What is the future of .NET Core with upcoming releases of .NET 5 and later?

Since .NET 5 dropped "Core" from the name, Microsoft has committed to a predictable yearly release every November: even-numbered versions (6, 8, 10…) are Long-Term Support (roughly 3 years of support), odd-numbered versions (7, 9, 11…) are Standard-Term Support (about 18 months), aimed at teams that want to track improvements more closely. That cadence — rather than any single release — is the actual long-term plan: continuous, incremental delivery instead of the multi-year gaps .NET Framework had.

Q86. How has the introduction of .NET 5 changed the way .NET Core is used?

.NET 5 merged .NET Core, .NET Framework's remaining relevant pieces, and Mono/Xamarin's mobile runtime into one unified platform and one BCL — which is also why .NET Standard, the compatibility-shim spec that used to bridge them, became largely unnecessary going forward. Practically, it means a single mental model and a single set of APIs whether you're building a web API, a desktop app, or a mobile app, instead of three separate ecosystems with their own quirks.

Q87. Discuss the role of .NET Core in IoT development.

.NET's ARM32/ARM64 support and small runtime footprint make it viable on devices like the Raspberry Pi, and the System.Device.Gpio and Iot.Device.Bindings packages give direct access to GPIO pins, I2C/SPI buses, and a large catalog of common sensors/displays — so the same C# skills used for a web API extend to reading a temperature sensor or driving a relay, without switching to a different language stack for the device layer.

Q88. What impact does .NET Core have on desktop application development with technologies like MAUI?

.NET MAUI (the successor to Xamarin.Forms) is a single-project, single-codebase framework for iOS, Android, Windows, and macOS built on the same unified .NET — one C#/XAML codebase compiles down to each platform's native UI toolkit rather than a webview wrapper, which is the main reason it replaced Xamarin.Forms's multi-project structure.

Q89. Explain the support for gRPC in .NET Core.

gRPC is a high-performance RPC framework using HTTP/2 and Protocol Buffers for a compact binary wire format — meaningfully faster and smaller on the wire than JSON-over-REST, with a strongly-typed contract (a .proto file) generating client and server code in whatever language each side uses. ASP.NET Core has first-class support via the Grpc.AspNetCore package, and it's the natural choice for internal service-to-service calls in a microservices setup where you control both ends, less so for a public API a browser needs to call directly.

// greet.proto defines: service Greeter { rpc SayHello (HelloRequest) returns (HelloReply); }

public class GreeterService : Greeter.GreeterBase
{
    public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context) =>
        Task.FromResult(new HelloReply { Message = $"Hello {request.Name}" });
}

// Program.cs
builder.Services.AddGrpc();
app.MapGrpcService<GreeterService>();

.NET Core and Front-End Frameworks

Q90. How can you integrate Angular, React, or Vue.js with a .NET Core Web API?

The common, current pattern is two independent projects: a .NET Core Web API exposing JSON endpoints, and a separately built/deployed SPA (via Vite, Next.js, Angular CLI) that calls it over HTTP — decoupled deployment and scaling for each side. CORS has to be explicitly configured on the API (AddCors + UseCors) whenever the two are served from different origins, which they usually are during development at least.

builder.Services.AddCors(options =>
    options.AddPolicy("AllowFrontend", policy =>
        policy.WithOrigins("https://myapp.com").AllowAnyHeader().AllowAnyMethod()));

app.UseCors("AllowFrontend");

Q91. What is a SPA (Single Page Application) template in .NET Core?

Earlier .NET Core versions shipped `dotnet new angular`/`react` templates that bundled a JS front end and the .NET backend into one project with one build. Microsoft has since deprecated those templates — the current recommendation is exactly the decoupled setup above, standing up the front end with its own modern tooling (Vite, the framework's own CLI) and pointing it at a separate Web API rather than sharing one project.

Q92. Discuss server-side rendering with JavaScript frameworks in the context of .NET Core.

SSR frameworks (Next.js, Nuxt, Remix) increasingly run as their own Node-based front-end tier that calls a .NET Core API as its backend-for-frontend, rather than .NET Core doing the rendering itself — .NET's own answer to "UI rendered on the server" today is Blazor's Static SSR / Server render modes, not hosting a JS SSR engine inside ASP.NET Core.

.NET Core Advanced Features

Q93. What new features are introduced in the latest version of .NET Core?

• Minimal APIs and top-level statements — far less boilerplate for small services
• Native AOT — compile straight to native code for near-instant startup and a smaller footprint
• Keyed DI services — register multiple implementations of the same interface, resolved by key
• Built-in rate limiting middleware — no third-party package needed for basic throttling
• Blazor Web Apps with per-component render modes — Static SSR, Server, WebAssembly, or Auto

The exact list depends on which release you're being asked about — since .NET ships every November, the honest interview answer is naming the general direction (faster startup, less ceremony, unified Blazor) plus one or two concrete examples, rather than reciting a changelog from memory.

Q94. How does .NET Core support machine learning with ML.NET?

ML.NET is Microsoft's open-source ML framework built for .NET developers — train and consume models (classification, regression, recommendation, anomaly detection) using C#/F# and familiar .NET tooling, without needing to learn Python. It also supports loading models trained elsewhere (ONNX, TensorFlow) for inference, which is the more common real-world path — train in Python where the ML ecosystem is richest, then serve inference from a .NET Core API in production.

Q95. Discuss Source Generators and their use in .NET Core.

Source Generators are Roslyn compiler plugins that inspect your code at compile time and generate additional C# source to compile alongside it — real code, not runtime reflection, so there's zero startup-time reflection cost. System.Text.Json's [JsonSerializable] source-generated serializers and the [LoggerMessage] attribute for allocation-free logging are the two most common examples a .NET Core developer will actually touch.

public partial class OrderLog
{
    [LoggerMessage(Level = LogLevel.Information, Message = "Order {OrderId} processed in {Ms}ms")]
    public partial void OrderProcessed(ILogger logger, int orderId, long ms);
}
// The compiler generates the actual logging implementation for this method —
// no boxing, no string formatting, at compile time.

Q96. What are dynamic compilations and how does .NET Core handle them?

"Dynamic compilation" usually means generating and executing code at runtime — via System.Linq.Expressions (building and compiling expression trees on the fly), System.Reflection.Emit (emitting IL directly), or Roslyn's own scripting APIs (Microsoft.CodeAnalysis.CSharp.Scripting) to compile and run a C# snippet given as a string. It's powerful for rules engines and plugin systems but sits in tension with Native AOT, which needs to know everything at publish time — a heavily reflection/dynamic-compilation-based app generally can't be trimmed or AOT-compiled without extra work.

Q97. Explain the support for local functions in .NET Core.

public int SumOfSquares(IEnumerable<int> numbers)
{
    int Square(int n) => n * n;   // local function — only visible inside SumOfSquares

    return numbers.Sum(Square);
}

Local functions (C# 7+) are methods defined inside another method — useful for small helper logic that's only meaningful in one place, without polluting the class with a private method or paying for a full lambda/delegate allocation. Unlike a private method, they can also capture the enclosing method's local variables directly, the same way a lambda closure does.

Q98. Discuss null reference types in C# 8.0 and how they affect .NET Core development.

#nullable enable

public class Order
{
    public string Id { get; set; } = "";       // never null — compiler-enforced
    public string? DiscountCode { get; set; }   // explicitly nullable
}

string code = order.DiscountCode; // compiler warning: possible null assigned to non-nullable

Nullable reference types don't change runtime behavior at all — a null is still just null — but they let the compiler flag places where a possibly-null value flows into a spot that assumes it isn't, catching a huge class of NullReferenceException bugs at compile time instead of in production. It's opt-in per project (<Nullable>enable</Nullable> in the csproj) and the default in every project template since .NET 6.

.NET Core Community and Support

Q99. How does the .NET Core open source community contribute to the framework's development?

The runtime, ASP.NET Core, and EF Core are all developed fully in the open on GitHub (dotnet/runtime, dotnet/aspnetcore, dotnet/efcore) under the .NET Foundation — anyone can file issues, propose API changes through the public "API review" process, and submit pull requests that Microsoft engineers review and merge directly, not just report bugs into a black box. Community-maintained packages (Serilog, Polly, MediatR, AutoMapper, and hundreds more) fill gaps the framework deliberately leaves unopinionated, which is as much a part of "the .NET ecosystem" in practice as the framework itself.

Q100. What's the difference between LTS and STS releases, and where do you go for support or to contribute?

Every even-numbered .NET version (6, 8, 10…) is Long-Term Support — about three years of patches, the safe default for production unless you specifically need something newer. Every odd-numbered version (7, 9, 11…) is Standard-Term Support — roughly 18 months, for teams that want to stay closer to the latest features and are willing to upgrade yearly. For support: GitHub issues on the relevant repo for bugs, the Microsoft Q&A / Stack Overflow for usage questions, and the .NET Foundation / community standups for anyone wanting to get involved in the framework's direction rather than just consume it.

Test yourself

A quick mock test covering the ground above — the kind of rapid-fire round that often opens a .NET Core interview before the deeper follow-ups.