DevOps & Cloud: real interview questions

Show a calm incident process: assess blast radius, mitigate before diagnosing, communicate, then root-cause later. Mention rollback as the default first move.

First two minutes: acknowledge the page, open the dashboard, establish blast radius — all users or a slice? Then mitigate, not diagnose: check what changed (deploys, flags, config) — if something shipped recently, roll it back immediately; that fixes most 3am incidents. If no change, check dependencies and failover options (shift traffic, disable the failing feature behind a flag). Throughout: post short status updates in the incident channel — silence at 3am creates panic. Only once users are unblocked do I dig for root cause, and I file the postmortem while the timeline is fresh. The principle I'd state plainly: restore service first; understanding can wait, customers can't.

One-line technical difference (shared kernel vs virtualized hardware), then the practical consequences: density, startup, isolation strength, kernel-dependency cases.

A VM virtualizes hardware and boots its own kernel; a container shares the host kernel and isolates at the process level with namespaces and cgroups. Consequences: containers start in milliseconds, pack far denser, and image layers make builds fast — which is why they won for app deployment. It matters in the other direction when you need a different kernel/OS, stronger isolation for untrusted or multi-tenant workloads (a container escape is a kernel exploit away; a VM adds a hypervisor boundary), or kernel-level tuning per workload. Real-world stacks use both: containers for apps, running on VMs for isolation — and gVisor/Firecracker exist precisely to blur that line for untrusted code.

Give the command sequence in order: describe → logs (current and previous) → events → exec/ephemeral container, and name the usual suspects.

kubectl describe pod first — it shows exit codes, restart count, and events (image pull errors, OOMKilled, failed probes are all visible here). Then kubectl logs --previous to see what the container said before it died — the current logs are often empty because it just restarted. Usual suspects in order: bad config/env (app exits on startup), failing liveness probe killing a healthy-but-slow container (check initialDelaySeconds), OOMKilled (raise the memory limit or fix the leak — exit code 137), and missing dependencies (can't reach the DB, so it panics). If logs are useless, kubectl exec or an ephemeral debug container to poke around. Exit code + previous logs + events solves 90% of these in minutes.

Immediate recovery (state backup, terraform state commands, import) then the systemic fix: remote backend with locking and CI-only applies.

Recovery: stop all applies, snapshot the current state file, and diff state against reality (terraform plan). Most 'corruption' is drift or a lost resource reference — fixable surgically with terraform state rm / mv and terraform import to re-adopt real resources, verifying with plan until it's clean. Worst case, restore the backend's previous state version (S3 versioning saves you here). Prevention is the real answer: remote backend with state locking (S3+DynamoDB or Terraform Cloud) so concurrent applies are impossible, applies only from CI (never laptops), plan output reviewed in PRs, and state versioning on. If two humans can race on state, the process — not the humans — is broken.

Cover rolling/blue-green/canary, connection draining, health checks gating traffic — and preempt the killer follow-up: backward-compatible database migrations.

Mechanics: rolling or blue-green deploys behind a load balancer — new instances must pass readiness checks before receiving traffic, old ones get connection-drained before termination, and a canary slice with automated rollback catches regressions at 5% instead of 100%. The part that actually breaks zero-downtime is the database: during a rollout, old and new code run simultaneously, so every migration must be backward-compatible — expand-and-contract: add the new column, deploy code that writes both, backfill, switch reads, then drop the old column releases later. Never rename or drop in the same release that deploys code depending on it. Zero downtime is a contract between the deploy mechanics and the schema discipline; either alone isn't enough.

Rotate first (assume compromise), then assess usage, then clean history, then prevent recurrence. Bonus points for 'bots scrape GitHub in seconds'.

Treat it as an active compromise, not a cleanup task — scrapers find public keys in under a minute. Order: (1) revoke/rotate the keys immediately — before any git surgery; (2) audit CloudTrail for use of those keys since the commit — look for new IAM users, instances, or data access; (3) then scrub history (git filter-repo / BFG) knowing it's cosmetic once rotated, since forks and caches exist; (4) prevention: pre-commit secret scanning (gitleaks), GitHub push protection, and moving the team to short-lived credentials (OIDC roles instead of long-lived keys) so the next leak expires in an hour instead of living forever. The interviewer is checking one thing: that you rotate before you clean.