How do multi-stage Docker builds optimize image size and security?

I am preparing for a senior container engineering interview where candidate discussions often touch on container optimization and CI/CD build efficiency. Multi-stage Docker builds are a standard topic, but I want to ensure my explanation goes deeper than just saying 'it makes images smaller.'

Consider this conceptual structure of a multi-stage Dockerfile for a compiled application:

# Define build stage using full Go SDK
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
# Compile binary executable without extra debugging symbols
RUN go build -o myapp .

# Define runtime stage using lightweight Alpine distribution
FROM alpine:3.19
WORKDIR /app
# Copy only compiled binary from builder stage into minimal image
COPY --from=builder /app/myapp .
CMD ["./myapp"]

I want to understand the exact technical points to highlight when asked about multi-stage builds in an interview. In particular:

• How multi-stage builds discard build-time compilers, development libraries, and intermediate cache layers from the final artifact.
• The security benefits of reducing attack surface area by omitting package managers and shell utilities in slim or distroless runtime images.
• How COPY --from works across different stages and how named build stages improve readability and maintainability in production pipelines.