Question 1
Walk through how a change for this team should get to production. Where can it stop?
Approach. Name the checks before deploy and the rollback that does not need a hero.
DevOps engineer interview questions from a job description
Map a DevOps job description to the pipeline, cloud, and incident questions it usually leads to, with a one-line approach.
Matched in your browser from the requirements in the posting and Luna’s interview-question hub. These are practice prompts, not a claim that this wording will be asked.
Requirements in the posting
DevOps Engineer
Build the path from pull request to production and keep it observable.
You will:
- Own CI/CD with GitHub Actions and make a bad deploy easy to stop
- Manage infrastructure with Terraform across AWS accounts
- Run workloads on Kubernetes and say what should not be a cluster yet
- Define monitoring, SLOs, and what is worth an on-call page
- Review security of the deploy path: who can ship, and how that access is audited
We want the pipeline change after a bad release, not only the hotfix.
Build the path from pull request to production and keep it observable.
You will:
- Own CI/CD with GitHub Actions and make a bad deploy easy to stop
- Manage infrastructure with Terraform across AWS accounts
- Run workloads on Kubernetes and say what should not be a cluster yet
- Define monitoring, SLOs, and what is worth an on-call page
- Review security of the deploy path: who can ship, and how that access is audited
We want the pipeline change after a bad release, not only the hotfix.
Likely questions
System design
CI/CD and infrastructure
Own CI/CD with GitHub Actions and make a bad deploy easy to stop
Question 2
How would you manage infrastructure so a new environment is not a one-off?
Approach. Say what is code, what is still manual, and why that manual step remains.
System design
Reliability and observability
Define monitoring, SLOs, and what is worth an on-call page
Question 3
What would you page a human for in this system, and what should stay a ticket?
Approach. Tie the page to user pain, and say the alert you would delete because it trained people to ignore pages.
Question 4
Walk through an incident. What did the user see, and what changed afterward?
Approach. Timeline in a few beats, then one system change and one team change.
Behavioral
Code review
Build the path from pull request to production and keep it observable.
Question 5
What do you insist on seeing in a pull request for this team, and what do you let go?
Approach. Name the risk you will block on and the style nit you will not spend the review on.
Question 6
Tell me about review feedback you rejected. Why was the author right, or why were you?
Approach. State the change that shipped and the reason, in one or two sentences.
System design
Containers and cloud
Run workloads on Kubernetes and say what should not be a cluster yet
Question 7
What would you run in this stack, and what is overkill for the traffic you expect?
Approach. Pick the simplest place the workload can live, then the signal that would justify a move.
Question 8
A container is healthy and the user path is not. How do you debug that?
Approach. Separate process health from the request path, and say the first signal you would open.
System design
Security
Review security of the deploy path: who can ship, and how that access is audited
Question 9
What data in this product is sensitive, and who is allowed to read it?
Approach. List readers, writers, and auditors before you name a tool.
Question 10
How would you threat-model the main action in this posting in the time a design review actually has?
Approach. One asset, one attacker, one control, and the risk you would explicitly accept.
What to prepare
- Draw the path from merge to production and mark the step that can fail safely.
- Write one user-facing symptom and the dashboard that would show it within five minutes.
- Bring one review where you blocked a change, and one where you let a smaller issue go.
- Explain one deploy target: what runs, what scales, and what you would not autoscale yet.
- Sketch who can read, write, and audit the data this posting mentions.
- Mark the three requirements you cannot yet support with a story.
- Say each answer out loud once, in under two minutes.
DevOps postings interview the path from merge to production and the path from symptom to rollback. CI/CD bullets become “where can a change stop?” Terraform or infrastructure bullets become “what is still a one-off?” Kubernetes and cloud bullets become “what is overkill for this traffic?” Incident and monitoring bullets become paging philosophy.
Security shows up as who can change production, not as a vocabulary test. If the posting says on-call, have a real incident, including the alert you would delete.
Draw the pipeline once before the interview and mark the step a human still has to bless. The sample posting is a platform role.
Sample job description
The posting below is already in the tool. The questions are the ones its requirements point to. Replace it with a posting you are actually interviewing for.
Related: Microsoft system design questions · Google system design questions · Narrate a design first