DevOps Engineer Interview Questions (2026) and How to Answer
By FindAJobAI team Updated How we wrote this page
DevOps interviews are practical. Expect questions on CI/CD pipelines, containers and Kubernetes, infrastructure as code (usually Terraform), a cloud provider, and Linux and networking basics, often with a hands-on task such as fixing a broken pipeline or writing a Dockerfile.
Behind the tools, interviewers look for someone who automates the boring parts, makes releases safe and routine, and works well with the developers who use the platform.
Below: 30 questions with what each one really asks and an answer outline, full sample answers to the 10 most asked, red flags to avoid and a 7-day plan.
Answering with STAR
Tell each story in four steps: the situation in a sentence, your task, the actions you took (most of the answer) and the result, with a number if you have one. Aim for about two minutes; the outlines show what to include, the details must be yours.
Behavioural questions (1–10)
How you've handled real situations. Answer each with one true story, in STAR order.
1.Tell me about a CI/CD pipeline you built or rebuilt.
What they're really asking: Can you design delivery end to end, and did it make developers faster?
Answer outline (STAR)
- SituationSlow, flaky or manual releases that developers avoided.
- TaskMake deploys fast, safe and routine.
- ActionPipeline stages, caching, parallel tests, automated rollback, promotion between environments.
- ResultDeploy frequency and lead time, before and after.
Full sample answer (fictional example)
Releases at my last company took two hours by hand and happened once a week. I rebuilt the pipeline in GitHub Actions. Every commit builds a container with cached layers, runs unit tests in parallel, scans the image and deploys to a preview environment. Merging to main deploys to staging and, after smoke tests, to production as a 10 percent canary with automatic rollback on error rate. Deploys went from weekly to about 15 a day, lead time from five days to under two hours, and failed changes halved.
2.Describe a time you automated something your team did by hand.
What they're really asking: Do you spot toil and remove it for good?
Answer outline (STAR)
- SituationA manual, error-prone task such as provisioning or certificate renewal.
- TaskAutomate it without breaking existing setups.
- ActionScript it, keep it in version control, add tests and document it.
- ResultHours saved per month, and the errors that stopped.
Full sample answer (fictional example)
Every quarter someone renewed about 40 internal certificates by hand, and twice one was missed and a service went down. I wrote a small Python job using the certificate manager's API that renews certificates 30 days before expiry, deploys them through the existing pipeline and posts to Slack. It lives in the repo with tests, a README and a dry-run mode. It saves about eight hours a quarter, and there have been no expiry incidents in two years. I also added an alert for any certificate under 14 days.
3.Tell me about an outage you helped resolve.
What they're really asking: How you behave under pressure, and whether you fix causes or only symptoms.
Answer outline (STAR)
- SituationA production outage: what users saw, and for how long.
- TaskYour role, from first responder to incident lead.
- ActionHow you diagnosed it, what you rolled back and how you kept people informed.
- ResultRecovery time, and the follow-up actions that prevented a repeat.
Full sample answer (fictional example)
On a Saturday our checkout failed for 25 minutes. I was on call. Alerts showed errors started right after a config change that reduced the database connection pool. I told the incident channel I was rolling the change back, did it, and watched error rates fall within three minutes, then posted updates every ten minutes until we were clear. In the review we found nothing validated pool settings against instance count. We added a pipeline check for that and a canary for config changes, and no similar incident has happened since.
4.Tell me about a time developers resisted a tool or process you introduced.
What they're really asking: Can you win adoption instead of forcing it?
Answer outline (STAR)
- SituationA new deploy process, quality gate or platform change.
- TaskGet teams to adopt it willingly.
- ActionListen to the objections, fix the real friction, show a pilot team's results.
- ResultAdoption, and what you changed because of the feedback.
Full sample answer (fictional example)
Developers resisted a mandatory security scan in the pipeline because it added eight minutes and flagged noise. I didn't argue the policy. I sat with two teams and found the scan ran twice and reported old issues in code they hadn't touched. I fixed both: it ran once, in parallel with tests, and failed only on new high-severity findings. One pilot team ran it for a month, and we shared their numbers: three real vulnerabilities caught, no slowdown. The other teams adopted it within six weeks.
5.Tell me about moving a service onto containers or Kubernetes.
What they're really asking: Real migration experience, including what went wrong along the way.
Answer outline (STAR)
- SituationA service running on hand-managed VMs or a legacy platform.
- TaskContainerise it and move it without downtime.
- ActionA Dockerfile, manifests or a Helm chart, probes and resource limits, a gradual traffic shift.
- ResultDeploy time and stability after the move, and one lesson learned.
6.Tell me about an infrastructure change that went wrong.
What they're really asking: Do you own the mistake and make the system safer?
Answer outline (STAR)
- SituationA change, such as a firewall rule or scaling edit, that caused an incident.
- TaskRestore service, then learn how it got through.
- ActionRevert, communicate, run a blameless review, find the missing check.
- ResultRecovery time, and the guardrail you added.
7.Tell me about securing a delivery pipeline.
What they're really asking: Do you treat the pipeline as part of the attack surface?
Answer outline (STAR)
- SituationA pipeline with long-lived keys, loose dependencies or no scans.
- TaskHarden it without slowing teams.
- ActionMove to OIDC credentials, pin and scan dependencies, sign images, limit approvers.
- ResultFindings before and after, and developer feedback.
8.Tell me about improving developer experience on your platform.
What they're really asking: Do you measure what it is like to use what you build?
Answer outline (STAR)
- SituationDevelopers waiting for environments or fighting local setup.
- TaskCut the friction measurably.
- ActionShadow developers, add preview environments or a dev container, document the path.
- ResultSetup time or lead time, before and after.
9.Tell me about an environment that didn't match production.
What they're really asking: Can you close the gaps that make bugs impossible to reproduce?
Answer outline (STAR)
- SituationA bug that appeared only in production because staging differed.
- TaskMake environments predictable.
- ActionDiff configuration and versions, define both in code, add a drift check.
- ResultFewer environment-only bugs, and how you measured it.
10.Tell me about meeting a compliance requirement in the delivery process.
What they're really asking: Can you build controls that stay light for developers?
Answer outline (STAR)
- SituationA rule such as two-person approval or audit logs for production changes.
- TaskMeet it without slowing every release.
- ActionAutomate approvals and evidence in the pipeline, and talk to the auditor early.
- ResultThe audit outcome, and the effect on lead time.
Technical and role-skill questions (11–22)
Can you do the work itself? Think out loud and name the trade-offs.
11.A Kubernetes pod keeps restarting. How do you find out why?
What they're really asking: Hands-on Kubernetes debugging, the most common practical question.
Answer outline
- Check kubectl describe and the logs, including the previous container's logs.
- Usual causes: failing probes, OOMKilled from a low memory limit, a bad config or secret, a crashing entrypoint.
- Fix the cause, then tune the resources and probes.
Full sample answer (fictional example)
I start with kubectl describe pod, which shows the last state and its reason, and the events. Then I read the logs, including the previous container's with the previous flag, since the current one may have just started. The usual causes are a failing liveness or readiness probe, an OOMKilled exit because the memory limit is too low, a bad config map or secret, or an entrypoint that crashes. If it's memory, I check real usage in the metrics and raise the limit. Then I tune the probes so a slow start isn't killed.
12.How do you manage Terraform state in a team?
What they're really asking: Infrastructure as code at team scale: safety and collaboration.
Answer outline
- Remote state (an S3 bucket or Terraform Cloud) with locking, never local files.
- Separate state per environment and component, to limit the blast radius.
- Plan in CI, review the plan, apply from the pipeline, and detect drift.
Full sample answer (fictional example)
I'd use remote state, for example an S3 bucket with a DynamoDB lock or Terraform Cloud, never local files, so two people can't apply at once. I'd split state per environment and per component, such as network and application, which limits the blast radius of a mistake and keeps plans fast. Changes go through pull requests: CI runs plan, a reviewer reads it, and the pipeline applies after merge. I'd also run a scheduled plan to detect drift, and restrict who can read the state, because it can contain secrets.
13.How would you deploy with zero downtime?
What they're really asking: Do you know the rollout patterns and their trade-offs?
Answer outline
- Rolling updates with readiness probes, blue-green for instant switch-back, canaries for gradual exposure.
- Database changes must work with both the old and the new version.
- Roll back automatically when error rate or latency crosses a threshold.
Full sample answer (fictional example)
I'd use a rollout pattern that keeps old instances serving until new ones are healthy. Rolling updates with readiness probes are the default. For instant switch-back I'd use blue-green, and for risky changes a canary that sends a small share of traffic first. The part people forget is the database: schema changes must work with both old and new code, so I use expand and contract. I'd also set automatic rollback when error rate or latency crosses a threshold, and drain connections gracefully on shutdown.
14.What makes a good Dockerfile?
What they're really asking: Container fundamentals: image size, security and build speed.
Answer outline
- A slim, pinned base image and a multi-stage build to keep the result small.
- Order layers so dependencies cache well, and run as a non-root user.
- No secrets in the image, and a vulnerability scan in CI.
15.How do you handle secrets in pipelines and infrastructure?
What they're really asking: Security hygiene that DevOps interviews nearly always test.
Answer outline
- A secret manager such as Vault or AWS Secrets Manager, or external secrets in Kubernetes.
- Short-lived credentials, such as OIDC federation from CI, instead of static keys.
- Rotate them, restrict who can read them, and never print them in logs.
16.One service can't reach another inside the cluster. How do you troubleshoot it?
What they're really asking: Networking basics: DNS, ports and policies.
Answer outline
- Check the Service, its endpoints, the label selector and the target port.
- Test DNS resolution and connectivity from a debug pod.
- Look for a network policy, security group or service mesh rule blocking traffic.
17.What would you monitor for a new service, and what would you alert on?
What they're really asking: Will your alerts catch real problems without waking people for nothing?
Answer outline
- The four golden signals: latency, traffic, errors and saturation.
- Alert on symptoms users feel, not on every CPU spike.
- Use dashboards and logs for diagnosis, and give every alert a runbook.
18.What is the difference between a Deployment, a StatefulSet and a DaemonSet?
What they're really asking: Kubernetes basics: do you pick the right workload type?
Answer outline
- A Deployment runs interchangeable replicas, the default for stateless services.
- A StatefulSet gives stable names and storage, for databases and brokers.
- A DaemonSet runs one pod per node, for log shippers and monitoring agents.
19.How would you set up a GitOps workflow?
What they're really asking: Do you understand declarative delivery and its benefits?
Answer outline
- Git holds the desired cluster state, and a controller such as Argo CD or Flux applies it.
- Changes arrive by pull request, giving review, history and easy rollback.
- Handle secrets separately, and alert on drift between Git and the cluster.
20.What is the difference between a layer 4 and a layer 7 load balancer?
What they're really asking: Networking fundamentals applied to a real choice.
Answer outline
- Layer 4 forwards TCP or UDP by address and port: fast and protocol-agnostic.
- Layer 7 understands HTTP, so it can route by path or header and terminate TLS.
- Add health checks and connection draining, and say which you'd choose and why.
21.How would you set up autoscaling for a web service on Kubernetes?
What they're really asking: Do you know what each scaler reacts to and where it fails?
Answer outline
- Set requests and limits first; the pod autoscaler scales on CPU or custom metrics.
- The cluster autoscaler adds nodes when pods can't be scheduled.
- Load test it, and allow for slow start-up and over-eager scale-down.
22.How do you manage configuration across dev, staging and production?
What they're really asking: Do you keep environments consistent without leaking production secrets?
Answer outline
- One codebase and one build artefact, with configuration injected per environment.
- Keep config in version control and secrets in a secret manager.
- Validate config at start-up and in CI, so a typo fails early.
Take-home or live exercise: tips
DevOps interviews often include a hands-on task: fix a broken pipeline, write a Dockerfile or Kubernetes manifest, or review a Terraform plan.
- Say what you check first, such as logs, recent changes and the plan output, before you touch anything.
- Prefer small, reversible changes, and say how you'd test and roll back each one.
- Leave the setup better than you found it: a comment, a check, or a note on what to automate next.
Skills employers test for
Technical rounds follow the job ad. These skills are named most often in the 481 newest DevOps engineer job ads we analysed (out of 1,932 live postings), shown as the share of ads that mention each. Expect questions on the top few.
- 1CI/CD82%
- 2Kubernetes67%
- 3Terraform67%
- 4Python63%
- 5Infrastructure as Code61%
- 6AWS61%
- 7Docker48%
- 8Linux45%
Full list: DevOps Engineer resume keywords.
From live job ads · computed November 2, 2026 · refreshed daily
Situational questions (23–30)
Scenarios that test judgement: say what you'd do first, and why.
23.A deploy failed halfway and production is in a mixed state. What do you do?
What they're really asking: Do you stay calm, decide quickly and keep everyone informed?
Answer outline
- Stop the rollout and decide quickly: roll back or roll forward.
- Tell stakeholders what's affected and when they'll hear from you next.
- Afterwards, make the pipeline fail safe so a partial deploy can't happen again.
Full sample answer (fictional example)
I'd stop the rollout first so the situation can't get worse, then decide quickly: roll back or roll forward. If the previous version is known good and rollback is safe, I'd roll back; if a database change already ran and rollback is unsafe, I'd roll forward with the fix. I'd tell stakeholders what's affected and when they'll hear from me next. Afterwards I'd make the pipeline fail safe, with health-checked stages, so a partial deploy can't stay half-finished, and write a short review.
24.Developers want production access to debug faster. How do you respond?
What they're really asking: Balancing speed against security and compliance.
Answer outline
- Find out what they actually need: logs, metrics or a shell.
- Offer self-service observability and read-only access first.
- Keep time-limited, audited break-glass access for real emergencies.
25.Your Terraform plan says it will destroy a production database. What do you do?
What they're really asking: Do you stop and investigate before an irreversible change?
Answer outline
- Stop, don't apply, and find out why: a renamed resource, a changed attribute or drift.
- Fix the address with a moved block or a state command, and protect it with prevent_destroy.
- Confirm recent backups before any change to stateful resources.
Full sample answer (fictional example)
I'd stop and not apply. A plan that destroys a production database is a stop sign. First I'd find out why: usually a renamed resource, so Terraform sees an old resource to delete and a new one to create, or a changed attribute that forces replacement, or drift. I'd fix the address with a moved block or a state move, and re-run the plan until it shows no destroy. I'd check recent backups before touching stateful resources, and add prevent_destroy to the database so it can't happen by accident.
26.Pipelines take 40 minutes and developers complain. Where do you start?
What they're really asking: Do you measure where the time goes before optimising anything?
Answer outline
- Time each stage to find the slowest.
- Cache dependencies and Docker layers, parallelise tests, run only the affected tests.
- Set a target and track pipeline duration over time.
Full sample answer (fictional example)
I'd measure before changing anything: time each stage and find the slowest. Usually it's dependency installs, Docker builds without caching, and a long test suite running in series. I'd cache dependencies and image layers, run tests in parallel, and run only the tests affected by the change on pull requests, with the full suite after merge. I'd set a target, say under ten minutes, and chart pipeline duration so slowdowns get noticed. And I'd ask developers which waiting hurts most, because perception matters as much as the number.
27.A production certificate expired and nobody noticed. What do you do?
What they're really asking: Do you fix quickly and remove the cause, not just renew once?
Answer outline
- Renew and deploy the certificate now, and confirm the full chain works.
- Find why alerts or automation missed it.
- Automate renewal, and alert on expiry well ahead, in every environment.
28.Your CI provider has an outage on release day. What do you do?
What they're really asking: Calm contingency thinking: is there a safe manual path?
Answer outline
- Check whether the release is urgent, and talk to stakeholders about a delay.
- If it must go, use a documented manual path with the same checks and a second reviewer.
- Afterwards, plan a fallback runner or a runbook to reduce the dependency.
29.Two teams want conflicting changes to the shared pipeline templates. How do you decide?
What they're really asking: Can you run a platform fairly, as a product with many users?
Answer outline
- Ask each team for the problem they're solving, not the change they want.
- Look for a configurable option that serves both, or a versioned template.
- Decide by impact on everyone, and record the reason in a short design note.
30.A team wants to run its own cluster outside the platform. What do you say?
What they're really asking: Do you meet a team routing around you with curiosity, not control?
Answer outline
- Ask what the platform fails to give them, and treat it as feedback.
- Explain the costs of a separate cluster: security, upgrades, on-call and spend.
- Offer a fix, or an exception with conditions such as standard logging and ownership.
Red flags to avoid in your answers
Each one is quick to fix before the day.
Reciting tool names without describing a pipeline you ran.
Walk through a real pipeline, stage by stage, and say what each stage prevented.
Making production changes by hand 'just this once'.
Explain how you'd make the change through code and review, even in an emergency.
Treating developers as users who break things.
Talk about them as customers, and about what you changed because of their feedback.
Offering no numbers: deploy frequency, lead time or recovery time.
Bring a few figures from your work, and say how you measured them.
How to prepare for a DevOps engineer interview in 7 days
An hour or two a day is enough; the order matters more than the length.
Day 1: Decode the ad
List the cloud, orchestration and pipeline tools in the ad, and mark the two you know least.
Day 2: Containers
Write a Dockerfile and a Kubernetes manifest from scratch, then break them on purpose and debug the failures.
Day 3: Terraform
Build a small network and one service with remote state, then read your plan aloud as you would in review.
Day 4: Pipeline on paper
Draw the path from git push to production with every check, and explain rollback and database changes.
Day 5: Outage and toil stories
Write two STAR stories, one outage and one automation, with timelines and numbers.
Day 6: Hands-on mock
Have a friend break a pipeline or cluster for you to fix in 45 minutes, thinking aloud.
Day 7: Last checks
Review Linux and networking basics, prepare three questions on on-call and deploys, then rest.
Questions to ask the interviewer
Pick two or three; the answers tell you whether you want the job.
- How many deploys a day do you do, and how often do they fail?
- Which parts of the infrastructure are still managed by hand?
- How is on-call shared between this team and the developers?
- Where is the platform heading next year: more Kubernetes, serverless, something else?
- How do you measure whether this team is doing well?
Preparation tips
- Practise the hands-on tasks: write a Dockerfile, a Kubernetes manifest and a pipeline from scratch.
- Be ready to whiteboard the path from git push to production, with every check in between.
- Revise Linux and networking basics: processes, permissions, DNS, TCP and load balancers.
- Bring numbers from your work: deploy frequency, lead time, recovery time and money saved.
Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.
How we wrote this page
The FindAJobAI team wrote the questions, outlines and sample answers for DevOps engineer interviews. The people, employers and numbers in the samples are invented: copy the structure, and use details from your own work.
The live skills section is based on 481 DevOps engineer job ads analysed, the newest we track, with the same deterministic skill matcher as our in-demand skills report: no AI model reads the postings. It was last computed on November 2, 2026 and refreshes daily.
Last reviewed on November 1, 2026.