12 Scenario-Based DevOps Interview Questions (With Answers)

Scenario questions are now the core of mid-level and senior DevOps interviews. Nobody asks "what is a Pod" anymore; they ask what you do when one won't start. The interviewer is grading your order of operations: what you check first, how you narrow it down, and whether you fix the cause or just the symptom.

A strong answer has three parts: the first command, what its output would tell you, and the fix plus the prevention. Here are twelve scenarios we've seen asked, with answers in that shape.

#	Scenario	What it really tests	First command
1	Pod in CrashLoopBackOff	Reading logs from a dead container	kubectl logs <pod> --previous
2	Pod stuck Pending	Scheduler reasoning	kubectl describe pod <pod>
3	Deploy succeeded, users get 502	Probes and Service wiring	kubectl get endpoints <svc>
4	Plan wants to replace the prod database	Reading a plan before applying	terraform plan and read -/+
5	State lock won't release	Safe recovery under pressure	terraform force-unlock <id> (carefully)
6	Node disk full	Linux basics on Kubernetes	df -h, crictl images
7	A CI dependency was compromised	Secret blast radius	Audit logs, rotate, pin
8	Cloud bill doubled overnight	Cost triage	Cost Explorer grouped by service
9	Argo CD app is always OutOfSync	Controllers vs Git	argocd app diff <app>
10	HPA never scales	Metrics pipeline	kubectl describe hpa <name>
11	Bad release, roll back now	Calm, reversible action	kubectl rollout undo
12	Someone dropped a production table	Recovery and blameless follow-up	Restore plan, then postmortem

Kubernetes: the scenarios asked most

1. "A Pod is in CrashLoopBackOff. Walk me through it." Run kubectl logs <pod> --previous, because the current container may have no logs yet. Then kubectl describe pod for the exit code: 137 points to memory (OOMKilled), 1 usually means an application error such as missing config. Fix the cause, not the restart policy. Our CrashLoopBackOff guide has the full exit-code table.

2. "A Pod has been Pending for ten minutes." kubectl describe pod and read the Events: FailedScheduling names the reason, usually insufficient CPU or memory, a taint without a toleration, an affinity rule nothing satisfies, or an unbound PersistentVolumeClaim. Mention that requests, not actual usage, drive scheduling.

3. "The deploy succeeded but users get 502s." Check kubectl get endpoints <svc>. Empty endpoints mean the Service selector doesn't match the Pod labels, or readiness probes are failing. If endpoints exist, check the target port and then the ingress or load balancer health checks.

10. "The HPA never scales up." kubectl describe hpa and look for <unknown> targets. The usual causes are no metrics-server, Pods without CPU requests, or maxReplicas already reached. We cover all of them in why your HPA isn't scaling.

11. "The release is bad. Roll back now." kubectl rollout undo deployment/<name>, then confirm with kubectl rollout status. Say out loud that you'd roll back first and debug second, and that the real fix is a deployment that canaries before full rollout.

Terraform and infrastructure

4. "terraform plan wants to replace the production database." Stop. Find the attribute marked # forces replacement in the plan. Common causes are a changed immutable attribute, a renamed resource address, or a provider upgrade. Fix it with a moved block or by reverting the attribute, and never apply a plan that destroys stateful resources without a reviewed, tested backup.

5. "The state lock is stuck and the pipeline is blocked." First confirm nobody is running an apply: check CI and ask the team. Only then run terraform force-unlock <lock-id>. Unlocking under a live apply can corrupt state, so the answer interviewers want includes the check, not just the command.

6. "A node's disk is full." df -h on the node, then find what's large: container images (crictl images), logs under /var/log, or emptyDir volumes. Kubelet image garbage collection and log rotation are the prevention; deleting files by hand is the emergency fix.

CI/CD, cost and incidents

7. "A GitHub Action you use was compromised." Treat every secret the affected workflows could read as exposed, and rotate them. Check run logs for the exposure window, then pin actions to full commit SHAs and cut GITHUB_TOKEN permissions to read-only by default. The March 2026 trivy-action compromise is the example to cite.

8. "The cloud bill doubled overnight." Group cost by service and then by usage type for the last two days. Look for new regions, data transfer, NAT gateways and GPU or large instance types. If anything looks like crypto-mining, deactivate access keys before investigating further.

9. "Argo CD shows the app OutOfSync forever." argocd app diff <app> to see the field. Usually a controller owns it: an HPA changing spec.replicas or a webhook injecting a sidecar. Remove the field from Git or add an ignoreDifferences rule.

12. "Someone dropped a production table." Stop writes if data is still being lost, restore from point-in-time recovery to a new instance, and copy back the missing rows. Then run a blameless postmortem focused on why one command could do that: privileges, review, and tested restores.

Questions people ask

What are the most common DevOps interview questions in 2026?

The most common are scenario questions: a Pod in CrashLoopBackOff or Pending, a failed or risky deployment, a Terraform plan that would destroy something important, a leaked secret, and an unexplained cloud bill. Interviewers want your debugging order and your reasoning, not definitions.

How do I answer scenario-based interview questions?

Use three steps: name the first command you'd run, explain what its output would tell you, then give the fix and the prevention. Thinking aloud is expected. Saying "I'd confirm nobody is applying before I force-unlock" scores better than a fast but risky answer.

How should I prepare for a senior DevOps interview?

Break a test cluster and a Terraform project on purpose and fix them, and practice explaining each step aloud. Prepare two real incident stories with the cause, your fix and what changed afterward. Senior interviews weigh judgment under pressure and prevention as much as technical depth.

The decision, concretely

• Junior role? Master scenarios 1, 2, 3 and 11 cold; they cover most Kubernetes questions.
• Infrastructure-heavy role? Add 4, 5 and 6, and be ready to read a Terraform plan line by line.
• Senior or lead role? Expect 7, 8 and 12, which test judgment, communication and prevention.
• Short on time? Practice the first command and the prevention for each scenario; that's what separates strong answers.

The call we'd make

Don't memorize answers. Build a small lab with a cluster and a Terraform project, break each scenario on purpose, and fix it while explaining aloud. The candidates who get offers are the ones who sound like they've seen the failure before, because they have.

Sources

• Kubernetes documentation: Debug Pods
• HashiCorp: terraform plan command
• Google SRE book: Postmortem culture