DevOps Engineer Interview Prep: Questions and a Mock Test

The most common conceptual gap in a DevOps interview is treating a container as a lightweight virtual machine. It is not one, and the difference determines several correct answers.

A container is an ordinary process on the host kernel, constrained by two mechanisms. Namespaces control what the process can see: its own process tree, network interfaces, mount table, hostname and user IDs. Control groups control what it can use: CPU shares, memory limits, I/O. There is no second kernel and no hypervisor boundary, which is why a kernel vulnerability is a container escape and why running as root inside a container is a real risk when user namespaces are not in play.

Images are the other half. A layered filesystem means each instruction in a build produces a layer, layers are content addressed and cached, and only the topmost layer is writable at runtime. That explains a set of practical answers: ordering instructions so the least frequently changed come first maximises cache reuse, deleting a file in a later layer does not reclaim its space or remove it from the image, and secrets baked into an early layer remain retrievable however carefully they are deleted later. Multi-stage builds exist so the toolchain used to compile something never ships in the artefact.

A tag is a mutable pointer, so pinning by digest rather than by tag is what makes a deployment reproducible.

Two areas produce most Kubernetes interview questions because they are so often misconfigured in the wild.

Probes come first. The documentation is explicit about the division of labour. "Liveness probes determine when to restart a container. For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress." "Readiness probes determine when a container is ready to accept traffic." And when they fail, different things happen: a failed liveness probe means "the kubelet restarts that container", while a failed readiness probe means "the EndpointSlice controller removes the Pod's IP address from the EndpointSlices of all Services that match the Pod". One kills, the other steers traffic.

The documented warning is worth quoting in an interview because it shows you have seen this go wrong: "Incorrect implementation of liveness probes can lead to cascading failures. This results in restarting of container under high load; failed client requests as your application became less scalable; and increased workload on remaining pods due to some failed pods." A liveness probe that fails because a dependency is slow will restart every pod during a dependency outage, converting a degradation into an outage. Slow starts belong to the startup probe, which suspends the other two until the application has initialised.

Resources are the second area. A request is what the scheduler uses to place the pod; a limit is what the runtime enforces. Exceeding a memory limit gets the container killed, while exceeding a CPU limit throttles it, and that asymmetry is why CPU limits are contentious and memory limits are not.

CI/CD rounds ask you to design a pipeline and then defend its properties. The properties that matter are speed, reliability and reversibility.

A build should be reproducible, which means pinned dependencies and no reliance on ambient state on the runner. Runners should be ephemeral so one job cannot contaminate the next. Artefacts should be built once and promoted through environments rather than rebuilt per environment, because rebuilding means the thing you tested is not the thing you shipped.

On measurement, DORA's current guidance is worth being current about, because a lot of preparation material is not. The guide now presents five metrics rather than four: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Note the renaming: mean time to restore has become failed deployment recovery time, and deployment rework rate is an addition.

The guidance about how to use them is the part that separates a thoughtful answer from a recited one. The metrics are meant to be read as a set, and treating one as a standalone target "encourages gaming the system". It also warns against comparing across teams and applications with different contexts, and directs attention to a team's own improvement over time. A candidate who proposes putting deployment frequency on an individual performance review has answered the wrong question.

Infrastructure as code questions almost always converge on state, because that is where the real operational pain lives.

Declarative tools keep a state file mapping the resources they manage to real infrastructure. That file is how the tool knows the difference between creating something new and modifying something existing, which is why it must be shared, must be locked during an apply, and is a sensitive artefact in its own right, since it frequently contains resource attributes including secrets. Two engineers applying concurrently without locking is the classic way to produce a state file that no longer describes reality.

Drift is the companion topic: someone changes something in a console, the code no longer matches, and the next apply either reverts their change or fails. The mature answers are detecting drift on a schedule, restricting console write access in environments that are managed by code, and importing anything created by hand rather than leaving it unmanaged.

Expect a question about blast radius. Splitting state by environment and by blast radius means an error in one component cannot destroy another, and it keeps plan times tolerable. Expect also a question about deletion: knowing which changes force replacement of a resource rather than an in-place update, and reading a plan carefully enough to notice, is the difference between a routine change and an outage.

Secrets belong in a secret manager, injected at deploy time, not in the repository and not in the state file if it can be avoided.

The final theme is reversibility, and it is where behavioural and technical questions meet.

Rolling updates replace instances gradually and are the default in most orchestrators. Blue-green keeps two full environments and switches traffic, which makes rollback instant at the cost of running two of everything. Canary exposes a small share of traffic and, done properly, includes the analysis that decides whether to proceed, since a canary nobody evaluates is just a slow rollout.

Feature flags are the important separation: deploying code and releasing behaviour become different events, so a bad feature can be turned off without a deploy. The cost is flag debt, and a good answer includes removing flags once a decision is made.

The hardest part of reversibility is data. A schema change that drops or renames a column cannot be undone by redeploying the previous binary, because the old code no longer matches the database. The expand-and-contract pattern is the standard answer: add the new shape, write to both, migrate readers, and only remove the old shape once no deployable version depends on it. Backwards compatibility between adjacent versions is the invariant that makes rolling deploys and rollbacks possible at all.

Twelve-factor's disposability factor, "maximize robustness with fast startup and graceful shutdown", is the underlying property: instances that start quickly and drain connections cleanly are what make all of the above routine rather than risky.