DevOps engineer interview questions, with worked answers

How to use these questions

Read the short answer and say it out loud. That is your first thirty seconds. Then read the full answer and pick two or three points to add, with an example from a system you ran. Interviewers want to hear how you think about failure, not a list of tools.

A note that says “depends on the provider” or “depends on the release” marks a detail that can change with a provider or a release. Check the current documentation before you quote it.

What a DevOps engineer is expected to know

• LinuxAsked in 39% of DevOps engineer ads (as of 5 Nov 2026).The base of most servers and containers: processes, files, permissions, systemd, networking tools and logs. and NetworkingAsked in 10% of DevOps engineer ads (as of 5 Nov 2026).DNS, TCP/IP, load balancers, TLS certificates, firewalls and private networks in the cloud.: processes, permissions, logs, DNS, load balancers and TLS certificates (what makes a connection secure).
• Containers: DockerAsked in 38% of DevOps engineer ads (as of 5 Nov 2026).Small, secure images built the same way every time; know layers, caching, and running as a normal user. images built well, and KubernetesAsked in 48% of DevOps engineer ads (as of 5 Nov 2026).Deploy, scale and debug workloads: deployments, services, ingress, resource limits, probes and rollbacks. to run, scale and heal them.
• CI/CDAsked in 73% of DevOps engineer ads (as of 5 Nov 2026).Pipelines that build, test, scan and deploy every change, with safe rollouts and a fast way back.: CI (continuous integration) builds and tests every change; CD (continuous delivery or deployment) releases it safely. Tools such as GitLab CIAsked in 10% of DevOps engineer ads (as of 5 Nov 2026).Pipelines defined next to the code: stages, runners, environments, and approvals for production., GitHub ActionsAsked in 5% of DevOps engineer ads (as of 5 Nov 2026).Workflows for build, test and deploy, reusable actions, secrets handling and short-lived cloud logins. or JenkinsAsked in 19% of DevOps engineer ads (as of 5 Nov 2026).Still common in large companies: pipelines as code, shared libraries, agents, and keeping it secure..
• Infrastructure as code: TerraformAsked in 27% of DevOps engineer ads (as of 5 Nov 2026).Infrastructure as code: modules, remote state with locking, plans reviewed before apply, no hand changes. for cloud resources, AnsibleAsked in 27% of DevOps engineer ads (as of 5 Nov 2026).Configure servers the same way every time with playbooks and roles; know when Terraform fits better. for server set-up, all changed through GitAsked in 38% of DevOps engineer ads (as of 5 Nov 2026).Branching, reviews and history; everything (code, pipelines, infrastructure) changes through a pull request. and review.
• A cloud: AWSAsked in 23% of DevOps engineer ads (as of 5 Nov 2026).Core services (compute, storage, networking, IAM), and designing for failure across availability zones. depends on the provider, AzureAsked in 27% of DevOps engineer ads (as of 5 Nov 2026).Common in European companies: identity, networking, AKS and policies; often joined to Microsoft 365. depends on the provider or Google CloudAsked in 12% of DevOps engineer ads (as of 5 Nov 2026).Google Cloud: projects, IAM, GKE and networking; less common in ads than AWS and Azure. depends on the provider: accounts, identity, networks, and designing for failure. depends on the provider
• Monitoring: metrics, logs and traces, for example with PrometheusAsked in 15% of DevOps engineer ads (as of 5 Nov 2026).Metrics and alerts (with Grafana for dashboards): what to measure, and alerts people can act on. and Grafana, and alerts people can act on.
• Code: scripts in BashAsked in 17% of DevOps engineer ads (as of 5 Nov 2026).Short, safe scripts for glue work; know when a script should become a proper tool instead. and small tools in PythonAsked in 31% of DevOps engineer ads (as of 5 Nov 2026).Automation and small tools: cloud APIs, data clean-up, checks. Readable, tested code. or GoAsked in 0% of DevOps engineer ads (as of 5 Nov 2026).Used for many cloud-native tools and Kubernetes operators; a plus in platform teams. depends on the release.
• Security: least privilege (each person and service gets only the access it needs), secrets kept out of code, patched images.

CI/CD pipelines and releases

Design a CI/CD pipeline for a web service, from commit to production.

What they check: that you think in stages with fast feedback, build once, release safely, and always have a way back.

Short answer: "Every change runs the fast checks first: build, unit tests, linting and a security scan. The pipeline builds one container image, tags it with the commit, and that same image goes to test, staging and production. Each step up needs its checks to pass. Production gets a gradual rollout with health checks, and a failed check rolls back automatically."

The full answer, in seven steps:

1. On every change: build, unit tests, a style check, and a scan of the dependencies for known security holes. Aim for feedback within ten minutes, so people wait for it rather than ignore it.
2. Build once. Make one container image, tag it with the commit, and store it in a registry. Never rebuild for production: what was tested is what ships.
3. Test environment. Deploy the image automatically and run the API and end-to-end tests. Database changes run as migrations (scripted, versioned changes), tested here first.
4. Staging. A copy of production in shape, not in data. Run smoke tests (quick checks that the main things work) and, for big changes, a load test.
5. Production, gradually. A rolling, blue-green or canary release (explained in the next question), watched by health checks and error rates.
6. The way back. An automatic rollback when the checks fail, and a one-step manual rollback for everything else. Database changes are written so the old version still works with the new schema.
7. Rules and records. Who may approve production, secrets taken from a vault, not stored in the pipeline, and a record of what went out when, so an incident can be traced to a change.

A weak answer: "Jenkins builds it and copies it to the server." No stages, no tests named, no rollback.

Follow-up: "The pipeline takes forty minutes and developers complain." Measure each stage, cache dependencies and image layers, run tests in parallel, and move slow tests to a later stage that does not block every change.

Blue-green, canary or rolling: how do you choose a deployment strategy, and how do you roll back?

What they check: that you know the trade-offs and plan the rollback before the release.

Short answer: "A rolling release replaces servers a few at a time; it is simple and the default in Kubernetes. Blue-green runs the new version next to the old and switches traffic in one step, so rollback is a switch back. Canary sends a small share of users to the new version first and widens it while the numbers stay good. I choose by risk, cost and how good our monitoring is."

The full answer: Blue-green needs double capacity for a while, but rollback is instant. Canary needs good metrics, because the point is to compare the new version with the old on real traffic; it can be automated with a tool that stops the rollout when errors rise. Rolling is cheap but mixes two versions for a while, so both must work with the same database. Feature flags (switches in the code) let you release code turned off and turn it on later, which separates deploying from releasing. The rollback plan is the same in every case: know which version to go back to, and make sure the data still works with it.

A weak answer: "We deploy at night when nobody is using it." Follow-up: "The new version changed the database. Can you still roll back?" Only if the change was additive (new columns, nothing removed); remove old parts in a later release.

How do you keep builds fast and reproducible?

What they check: practical experience with slow, flaky pipelines.

Short answer: "Pin the versions of tools and dependencies, build in clean containers, cache what is safe to cache, and keep images small. The same commit must always give the same result."

The full answer: Reproducible means a build from last month's commit gives the same image today. That needs pinned versions, a lock file for dependencies, and base images with a fixed version rather than "latest". For speed: order the image steps so the parts that change least come first and are cached, run jobs in parallel, and only build what changed in a large repository. Track pipeline time as a number the team sees.

A weak answer: "We buy bigger build servers." Follow-up: "A build passes on one runner and fails on another." Something is not pinned or not clean: compare versions, and build in a fresh container each time.

Infrastructure as code and secrets

What is infrastructure as code, and how do you work safely with Terraform state?

What they check: that you treat infrastructure like software, and know where Terraform can hurt you.

Short answer: "Infrastructure as code means servers, networks and cloud services are described in files, kept in Git and changed through review, so they can be rebuilt and every change is recorded. Terraform keeps a state file that maps the files to real resources. I keep the state in a shared, locked, backed-up store, split it by environment, and review every plan before it is applied."

The full answer: The state file is Terraform's memory of what exists. If two people change it at once or it is lost, Terraform may try to create or delete the wrong things. So: remote state with locking, encryption and versioning; separate state per environment and per large part, so a mistake has a small blast radius (the area a failure can reach); modules for repeated patterns; the plan shown in the pull request and applied by the pipeline, not from laptops; and a regular check for drift, changes someone made by hand outside the code. depends on the release

A weak answer: "I run Terraform from my laptop when something needs changing." Follow-up: "Someone changed a security group by hand in the console." The drift check shows it; either put the change into code through review, or let Terraform put it back, and close the hand access.

Terraform or Ansible: what is each for?

What they check: that you pick tools for a reason.

Short answer: "Terraform creates and changes cloud resources: networks, databases, clusters. Ansible configures what runs on servers: packages, files, services. With containers and managed services, much of what Ansible did moves into the image build."

The full answer: Terraform describes the end state and works out the steps; Ansible runs steps in order, written so they can run twice safely. Both can do some of the other's job, but mixing them without a rule leads to two tools fighting over one resource. I write down which tool owns what. Where servers are rebuilt from images instead of changed in place, there is less to configure at all.

A weak answer: "They are the same, I use whichever." Follow-up: "Fifty old servers must be patched tonight." Ansible, in batches, with a check after each batch and a stop on failure.

How do you handle secrets such as passwords and API keys?

What they check: that secrets never live in code, images or logs, and that you plan for a leak.

Short answer: "Secrets live in a secrets manager or vault, not in Git, images or pipeline files. Services fetch them at start with their own identity, access is the least needed, every read is logged, and secrets are rotated, changed on a schedule and at once after a leak."

The full answer: Where possible, avoid long-lived secrets entirely: the pipeline logs in to the cloud with short-lived credentials, and services use the cloud's own identities. Scan every commit for secrets, and treat a secret that reached Git as leaked, even if the commit is removed: rotate it. Kubernetes secrets are only encoded, not encrypted, by default, so turn on encryption or use an external store. depends on the provider

A weak answer: "We keep them in an environment file in the repository, but it is private." Follow-up: "A key was pushed to a public repository an hour ago." Revoke it now, issue a new one, check the logs for use of the old key, then find out how it happened.

Containers and Kubernetes

Explain how an application runs on Kubernetes, in plain words.

What they check: a clear picture of the main parts, not memorised names.

Short answer: "The app is packed in a container image. A pod is one or more containers that run together. A deployment says how many pods of which version should run and replaces them when they fail or when a new version comes. A service gives the pods one stable address, and an ingress lets traffic in from outside. Kubernetes keeps checking that what runs matches what was asked for."

The full answer: Add the parts that make it work in production: probes, the checks Kubernetes uses to see whether a pod is alive and ready for traffic; requests and limits, how much processor and memory a pod reserves and may use; config maps and secrets for settings; namespaces to keep teams apart; and autoscaling, which adds pods when load rises. Managed services (EKS, AKS, GKE) run the control part for you. depends on the provider

A weak answer: a list of every object type with no idea how they fit. Follow-up: "Why would a pod be running but get no traffic?" Its readiness probe fails, or the service's labels do not match the pod.

A pod keeps restarting. How do you find out why?

What they check: a calm, ordered way of debugging.

Short answer: "I look at the pod's events and status first, then the logs of the last crashed run. The usual causes are a crash at start, a wrong setting or secret, a failed liveness probe, or the pod running out of memory and being killed. Then I check what changed: a new image, a new setting or a dependency that is down."

The full answer: The status tells you which kind of failure it is: out of memory, an image that cannot be pulled, or the app exiting with an error. The logs of the previous run usually show the error. If the liveness probe is too strict, Kubernetes kills a slow but healthy app, so check its timing. If it is memory, compare the limit with real use over time. If it started after a release, roll back first and debug after, because users come first.

A weak answer: "I delete the pod and see if it comes back." Follow-up: "Only one of three pods restarts." Look at what is different: its node, its data, or the requests that reach it.

How do you set resource requests and limits, and how do you scale?

What they check: that you base settings on measurements and understand the cost side.

Short answer: "I set requests from measured normal use, so the scheduler places pods well, and a memory limit to protect the node. I scale pods on a signal that tracks load, such as processor use or queue length, and let the cluster add nodes when pods do not fit."

The full answer: Requests too high waste money; too low and pods are squeezed onto busy nodes. Memory limits stop one leaky pod from taking down a node; processor limits can slow apps down, so many teams leave them off. Scale on what actually limits the service: for a worker, the length of its queue rather than processor use. Test the scaling with a load test before you need it, and set a maximum so a bug cannot scale the bill without limit.

A weak answer: "We give every pod plenty, to be safe." Follow-up: "Costs doubled after the move to Kubernetes." Compare requests with real use, right-size, and scale down at quiet times.

Monitoring, SLOs and incidents

What do you monitor, and what should page someone at night?

What they check: that you alert on what users feel, not on every number.

Short answer: "I collect metrics, logs and traces for every service. I page only on symptoms users feel, such as errors, slow answers or a service down, and only when someone must act now. Everything else goes to a dashboard or a ticket for working hours."

The full answer: Monitoring tells you that something is wrong; observability means you have enough data (metrics, logs, traces) to find out why, even for a problem you never expected. A simple start is the four golden signals: traffic, errors, latency (how long answers take) and saturation (how full the system is). Each page must have a clear owner and a runbook, a short guide to the first steps. Too many alerts teach people to ignore them, so remove or fix any alert that fires without needing action.

A weak answer: "We alert when processor use is over eighty percent." That may be fine for users. Follow-up: "The on-call engineer got thirty pages last week." Go through each one, delete or tune the noisy ones, and fix the causes of the real ones.

What are SLOs and error budgets, and how do they change decisions?

What they check: that you can turn "reliable" into a number the business agrees with.

Short answer: "An SLI is a measure of what users feel, such as the share of requests that succeed fast enough. An SLO is the target for it, agreed with the business. The error budget is the failure the target allows. While budget is left, the team ships; when it is spent, the team puts reliability first."

The full answer: SLO means service level objective; SLI, service level indicator. A target of one hundred percent is wrong: it stops all change and users cannot tell the difference from a slightly lower one. Choose a few SLOs per service from the user's point of view, measure them over a rolling month, and alert when the budget is being used up too fast rather than on every error. The budget turns arguments into a rule: product and engineering agree in advance what happens when it runs out.

A weak answer: "Our SLA is five nines." An SLA is a contract with customers, and the target is not based on users. Follow-up: "The budget is spent but the business wants a big release." Follow the agreed rule, or make the exception openly, with extra safety such as a canary release.

Walk me through how you handle an incident, and what happens after.

What they check: calm order under pressure, communication, and learning without blame.

Short answer: "First limit the damage for users, then find the cause. One person leads, one works on the fix, one keeps people informed. Often the fastest fix is a rollback. Afterwards we write a blameless postmortem: what happened, why, what helped, and the actions that stop it happening again."

The full answer, in six steps:

1. Declare it. Say clearly that there is an incident, how severe it is, and who leads. Open one channel for it.
2. Limit the damage. Roll back the last change, turn off a feature, move traffic or add capacity. Fixing the root cause can wait until users are safe.
3. Keep people informed. Short updates at fixed times for support and customers, in plain words: what is affected, what we are doing, when the next update comes.
4. Find the cause. Look at what changed (releases, settings, traffic, providers), then the metrics, logs and traces. Write a timeline as you go.
5. Close it. Confirm with the measures users feel that the service is back, then stand down.
6. Learn. A blameless postmortem within a few days: the timeline, the causes, what made it worse or better, and actions with owners and dates. Blameless means asking how the system let it happen, not who to punish, so people tell the whole story.

A weak answer: "I log in to the servers and start fixing things." No lead, no updates, no rollback, no learning.

Follow-up: "The same kind of incident happened three times this year." The actions from the postmortems were not done or not enough: track them like product work, and look for the common cause.

A Linux server is slow. How do you find out why?

What they check: a method, from the outside in, not guesses.

Short answer: "I check the four resources in order: processor, memory, disk and network. Which one is full, and which process uses it? Then the logs for errors, and what changed recently."

The full answer: Load and processor use show whether the machine is busy or waiting. Memory: is it swapping, moving memory to disk, which makes everything slow? Disk: is it full, or are reads and writes queuing? Network: errors, lost packets, slow DNS? Then the process itself: is it stuck waiting on a database or another service? Compare with the same time last week in the metrics. On a container platform, the same questions apply per container.

A weak answer: "I restart it." That may help for now, but it hides the cause. Follow-up: "Processor use is low but everything is slow." Look for waiting: disk, network, locks or a slow dependency.

Cloud, security and cost

How do you set up access and networks in a cloud account safely?

What they check: least privilege, separation, and no shortcuts that last.

Short answer: "Separate accounts or subscriptions for production and the rest, people signing in through the company's identity system with roles instead of personal keys, services with their own narrow permissions, private networks for databases, and every change through code and review."

The full answer: Production is reached only through roles that are logged, with extra checks for powerful actions. Nothing important has a public address unless it must: databases and internal services sit in private networks, and traffic in goes through a load balancer and a firewall. Guardrails, rules set for the whole organisation, block things such as public storage buckets. Logs of who did what go to a separate, locked account. depends on the provider

A weak answer: "Everyone in the team has admin rights, it is faster." Follow-up: "A developer needs production data to debug." Give time-limited, logged, read-only access, or better a safe copy without personal data.

How do you cut cloud costs without hurting reliability?

What they check: that you measure first, and know the main levers.

Short answer: "First make costs visible per team and service with tags. Then remove what is unused, right-size what is too big, scale down at quiet times, and commit to discounts for the steady base. I check each change against the SLOs."

The full answer: The usual wins: idle test environments switched off at night; old disks, snapshots and logs deleted by rule; servers and pods sized to measured use; spot or pre-emptible machines, cheap spare capacity that can be taken back, for work that can be interrupted; savings plans or reservations for the base load; and data transfer between regions kept down. Costs shown to the teams that cause them fall fastest. depends on the provider

A weak answer: "We move everything to the cheapest instance type." Follow-up: "Finance wants costs down by a third this quarter." Show the biggest items, the safe savings, and what would cost reliability, and let the business choose.

What does DevOps mean to you, and how do you work with development teams?

What they check: that you see DevOps as a way of working, not a separate team that deploys for others.

Short answer: "DevOps means the people who build a service also help run it, and the path to production is automated and shared. My job is to make the safe way the easy way: good pipelines, templates and a platform developers can use themselves, so they do not wait for me."

The full answer: Signs it works: teams deploy on their own many times a day, incidents are rare and short, and the platform has documentation and a clear way to ask for help. Common measures are the DORA metrics: how often a team deploys, how long a change takes to reach production, how often a change causes a failure, and how fast service is restored. I treat the platform as a product: developers are its users, and I ask them what slows them down.

A weak answer: "Developers write the code, and we deploy it." Follow-up: "A team keeps asking you to deploy for them." Find out what blocks them, fix it in the platform or the documentation, and pair with them on the first few releases.

Your CV for these questions

Every answer above is easier when your CV already says it, because the interviewer asks about what is on it. Put one line under each job for each of these, in the words the ads use:

Then score your CV against a real job: you will see which of these the job needs and which your CV does not prove yet.