Docker & Kubernetes Interview Questions

What Docker & Kubernetes interviews cover

Sample Docker & Kubernetes interview questions

• What is the difference between a Docker image and a container?
  What a strong answer covers

  • A Docker image is a read-only template with instructions for creating a container.
  • A container is a runnable instance of an image, with its own filesystem, network, and process isolation.
  • Images are built from Dockerfiles and stored in registries; containers are ephemeral and can be started, stopped, and deleted.

  View a sample answer

  The fundamental difference is that a Docker image is a static, immutable snapshot of a filesystem and configuration, while a container is a running process with that snapshot. Images serve as blueprints; containers are the actual execution environments. You can pull an image and create multiple containers from it, each isolated. Containers have a writable layer on top of the image layers, allowing runtime changes. Images are versioned and stored in registries like Docker Hub, whereas containers exist only while running. Misconfigurations often occur when developers modify a container and expect it to persist, but containers are ephemeral; changes should be committed into a new image.

• How would you debug a Pod that is stuck in CrashLoopBackOff?
  What a strong answer covers

  • Check the Pod's logs using 'kubectl logs <pod>' or describe the pod for events.
  • Ensure the container command and arguments are correct, and image is present/pulled.
  • Verify resource limits, liveness/readiness probes, and configuration (e.g., environment variables, volumes).

  View a sample answer

  CrashLoopBackOff indicates a container repeatedly crashes after startup. First, examine logs with 'kubectl logs <pod> --previous' to see the last crash's output. Use 'kubectl describe pod <pod>' to check events and status. Common causes include: missing dependencies, misconfigured environment variables, or failed startup procedures due to missing files. If the container runs a web server, ensure the port binding is correct and not conflicting. Also check resource limits—if the container exceeds memory, it may be OOMKilled. Liveness probes that fail too early can also cause restarts. Temporarily override the command to '/bin/sh' (e.g., kubectl run --command) to inspect the filesystem. For init containers, verify they complete successfully. Sometimes the issue is a secret or config map not mounted correctly. Perform iterative debugging by simplifying the container entrypoint.

• Write a Dockerfile for a Node.js application that runs on port 3000.
  What a strong answer covers

  • Use a Node.js base image (e.g., node:18-alpine) for minimal size.
  • Set the working directory, copy package.json, install dependencies, then copy application code.
  • Expose port 3000 and define the start command using CMD ["node", "app.js"].

  View a sample answer

  A typical Dockerfile for a Node.js app on port 3000 uses an official Node image, preferably Alpine for smaller footprint. It's efficient to copy package.json first and install dependencies before copying the rest of the source code to leverage Docker layer caching. The WORKDIR sets /usr/src/app. After COPY . ., the EXPOSE 3000 instruction documents the port, and CMD runs the app. Use a .dockerignore to avoid sending node_modules to the build context. For production, consider using a multi-stage build, but the simplest version suffices here. Pitfalls: forgetting to include .dockerignore, running as root, or not using a lockfile for deterministic installs.

  FROM node:18-alpine AS builder
  WORKDIR /usr/src/app
  COPY package*.json ./
  RUN npm ci --only=production
  FROM node:18-alpine
  WORKDIR /usr/src/app
  COPY --from=builder /usr/src/app/node_modules ./node_modules
  COPY . .
  EXPOSE 3000
  CMD ["node", "app.js"]

• Explain how Kubernetes Services work and how they enable load balancing.
  What a strong answer covers

  • A Service is an abstraction that exposes a set of Pods as a network service.
  • It uses label selectors to dynamically find Pods and provides a stable IP and DNS name.
  • kube-proxy implements load balancing (e.g., round-robin) across Pod endpoints.

  View a sample answer

  Kubernetes Services provide a stable endpoint to access Pods, which are ephemeral and may be rescheduled. By assigning a virtual IP (ClusterIP) or external IP, the Service decouples client from Pod IPs. It uses label selectors to identify which Pods belong to the service. Traffic to the Service IP is forwarded to one of the matching Pods via kube-proxy, which can use iptables, IPVS, or userspace mode for load balancing. Services also enable service discovery via DNS (e.g., <service>.<namespace>.svc.cluster.local). For external access, NodePort or LoadBalancer types expose the service outside the cluster. Complexity arises when handling session affinity, multiple ports, or headless services for stateful workloads. A common pitfall is mismatched selector labels, causing no endpoints to be selected. Additionally, Services only load balance TCP/UDP; for HTTP, an Ingress controller is preferred.

• Create a Deployment that rolls out an update with zero downtime.
  What a strong answer covers

  • Use a Deployment with a rolling update strategy (default) to update Pods incrementally.
  • Define 'maxSurge' and 'maxUnavailable' to control the update pace, e.g., 25% each.
  • Ensure liveness and readiness probes are configured so new Pods only receive traffic when ready.

  View a sample answer

  Zero-downtime deployment is achieved by a Deployment's RollingUpdate strategy. The Deployment creates a new ReplicaSet and gradually scales it up while scaling down the old one. By default, maxUnavailable=25% and maxSurge=25%, ensuring at least 75% of desired Pods are available during update. Readiness probes are critical: they prevent the Service from routing traffic to a new Pod until it passes the probe, avoiding downtime. For a truly smooth transition, use pod anti-affinity to spread new Pods across nodes and consider preStop hooks to gracefully drain connections. Pitfalls: failing to configure probes, having a single replica, or not adjusting update parameters for critical services. Also, if the new version has breaking changes, the update fails gracefully, but the old version remains intact.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: my-app
  spec:
    replicas: 3
    strategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 1
        maxUnavailable: 0
    selector:
      matchLabels:
        app: my-app
    template:
      metadata:
        labels:
          app: my-app
      spec:
        containers:
        - name: my-container
          image: my-app:v2
          ports:
          - containerPort: 80
          readinessProbe:
            httpGet:
              path: /healthz
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5

• How do you manage secrets in Kubernetes?
  What a strong answer covers

  • Use Kubernetes Secrets to store sensitive data like passwords, tokens, or keys.
  • Create Secrets via kubectl, YAML, or from files; they are base64 encoded (not encrypted).
  • Mount Secrets as volumes or environment variables in Pods; enable encryption at rest with etcd encryption.

  View a sample answer

  Secrets in Kubernetes are objects that store confidential data. They are similar to ConfigMaps but base64-encoded; however, base64 is not encryption, so Secrets are only slightly more secure. For production, enable encryption at rest for etcd (e.g., using KMS). Secrets can be injected into Pods via environment variables or volume mounts, which is preferred for sensitive data to avoid exposing them in logs. Use RBAC to restrict access to Secrets. External secret management tools (e.g., HashiCorp Vault, AWS Secrets Manager, or sealed-secrets) provide enhanced security, like automatic rotation and encrypted YAML. A common pitfall is checking Secrets into version control—use tools like helmsman or kustomize with external plugins. Also, Secrets are not encrypted in etcd by default, so enable encryption-provider config. Remember that secrets are shared within a namespace; avoid using them for non-sensitive data.

• Describe the lifecycle of a Pod from creation to deletion.
  What a strong answer covers

  • Pod phases: Pending (scheduling, image pull), Running (at least one container running), Succeeded (all containers exited with 0), Failed (at least one container exited non-zero), Unknown.
  • Pod transitions: creation from YAML, scheduling on a node, container runtime starts containers, probes determine readiness/liveness.
  • Deletion: Pod may be terminated gracefully (default 30s), then removed from endpoints, and final state is Terminating until cleanup.

  View a sample answer

  A Pod's lifecycle begins when it is submitted to the API server. It enters Pending while the scheduler assigns a node and images are pulled. Once containers start, it becomes Running. If all containers exit with zero, it goes Succeeded; if a container exits non-zero, it goes Failed. The Pod moves to Unknown if node communication fails. During Running, liveness and readiness probes control restart and traffic routing. On deletion, a terminationGracePeriodSeconds (default 30s) is given for preStop hooks and graceful shutdown. The Pod is marked Terminating, removed from endpoints, and then cleaned up. Init containers run sequentially to completion before main containers start. Ephemeral containers only exist for debugging. Understanding this lifecycle is crucial for designing proper health checks and graceful shutdowns to avoid disrupting traffic.

• How would you scale a deployment based on CPU usage using HorizontalPodAutoscaler?
  What a strong answer covers

  • Define a HorizontalPodAutoscaler (HPA) that references the Deployment and a target CPU utilization (e.g., 50%).
  • HPA periodically queries the metrics server for average CPU across Pods, then adjusts the replica count.
  • Set minReplicas and maxReplicas to limit the scaling range.

  View a sample answer

  The HorizontalPodAutoscaler automatically scales the number of Pods based on observed CPU utilization (or custom metrics). It requires the metrics server to be installed in the cluster. You define an HPA with a target average CPU utilization (e.g., 50%). The HPA controller computes the desired replicas: desiredReplicas = ceil(currentReplicas * (currentMetric / targetMetric)). For example, if current CPU is 80% and target is 50%, it will scale up by 60% (80/50=1.6 -> 2x if replicas=1). It respects min/max bounds. Important considerations: multiple metrics can be used; scale-down has a cooldown period (default 5 min) to avoid thrashing. A common pitfall is setting too low a target causing aggressive scaling, or not having proper resource requests defined—without requests, the HPA cannot calculate usage. Also, HPA does not consider application-level readiness, so combine with proper probes.

  apiVersion: autoscaling/v2
  kind: HorizontalPodAutoscaler
  metadata:
    name: my-app-hpa
  spec:
    scaleTargetRef:
      apiVersion: apps/v1
      kind: Deployment
      name: my-app
    minReplicas: 2
    maxReplicas: 10
    metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

How to prepare

• Practice writing Dockerfiles and Kubernetes YAML manifests by hand without relying on tools.
• Set up a local cluster using Minikube or kind to experiment with real deployments and services.
• Understand the kubectl command line thoroughly, including troubleshooting commands like kubectl describe, kubectl logs, and kubectl exec.
• Learn the core concepts of container networking and how Kubernetes implements networking with CNI plugins.
• Study common interview scenarios such as rolling updates, canary deployments, and pod resource limits.

Frequently asked questions