DevOps Interview Questions and Answers (2026)

A way of working that shortens the loop between writing code and running it in production by sharing ownership, automating the path to production, and measuring the result.

Deployment frequency, lead time for changes, change failure rate, and time to restore service. They correlate with organisational performance and are a common way to answer "how do you know your delivery is improving?"

Blue/green runs two full environments and switches all traffic at once — simple rollback, but a big blast radius if you missed something. Canary shifts a small percentage of traffic to the new version, watches metrics, then ramps up — safer, more complex to automate.

CI: build, unit and integration tests, static analysis, security scanning, artefact creation — fast feedback on every commit. CD: promoting that artefact through environments with the right gates (automated tests, approvals) to production.

Never in the repo or plain environment variables in logs. Use the platform's secret store (GitHub Actions secrets, GitLab CI variables masked) or an external one (Vault, AWS Secrets Manager, SOPS), inject at runtime, scope to the minimum jobs, and rotate.

Measure each stage first. Then: cache dependencies and layers, run independent jobs in parallel, only run what changed (path filters, affected-project detection), use bigger runners for the bottleneck, split slow test suites, and move non-blocking checks off the critical path.

A small, specific base image; multi-stage builds so the final image has only runtime artefacts; layers ordered least- to most-frequently-changing for cache reuse; a non-root user; no secrets baked in; and a pinned base image tag or digest.

Usually a heavy base image, build tools left in the final stage, npm install including dev dependencies, copying the whole context instead of just what is needed, or not using .dockerignore. Multi-stage builds fix most of it.

A VM virtualises hardware and runs a full guest OS. A container shares the host kernel and isolates processes with namespaces and cgroups — much lighter and faster to start, but weaker isolation and tied to the host kernel.

A Deployment manages a ReplicaSet of Pods and handles rolling updates. A Service gives them a stable virtual IP and load-balances across them. An Ingress routes external HTTP traffic to Services. ConfigMaps and Secrets hold configuration. HPA scales the Deployment on metrics.

kubectl describe pod for events, kubectl logs --previous for the last crash output. Common causes: bad command/entrypoint, missing config or secret, failing readiness/liveness probe, out-of-memory kill (check kubectl get pod -o yaml for OOMKilled), or the app can't reach a dependency.

Requests are what the scheduler reserves; limits are the hard cap. Too-low requests cause overcommitment and noisy-neighbour problems; too-high requests waste capacity and block scheduling. Hitting the CPU limit throttles the pod; hitting the memory limit kills it.

Liveness: is the process healthy? Failing it restarts the pod. Readiness: is it ready to serve traffic? Failing it removes the pod from the Service endpoints without restarting. Getting these backwards causes restart storms or blackholed traffic.

The mapping between your configuration and the real resources. It must be stored remotely (S3 + DynamoDB lock, Terraform Cloud) so a team can share it safely, and never committed to git — it can contain secrets and concurrent writes corrupt it.

Reusable modules for the building blocks, then thin per-environment configurations (separate state, separate variables) that call those modules. Avoid one giant state file and avoid copy-pasting whole environments.

Drift — someone changed a resource outside Terraform (in the console), or a provider default changed, or a computed value updates on every run. Investigate before applying; import or reconcile the manual change, or pin the value.

Metrics (aggregated numbers over time — rates, latencies, saturation), logs (discrete events with context), and traces (the path of one request across services). You need all three to answer "what is happening and why".

Latency, traffic, errors and saturation. If you can only put four graphs on a dashboard, use these.

Acknowledge and declare it. Stabilise first — roll back or fail over to stop the bleeding, before diagnosing. Communicate status regularly. Once stable, find the root cause. Afterwards, write a blameless post-mortem with concrete action items and track them to done.