DevOps Interview Questions and Answers

DevOps is a way of working where the people who build software and the people who run it share responsibility for the whole path from commit to production, backed by automation. The problem it fixes is the hand-off wall: developers throw a release over, operations absorb outages they did not cause, and releases become rare, large and risky.

The practices are version control for everything, automated build, test and deploy, infrastructure defined as code, and monitoring that feeds back into planning. The visible result is small, frequent, reversible releases. It is a culture first; Jenkins or Kubernetes are just how a team expresses it.

What the interviewer is checking: Whether you see DevOps as culture plus practices rather than a job title or a list of tools.

Likely follow-up: How would you tell whether a team's DevOps practices are actually working?

An image is a read-only, layered package: the filesystem contents, the app, its dependencies and default metadata such as the start command. A container is a running (or stopped) instance created from that image, with a thin writable layer on top and its own process, network and filesystem view.

The relationship is like a class and its objects: one image for a clinic-booking API can start ten containers. Anything a container writes goes into its writable layer and disappears when the container is removed, which is why state belongs in volumes or external services, not inside the container.

What the interviewer is checking: Basic container mental model, including the fact that container storage is ephemeral.

Likely follow-up: If I delete a running container and start a new one from the same image, what happens to files the old one wrote?

Both bring one branch's work into another. Merge creates a new commit with two parents and keeps the real history, branch shape included. Rebase replays your commits one by one on top of the target branch, giving them new hashes and a straight-line history.

I rebase my own unpublished feature branch onto main to pick up changes and keep history tidy, then merge it (often with a merge commit or squash) into main. I never rebase commits other people already pulled, because rewriting shared history forces everyone to reconcile diverged copies.

# main gained a "main hotfix" commit after feature/surcharge branched from "base"
git switch feature/surcharge
git rebase main
git switch main
git merge --no-ff -m "Merge surcharge" feature/surcharge
git log --graph --format=%s

*   Merge surcharge
|\
| * tune surcharge
| * add surcharge
|/
* main hotfix
* base

What the interviewer is checking: That you know rebase rewrites history and can state the shared-branch rule.

Likely follow-up: You rebased a branch that a teammate already pulled. What do they see, and how do you recover?

git revert creates a new commit that undoes the changes of an earlier commit. History only grows, so it is safe on shared branches. git reset moves the branch pointer back to an earlier commit; with --hard it also discards working-tree changes. Because it rewrites where the branch points, it is for local, unpublished work.

If a bad commit is already on main, revert it. If I made three messy local commits, reset lets me redo them. A reset mistake is usually recoverable through git reflog, which still lists the old tip for a while.

# history: add a, add b (buggy), add c
git revert --no-edit HEAD~1 > /dev/null
git log --format=%s
echo ---
git reset -q --hard HEAD~3
git log --format=%s

Revert "add b (buggy)"
add c
add b (buggy)
add a
---
add a

What the interviewer is checking: Whether you understand history rewriting and pick the safe tool for published commits.

Likely follow-up: You ran git reset --hard and lost commits. How do you get them back?

Permissions are three octal digits for owner, group and others, built from read 4, write 2 and execute 1. So 640 means the owner can read and write (6), the group can only read (4), and everyone else gets nothing (0).

It suits a file such as an application environment file that holds credentials: the service account owns it, an ops group can read it, and no other user on the machine can. For scripts I add execute with chmod u+x, and for directories the execute bit means permission to enter. I also check who owns the file with ls -l, because correct modes with the wrong owner still break things.

What the interviewer is checking: Basic Linux fluency with the permission model and sensible secret handling.

Likely follow-up: What does the sticky bit on a directory like /tmp do?

Continuous integration means developers merge small changes into a shared branch often, and every merge automatically builds and runs tests, so integration problems show up within minutes. Continuous delivery goes further: every change that passes the pipeline is always in a releasable state, but a human decides when to push the button for production.

Continuous deployment removes that button: a change that passes all automated checks goes to production on its own. It demands strong tests, good monitoring and usually feature flags. Many teams stop at delivery for regulated or high-risk systems, and that is a legitimate choice, not a failure. See the CI/CD course for pipeline examples.

What the interviewer is checking: Precise vocabulary and awareness that the last step is a risk decision.

Likely follow-up: Where do feature flags fit into continuous deployment?

A Pod is the smallest deployable unit: one or more containers sharing a network namespace and storage. Pods are disposable and get new IPs when recreated. A Deployment declares the desired state, for example three replicas of an image, and manages ReplicaSets to keep that many Pods running and to roll out changes.

A Service gives a stable virtual IP and DNS name and load-balances to whichever Pods match its label selector. So you rarely create bare Pods: the Deployment owns Pods, and the Service finds them by labels. The app label in the template below is the link between the two.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: booking-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: booking-api
  template:
    metadata:
      labels:
        app: booking-api
    spec:
      containers:
        - name: api
          image: registry.example.com/booking-api:1.0.0
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: booking-api
spec:
  selector:
    app: booking-api
  ports:
    - port: 80
      targetPort: 8080

What the interviewer is checking: Core Kubernetes objects and the label-selector mechanism that ties them together.

Likely follow-up: What are the common Service types and when would you use each?

First git status shows which files are unmerged. In each file Git marks the competing versions between conflict markers: my side (HEAD) above the divider and the incoming side below. I decide what the correct combined result is, which sometimes means asking the other author, then delete the markers and save.

Next I git add the file, and finish with git merge --continue (or git rebase --continue if I was rebasing). Then I run the tests, because a conflict-free merge can still be logically broken. If I get lost, git merge --abort returns me to where I started. Small, frequent branches keep conflicts rare.

<<<<<<< HEAD
rate=3
=======
rate=2
>>>>>>> a

What the interviewer is checking: Practical, calm process, including aborting and re-testing afterwards.

Likely follow-up: Both sides changed the same file, but Git merged it with no conflict. How can that still go wrong?

It takes the change introduced by one existing commit and applies it on top of the current branch as a brand-new commit with a different hash. The classic use is a hotfix: a bug is fixed on main and I need the same fix on a release branch without merging everything else that main contains.

Pitfalls: if the commit depends on earlier unpicked work it may conflict or silently misbehave, and you end up with duplicate commits across branches, which makes history harder to follow. Adding -x records the original hash in the message so people can trace it. If I find myself cherry-picking many commits, I probably need a different branching strategy.

# dev has: "fix rounding bug", then "new feature"
git switch main
git cherry-pick dev~1 > /dev/null   # hide the summary line (it contains a commit id)
git log --format=%s
ls

fix rounding bug
base
x
y

What the interviewer is checking: Knows a legitimate use case and its downsides.

Likely follow-up: How would you backport a fix to three supported release branches without chaos?

ENTRYPOINT defines the executable the container always runs; CMD supplies default arguments to it, or the default command when there is no entrypoint. Arguments given after the image name in docker run replace CMD, while ENTRYPOINT is only replaced with the explicit --entrypoint flag.

So a tool image uses ENTRYPOINT for the program and CMD for sensible defaults users can override. I always use the exec form, a JSON array, so the process becomes PID 1 and receives stop signals directly; the shell form wraps it in /bin/sh -c and often swallows SIGTERM, causing slow, forceful shutdowns.

FROM python:3.12-slim
COPY report.py /app/report.py
ENTRYPOINT ["python", "/app/report.py"]
CMD ["--format", "csv"]
# docker run report-tool                  -> python /app/report.py --format csv
# docker run report-tool --format json    -> python /app/report.py --format json

What the interviewer is checking: Understanding of how the two interact, and awareness of signal handling.

Likely follow-up: Why does a container sometimes take ten seconds to stop when you press Ctrl+C or scale down?

Each instruction produces a layer, and Docker reuses a cached layer if the instruction and its inputs are unchanged. The moment one layer is invalidated, every layer after it is rebuilt. For COPY, the inputs are the file contents, so changing any copied file busts that layer and everything below.

So I order from least to most frequently changing: base image, system packages, copy only the dependency manifest, install dependencies, then copy the source. Editing application code then reuses the expensive install layer. A .dockerignore keeps junk like node_modules and .git out of the build context, and I combine apt-get update with the install in one RUN to avoid stale package lists.

FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
CMD ["node", "server.js"]

What the interviewer is checking: Whether you can explain cache invalidation, not just recite a best practice.

Likely follow-up: A build is slow even though you only changed one line. How do you find which layer is responsible?

A container's own filesystem layer is deleted with the container, so data must live outside it. A named volume is storage managed by Docker, independent of any container's lifecycle, and is the normal choice for databases and persistent app data. A bind mount maps a specific host directory into the container, which is handy in development so that edits on the host appear instantly.

Bind mounts depend on the host path and its permissions, so they are less portable. For production on an orchestrator I would go further: use object storage or a managed database for state, so containers stay disposable and any replica can serve any request.

What the interviewer is checking: Whether you separate ephemeral compute from persistent state.

Likely follow-up: In Kubernetes, what plays the role of a volume for a database Pod, and why is a StatefulSet used?

A multi-stage build uses several FROM stages in one Dockerfile. Early stages contain compilers, build tools and source; the final stage starts from a small runtime image and copies in only the built artifact with COPY --from. Everything else is discarded.

The benefits are a much smaller image, a smaller attack surface because no compilers or package managers ship to production, and faster pulls and deploys. It also keeps one Dockerfile as the single source of truth for building, instead of a separate build script that must be kept in sync. The tags below are illustrative.

FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /src
COPY pom.xml .
COPY src ./src
RUN mvn -q package -DskipTests

FROM eclipse-temurin:21-jre
COPY --from=build /src/target/app.jar /app/app.jar
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

What the interviewer is checking: Image hygiene and security awareness, not just size.

Likely follow-up: How would you run tests inside the build, and should the test stage end up in the final image?

Both inject configuration into Pods as environment variables or mounted files. A ConfigMap holds non-sensitive settings, such as a fare cap. A Secret is meant for credentials and tokens, and has tighter handling: separate RBAC, and it is not printed in plain form by default.

However, the data is only base64-encoded, which is not encryption. Anyone who can read the Secret object can decode it, so security depends on RBAC, enabling encryption at rest for etcd, and often pulling values from an external secrets manager. Also, values injected as environment variables do not change until the Pod restarts, whereas mounted files are refreshed eventually. And never commit Secret manifests with real values to Git.

What the interviewer is checking: Honest understanding of Kubernetes Secret limits rather than a marketing answer.

Likely follow-up: How would you get secrets into a cluster without storing them in Git?

A liveness probe tells the kubelet when to restart a container that is stuck. A readiness probe decides whether the Pod receives traffic from Services; failing it removes the Pod from the endpoints without restarting it. A startup probe gives slow-starting apps time to boot, and holds the other two off until it succeeds.

Typical mistakes: making liveness check a downstream database, so a database blip restarts every Pod and turns a small incident into an outage; setting thresholds so tight that a slow garbage-collection pause kills healthy Pods; and having no readiness probe, so traffic arrives before the app can handle it. Keep liveness cheap and local, and readiness honest about whether the Pod can serve.

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /alive
    port: 8080
  initialDelaySeconds: 20
  periodSeconds: 10
  failureThreshold: 3

What the interviewer is checking: Whether you know the three probes' different consequences and a real failure mode.

Likely follow-up: During a rolling update, why does a missing readiness probe cause dropped requests?

Requests are what a container is guaranteed and what the scheduler uses to choose a node. Limits are the enforced ceiling. Exceeding a CPU limit means throttling: the process slows down but survives. Exceeding a memory limit means the container is killed by the OOM killer and shows OOMKilled, usually exit code 137.

When requests equal limits for every container, the Pod gets Guaranteed QoS and is evicted last under node pressure; no requests at all is BestEffort, evicted first. Setting no requests lets the scheduler overcommit nodes, while a tiny CPU limit causes latency spikes. Some teams deliberately skip CPU limits and keep memory limits; it depends on how noisy the neighbours are.

What the interviewer is checking: Understanding of CPU versus memory behaviour and scheduling versus enforcement.

Likely follow-up: A Pod is Pending with an 'Insufficient memory' event. What do you check?

When you change the Pod template, the Deployment creates a new ReplicaSet and gradually scales it up while scaling the old one down. maxSurge controls how many extra Pods may exist and maxUnavailable how many may be missing during the process. A new Pod only counts as available once its readiness probe passes, so a good probe protects users.

If the new version never becomes ready, the rollout stalls instead of replacing healthy Pods, and I can watch it with rollout status. To go back, rollout undo restores the previous ReplicaSet's template. The caveat is that the undo reverts the Pod spec only; it cannot reverse a database migration the new version ran.

kubectl set image deployment/fare-api api=registry.example.com/fare-api:1.4.2
kubectl rollout status deployment/fare-api
kubectl rollout history deployment/fare-api
kubectl rollout undo deployment/fare-api

What the interviewer is checking: Mechanics of the rollout and awareness that readiness and data changes limit rollback.

Likely follow-up: What would you change if you could not tolerate any capacity loss during a deploy?

A typical flow is: checkout, build, unit tests, lint and static analysis, dependency and image scanning, package an immutable artifact such as a container image tagged with the commit, push it to a registry, deploy to staging, run integration and smoke tests, then promote the same artifact to production with an approval or automatic gate and a post-deploy check. Build once and promote, rather than rebuilding per environment.

For secrets: never in the repo, image or logs. Use the CI system's secret store or a cloud secrets manager, scope them per environment with least privilege, prefer short-lived credentials via OIDC federation to long-lived keys, mask them in output, rotate them, and withhold them from pipelines triggered by untrusted forks. See the CI/CD course.

What the interviewer is checking: End-to-end pipeline thinking and practical secret hygiene.

Likely follow-up: A pipeline takes forty minutes. How would you speed it up without losing safety?

I start with uptime for load averages, compared to the CPU count, then top or htop to see which process is eating CPU or memory. free -h shows memory and swap pressure, df -h and df -i show full disks or exhausted inodes, and vmstat or iostat reveals I/O wait.

For network and service issues, ss -tulpn lists listening sockets and owners, and journalctl -u <service> shows recent logs. dmesg can reveal that the kernel OOM killer terminated something. Importantly I ask what changed: a deploy, a cron job or a traffic spike. I form a hypothesis from the evidence before restarting anything, because a restart destroys the clues.

What the interviewer is checking: A structured, evidence-first triage approach instead of guessing.

Likely follow-up: Load average is high but CPU usage is low. What does that usually point to?

Infrastructure as code means describing servers, networks and databases in versioned files that a tool turns into real resources. Declarative tools like Terraform let me state the desired end result; the tool compares it to the current state, shows a plan, and applies only the difference. Re-running it is idempotent.

That gives code review for infrastructure, reproducible environments, an audit trail, and ways to detect drift when someone changes things by hand. Terraform tracks what it manages in a state file; in a team that must be stored remotely with locking, otherwise two people applying at once can corrupt it. State may also contain sensitive values, so it needs access control.

What the interviewer is checking: Core IaC ideas: declarative, idempotent, plan before apply, and state handling.

Likely follow-up: What is configuration drift and how would you detect and fix it?

An SLI is a measured indicator of user experience, for example the fraction of requests that return successfully in under 300 ms. An SLO is the target for that indicator over a window, such as 99.9% over 30 days. An SLA is the contractual promise to customers, with consequences like credits, and is usually looser than the internal SLO.

The error budget is what remains: a 99.9% objective over 30 days allows roughly 43 minutes of full unavailability. While there is budget left, the team can ship features quickly; when it is nearly spent, reliability work takes priority over risky releases. That turns the argument between speed and stability into a shared, measurable rule.

What the interviewer is checking: Precise definitions plus the practical use of error budgets to decide priorities.

Likely follow-up: Why is 100% a bad reliability target?

CrashLoopBackOff means the container starts, exits, and the kubelet keeps restarting it with an increasing delay. I first read the logs of the previous crashed instance with kubectl logs --previous, since the current one may be empty. Then kubectl describe pod shows the last state, exit code, reason and recent events.

Common causes: an application error or bad command, a missing ConfigMap or Secret, a wrong environment variable, a liveness probe killing a slow starter, or OOMKilled with exit code 137 meaning the memory limit is too low. Exit code 1 usually points at the app itself. I fix the cause rather than raising restart tolerances, and if logs are empty I override the command to run a shell and inspect the environment by hand.

kubectl get pods
kubectl logs <pod> --previous
kubectl describe pod <pod>
kubectl get events --sort-by=.lastTimestamp

What the interviewer is checking: A systematic debugging workflow and fluency in reading exit codes and events.

Likely follow-up: The logs are empty and the Pod dies instantly. What do you try next?

I check whether the Service has endpoints at all with kubectl get endpoints <svc>. Empty endpoints mean no ready Pod matches: either the Service selector does not match the Pod labels (the most common typo), or the Pods exist but are failing their readiness probe. kubectl get pods --show-labels compares both.

If endpoints exist, I check that targetPort matches the port the app actually listens on, and test from inside the cluster with a throwaway Pod calling the Service DNS name. Then I look at NetworkPolicies, which may block traffic, and finally at the Ingress or LoadBalancer layer in front. Working from the Pod outward isolates which hop is broken.

What the interviewer is checking: Layered network debugging in Kubernetes and knowledge of selectors and endpoints.

Likely follow-up: How does a request travel from the internet to a Pod when you use an Ingress?

Blue-green runs two full environments: the live one and an idle copy running the new version. After verification I switch all traffic over at once, and rollback is flipping back. It is simple and fast to reverse, but doubles the capacity cost during the switch, and a defect hits everyone at the same moment.

Canary sends a small slice of real traffic, say a few percent, to the new version while I watch error rate and latency, then ramps up or aborts. It limits the blast radius and tests with real users, but needs traffic splitting, good metrics and tolerance for two versions running together. I pick canary for risky, high-traffic changes, and blue-green when instant, all-or-nothing cutover matters.

What the interviewer is checking: Trade-off reasoning across risk, cost and operational tooling.

Likely follow-up: Both strategies run two versions against one database. How do you keep that safe?

Rolling back code is easy; rolling back data is not. So I use the expand and contract pattern: first add the new column or table in a backward-compatible way, deploy code that works with both shapes, backfill data, switch reads to the new structure, and only in a later release remove the old one. At every step the previous app version still works against the current schema.

I also keep the previous artifact available, hide new behaviour behind feature flags so release and deploy are separate, and make migrations small and tested on production-sized data. Sometimes rolling forward with a quick fix is safer than rolling back; the point is deciding that beforehand, not during the incident.

What the interviewer is checking: Judgement about data-layer compatibility, which is where most rollbacks fail.

Likely follow-up: How would you rename a column on a busy table with zero downtime?

I page only on symptoms that users feel and that need a human now: error rate or latency breaching the SLO, or an error budget burning too fast. Cause-level signals such as high CPU or a single failed node go on dashboards or create tickets, because they often self-heal and do not always hurt users.

Every alert needs a clear owner, severity and a runbook link. I use a duration condition so brief spikes do not trigger it, group related alerts, and review noisy ones after each on-call rotation: if an alert was ignored or auto-resolved repeatedly, fix or delete it. Alert fatigue is a reliability risk, because people stop trusting the pager.

What the interviewer is checking: Mature monitoring philosophy: symptoms over causes, actionable alerts, fatigue awareness.

Likely follow-up: What is a burn-rate alert and why use more than one time window?

Mitigate first, diagnose later. I acknowledge the page, declare an incident, and assign roles: someone leads, someone investigates, someone communicates status. I check the obvious first, which is what changed recently: a deploy, flag, config or dependency. If a recent change is the suspect, I roll it back or disable the flag rather than debugging live.

I post short status updates at a regular rhythm so stakeholders stop interrupting the responders. Once service is restored, I hold a blameless postmortem: a factual timeline, contributing factors, what detected it, and action items with owners and dates. The goal is fixing systems and process, not finding someone to blame.

What the interviewer is checking: Calm prioritisation, communication discipline and a learning culture.

Likely follow-up: How would you decide between rolling back and rolling forward during an incident?