What would you put in a production Docker image for an ASP.NET Core API, and how would you keep the image small, secure, and repeatable?

Build a production container image for a .NET API

Builds a small, immutable, non-root .NET runtime image with controlled inputs, external configuration, graceful lifecycle behavior, and a practical patching strategy.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would use a multi-stage build: restore, build, test, and publish with an SDK image, then copy only the published output into the matching ASP.NET Core runtime image. The final image would run as a non-root user, contain no source code or secrets, and receive environment-specific configuration at runtime. I would tag it with the commit or release identity and deploy that immutable image through every environment. A .dockerignore would keep build output, repository metadata, and local secrets out of the build context.

Full answer below

Practice focus

Multi-stage builds, SDK and runtime separation, immutable images, non-root execution, configuration, secrets, lifecycle signals, diagnostics, and patching.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A container image becomes the deployable application boundary. Build choices affect repeatability, startup, patching, diagnostics, and the permissions an attacker receives if the process is compromised.
I would use a multi-stage build: restore, build, test, and publish with an SDK image, then copy only the published output into the matching ASP.NET Core runtime image. The final image would run as a non-root user, contain no source code or secrets, and receive environment-specific configuration at runtime. I would tag it with the commit or release identity and deploy that immutable image through every environment. A .dockerignore would keep build output, repository metadata, and local secrets out of the build context.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would make the inputs controlled and the runtime behavior explicit. Package lock files and pinned base-image versions improve repeatability, while build cache layers keep restore efficient. The API writes logs to standard output, exposes separate liveness and readiness behavior, listens on the documented port, and handles termination long enough to stop accepting traffic and finish bounded work. The filesystem can be read-only apart from deliberate temporary paths, and the deployment sets CPU, memory, and process limits rather than relying on the image to discover them.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would choose the final base image by balancing size, compatibility, and diagnostic needs; a smaller or chiseled image reduces surface area but can make emergency inspection harder. Base images and NuGet dependencies need routine vulnerability review and a rebuild path so a patched runtime can be released without an application change. I would test the image itself for startup, health, shutdown, configuration, certificate, globalization, and filesystem assumptions. Multi-architecture output, registry retention, and rollback tags would be deliberate, while deployment still identifies the exact image digest rather than a mutable tag such as latest.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Shipping the SDK and build tools in the runtime image.
Copying the entire repository, secrets, or local configuration into the image.
Running as root because the application works locally that way.
Deploying a mutable latest tag with no commit or digest traceability.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The image must be rebuilt separately for each environment.
Shutdown kills active requests or background work without a bounded drain period.
A runtime patch cannot be rolled out without an improvised Dockerfile change.
No test runs against the same image that production will execute.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why use separate SDK and runtime image stages?
What changes when the container filesystem is read-only?
How would you roll out a patched .NET base image?

Continue the section