Concept questionMedium~7 minContainers & Runtime Essentials / 3 of 15

Interview question

A .NET Docker build is slow and rebuilds restore layers after almost every source edit. How would you improve it without making the image unreliable?

Docker build context, layer caching, and reproducible .NET builds

Builds deterministic images efficiently by controlling context, restore layers, dependency inputs, and cache invalidation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would keep the build context small with .dockerignore, then copy solution, project, and dependency files before running dotnet restore. Source files are copied afterward, so a code-only change can reuse the restore layer. I would include every file that affects restore, such as NuGet.config, Directory.Build.props, Directory.Packages.props, and lock files, so the cache is fast without becoming stale.

Full answer below

Practice focus

Build context, .dockerignore, Docker layers, project files, dotnet restore, locked dependencies, cache invalidation, and CI caches.

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
Docker reuses an instruction only when that layer and its inputs still match. The order of COPY and restore steps determines whether an ordinary source edit invalidates the expensive dependency layer.
I would keep the build context small with .dockerignore, then copy solution, project, and dependency files before running dotnet restore. Source files are copied afterward, so a code-only change can reuse the restore layer. I would include every file that affects restore, such as NuGet.config, Directory.Build.props, Directory.Packages.props, and lock files, so the cache is fast without becoming stale.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A multi-stage build keeps SDK and compiler artifacts out of the runtime image. In CI I can use BuildKit cache mounts or a remote cache, but the build must remain correct when the cache is empty. I pin the SDK through the build image and use controlled package sources and locked dependency versions where the project requires repeatability. Secrets for private feeds use build-secret mechanisms and must not appear in Dockerfile arguments or persisted layers.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I separate speed from provenance. The resulting image should record the source revision, dependency inputs, base-image digest, and build pipeline identity without embedding credentials. I rebuild in a clean environment periodically to catch accidental cache dependence. Cache keys include platform and relevant configuration, while generated output, local packages, and repository metadata stay outside the context unless needed. I compare build duration and cache-hit evidence, but a fast build that can silently use the wrong dependency graph is a failed optimization.

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

Copying the whole repository before dotnet restore.
Leaving bin, obj, and local secrets in the build context.
Assuming CI cache is required for correctness.
Passing feed credentials through ARG values.

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

Details

A source edit downloads every package again.
Clean builds produce a different dependency graph.
Secrets appear in image history.
Important central build files are not copied before restore.

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.

Which files affect dotnet restore?
Why does Dockerfile instruction order matter?
How would you use private NuGet credentials safely?

Continue the section

Next in Containers & Runtime Essentials: Image identity and patching

Step 4 of 15

Container image tags, digests, registries, and patching

Opening drill

Concept questionMedium~7 minContainers & Runtime Essentials / 3 of 15

Interview question

A .NET Docker build is slow and rebuilds restore layers after almost every source edit. How would you improve it without making the image unreliable?

Docker build context, layer caching, and reproducible .NET builds

Builds deterministic images efficiently by controlling context, restore layers, dependency inputs, and cache invalidation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Build context, .dockerignore, Docker layers, project files, dotnet restore, locked dependencies, cache invalidation, and CI caches.

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
Docker reuses an instruction only when that layer and its inputs still match. The order of COPY and restore steps determines whether an ordinary source edit invalidates the expensive dependency layer.
I would keep the build context small with .dockerignore, then copy solution, project, and dependency files before running dotnet restore. Source files are copied afterward, so a code-only change can reuse the restore layer. I would include every file that affects restore, such as NuGet.config, Directory.Build.props, Directory.Packages.props, and lock files, so the cache is fast without becoming stale.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A multi-stage build keeps SDK and compiler artifacts out of the runtime image. In CI I can use BuildKit cache mounts or a remote cache, but the build must remain correct when the cache is empty. I pin the SDK through the build image and use controlled package sources and locked dependency versions where the project requires repeatability. Secrets for private feeds use build-secret mechanisms and must not appear in Dockerfile arguments or persisted layers.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I separate speed from provenance. The resulting image should record the source revision, dependency inputs, base-image digest, and build pipeline identity without embedding credentials. I rebuild in a clean environment periodically to catch accidental cache dependence. Cache keys include platform and relevant configuration, while generated output, local packages, and repository metadata stay outside the context unless needed. I compare build duration and cache-hit evidence, but a fast build that can silently use the wrong dependency graph is a failed optimization.

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

Copying the whole repository before dotnet restore.
Leaving bin, obj, and local secrets in the build context.
Assuming CI cache is required for correctness.
Passing feed credentials through ARG values.

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

Details

A source edit downloads every package again.
Clean builds produce a different dependency graph.
Secrets appear in image history.
Important central build files are not copied before restore.

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.

Which files affect dotnet restore?
Why does Dockerfile instruction order matter?
How would you use private NuGet credentials safely?

Continue the section

Next in Containers & Runtime Essentials: Image identity and patching

Step 4 of 15

Container image tags, digests, registries, and patching

A .NET Docker build is slow and rebuilds restore layers after almost every source edit. How would you improve it without making the image unreliable?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A .NET Docker build is slow and rebuilds restore layers after almost every source edit. How would you improve it without making the image unreliable?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section