DevOps engineer interview questions

What they're checking

Whether you troubleshoot systematically from symptoms to cause.

A strong answer covers

1. Scope the problem first: one server or all, since when, and what changed recently.
2. Check resources in order (CPU, memory and swap, disk I/O, then network) with tools such as top, free and iostat.
3. Look at application logs and dependencies, such as slow database queries or an upstream service.
4. Fix the cause, then add monitoring or an alert so you would catch it earlier next time.

What they're checking

Whether you can build a pipeline that is fast, safe and easy to roll back.

A strong answer covers

1. Start with what runs on every commit: build, unit tests, linting and security scans.
2. Produce one versioned artefact, such as a container image, and promote that same artefact through each environment.
3. Deploy to staging with integration tests, then to production with a gradual strategy such as a canary.
4. Make rollback a single step, and keep the pipeline fast enough that people don't bypass it.

What they're checking

Whether you understand release strategies and when each is worth its cost.

A strong answer covers

1. Blue-green runs two identical environments and switches all traffic at once, so rolling back means switching back.
2. Canary sends a small share of traffic to the new version first and widens it while the metrics stay healthy.
3. Compare them: blue-green is simple but doubles infrastructure, while canary limits the damage but needs good metrics.
4. Say which you have used and why it fitted that system.

What they're checking

Whether you monitor what users experience and avoid alerts nobody acts on.

A strong answer covers

1. Start from user-facing signals, such as latency, error rate, traffic and saturation.
2. Set service level objectives and alert when they are at risk, rather than on every spike in CPU.
3. Make each alert actionable, with an owner and a runbook, and send the rest to dashboards.
4. Add logs and traces so the person on call can go from an alert to the cause quickly.

What they're checking

How you act under pressure, and whether you fix causes rather than symptoms.

A strong answer covers

1. Describe the impact briefly: what broke, for whom and for how long.
2. Explain how you responded: stopping the damage first, then communicating, then finding the cause.
3. Name the root cause, including any process gaps, without blaming individuals.
4. List what changed afterwards, such as a test, an alert, a runbook or an architecture change.