DevOps interviews blend systems knowledge with practical tooling. Interviewers want to know that you understand how containers actually work, how Kubernetes schedules and heals workloads, how a CI/CD pipeline moves code safely to production, and how to deploy changes without downtime. This guide covers the DevOps interview questions that appear most often in 2026, with clear explanations and real configuration examples you can practice explaining out loud.

Containers and Docker Fundamentals

A virtual machine virtualizes hardware and runs a full guest operating system on top of a hypervisor, so each VM includes its own kernel and is heavyweight, typically gigabytes in size and slow to boot. A container virtualizes the operating system: it shares the host kernel and isolates processes using Linux namespaces and cgroups. Containers are lightweight, start in seconds, and package only the application and its dependencies. VMs provide stronger isolation and can run different operating systems, while containers offer higher density and faster startup, which is why they are the standard unit for microservices.

A Docker image is built from a stack of read-only layers, where each instruction in a Dockerfile (such as RUN, COPY, or ADD) creates a new layer. Layers are cached and shared: if a layer has not changed, Docker reuses the cached version instead of rebuilding it, which speeds up builds and reduces storage and network usage. To take advantage of caching, order your Dockerfile so that rarely changing steps (like installing dependencies) come before frequently changing steps (like copying source code). At runtime, a thin writable layer is added on top for changes made by the container.

# Multi-stage build keeps the final image small
FROM node:20-alpine AS build
WORKDIR /app
# Copy manifests first so dependency layer is cached across code changes
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
EXPOSE 3000
USER node
CMD ["node", "dist/server.js"]

Kubernetes Core Objects

A Pod is the smallest deployable unit in Kubernetes and wraps one or more tightly coupled containers that share a network namespace and storage. Pods are ephemeral and get replaced when they fail. A Deployment is a controller that manages a set of identical Pods via a ReplicaSet, handling scaling, rolling updates, and self-healing so the declared number of replicas is maintained. A Service provides a stable network endpoint and load-balances traffic across the Pods that match its label selector, decoupling clients from the changing IP addresses of individual Pods.

When you update a Deployment's Pod template (for example, a new image tag), the Deployment controller creates a new ReplicaSet and gradually shifts Pods from the old ReplicaSet to the new one, respecting maxSurge and maxUnavailable settings so the application stays available. Readiness probes ensure traffic only reaches Pods that are ready. If something goes wrong, you can roll back to the previous revision with kubectl rollout undo, because Kubernetes retains the history of ReplicaSets for the Deployment.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myregistry/web:1.4.0
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

CI/CD Pipelines

Continuous integration (CI) is the practice of merging code frequently and automatically building and testing every change to catch integration problems early. Continuous delivery extends CI so that every passing change is automatically prepared and can be released to production with a manual approval step. Continuous deployment goes one step further and automatically releases every change that passes the pipeline to production with no manual gate. The distinction between delivery and deployment is whether a human approves the final release.

A typical pipeline runs on each push or pull request and includes: checkout, dependency installation, linting and static analysis, unit and integration tests, building an artifact such as a Docker image, pushing the image to a registry, and deploying to an environment. Good pipelines fail fast by running quick checks first, cache dependencies to speed up builds, and gate production deployments behind test success and, for continuous delivery, an approval. Security scanning of dependencies and images is increasingly a standard stage.

name: ci-cd
on:
  push:
    branches: [main]
jobs:
  build-test-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --ci
      - name: Build and push image
        run: |
          docker build -t myregistry/web:${{ github.sha }} .
          docker push myregistry/web:${{ github.sha }}
      - name: Deploy to Kubernetes
        run: |
          kubectl set image deployment/web web=myregistry/web:${{ github.sha }}
          kubectl rollout status deployment/web

Infrastructure as Code and Deployment Strategies

Infrastructure as code (IaC) means defining and provisioning infrastructure (networks, servers, load balancers, clusters) through machine-readable configuration files rather than manual console clicks. Tools like Terraform and Pulumi let you version, review, and reproduce infrastructure. IaC solves configuration drift, makes environments consistent and repeatable, enables code review and rollback for infrastructure changes, and supports disaster recovery. Declarative tools like Terraform describe the desired end state and compute the changes needed to reach it, which is why running the same configuration twice is idempotent.

Blue-green deployment runs two identical production environments: blue (current) and green (new). You deploy and test the new version on green, then switch all traffic from blue to green at once, giving near-instant rollback by switching back if problems appear. Canary deployment releases the new version to a small percentage of users first, monitors metrics like error rate and latency, and gradually increases traffic if the new version is healthy. Blue-green minimizes risk with fast rollback but needs double the resources during the switch; canary limits blast radius and enables data-driven rollout but is more complex to orchestrate and monitor.

# Canary using two Deployments behind one Service selector
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-stable
spec:
  replicas: 9        # ~90% of traffic
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
        track: stable
    spec:
      containers:
        - name: web
          image: myregistry/web:1.4.0
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-canary
spec:
  replicas: 1        # ~10% of traffic
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
        track: canary
    spec:
      containers:
        - name: web
          image: myregistry/web:1.5.0

Frequently Asked Questions

Yes, they are complementary and both come up frequently. Docker is about building and running containers, while Kubernetes is about orchestrating many containers across a cluster. You should understand Dockerfiles, image layers, and networking basics, plus core Kubernetes objects like Pods, Deployments, Services, ConfigMaps, and how scheduling and self-healing work. Even for a role that uses a managed platform, interviewers expect you to explain the underlying concepts.

Walk through a structured diagnostic process out loud: describe how you would gather evidence (logs, metrics, kubectl describe and events), form a hypothesis, test it, and verify the fix. For example, if a Pod is in CrashLoopBackOff, you would check the logs, inspect the exit code and events, verify readiness and liveness probes, and confirm resource limits. Interviewers value a calm, methodical approach more than instantly naming the answer.

DevOps is as much about culture as tooling, so communication, collaboration, and a blameless approach to incidents matter a lot. Be ready to discuss how you improved a deployment process, reduced toil through automation, or handled an outage and what you changed afterward. Clear communication under pressure is exactly the skill a voice-based mock interview helps you build, so practice narrating your reasoning until it feels natural.