ASP.NET Core Deployment & Docker Interview Questions for Senior .NET Developers (2026)

Deployment and containerisation have moved from "ops concerns" to core developer competency. In 2026, senior .NET engineers are routinely questioned on Dockerfile structure, Kubernetes readiness probes, CI/CD pipeline design, and production-readiness thinking — not just on C# syntax and design patterns. Whether you are preparing for a staff engineer interview or evaluating a candidate, this guide covers the questions that consistently appear in senior-level technical rounds, along with clear, substantive answers that separate strong candidates from surface-level ones.

If you want to go deeper than theory — with annotated, production-ready Dockerfiles, GitHub Actions workflows, and fully wired deployment setups you can clone and adapt — the complete implementations are available on Patreon. The patterns covered here are exactly what enterprise .NET teams ship.

Understanding deployment in isolation is useful, but seeing it wired into a complete ASP.NET Core Web API — alongside authentication, caching, error handling, and observability — is what makes it click. Chapter 15 of the Zero to Production course walks through the full production Dockerfile, GitHub Actions CI/CD pipeline, and Docker Compose setup inside a real codebase you can run immediately.

---

Basic: Foundational Docker & Containerisation Questions

What is a multi-stage Docker build, and why is it required for .NET applications?

A multi-stage Docker build uses multiple FROM statements in a single Dockerfile. Each stage produces an intermediate image; subsequent stages can copy specific artefacts from earlier ones. For .NET applications, the standard pattern is:

• Stage 1 (build): Uses the full .NET SDK image to restore packages, build the project, and publish the release output.
• Stage 2 (runtime): Uses a smaller ASP.NET runtime image and copies only the published output from stage 1.

The result is a final image that contains no SDK, no source files, and no build tooling — only the runtime and the compiled application. This typically reduces image size from several hundred megabytes (SDK image) to roughly 100–250 MB (runtime image), depending on the application.

Without a multi-stage build, the image either bloats with build tools or requires a separate build pipeline outside Docker to produce the publish output.

---

What is the difference between the .NET SDK image and the ASP.NET runtime image?

The SDK image should only appear in build stages, never in the final image. Strong candidates know this distinction immediately and explain the security motivation: a smaller attack surface in production.

---

What is a .dockerignore file, and why does it matter for .NET builds?

.dockerignore works like .gitignore — it tells the Docker CLI which files to exclude from the build context before sending it to the Docker daemon. For .NET projects, the most important exclusions are:

• **/bin/ and **/obj/ — local build artefacts that should not interfere with the container's build
• .git/ — version control history adds unnecessary size
• *.user and launchSettings.json — developer-machine-specific files

Without a .dockerignore, the Docker build context includes all local build output and tooling files, which can slow builds significantly and pollute the container's restore/build steps with stale artefacts.

---

How should ASP.NET Core configuration work inside a Docker container?

ASP.NET Core reads configuration through a layered provider hierarchy: appsettings.json, appsettings.{Environment}.json, environment variables, and command-line arguments — in that order, with later providers overriding earlier ones.

In a containerised deployment:

• appsettings.json contains non-sensitive defaults that are baked into the image
• Sensitive values (connection strings, API keys) are injected at runtime as environment variables — either from docker run -e, Docker Compose environment: keys, Kubernetes Secrets mounted as env vars, or a secrets manager like Azure Key Vault
• The ASPNETCORE_ENVIRONMENT environment variable controls which appsettings.{Environment}.json is loaded

A strong candidate warns against baking secrets into images — any secret in an image layer is permanently accessible via docker history.

---

What is the non-root user pattern in Docker, and why is it a production requirement?

By default, Docker containers run as root. This is a security risk: if an attacker exploits a vulnerability in the application, they gain root access inside the container and — depending on the host configuration — potentially on the host itself.

The non-root pattern involves creating a dedicated system user in the Dockerfile and switching to that user before the ENTRYPOINT. Microsoft's .NET sample Dockerfiles include this pattern. Enterprise security policies and container platform compliance checks typically flag containers running as root. Candidates who mention this demonstrate production security awareness rather than just "it works on my machine" thinking.

---

Intermediate: CI/CD, Kubernetes, and Production Readiness

What does a production-ready GitHub Actions workflow for a .NET API look like?

A complete workflow has two distinct jobs:

Job 1 — Build and Test:

• Checkout code
• Setup .NET SDK (specify exact version, e.g., dotnet-version: '10.x')
• Restore packages
• Build in Release configuration
• Run unit and integration tests
• Fail the pipeline on any test failure

Job 2 — Build and Push Docker Image (only on main branch):

• Login to container registry (e.g., GitHub Container Registry ghcr.io or ACR)
• Build Docker image with a versioned tag (Git SHA is preferred over latest)
• Push image to registry

Key senior-level points:

• Never tag production images as latest — it makes rollbacks and audits impossible
• SHA tagging (ghcr.io/org/app:abc1234) gives you an immutable, traceable artefact
• Separation of build-and-test from image push is intentional: tests gate the release
• Layer caching (using actions/cache or Docker's --cache-from) significantly reduces CI build times

---

What are the three Kubernetes probe types, and how do they map to ASP.NET Core health checks?

A common mistake is configuring a liveness probe that checks the database. If the database goes down, Kubernetes will restart all pods — compounding an outage rather than isolating it. Liveness should only check the application process itself. Readiness checks dependencies.

---

How do you handle database migrations in a Dockerised ASP.NET Core application?

There are three common approaches, each with different trade-offs:

1. MigrateAsync at startup (context.Database.MigrateAsync() in Program.cs)

• Simple, self-contained
• Risk: every pod instance runs migrations on startup — race conditions in multi-replica deployments if EF Core migrations are not idempotent
• Acceptable for single-instance or carefully designed low-risk scenarios

2. Kubernetes init container

• A separate container runs dotnet ef database update before the main container starts
• Kubernetes ensures the init container completes successfully before starting the main pod
• Clean separation of migration from application runtime

3. Separate migration job

• A Kubernetes Job or CI/CD pipeline step runs migrations as a one-time task
• Most controlled approach for production: migrations are an explicit, auditable step, not an implicit startup side effect

Strong candidates can articulate the race condition risk in approach 1 and explain why teams with multiple replicas or strict change management prefer approaches 2 or 3.

---

What is layer caching in Docker, and how do you optimise a .NET Dockerfile to take advantage of it?

Docker caches each layer produced by a RUN, COPY, or ADD instruction. A cache hit means Docker skips re-executing that layer — dramatically speeding up rebuilds.

The key optimisation for .NET is to copy and restore the project files before copying application source code. The pattern is: copy .sln and .csproj files first, run dotnet restore, then copy the full source and run dotnet publish. This way, as long as project files haven't changed, Docker reuses the NuGet restore layer from cache — saving minutes per build in large solutions.

If the restore and the full source copy happen on the same layer, every source code change invalidates the restore cache and forces a full package download on every build. Separating these into distinct layers is the single highest-value Dockerfile optimisation for .NET teams.

---

How should you pass environment-specific configuration to an ASP.NET Core container at runtime?

The correct pattern for containerised .NET apps:

1. Non-sensitive configuration: Bake appsettings.json defaults into the image. For environment overrides, mount appsettings.Production.json as a ConfigMap volume in Kubernetes (appropriate for non-sensitive environment flags, feature toggles, external URLs).

2. Sensitive configuration: Inject as environment variables from Kubernetes Secrets, Azure Key Vault (via the Key Vault provider), AWS Secrets Manager, or HashiCorp Vault. Never mount secrets as files in Kubernetes unless explicitly encrypting at rest.

3. ASPNETCORE_URLS: Set this to http://+:8080 (non-privileged port) in the Dockerfile or compose file — required when running as a non-root user, since ports below 1024 require elevated privileges.

4. ASPNETCORE_ENVIRONMENT: Always set explicitly (Production, Staging, etc.) — do not rely on defaults.

---

What is the Docker Compose role in .NET development, and what should it not be used for?

Use in development:

• Spin up the full local stack (API + PostgreSQL + Redis + any messaging infrastructure) with a single docker compose up
• Ensures every developer has an identical local environment
• Eliminates "works on my machine" dependency issues

What Compose is not for:

• Production deployment — Compose lacks Kubernetes-grade health management, rolling updates, autoscaling, and multi-node orchestration
• CI/CD artifact management — use a proper registry and Kubernetes manifests

A well-architected project maintains a docker-compose.yml (local dev) and separate Kubernetes YAML manifests (production) — Compose is a developer productivity tool, not a production orchestrator.

---

Advanced: Production Operations, Security, and Architecture

How do you implement zero-downtime deployments for an ASP.NET Core API in Kubernetes?

Zero-downtime deployments rely on:

1. Rolling update strategy: Kubernetes gradually replaces old pods with new ones (maxUnavailable: 0, maxSurge: 1 is a common production setting). No old pod is terminated until the new pod passes its readiness probe.

2. Correct readiness probe configuration: The new pod must not receive traffic until it is genuinely ready — including database migrations, connection pool warmup, and cache preloading.

3. Graceful shutdown handling in ASP.NET Core: When Kubernetes sends SIGTERM, ASP.NET Core has a configurable grace period (ASPNETCORE_SHUTDOWNTIMEOUTSECONDS) to finish in-flight requests. The IHostedService.StopAsync method should clean up background workers without abruptly dropping requests.

4. Connection draining: If behind a load balancer or Ingress, ensure the load balancer removes the pod from rotation before the pod terminates (Kubernetes handles this with pod lifecycle hooks — preStop sleep is a common workaround for timing gaps).

A candidate who only mentions "rolling update" without addressing readiness probes or graceful shutdown is describing the theory without the operational reality.

---

What are the security hardening steps you apply to a .NET Docker image before production?

1. Non-root user (covered above — mandatory)
2. Use specific image tags, not latest — mcr.microsoft.com/dotnet/aspnet:10.0-bookworm-slim not aspnet:latest — prevents unexpected runtime changes from upstream updates
3. Distroless or minimal base images — consider mcr.microsoft.com/dotnet/aspnet:10.0-alpine to further reduce attack surface (fewer packages = fewer CVEs)
4. No secrets in image — verified via image scanning (Trivy, Snyk, Docker Scout)
5. Read-only filesystem where possible — mark the container root as read-only and explicitly mount only writable paths (temp, logs)
6. Container vulnerability scanning in CI — run Trivy or equivalent on every image before pushing to the registry; fail the pipeline on CRITICAL CVEs
7. Drop Linux capabilities in Kubernetes: securityContext.capabilities.drop: ["ALL"]

Strong candidates can name specific tools (Trivy, Snyk) and reference Kubernetes securityContext fields — indicating they have shipped to production, not just built demos.

---

How do you handle secrets rotation in a containerised .NET application without redeployment?

Three patterns are commonly used:

1. Kubernetes Secrets with volume mounts + reloading: Mount the secret as a file. Kubernetes updates the mounted file when the Secret is updated (with a configurable sync delay). ASP.NET Core's IOptionsMonitor<T> with a file-based configuration provider can hot-reload without restart.

2. Azure Key Vault with ASP.NET Core provider: The Azure.Extensions.AspNetCore.Configuration.Secrets package supports periodic reload intervals. Set ReloadInterval to poll the vault and pick up rotated values without pod restarts.

3. Sidecar/agent pattern: Vault Agent (HashiCorp) or the Secrets Store CSI Driver can inject refreshed secrets as files or environment variables, triggering application reload through signal or file-watching.

The anti-pattern to flag: baking a specific secret value into the image at build time. Any rotation requires a full image rebuild and redeployment — operationally fragile for credentials that rotate frequently.

---

What production-readiness checks do you apply before declaring a .NET API ready for live traffic?

A production readiness checklist for a Dockerised ASP.NET Core API:

Container:

• Multi-stage build, non-root user, minimal base image
• No secrets baked in, vulnerability scan passing

Application:

• Structured logging (Serilog or equivalent) with correlation IDs on every log entry
• OpenTelemetry traces and metrics exported to the observability backend
• /health/live and /health/ready endpoints responding correctly
• ASPNETCORE_ENVIRONMENT=Production confirmed
• Request timeout middleware configured
• Global error handler returning Problem Details (RFC 7807) — no raw exceptions exposed

Kubernetes:

• Liveness, readiness, and startup probes configured with appropriate intervals and thresholds
• Resource requests and limits set (missing limits → noisy neighbour problems; missing requests → incorrect scheduling)
• PodDisruptionBudget defined for high-availability services
• HorizontalPodAutoscaler configured for traffic-sensitive endpoints

Pipeline:

• Build, test, and security scan all passing
• SHA-tagged image in registry
• Deployment tracked (ArgoCD, Flux, or explicit GitOps)

Senior engineers who run through this kind of checklist fluently signal that they own operational quality, not just feature delivery.

---

☕ Prefer a one-time tip? Buy us a coffee — every bit helps keep the content coming!

---

Frequently Asked Questions

What Docker base image should I use for an ASP.NET Core application in 2026?

Use mcr.microsoft.com/dotnet/aspnet:10.0-bookworm-slim for the runtime stage of a multi-stage build. For production security, consider 10.0-alpine if you can handle Alpine's musl libc implications. Always pin to a specific version tag rather than latest to avoid unexpected upstream changes. The SDK image (mcr.microsoft.com/dotnet/sdk:10.0) is used only in the build stage and never ships to production.

What port should an ASP.NET Core container listen on?

Non-privileged ports (1024+) are required when the container runs as a non-root user. The convention in .NET 10 is port 8080, set via the ASPNETCORE_HTTP_PORTS or ASPNETCORE_URLS=http://+:8080 environment variable. In Kubernetes, the container port is 8080 and the Service exposes it on the desired external port.

How do I run Entity Framework Core migrations in a Kubernetes deployment?

The safest pattern for production is a Kubernetes init container or a dedicated Kubernetes Job that runs dotnet ef database update (or a custom migration runner) before the main application pods start. This ensures migrations are applied exactly once, in sequence, before any application instance begins serving traffic. Running MigrateAsync inside each pod's startup is simpler but introduces a race condition risk in multi-replica deployments.

What is the difference between a Kubernetes liveness probe and a readiness probe for ASP.NET Core?

A liveness probe answers: "Is the process still functioning?" If it fails, Kubernetes restarts the pod. Map it to a lightweight /health/live endpoint that only checks the application process. A readiness probe answers: "Is this pod ready to handle requests?" If it fails, the pod is removed from the Service load balancer — but not restarted. Map it to /health/ready, which checks external dependencies (database, Redis, downstream services). Never check external dependencies in a liveness probe — a failing database would trigger cascading pod restarts across all replicas.

How do I pass different appsettings to a Docker container per environment?

Three approaches in order of preference: (1) Inject environment-specific values as environment variables at runtime — the ASP.NET Core configuration system automatically overrides matching keys. (2) Mount a Kubernetes ConfigMap as a volume containing appsettings.Production.json. (3) For secrets, inject values from Kubernetes Secrets or a secrets manager (Azure Key Vault, HashiCorp Vault) — never bake them into the image. The application code should be identical across environments; only the configuration injected at runtime changes.

Why is the latest Docker tag considered harmful in production?

The latest tag is mutable — any push to the repository can overwrite it. In production, this means: (1) rollbacks become unreliable because you cannot guarantee which image version latest points to; (2) audits and incident investigation are impaired because you cannot trace which exact image was running at a given time; (3) CI/CD pipelines may silently deploy a different version than intended. The recommended practice is SHA-based tagging (e.g., ghcr.io/org/app:3f8a2c1) for production deployments, with semantic version tags (v1.4.2) as human-readable aliases.

What is ASPNETCORE_ENVIRONMENT and why must it be set explicitly in containers?

ASPNETCORE_ENVIRONMENT tells ASP.NET Core which environment-specific configuration to load (appsettings.Production.json, appsettings.Staging.json) and controls framework behaviours like detailed error pages and developer exception pages. Without it, the default is Production — but relying on defaults is fragile. Always set it explicitly in the Dockerfile or Kubernetes Deployment manifest. An application running with Development settings in a production container can expose exception details to end users — a direct security exposure.