⚙
Automation Judgment, Not Just Tool Trivia
Knowing Terraform syntax by heart matters less than knowing when infrastructure-as-code is the right tool versus overkill, and how to reason about a tool trade-off out loud.
🔒
Safety Around Shared State
DevOps tooling touches shared, hard-to-reverse infrastructure. They're listening for state-locking awareness, rollback thinking, and respect for blast radius — not just "does it work."
🩹
Incident Composure on a Pipeline
A broken deploy pipeline blocks the whole team, not just one user — expect scenario questions testing whether you triage methodically under that pressure.
🔁
Idempotency & Repeatability Thinking
Can you explain why re-running the same automation twice should be safe, and recognize when a tool/script breaks that property? This comes up constantly in DevOps interviews.
Q A deploy pipeline that's worked for months suddenly fails on every run. How do you troubleshoot it?
A Check what actually changed first — a dependency version bump, an expired credential/token, or an upstream service outage are far more common than the pipeline config itself silently breaking. Read the actual failure log before assuming.
Q How do you decide what should be a fully automated deploy versus requiring a manual approval gate?
A Weigh blast radius and reversibility — low-risk, easily-rolled-back changes (a stateless service redeploy) can be automated; anything touching data migrations, production database schema, or hard-to-reverse infra changes gets a manual gate.
Q A deploy succeeds in staging but fails in production. What do you check first?
A Environment parity — config/secret differences, resource limits, network policy differences between staging and prod are the most common causes; "works in staging" is a strong hint the environments aren't actually equivalent.
Q How would you roll back a bad production deployment quickly and safely?
A Depends on the platform, but the principle is the same: have a known-good previous version ready to redeploy (not a manual undo), and be specific about whether that also requires a database/config rollback, which is often the harder half.
Q How do you handle secrets (API keys, credentials) in a CI/CD pipeline?
A Never in plaintext in the repo or pipeline config — use a secrets manager or the CI platform's encrypted secret store, scope credentials to the minimum permission needed, and rotate them on a schedule.
Q A terraform plan shows a resource will be destroyed and recreated instead of updated in place. What do you do?
A Stop and confirm this is expected before applying — a destroy-and-recreate on a stateful resource (a database, for example) can mean real data loss or downtime that a simple in-place update wouldn't cause.
Q How do you handle configuration drift — infrastructure that no longer matches what's in code?
A Detect it first (a plan/refresh against real state), then decide deliberately whether to bring code up to match reality or reality back to match code — silently ignoring drift just lets it compound.
Q When would you choose Ansible over Terraform, or the reverse, for a given task?
A Terraform for provisioning/managing the existence and shape of infrastructure resources; Ansible for configuring what runs on top of already-provisioned hosts — they solve adjacent but different problems and are often used together, not as substitutes.
Q How do you make sure a script or playbook is safe to re-run without side effects?
A Design it to check current state before acting (idempotent by construction) rather than blindly executing every step every time — this is the same principle Ansible modules use internally.
Q How would you structure Kubernetes manifests/Terraform code for a team of multiple engineers working concurrently?
A Split into smaller, independently-applicable units (separate state files/namespaces per service or environment) to limit blast radius and reduce how often people are blocked on the same lock or PR.
Q Tell me about a time an automated deployment or IaC change caused an incident.
A Own it directly (Situation/Task), walk through the specific fix and rollback (Action), and — most important — the concrete safeguard you added afterward so the same class of mistake can't repeat (Result).
Q Describe a time you automated something manual and repetitive.
A Quantify the impact (time saved, errors eliminated) and be honest about the trade-off — automation has an upfront cost, so show you knew it was worth building, not just that you could.
Q Tell me about a time you disagreed with a teammate on tooling choice (e.g. which IaC tool, which CI platform).
A Show the disagreement was resolved with concrete trade-off reasoning — cost, team familiarity, maintenance burden — rather than personal preference, and how the team ultimately decided.
Q Describe how you've handled being paged for a production incident tied to infrastructure you manage.
A Talk concretely about triage speed and escalation judgment, and whether you communicated status while working the problem, not just the eventual fix.
Q Tell me about a time you had to learn a new tool in your stack quickly.
A DevOps tooling changes fast — give a concrete example of ramping up on unfamiliar tooling under real deadline pressure, and what your actual learning process looked like.