Docker interview questions for senior developers

6 min read

If you are working as an engineer, front or backend, or in devOps then docker is a skill is expected . So, here are 12 questions that will help senior developers who are preparing of the interviews:

friend’s link: https://hellonehha.medium.com/docker-interview-questions-for-senior-developers-4f58a3206315?source=friends_link&sk=81b25d3099494ee3d4247adacae9be80

1. Explain Docker layering and how it affects image size and caching.

Docker images are built using a layers filesystem. Each instruction in the dockerfile (RUN, FROM, COPY, and ADD) creates a new immutable layer on top of the previous one. These layers stacked to form the final image.

When docker builds an image , it caches each layer. If dockefile’s instrcution has not changed then docker resue the cached layer instead of rebuilding it, which significantly speeds up image builds.

When a container is started from an image docker run, Docker adds a thin, writable container layer on top of the image layers. All changes made at runtime (such as file modifications) are stored in this writable layer, while the underlying image layers remain read-only.

Docker layer caching helps reduce build time and startup time. However, to optimize both image size and cache efficiency, Dockerfiles should be written carefully:

  1. All the least changing commands should be on the top of the file.
  2. All the frequently changing commands should be at the bottom of the file.
  3. Combine the commands:
//Instead of this  
  
RUN npm install  
RUN RUN npm run build  
  
// Do this  
  
RUN npm install && npm run build

// use -no-cache to disable cache  
docker build --no-cache -t myapp .

Layering impacts the image size. Every layer add up to the size of the image. Hence, it is important to follow the best practices as stated above.

2. What is the difference between CMD and ENTRYPOINT?

Docker has these 2 commands which people get confuse. Difference between CMD and ENTRYPOINT:

  1. CMD provides default arguments and can be overridden easily. Use CMD for flexible containers. Eg:
CMD ["echo", "Hello"]   
  
// run the docker image  
docker run myimage echo "Hi" // output Hi. It has override the default CMD - hello
  1. ENTRYPOINT defines the main executable and harder to override. Use ENTRYPOINT for Executable-style containers. Eg:
ENTRYPOINT ["echo"]  
CMD ["Hello"]  
  
// Run the docker image  
docker run myimage "Hi" // output echo.

3. How does Docker networking work?

Docker networking works by placing each container in its own network namespace and connecting it to a Docker-managed network using virtual Ethernet pairs.

By default, containers connect to a bridge network, where Docker assigns them private IP addresses and manages routing using iptables and NAT. Containers on the same user-defined bridge network can communicate using container names via Docker’s embedded DNS.

Docker supports multiple network drivers:

  1. Bridge for single-host container communication

2. Host for sharing the host network stack

3. Overlay for multi-host networking in Swarm or Kubernetes

4. None for complete network isolation

Ports are exposed using port publishing, which maps host ports to container ports via NAT rules.

4. Your Docker image size is 1.5GB. How do you reduce it?

To reduce the size of docker image, the best practices are:

  1. Use multi-stage builds. Break the dockerfile into, build, copy state.
  2. Switch to lightweight base images such as alpine or even scratch
  3. Remove build-time dependencies. Create a .dockerignore file and move the files which are not important for image.
# Build stage  
FROM node:18 AS builder  
WORKDIR /app  
COPY package*.json ./  
RUN npm install  
COPY . .  
RUN npm run build  
  
# Runtime stage  
FROM node:18-alpine  
WORKDIR /app  
COPY --from=builder /app/dist ./dist  
CMD ["node", "dist/index.js"]

5. A container works locally but fails in production. What will be your next step?

This will require a brute/force approach, logs, configuration, resource limits, etc. So, I will do the following:

  • Check logs first to identify startup or runtime errors.
  • Compare local vs production configuration, especially environment variables, secrets, and runtime versions.
  • Verify the image and tag running in production match what works locally.
  • Check resource limits, permissions, networking, and startup commands, which often differ in production.

6. Containers cannot communicate with each other.

Containers can only communicate directly if they are attached to the same Docker network. The recommended approach is to use a user-defined bridge network, which provides built-in DNS-based service discovery.

Best practices include:

  • Ensuring all related containers are attached to the same Docker network
  • Using container names as hostnames instead of hard-coded IPs
  • Avoiding localhost, since it refers to the container itself
  • Verifying connectivity and DNS resolution from inside the containers
docker network create app-net  
  
docker run -d --name api --network app-net api-image  
docker run -d --name web --network app-net web-image

http://api:8080

7. Application startup is slow inside Docker.

Slow container startup is usually caused by heavy images, runtime dependency installation, or inefficient Dockerfile layering.

To improve startup time:

  • Optimize Dockerfile caching so dependencies are installed only when necessary
  • Reduce image size by using lightweight base images and multi-stage builds
  • Remove unnecessary packages and runtime tools
  • Precompile dependencies during the build stage instead of at container startup
  • Use health checks and readiness probes to ensure traffic is only routed after the application is fully ready
HEALTHCHECK CMD curl -f http://localhost:3000/health || exit 1

8. How do you prevent containers from running as root?

  • Create and use a non-root user in the Dockerfile using USER.
  • Avoid default root images; prefer images that run as non-root by default.
  • Set permissions correctly on application files and directories.
RUN addgroup -S app && adduser -S app -G app  
USER app  
  
securityContext:  
  runAsNonRoot: true  
  runAsUser: 1000

9. How do you reduce the attack surface of Docker images?

Security of images is crucial. To avoid attack surface of docker image use minimal base images (distroless, alpine), remove package managers in final images, use multi-stage builds, and frequently scan images using tools like Trivy , https://snyk.io/ or Clair.

10. How do you monitor and observe container performance at scale?

At scale, container observability requires metrics, logs, and traces working together. Relying on only one signal is insufficient. Metrics: Prometheus, cAdvisor

  • Logs: ELK / Loki
  • Tracing: OpenTelemetry
  • Monitor: CPU throttling, OOM kills, Restart counts, Latency percentiles

11. How do you prevent one container from starving others of resources

Set resource limits and requests for CPU and memory so containers cannot exceed their allocated resources.

resources:  
  requests:  
    cpu: "250m"  
    memory: "256Mi"  
  limits:  
    cpu: "500m"  
    memory: "512Mi"

12. How do you handle stateful applications when scaling containers?

When scaling containers, the key principle is to decouple state from containers. Containers should be ephemeral and stateless, allowing them to scale horizontally without data consistency issues. Use volumes to store the data and state.

If you liked this blog then you will like my other writings too. If you found something to be fixed/added then let me know in comments. Don’t be a stranger and say hi Linkedin , X and do check my website, NehaSharma.dev.

← Back to home