DevOps and SRE interviews are less about naming tools and more about judgement under constraints: what you roll back first, what you alert on, and what you deliberately leave broken until morning. Below are the questions asked most often, each with a model answer. Middle: deeper understanding, optimization, and real-world situations.
kubectl describe pod first, because the events section carries image pull failures, failed mounts, OOMKilled and probe failures — most of the answer before you have read a log line. Then kubectl logs --previous, since the running container may be seconds old and have logged nothing. Then the exit code, and if it smells like OOM, the memory limit against actual usage.
It maps your configuration to real resources so Terraform knows what it owns. It is dangerous because it is authoritative: lose it and Terraform offers to rebuild everything, since it no longer knows those resources exist. It also holds secrets in plaintext, and two applies at once without locking corrupt it — which is why remote backends with locking, encryption and versioning are not optional.
An SLI is what you measure, an SLO is the target over a window, and the error budget is the unreliability you are allowed to spend. Its value is not as a metric but as a negotiating device: it turns 'we should slow down and fix reliability' from an opinion, which loses to a roadmap, into arithmetic both sides agreed to in advance.
Rolling needs little spare capacity but runs two versions at once, so the migration must be backward compatible whether you like it or not. Blue-green gives instant rollback and doubles infrastructure, and makes the migration harder rather than easier because both environments share one database. Canary catches real problems but only if observability notices inside the canary window.
An external store — Vault, a cloud secret manager — with the workload authenticating by identity rather than by another secret, which is the part that makes it more than moving the problem. Injection at runtime beats baking into the image, because an image is copied and cached everywhere. Rotation is the requirement people design out and then cannot add later.
A metric is a number over time and answers whether something is wrong. A log is an event with detail and answers what happened. A trace follows one request across services and answers where the time went. Teams usually over-invest in logs, which are the most expensive to store and the least useful for spotting a problem you were not already looking for.
Enough to know the instance can serve, and no more. Checking a shared database means one database problem removes every instance at once; checking nothing but the process means traffic keeps arriving at an instance that cannot answer. The usual answer is a shallow endpoint that confirms the app is up and its own dependencies are reachable, separate from the deep readiness check.
Two usual causes. Either you are out of inodes rather than bytes — millions of tiny files — which df -i shows immediately. Or a process still holds a deleted file open, so the blocks are not released while df no longer counts the file; lsof +L1 finds it and restarting the holder frees the space. A third possibility on ext filesystems is the 5% reserved for root, which a non-root writer cannot touch.
Keys only — PasswordAuthentication no — with no direct root login, a non-standard approach to who may log in via AllowUsers or a group, and a bastion in front rather than every host exposed. Per-person keys, not one shared key, because a shared key cannot be revoked for one leaver. Beyond that: agent forwarding avoided in favour of ProxyJump, command= restrictions on automation keys, and a certificate authority once the fleet is big enough that key distribution is its own problem.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle DevOps / SRE interview →