What problem does a multi-stage Docker build solve?

It keeps the production image small by compiling in one stage and copying only the build artifact to a minimal runtime stage — no source code, build tools, or devDependencies.

What is the difference between a Pod and a Deployment in Kubernetes?

A Pod is a single running instance of a container group. A Deployment is the controller that manages a desired number of Pod replicas, handles rollouts, and restarts failed pods.

What does a Kubernetes Service do that a Pod IP cannot?

A Service provides a stable virtual IP that persists across pod restarts and load-balances traffic across all healthy replicas. Pod IPs are ephemeral.

When should a frontend team choose containers over serverless functions?

When the app needs long-running processes (WebSockets, background queues), persistent connections, or more control over the runtime — and the team can accept the ops overhead.

What does Next.js output: 'standalone' do and why does it matter for Docker?

It traces which Node modules are actually used at runtime and writes a self-contained server directory. The Docker image copies that directory instead of the full node_modules, cutting image size significantly.

What is an image layer and why does layer order matter in a Dockerfile?

Each Dockerfile instruction creates a read-only layer. Docker reuses cached layers until a layer changes. Putting infrequently changing steps (e.g., npm ci) before frequently changing ones (e.g., COPY . .) maximises cache reuse.

Containers & Kubernetes

Summary

A container bundles an app and its runtime into a portable image, eliminating environment drift. Docker builds images from layered instructions. Kubernetes schedules containers across machines, handles restarts, and routes traffic via Services and Ingress. Most frontend teams only need this when they run a Node SSR server at scale — static sites and serverless functions skip it entirely.

Jump to the interview angle

A container is a process isolated by Linux namespaces and cgroups, sharing the host kernel but with its own filesystem snapshot — the image. Images are built in read-only layers: each Dockerfile instruction adds a layer, and unchanged layers are reused across builds and pulls. A multi-stage build compiles in one image and copies only the output artifact into a lean runtime image, keeping production images small and free of build tooling.

Multi-stage Dockerfile for a Next.js app

Two stages: builder runs next build, runner copies only the standalone output. Production image has no source code, no devDependencies, no compiler.

Dockerfile — Next.js standalone outputdockerfile

# Stage 1 — install deps and build
FROM node:22-alpine AS builder
WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci

COPY . .
# next.config.ts must set output: "standalone"
RUN npm run build

# Stage 2 — minimal runtime image (~120 MB vs ~800 MB)
FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production

# next build --output=standalone writes a self-contained server
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public

EXPOSE 3000
CMD ["node", "server.js"]

The standalone output (Next.js ≥12.2) bundles only the Node modules actually used at runtime. The final image copies three directories, not the full node_modules.

Kubernetes primitives a frontend engineer needs

**Pod** — smallest deployable unit; one or more containers sharing a network namespace and storage.
**Deployment** — declares desired replica count; replaces pods on update, rolls back on failure.
**Service** — stable virtual IP that load-balances across pod replicas inside the cluster.
**Ingress** — HTTP router that maps hostnames and paths to Services; handles TLS termination.
**ConfigMap / Secret** — inject env vars into pods without rebuilding the image.

When does a frontend actually need containers?

You need containers when you run a stateful Node process at scale: SSR servers, BFF APIs, or WebSocket servers that require always-on replicas and rolling deploys. Static sites (export to S3/CDN) and serverless functions (Vercel, AWS Lambda) skip Docker and Kubernetes entirely — the platform handles packaging and scaling for you.

Interview angle

Interviewers check whether you know the cost: containers add ops overhead that static hosting eliminates. Show you can pick the right deployment target, not just build a Dockerfile. Name the Next.js standalone output as a concrete size win.

Soundbite: "Containers solve environment parity and scaling for stateful servers — but most frontends never need them."

Key terms

Image layer: Read-only filesystem diff from one Dockerfile instruction; shared across builds to speed pulls.
Multi-stage build: Dockerfile pattern: compile in one stage, copy only the output to a lean runtime stage.
Pod: Kubernetes scheduling unit; one or more containers sharing a network namespace.
Ingress: Kubernetes HTTP router mapping hostnames and URL paths to backend Services.
Standalone output: Next.js build mode (output: 'standalone') that bundles only the runtime Node modules needed to run the server.

Summary

Multi-stage Dockerfile for a Next.js app

Kubernetes primitives a frontend engineer needs

Interview angle

Key terms

Related topics

Further reading

Search fearchitect