Interview Questions for DevOps, Security & Infra Roles

Infrastructure interviews follow a pattern. A recruiter or HR screen checks that your experience matches the posting. Then one or two technical rounds go deep on the tools and incidents on your CV. For senior roles, a final round with a manager or an architect asks how you make decisions. The questions below are grouped by role, and for each one we describe what the interviewer is usually trying to find out.

They are not a list to memorise. Interviewers rephrase, follow up, and ask about whatever is on your CV. Use them to check that you have a real story or a clear explanation ready for each area the posting mentions.

Two kinds of answer cover almost all of them. Questions about something you did ("tell me about an outage you handled") work best with the STAR structure in our STAR method guide. Questions that ask you to solve something on the spot ("how would you design...") work best when you talk through your reasoning, as described in our guide to thinking aloud in technical interviews.

Questions every infrastructure candidate should expect

"Walk me through your current setup." The interviewer wants to know how much of it you understand beyond your own part. Describe it from the user's request inwards: where traffic enters, what runs it, where data lives, how it is deployed and monitored. Say which parts you own and which you only use.

"Tell me about the worst incident you've been involved in." This tests how you behave under pressure and whether you learn from failures. Use STAR, keep the technical detail precise, and give the result honestly, including what was changed afterwards so it would not happen again. Avoid blaming people; describe the gap in the process.

"What would you automate first if you joined us?" There is no right answer, but there is a wrong one: naming a tool before asking what takes the team's time. A good answer starts with how you would find out where the repeated manual work is, then gives an example from your past.

"Tell me about a time you disagreed with a technical decision." The interviewer is checking whether you can push back with evidence and then commit to a decision you did not make. Describe what you proposed, what data you used, what was decided, and how you worked with the outcome.

DevOps and platform engineers

"How does a change get from a developer's laptop to production in your current team?" The interviewer is checking that you know the full pipeline, not only the step you maintain. Name the stages, the checks at each one, and who can approve what. Mention how a bad deploy is rolled back and how long that takes.

"How would you reduce deploy time from 40 minutes to 10?" This is a thinking-aloud question. Start by asking where the 40 minutes go, then go through the usual causes: slow tests, no caching of dependencies or images, sequential stages that could run in parallel, manual approvals.

"How do you manage secrets in your pipelines?" A security check disguised as a DevOps question. Explain where secrets are stored, how pipelines get them, how they are rotated, and what stops them appearing in logs.

"Your Kubernetes pods keep restarting. Where do you start?" A troubleshooting question. Say what you would look at in order (events, exit codes, logs of the previous container, resource limits, probes) and what each result would tell you.

Security engineers and SOC analysts

"Walk me through how you would triage this alert." Often given with a real-looking alert. The interviewer wants to see a method: confirm it is real, establish scope, decide on containment, and record what you did. Say what evidence you would collect before acting.

"How do you reduce false positives without missing real attacks?" This tests detection engineering judgement. Describe tuning against data rather than silencing rules, how you measure noise, and how you check that a tuned rule still fires on the attack it was written for.

"A developer wants an exception to a security policy to meet a deadline. What do you do?" The interviewer is checking how you balance risk against delivery. A strong answer neither refuses outright nor simply approves: it asks what the risk is, proposes a compensating control or a time limit, and records who accepted the risk.

"Explain this vulnerability to a non-technical manager." Communication matters in security roles more than many candidates expect. Practise explaining one vulnerability you have dealt with in terms of what an attacker could do and what it would cost the business.

System engineers and sysadmins

"A server is running out of disk space at 2 a.m. What do you do?" Tests whether you fix the immediate problem safely and then the cause. Say what you would check before deleting anything, how you would buy time, and what you would change so it doesn't happen again.

"How do you patch a fleet of servers without downtime?" Describe the order you would patch in, how you would test first, how load is moved away from servers being patched, and how you would roll back.

"What's your backup strategy, and when did you last test a restore?" The second half is the real question. Interviewers know that many backups are never tested. If you have a story about a restore test that found a problem, tell it.

"How do you document your systems?" A practical question about whether others can work on what you built. Give a concrete example: runbooks, diagrams, where they live, and how they are kept current.

IT architects

"Tell me about an architecture decision you would make differently today." This tests self-assessment. Pick a real decision, explain why it made sense at the time, what changed, and what you learned.

"How do you choose between building, buying and using an open-source component?" There is no single answer. The interviewer wants to hear the criteria: cost over several years, the team's ability to run it, how close it is to the core of the business, and how hard it would be to leave.

"How do you get a design accepted by teams who don't report to you?" Architects rarely have direct authority. Describe how you involve teams early, how you document decisions and their reasons, and an example where you changed your design after feedback.

"Draw the architecture of a system you know well, and tell me its weakest point." Combine a clear diagram with an honest assessment. Naming the weak point yourself shows more understanding than defending every choice.

Questions to ask the interviewer

Most interviews end with "Do you have any questions for us?" For infrastructure roles, questions about how the team works tell you more than questions about the company:

• How often are people paged outside working hours, and how is on-call shared?
• What happened after the last major incident?
• How much of the infrastructure is defined in code today?
• What would you expect me to have done by the end of the first three months?

FAQ

How technical is the first interview?

Usually not very. The first call is often with a recruiter or HR, who checks your experience against the posting, your notice period and salary expectations, and why you are looking. Expect to explain your current role in plain language. The deep technical questions come in later rounds.

What if they ask about a tool I haven't used?

Say so, then connect it to something you have used. "I haven't used that one, but I've run a similar tool for two years, and the concepts I'd expect to carry over are these." Interviewers usually value honesty and the ability to transfer knowledge over a list of exact tools.

How many stories should I prepare?

Six to eight is enough for most infrastructure interviews: an incident you handled, an automation you built, a disagreement, a mistake, a migration or large change, a time you explained something technical to a non-technical person, and one or two that show the main skill the posting asks for.

Will they ask about things on my CV that I only touched briefly?

Often, yes. Interviewers prepare from your CV and pick the tools and projects that match the role. If something is on your CV, be ready to explain what you did with it and at what depth. If you could not answer two follow-up questions about it, consider moving it lower or removing it.

Do these questions change for senior roles?

The topics stay similar, but the expected answers move from what you did to why, and from your own work to the team's. A senior candidate describing an incident is expected to talk about the process change afterwards, not only the fix.