Shipping ASP.NET Core means more than passing tutorials: configuration, observability, security headers, and deployment topology matter in production.
Before deploy
- Pin SDK/runtime in CI and Docker (
mcr.microsoft.com/dotnet/aspnet:8.0) ASPNETCORE_ENVIRONMENT=Production; secrets via Key Vault or env vars- HTTPS everywhere; HSTS and forwarded headers behind reverse proxy
- Health checks (
/health), structured logging (Serilog), metrics (OpenTelemetry) - Run EF migrations in controlled pipeline step—not on every pod startup blindly
- Enable response compression and caching where safe
Runtime hygiene
- Connection pool limits; async database access
- Rate limiting and CORS configured explicitly—not
AllowAnyOriginin prod - Graceful shutdown; drain requests before SIGTERM in Kubernetes
Important interview questions and answers
- Q: Kestrel vs IIS?
A: Kestrel is in-process server; IIS/nginx terminate TLS and reverse-proxy to Kestrel in many deployments. - Q: Where store connection strings?
A: Environment-specific config or secret store—never committed plaintext for production DBs.
Self-check
- Why use a slim runtime Docker image?
- What does forwarded headers middleware fix?
Challenge
Local ASP.NET check
- Install the .NET SDK and run
dotnet --version. - Run
dotnet new web -n Demoanddotnet runinside the folder. - Open the HTTPS URL shown in the terminal.
Done when: you see the default ASP.NET Core welcome page in the browser.