DevOps Engineer Interview Guide: Topics & Study Plan (2026)

DevOps job titles vary widely. A DevOps Engineer may focus on cloud infrastructure, delivery platforms, reliability, developer enablement, security, or a mixture; an SRE or Platform Engineer role can overlap but usually has a different operating model and success measures.

This guide is a study map, not a claim that every interview covers the same tools. Use the job description and recruiter briefing to choose depth, then practice explaining evidence, failure modes, trade-offs, and recovery. The linked topic guides contain the detailed questions.

Table of Contents

1. Interview Expectations Questions
2. Docker Questions
3. Kubernetes Questions
4. CI/CD Questions
5. Linux Questions
6. Git Questions
7. System Design Questions
8. Security Questions
9. Quick Reference
10. Interview Format Questions
11. Preparation Questions
12. Related Articles

Interview Expectations Questions

Before diving into topics, understand what interviewers are really evaluating:

Technical depth:

• Can you explain why things work, not just how?
• Do you understand trade-offs between approaches?
• Can you troubleshoot when things go wrong?

Operational mindset:

• How do you think about reliability, monitoring, and incident response?
• Do you consider security, scalability, and maintainability?
• Can you balance velocity with stability?

Collaboration signals:

• How do you work with developers?
• Can you explain technical concepts clearly?
• Do you understand the full software delivery lifecycle?

Docker Questions

Container questions are common when the role owns image builds or container platforms, but the required runtime may be Docker, containerd, a managed service, or no container stack at all.

Key concepts:

• Image content and metadata vs a running container process
• Dockerfile instructions and layer caching
• Multi-stage builds for production images
• docker-compose for local development
• Networking and volumes

Example question: "Walk me through how you'd containerize a Node.js application for production."

# Multi-stage build
FROM node:24-bookworm-slim AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
RUN npm prune --omit=dev
 
FROM node:24-bookworm-slim AS runtime
WORKDIR /app
USER node
COPY --chown=node:node --from=builder /app/dist ./dist
COPY --chown=node:node --from=builder /app/node_modules ./node_modules
COPY --chown=node:node --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["node", "dist/index.js"]

What interviewers want to hear:

• How multi-stage builds separate build dependencies from the runtime payload
• How base-image choice affects libc compatibility, packages, patching, provenance, and size
• Why a non-root runtime user reduces impact but is not a complete sandbox
• Layer ordering, .dockerignore, BuildKit secrets, and cache behavior
• Reproducibility versus timely security updates: pin reviewed base digests and automate update PRs

Kubernetes Questions

Kubernetes is one widely used orchestration platform, but it adds control-plane, networking, security, upgrade, and workload-operability costs. A strong answer explains when those costs are justified and when a simpler managed runtime is enough.

Key concepts:

• Pods, Deployments, ReplicaSets
• Services (ClusterIP, NodePort, LoadBalancer)
• ConfigMaps and Secrets, including their storage and access boundaries
• Namespaces as naming and policy scopes—not complete tenant isolation by themselves
• Resource requests and limits
• Liveness and readiness probes

Example question: "A pod is stuck in CrashLoopBackOff. How do you troubleshoot?"

# Check pod status and events
kubectl describe pod my-app-xxx
 
# Check logs from current and previous container
kubectl logs my-app-xxx
kubectl logs my-app-xxx --previous
 
# Common causes:
# - Application error on startup
# - Missing config/secrets
# - Failing liveness probe
# - OOMKilled (check resource limits)

What interviewers want to hear:

• Systematic debugging approach
• The container's last termination reason, events, current and previous logs, probes, config, image, resources, node state, and dependency health
• Awareness that CrashLoopBackOff is a retry backoff symptom rather than a single root cause
• Safe remediation, verification, and prevention rather than repeated restarts

CI/CD Questions

Software delivery automation is common in DevOps roles, but the platform and expected depth depend on the team's responsibilities.

Key concepts:

• CI vs CD vs Continuous Deployment
• Pipeline stages (build, test, deploy)
• GitHub Actions / Jenkins / GitLab CI
• Secrets management
• Deployment strategies (rolling, blue-green, canary)
• Artifact management

Example question: "Design a CI/CD pipeline for a microservices application."

# GitHub Actions example
name: CI/CD
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
permissions:
  contents: read
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7  # Pin a reviewed full SHA in production
      - uses: actions/setup-node@v6
        with:
          node-version: '24'
          cache: npm
      - run: npm ci
      - run: npm test
 
  publish:
    needs: test
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    outputs:
      digest: ${{ steps.image.outputs.digest }}
    steps:
      - uses: actions/checkout@v7
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        id: image
        with:
          context: .
          push: true
          tags: ghcr.io/example/myapp:${{ github.sha }}
 
  deploy-staging:
    needs: publish
    runs-on: ubuntu-latest
    environment: staging
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v7
      # Add the cloud-specific OIDC login and cluster setup here.
      - run: ./scripts/deploy.sh staging "$IMAGE@$DIGEST"
        env:
          IMAGE: ghcr.io/example/myapp
          DIGEST: ${{ needs.publish.outputs.digest }}
 
  deploy-production:
    needs: [publish, deploy-staging]
    runs-on: ubuntu-latest
    environment: production  # A gate exists only if protection rules configure it
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v7
      # Add the cloud-specific OIDC login and cluster setup here.
      - run: ./scripts/deploy.sh production "$IMAGE@$DIGEST"
        env:
          IMAGE: ghcr.io/example/myapp
          DIGEST: ${{ needs.publish.outputs.digest }}

What interviewers want to hear:

• Separation of CI (quality gates) and CD (deployment)
• PR validation separated from privileged publication and deployment
• Build once, record the digest, and promote that exact immutable image
• Explicit least-privilege job permissions, short-lived OIDC credentials, protected environments, and concurrency control
• Progressive rollout, health evidence, rollback or roll-forward, and database compatibility
• Full-SHA pinning for actions; version tags above are readable examples, not an immutable supply-chain boundary

Linux Questions

Many production and container workloads run on Linux, so roles that operate them usually test command-line and systems reasoning. The goal is to form and test hypotheses, not recite utilities.

Key concepts:

• File permissions and ownership
• Process management (ps, top, kill)
• Text processing (grep, sed, awk)
• Networking (ss, ip, curl, dig, packet capture when authorized)
• Log analysis
• Shell scripting

Example question: "A server is running slowly. How do you diagnose the issue?"

# Establish scope, time window, and recent changes first.
uptime                       # Load averages and uptime
free -h                      # Memory accounting; inspect reclaimable cache
df -h                        # Filesystem capacity
df -i                        # Inode exhaustion
vmstat 1                    # CPU, run queue, memory, paging, and I/O trends
iostat -xz 1                # Device latency and saturation, if installed
 
# Check processes
ps aux --sort=-%cpu | head   # Snapshot, not a time series
pidstat 1                    # Per-process trends, if installed
 
# Check network
ss -s                        # Socket summary
ss -lntup                    # Listening TCP/UDP sockets (privilege affects detail)
ip -s link                   # Interface counters and drops
 
# Check logs
journalctl -u myservice --since '30 minutes ago'

What interviewers want to hear:

• Systematic approach (not random commands)
• Correlation with user impact, service metrics, deploys, dependencies, cgroups/containers, and the relevant time window
• Correct interpretation of CPU pressure, memory reclaim/swap, filesystem capacity/inodes, device latency, network loss, and queueing
• A safe mitigation followed by validation and root-cause evidence; one command rarely proves causality

Git Questions

Git workflows underpin everything in DevOps.

Key concepts:

• Branching strategies (GitFlow, trunk-based)
• Merge vs rebase
• Cherry-pick, reset, revert
• Resolving merge conflicts
• Git hooks

Example question: "When would you use rebase vs merge?"

Merge: Combines histories. Depending on flags and graph shape it may create a merge commit, fast-forward, or be configured to squash. A merge commit preserves branch topology and does not rewrite existing commits.

Rebase: Replays selected commits onto a new base, producing new commit identities. It can create a linear history, but conflicts may need resolution at multiple replayed commits. Rebase private work or coordinate explicitly before rewriting commits other people consume.

# Updating feature branch with main changes
git switch feature
git rebase main
 
# Interactive rebase to clean up commits
git rebase -i HEAD~3

What interviewers want to hear:

• Understanding of when each is appropriate
• Awareness of fast-forward, merge-commit, squash, and rebase policies
• Recovery with reflog, abort/continue, and --force-with-lease only when an authorized rewritten branch must be updated
• How changed commit identities, required checks, signed commits, bisectability, and release provenance affect delivery

System Design Questions

DevOps interviews often include system design, focused on infrastructure.

Key concepts:

• High availability and fault tolerance
• Load balancing and scaling
• Caching strategies
• Database replication
• CDN and edge computing
• Disaster recovery

Example question: "Design a highly available deployment for a web application."

Start with workload, SLO, failure domains, consistency, RTO/RPO, traffic, compliance, and cost. The diagram below is only a regional AWS sketch; it is not a complete highly available design or a universal template.

flowchart TB
    DNS["Route 53<br/>(DNS)"]
    ALB["ALB<br/>(Load Balancer)"]
 
    subgraph azs["Availability Zones"]
        direction LR
        subgraph az1["AZ-1"]
            K1["K8s<br/>nodes"]
        end
        subgraph az2["AZ-2"]
            K2["K8s<br/>nodes"]
        end
        subgraph az3["AZ-3"]
            K3["K8s<br/>nodes"]
        end
    end
 
    DB["Aurora Cluster<br/>(Multi-AZ DB)"]
 
    DNS --> ALB
    ALB --> K1
    ALB --> K2
    ALB --> K3
    K1 --> DB
    K2 --> DB
    K3 --> DB

What interviewers want to hear:

• Explicit dependencies and failure domains across zones, plus tested health checks and capacity for failover
• Autoscaling driven by an appropriate signal, with quotas, warm-up, downstream limits, and overload protection
• Database topology, consistency, backup/restore, replication lag, failover behavior, and data-loss objectives
• Multi-region only when business continuity requirements justify its routing, data, operational, and cost complexity
• Caches and CDNs where access patterns benefit, with invalidation, staleness, and origin-failure behavior
• SLO-based monitoring, actionable alerts, runbooks, exercises, and evidence that recovery actually meets RTO/RPO

Security Questions

Security is everyone's job, especially in DevOps.

Key concepts:

• Container security (non-root, image scanning)
• Secret management (Vault, cloud secret managers)
• Network policies and firewalls
• RBAC and least privilege
• OWASP top 10
• Supply chain security

Example question: "How do you handle secrets in a Kubernetes environment?"

# Don't do this - secrets in plain text
env:
  - name: DB_PASSWORD
    value: "mysecret"  # NO!
 
# Kubernetes Secret reference (protect RBAC and enable encryption at rest)
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password
 
# External store synchronized through External Secrets Operator
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  secretStoreRef:
    name: aws-secrets-manager
  target:
    name: db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: prod/db/password

What interviewers want to hear:

• No plaintext values in manifests, source, image layers, CI logs, or Terraform state
• Workload identity and short-lived credentials where possible, with least-privilege RBAC and cloud policy
• Kubernetes API and etcd encryption, backup protection, node/Pod boundaries, and restricted get, list, watch, or workload-creation privileges
• Rotation with application reload behavior, overlap, revocation, ownership, audit, and failure handling
• External Secrets Operator commonly materializes a normal Kubernetes Secret; it changes synchronization and source of truth, not the target Secret's attack surface
• Admission policy, signed or attested artifacts, image scanning, patched bases, runtime controls, and incident response as independent layers

Quick Reference

Interview Format Questions

Technical screen may include:

• Conceptual questions on containers, K8s, CI/CD
• "Tell me about a time you..." operational scenarios
• Basic troubleshooting walkthrough

System or delivery design may include:

• Design a deployment pipeline
• Architecture for high availability
• Scaling a specific service

Hands-on or live exercise may include:

• Write a Dockerfile
• Create a GitHub Actions workflow
• Debug a failing Kubernetes deployment
• Write a shell script

Take-home project:

• Set up infrastructure with Terraform
• Create complete CI/CD pipeline
• Deploy application to Kubernetes

Durations, coding languages, internet access, cloud accounts, and permitted tooling vary. Ask the recruiter what will be assessed and whether the exercise is production troubleshooting, platform design, application coding, or configuration authoring. Never run a take-home deployment against an employer's production account unless the scope and authorization are explicit.

Preparation Questions

Build real projects:

1. Containerize an application with Docker
2. Deploy to kind or minikube only if Kubernetes is relevant; otherwise use the target role's runtime
3. Set up CI/CD with GitHub Actions
4. Define one user-facing SLI/SLO and add enough telemetry to diagnose it
5. Automate infrastructure in a disposable account or local emulator and document cleanup/cost controls

Practice troubleshooting:

• Inject bounded failures only in a disposable or explicitly authorized environment
• Capture a baseline, prediction, guardrail, abort condition, and recovery evidence
• Practice narrating hypothesis, observation, mitigation, verification, and prevention

Study patterns, not just tools:

• Understand why patterns exist
• Know trade-offs between approaches
• Be ready to discuss alternatives

Prepare two or three concise stories using real evidence: an incident or difficult diagnosis, a delivery/reliability improvement, and a cross-team decision. State your own role, the constraints, what you measured, the outcome, and what you would change now.

Frequently Asked Questions

What topics are covered in DevOps interviews?

DevOps interviews typically cover containerization (Docker), orchestration (Kubernetes), CI/CD pipelines, Linux fundamentals, version control (Git), infrastructure as code, cloud platforms, monitoring, and system design. The mix depends on the role - some focus more on development, others on operations.

What is the difference between DevOps, SRE, and Platform Engineering?

DevOps is a broad sociotechnical approach to improving software delivery and operations. SRE applies software engineering and an SLO-based reliability model to operations. Platform engineering treats an internal platform as a product that provides supported paths and capabilities to developers. Organizations use the labels differently, and the practices overlap.

How do I prepare for a DevOps interview with no production experience?

Build a small service, containerize it, automate tests and deployment, add metrics and an SLO, inject failures in a disposable environment, and write a short incident review. kind or minikube can teach Kubernetes, but use it only when the target role needs Kubernetes. Explain what you measured, what failed, and which trade-offs you chose.

What are the most important DevOps tools to know?

There is no universal tool list. Learn the role's stack, then understand transferable concepts: Linux and networking, version control, a CI/CD system, image build and runtime, infrastructure as code, cloud identity and networking, observability, incident response, and security. Kubernetes is important only where the workload and job actually use it.

How technical are DevOps interviews compared to software engineering interviews?

The format depends on the company and role. Common exercises include production troubleshooting, architecture and delivery design, infrastructure or pipeline review, incident discussion, and scripting or programming in a language used by the team. Ask the recruiter which environments, tools, and assessment types are in scope.

What soft skills matter in DevOps interviews?

Clear communication, blameless incident collaboration, prioritization under uncertainty, written runbooks and post-incident reviews, and the ability to explain risk and trade-offs matter. Strong candidates improve reliability and developer experience without hiding policy decisions behind tools or treating another team as a ticket queue.

Sources

• DORA capabilities
• Google SRE: Service Level Objectives
• Docker build best practices
• Node.js release schedule
• Kubernetes Pod lifecycle
• Kubernetes multi-tenancy
• Kubernetes Secrets
• Kubernetes RBAC good practices
• Secure use reference for GitHub Actions
• Git merge documentation
• Git rebase documentation
• Linux man-pages project
• OWASP Secrets Management Cheat Sheet
• External Secrets Operator: ExternalSecret
• SLSA specification

Related Articles

This pillar guide connects to detailed coverage of each topic:

Containerization & Orchestration:

• Docker Interview Guide
• Kubernetes Interview Guide

Automation & Linux:

• CI/CD & GitHub Actions Interview Guide
• Linux Commands Interview Guide

Version Control:

• Git Rebase vs Merge Interview Guide
• Git Tricky Questions Interview Guide

Architecture & Security:

• System Design Interview Guide
• Web Security & OWASP Interview Guide

Monitoring & Observability:

• Monitoring & Observability Interview Guide

Cloud:

• AWS Interview Guide
• Azure Interview Guide
• GCP Interview Guide

Networking:

• Networking Interview Guide

Infrastructure as Code:

• Terraform Interview Guide
• Ansible Interview Guide