Interview prep · Technology

DevOps Engineer interview questions and answers

Interviewers for a DevOps Engineer role want to know whether you can build and run reliable, automated infrastructure and delivery pipelines, and whether you can troubleshoot calmly when production breaks. They will probe your hands-on depth with AWS, Kubernetes, Terraform, CI/CD, and monitoring. They also look for clear communication and collaboration with developers, and for good judgment about risk, automation, and trade-offs.

1. Question 1

   Tell me about yourself and how your background fits this DevOps Engineer role.

   What they're asking: The interviewer wants a concise summary of your hands-on experience, your strengths, and why you are a fit for this role.

   Sample answer

   I'm a DevOps engineer with [X] years of experience building and operating cloud infrastructure and delivery pipelines. Most recently at [company or type of company], I supported [number] services running on Kubernetes in AWS, provisioned with Terraform and deployed through [GitLab CI/CD or Jenkins] using Helm. I'm strongest at automating repetitive work. For example, I wrote Python and Bash tooling that [specific outcome, such as cutting manual release steps]. I also built dashboards and alerts with Prometheus, Grafana, and the ELK Stack so teams could spot problems early. I started as a [Linux administrator or developer], which gave me a solid base in troubleshooting. I enjoy mentoring junior engineers and working closely with developers, and I'm excited about this role because [reason tied to the job posting].

2. Question 2

   Walk me through how you would design a CI/CD pipeline to deploy a containerized application to Kubernetes on AWS.

   What they're asking: They want to see whether you understand the full delivery path, including quality gates, security, and safe rollout, not just individual tools.

   Sample answer

   I'd trigger the pipeline on a merge request in Git. The first stages run linting and unit tests, then build a Docker image with a tag tied to the commit SHA. Next I'd scan the image for vulnerabilities and push it to a private registry such as Amazon ECR. Deployment would use a Helm chart with environment-specific values files. The pipeline would deploy to staging automatically, run smoke tests, and require approval before production. In production I'd use a rolling or canary strategy with readiness probes, and the pipeline would run `helm rollback` automatically if health checks fail. Secrets would come from a secrets manager, not the repo. I'd also have the pipeline report deploy events to Grafana so we can correlate releases with metrics. In [GitLab CI/CD or Jenkins], I'd keep the pipeline definition versioned with the application code.

3. Question 3

   How do you manage Terraform in a team environment, and where does Ansible fit alongside it?

   What they're asking: They are checking that you understand state, safe collaboration on infrastructure code, and the right tool for provisioning versus configuration.

   Sample answer

   For Terraform, I use a remote backend, such as S3 with DynamoDB state locking, so state is shared and two people can't apply at once. I split state by environment and by system to limit blast radius. I put reusable patterns into versioned modules and pin provider versions. Changes go through pull requests, where the pipeline runs `terraform fmt`, `validate`, and `plan`, and a teammate reviews the plan output before anyone applies. I use Terraform to provision things like VPCs, EKS clusters, and IAM roles. I use Ansible for configuration inside machines, such as hardening Linux hosts, installing packages, and managing service configs, because it handles ordered, idempotent tasks well. Where possible I keep Ansible roles simple and tested, and I avoid configuration drift by making changes in code, not by hand on servers.

4. Question 4

   Users report that a service running on Kubernetes is slow. How do you troubleshoot it?

   What they're asking: The interviewer wants to see a structured, evidence-based troubleshooting approach across metrics, logs, and the underlying system.

   Sample answer

   I start by defining the scope: which endpoints, which users, since when, and whether it lines up with a recent deploy. In Grafana, I check latency, error rate, traffic, and saturation for the service, backed by Prometheus metrics. Then I look at pod-level CPU and memory, throttling, restarts, and whether the horizontal autoscaler is keeping up. I use `kubectl describe` and `kubectl logs` for events like OOM kills or failing probes, and I search the ELK Stack for error patterns and slow requests. If the cluster looks healthy, I check dependencies such as the database, DNS, and network paths. If needed, I SSH to a node and use Linux tools like `top`, `iostat`, and `ss`. Once I find the cause, I mitigate first, for example by scaling out or rolling back. Then I document the fix and add an alert so we catch it sooner next time.

5. Question 5

   Tell me about a time you diagnosed and resolved a serious production incident.

   What they're asking: They want evidence of problem solving, calm under pressure, attention to detail, and learning from failures.

   Sample answer

   Situation: At [company], our [service] began returning errors during a peak period after a routine release. Task: As the on-call engineer, I needed to restore service quickly and find the root cause. Action: I checked Grafana and saw error rates climbing right after the deploy, so I rolled back using Helm to stop the impact. Then I reviewed logs in the ELK Stack and found the new version was exhausting database connections because of a changed configuration value. I posted updates in the incident channel every [X] minutes so stakeholders knew the status. Afterward I led a blameless postmortem. Result: Service was restored in about [X] minutes. We added a connection-pool alert, a config validation step in the pipeline, and a canary stage for that service. The same issue hasn't recurred since.

6. Question 6

   Describe a time you disagreed with a developer or another team about how to deploy or operate something. How did you handle it?

   What they're asking: They are assessing collaboration, communication, and your ability to balance reliability with delivery speed.

   Sample answer

   Situation: At [company], a development team wanted to deploy directly to production without a staging step because staging was slow and unreliable. Task: I needed to address their speed concerns without lowering our reliability standards. Action: I asked them to walk me through their workflow and learned that staging builds took [X] minutes because of manual setup. I proposed fixing the root problem. I used Terraform and Helm to create short-lived preview environments automatically from merge requests, and I paired with two developers to test the approach. I shared the plan and a timeline in a short document so everyone could comment. Result: Deploys went through a safe path that was faster than before, the team adopted it, and we kept staging checks in place. The developers also began contributing to the pipeline templates themselves.

7. Question 7

   Give an example of a time you mentored someone or took the lead on a project.

   What they're asking: They want to see leadership, mentoring ability, and project management skills, even if you don't have a formal title.

   Sample answer

   Situation: At [company], our team was migrating [number] services from manually configured servers to Kubernetes, and two junior engineers were new to containers. Task: I was asked to lead the migration and get them productive. Action: I broke the work into phases with clear milestones in [Jira or other tracker] and prioritized the least risky services first. I ran weekly walkthroughs of Docker, Helm, and debugging with `kubectl`. I paired with each junior engineer on one service before having them own the next one, and I reviewed their pull requests with explanations, not just fixes. Result: We completed the migration by [date], and both engineers were later handling deployments and on-call shifts independently. We also left behind runbooks and Helm templates that the team continues to use.

8. Question 8

   Tell me about a time you had to juggle competing priorities or quickly learn a new tool or technology.

   What they're asking: They want to see adaptability and time management, since DevOps work often mixes planned projects with urgent requests.

   Sample answer

   Situation: At [company], I was in the middle of a Terraform refactor when leadership asked us to adopt [new tool or platform, such as a new CI system or a managed service] within [timeframe]. Task: I had to learn it quickly while keeping the existing work and daily support on track. Action: I listed everything on my plate, sorted by business impact and deadlines, and agreed with my manager to pause the lower-priority refactor. I set aside focused blocks each day to go through the documentation, built a small proof of concept, and documented what I learned for teammates. I still triaged urgent support tickets daily. Result: We adopted the new tool on schedule, and I resumed the refactor afterward with a clear plan. My notes became the team's onboarding guide for the tool.

9. Question 9

   You run `terraform plan` for a routine change and see that it will destroy and recreate a production database. What do you do?

   What they're asking: They are testing your caution, attention to detail, and ability to prevent costly infrastructure mistakes.

   Sample answer

   I would stop and not apply. First I'd read the plan closely to find which attribute change is forcing the replacement, such as a renamed resource, a changed identifier, or a provider version update. Then I'd check whether the change was intended. If it wasn't, I'd correct the code, for example by reverting the change, using a `moved` block or `terraform state mv` for a rename, or pinning the provider version. I'd re-run the plan until it shows no destructive action. I'd also confirm a recent backup or snapshot exists before any risky change. To prevent this in the future, I'd add `prevent_destroy` lifecycle rules on critical resources and require plan review in pull requests. If the replacement were truly needed, I'd plan a maintenance window and a data migration with the team.

10. Question 10

    A senior stakeholder asks you to bypass the pipeline and push an urgent fix straight to production. How do you respond?

    What they're asking: They want to see how you balance urgency, risk, and process while communicating well under pressure.

    Sample answer

    I'd first make sure I understand the urgency and the impact, because that determines the approach. Then I'd explain that I want to get the fix out fast and safely, and that the pipeline is what protects us from making the outage worse. If the pipeline is slow, I'd look for the fastest legitimate route, such as a hotfix branch that runs only the essential tests and skips nothing critical. If the situation truly demands an exception, I'd follow our emergency change process: get explicit approval from the right owner, have a second person review the change, apply it with a clear rollback plan, and log everything. Afterward, I'd open a ticket to backfill tests and review why the normal path couldn't meet the need. That keeps stakeholders confident that we can move quickly and still stay in control.