DevOps Engineer interview questions and answers

Continuous integration means developers merge small changes into the main branch often, and every push triggers an automatic build and tests, so integration problems show up within minutes instead of at the end of a sprint. Continuous delivery goes further: every change that passes the pipeline is packaged and ready to release, but going to production needs a manual approval. Continuous deployment removes that approval, so every change that passes all stages reaches production automatically.

Give an example: build, unit tests, Docker image, deploy to staging, integration tests, then a one-click approval for production is continuous delivery. Mention that continuous deployment needs strong automated tests, feature flags and a quick rollback.

I'd trigger it on every pull request and on every merge to main. The stages: check out the code, set up the runtime, restore the dependency cache, build, run linting and unit tests, run static analysis such as SonarQube, then build a Docker image tagged with the commit SHA and push it to a registry. After that it deploys to staging, runs smoke tests, and waits for an approval before production.

In GitHub Actions this is a YAML workflow in .github/workflows with jobs and steps; in Jenkins it's a Jenkinsfile with stages, kept in the repository. Put the cheap, fast checks first so a broken build fails within a minute or two.

First I'd measure which stages take the time instead of guessing. Then the usual fixes: cache dependencies (the Maven repository or npm cache, keyed on the lock file's hash), order the Dockerfile so dependency layers are reused, and run independent jobs such as linting, unit tests and security scans in parallel. Split a large test suite across several runners. In a monorepo, build and test only the modules that changed.

Build the artifact once and promote the same image through staging and production instead of rebuilding for each environment; it's faster and safer. Keep a short smoke suite on every push and move the slow end-to-end suite to after merge or nightly. Give your result: "from 40 minutes to 12".

Never in the repository or the pipeline file. Store them in the CI tool's secret store (GitHub Actions secrets, Jenkins credentials) or a vault such as HashiCorp Vault or AWS Secrets Manager, and inject them at run time; the tool masks them in logs. Better still, avoid long-lived cloud keys entirely: GitHub Actions can use OIDC to get a short-lived token and assume an IAM role.

Scope secrets per environment, so production secrets are available only to protected branches and approved deployments. Rotate them regularly and scan commits with a tool like gitleaks. If a secret is ever pushed, revoke and rotate it at once; deleting the commit isn't enough, because clones and history keep it.

An image is a read-only template made of layers: base files, the runtime, your application. A container is a running instance of an image with a thin writable layer on top; you can run many containers from one image.

A virtual machine runs a full guest operating system with its own kernel on a hypervisor, so it is heavier and slower to boot. Containers share the host's kernel and are isolated with Linux namespaces (what a process can see) and cgroups (how much CPU and memory it can use), so they start in seconds and are much smaller. The trade-off is weaker isolation than a VM. Interviewers often follow up: Docker Desktop on Windows or Mac runs Linux containers inside a small VM.

A typical one:

FROM node:22-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Order matters because of layer caching. Docker reuses a cached layer until an instruction, or a file it copies, changes; from that point every later step is rebuilt. Copying only the package files and installing dependencies before copying the source means an ordinary code change doesn't reinstall every dependency, so builds take seconds instead of minutes. Add a .dockerignore file to keep node_modules, .git and local .env files out of the build context. Mention that EXPOSE only documents the port; you still publish it with -p 3000:3000.

The data was in the container's writable layer, and docker compose down removes the containers, so the new container started empty. A restart alone keeps the data; removing the container doesn't.

The fix is to put the database's data directory on a named volume: under the service, volumes: - pgdata:/var/lib/postgresql/data, and declare pgdata under the top-level volumes key. Docker manages a named volume and keeps it when containers are removed. A bind mount, such as ./data:/var/lib/postgresql/data, maps a host folder instead; it's handy for source code and config files in development but depends on the host's paths and permissions. Warn that docker compose down -v deletes named volumes too.

Use a multi-stage build: compile with Maven and a full JDK in the first stage, then copy only the built jar into a small runtime image with just a JRE, such as an eclipse-temurin JRE image or a distroless Java image. That alone usually removes most of the size. Use a .dockerignore, and clean package caches in the same RUN instruction that created them, because a later deletion doesn't shrink an earlier layer.

For security, run as a non-root user with USER, pin the base image to a version or digest, and scan images in the pipeline with a tool like Trivy. Never copy secrets into the image: they stay in the layer history even if deleted later. Use build secrets instead.

A Pod is the smallest unit Kubernetes runs: one or more containers that share an IP address and can share volumes. Pods are disposable; if one dies, it isn't repaired, it's replaced. A ReplicaSet makes sure a set number of identical pods is always running, creating new ones when any disappear. A Deployment manages ReplicaSets and adds rolling updates and rollback: when you change the image, it creates a new ReplicaSet, scales it up and scales the old one down.

In practice you create Deployments, not bare pods or ReplicaSets. Mention the commands: kubectl rollout status deployment/web to watch an update and kubectl rollout undo deployment/web to go back to the previous version.

Pod IP addresses change every time pods are recreated, and there are usually several replicas. A Service gives them one stable virtual IP and DNS name, such as web.default.svc.cluster.local, and spreads traffic across the pods its label selector matches.

ClusterIP, the default, is reachable only inside the cluster; use it for internal services like a database or an API called by other pods. NodePort opens the same port on every node, from the range 30000 to 32767 by default, and forwards it to the Service. LoadBalancer asks the cloud provider to create an external load balancer for the Service. For many HTTP services, teams usually put one Ingress controller in front rather than paying for a load balancer per service.

Namespaces divide one cluster into virtual sections, for teams or environments like dev and staging. Names only need to be unique within a namespace, and you can apply RBAC permissions, ResourceQuotas and LimitRanges per namespace. A new cluster starts with default, kube-system, kube-public and kube-node-lease, and you choose one with kubectl -n.

They are not full isolation. By default, pods in different namespaces can still talk to each other over the network; you need NetworkPolicies, and a network plugin that enforces them, to block that. Some objects aren't namespaced at all, such as nodes, PersistentVolumes and ClusterRoles. For strong separation, production usually runs in its own cluster, often in its own cloud account.

ConfigMaps hold non-sensitive settings and Secrets hold passwords and tokens; pods read both as environment variables or as files from a mounted volume. Mounted files are updated after the object changes, while environment variables change only when the pod restarts.

By default a Secret is only base64-encoded, not encrypted: anyone allowed to read it through RBAC can decode it, and it's stored in etcd. To harden it, enable encryption at rest for etcd (managed clusters offer KMS encryption), restrict get and list on Secrets to the service accounts that need them, and never commit Secret YAML to Git. Many teams sync secrets from AWS Secrets Manager or Vault with the External Secrets Operator, or commit only encrypted Sealed Secrets.

Usually traffic is going to pods that aren't ready yet, or to pods that are shutting down. First check the readiness probe: without one, a pod gets traffic as soon as its container starts, before the application has loaded. Add a readiness probe on a real health endpoint. Then check the strategy: maxUnavailable: 0 with maxSurge: 1 keeps full capacity during the rollout.

Then shutdown: the application must handle SIGTERM and finish requests in progress, and a short preStop sleep gives the load balancer time to stop sending traffic before the process exits, within terminationGracePeriodSeconds (30 by default). Also check that the new version works with the current database schema, since old and new pods run side by side.

It makes a script stop on errors instead of carrying on silently. -e exits as soon as a command returns a non-zero exit status. -u treats an unset variable as an error, so a typo in a variable name doesn't quietly become an empty string; that matters in a line like rm -rf "$BUILD_DIR/". -o pipefail makes a pipeline fail if any command in it fails, not just the last one, so curl failing in curl ... | tar xz is caught.

Mention the limits: -e doesn't apply to commands tested in an if condition or joined with || and &&, so check those yourself. Add a trap on EXIT to clean up temporary files, and remember that $? holds the last exit status, 0 meaning success.

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -5

awk prints the first field, which is the client IP in Nginx's default log format. sort puts identical addresses next to each other, because uniq only merges adjacent duplicates. uniq -c counts each one, sort -rn sorts those counts from highest to lowest, and head -5 keeps the top five.

Interviewers often follow up with a variation, such as counting server errors: awk '$9 >= 500' access.log | wc -l, since the status code is the ninth field in that format. Mention that behind a load balancer the first field may be the load balancer's address unless Nginx is set up to log the real client IP.

The script: start with set -euo pipefail, then tar -czf "/backups/app-$(date +%F).tar.gz" /var/www/app, then find /backups -name 'app-*.tar.gz' -mtime +7 -delete. The crontab line: 30 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1, which runs at 2:30 every night.

What goes wrong in practice: cron runs with a minimal PATH and environment, so use full paths; output vanishes unless you redirect it; a % written directly in a crontab line must be escaped, which is why the date is inside the script; a slow run can overlap the next, so wrap it in flock; and the disk can fill up. Most important, alert when it fails and test a restore regularly.

The machine checks its own cache and /etc/hosts, then asks its configured resolver. If the resolver hasn't cached the answer, it asks a root server, then the top-level domain's servers (for .com or .in), then the domain's authoritative name servers, and caches the answer for the record's TTL.

To debug: dig example.com shows the answer and its remaining TTL; dig @8.8.8.8 example.com compares a public resolver with yours; dig NS example.com shows which name servers are really authoritative. A common mistake is editing records at the registrar while the domain's name servers point to another DNS provider. Also check /etc/hosts for an old entry, and remember old answers stay cached until their TTL expires.

A /24 has 32 minus 24, so 8 host bits: 256 addresses. Normally 254 are usable, because the first is the network address and the last is the broadcast. Cloud providers reserve more; AWS keeps 5 per subnet, leaving 251.

A /25 splits it in half: 10.0.1.0/25 covers .0 to .127, and 10.0.1.128/25 covers .128 to .255. Both .130 and .200 fall in the second half, so yes, the same /25. In /26 blocks of 64 they wouldn't be: .128 to .191 and .192 to .255. Explain why it matters in DevOps: firewall and security group rules use CIDR ranges, and a Kubernetes pod network or VPN range must not overlap the VPC or office network.

Work from the server outwards. On the server, ss -tlnp shows which TCP ports are listening and which process owns them. If it shows 127.0.0.1:8080, the app listens only locally; it must bind to 0.0.0.0 or the server's IP. Test locally with curl localhost:8080.

Then the host firewall: sudo ufw status, firewall-cmd --list-all or iptables -L -n. Then the cloud layer: a security group or network rule must allow that port from your IP. From the laptop, nc -zv server 8080 tests the port. Read the error: "connection refused" means the packet reached the host but nothing was listening, or it was actively rejected; a timeout means something dropped the packet, usually a firewall.

State, the terraform.tfstate file, records which real resource each block in your code created, with its IDs and attributes. Terraform compares code, state and the real infrastructure to work out what a plan should change.

A local state file fails in a team: it's lost with the laptop, two people can apply at once, and others can't see it. A remote backend, such as an S3 bucket with versioning and encryption, Azure Storage, Google Cloud Storage or HCP Terraform, keeps one shared copy, with locking so only one apply runs at a time: on S3 this was a DynamoDB table, and recent versions can lock with a file in S3 itself. State can contain passwords in plain text, so restrict access and never commit it to Git.

init downloads the providers and modules and connects to the backend. plan reads the current state, refreshes it against the real infrastructure, and shows what would change: + to create, ~ to update in place, - to destroy, and -/+ to replace. apply makes those changes.

In a pipeline, on each pull request run terraform fmt -check, terraform validate and terraform plan -out=tfplan, and post the plan for review. After merge, run terraform apply tfplan, so exactly what was reviewed is applied, with an approval step for production. The pipeline should get cloud access through short-lived credentials, not stored keys. Interviewers like to hear that you read every plan for unexpected destroys or replacements before approving.

Put the reusable parts in modules, such as a network module and an application module, with input variables and outputs, and version them with Git tags or a registry. Each environment is a small root configuration, for example envs/dev and envs/prod, that calls those modules with its own values like instance sizes and counts, and has its own state file. Ideally each environment is also in its own cloud account.

Separate state limits the blast radius: a mistake in dev can't touch production. Workspaces share one configuration with different state files; they suit identical temporary copies, but it's easy to apply to the wrong one, so many teams prefer directories. Pin provider and module versions, and promote a module change through dev and staging before prod.

Prometheus pulls, or scrapes, metrics over HTTP from each target's /metrics endpoint at a set interval. Targets come from its configuration or from service discovery, for example in Kubernetes. Each time series is a metric name plus labels, such as http_requests_total with method and status. Exporters expose metrics for software that doesn't do it natively, like node_exporter for a Linux server's CPU, memory and disk.

A counter only goes up, resetting when the process restarts, so you query its rate: rate(http_requests_total[5m]) gives requests per second. A gauge goes up and down, like memory in use or queue length. Grafana queries Prometheus to draw dashboards. Mention that labels with many values, such as user IDs, can overload Prometheus.

An SLI, service level indicator, is a measurement of what users experience: for example, the percentage of requests that succeed and respond within 300 ms. An SLO, objective, is the target the team sets for it: 99.9% of requests over 30 days. An SLA, agreement, is a contract with customers that carries penalties such as service credits if it's missed, so it's usually looser than the SLO.

The SLO gives an error budget: 99.9% over 30 days allows 0.1% failures, about 43 minutes of complete downtime (43,200 minutes times 0.001). If the budget is used up, the team slows down releases and works on reliability. Interviewers like candidates who choose SLIs that users feel, not CPU usage.

I'd page only for symptoms that affect users, like a high error rate, slow responses or a fast-burning error budget, not for every cause such as CPU at 80%. Every page should be urgent and actionable, with a link to a runbook; anything that can wait goes to a ticket or a chat channel for working hours.

In Prometheus, add a for: duration to rules so a one-minute spike doesn't page anyone. In Alertmanager, group related alerts and use inhibition, so one database outage doesn't send fifty alerts from the services behind it. Then review alerts every week: delete or tune ones nobody acted on, and track how many pages each on-call shift gets. Fewer, better alerts are what make people respond.

A registry stores and serves Docker images: Docker Hub, or a cloud one such as Amazon ECR, Azure Container Registry, Google Artifact Registry, or Harbor inside a company. The pipeline builds the image, tags it with the commit SHA, logs in to the registry with short-lived credentials and pushes it.

The cluster pulls with its own identity rather than a shared password: on EKS the nodes' IAM role gets read access to ECR, on AKS the cluster's managed identity is granted pull rights, or you use an imagePullSecret. Use a private registry for company images, turn on image scanning, and avoid the latest tag in production, so every deployment points to an exact, traceable image. Lifecycle rules delete old untagged images.

In a managed service the cloud provider runs the control plane: the API server, etcd and the scheduler. They keep it highly available, patched and backed up, and upgrades become a guided operation instead of a project. It also connects easily to the provider's load balancers, storage, identity and logging.

You still own a lot: worker nodes (unless you use something like Fargate or GKE Autopilot), upgrades of your add-ons, networking, security and your applications. A self-built cluster with kubeadm gives full control and suits on-premises data centres or special needs, but someone has to run etcd backups, certificates and upgrades. Mention the cost too: managed control planes have a fixed hourly charge per cluster, so don't create clusters casually.

First find where the money goes: tag every resource with team and environment and look at the provider's cost tools by tag. Then the usual savings. Schedule non-production servers and databases to stop at night and on weekends; that alone can cut their cost by more than half. Create preview environments per pull request and destroy them automatically when it's merged. Rightsize: dev rarely needs production-size instances or databases.

Use spot or preemptible capacity for CI runners and dev Kubernetes node groups, since a lost node there is only an inconvenience. Delete unattached disks, old snapshots and idle load balancers. Set budgets with alerts per team, so the cost is visible to the people who create it.

Keep it to about a minute and point it at DevOps. Present, past, future works well: "I'm a [degree] graduate from [college], and I enjoy automating how software gets built and shipped. In my project [project], I set up a GitHub Actions pipeline that built a Docker image and deployed it to [a cloud VM or Kubernetes], which cut our manual deployment steps to none. I've also been practising Linux, Terraform and [tool] on my own [lab or certification]. Now I'm looking for a DevOps role where I can work on CI/CD and cloud infrastructure for real users."

Name the tools you've actually used; interviewers will ask about each one.

Answer honestly, and show you understand why it exists: production systems run all the time, and someone has to respond when they break. A good answer: "Yes. I understand that on-call is part of running production, and I'm comfortable with a rotation. I'd want to make sure our alerts and runbooks are good enough that a page at night is rare and quick to fix, and I'd take part in improving them after each incident."

If you have a real limit, such as a family responsibility on certain days, say so politely and ask how the rotation works. Don't say yes to everything and then struggle later.

Interviewers want honesty and ownership, not a story where nothing ever goes wrong. Use STAR and spend most of the time on what you did and what changed afterwards: "I updated a shared pipeline template (situation), and it broke the builds for three other teams (task). I rolled back my change within fifteen minutes, told the affected teams in our channel, then found I'd tested it only on my own service (action). I added a test pipeline that runs the template against sample projects before release, and it caught two problems in the next month (result)."

Admit the mistake plainly, show the quick recovery, and end with the safeguard you added.

Show that you see both sides and use data and automation rather than opinions. Structure: understand each side's real concern, find a shared measure, then make the safe path the easy path. For example: "Developers wanted daily releases; operations remembered a bad outage. I suggested we agree an error budget, add automated tests and a canary step to the pipeline, and make rollback one command. Releases went from fortnightly to several a week, and incidents didn't go up."

Avoid taking a side or blaming either team; DevOps exists to remove exactly this conflict.

Give a concrete routine, not "I read blogs". For example: "I follow the release notes for the tools I use, such as Kubernetes and Terraform, and I try new things in a small home lab: [a cheap cloud account or local cluster]. Recently I learned [tool] by [what you built with it]. I also read incident write-ups that companies publish, because they show how real systems fail."

Then show judgement: you don't chase every new tool, you learn the fundamentals (Linux, networking, how pipelines and containers work) that make any new tool quick to pick up. Mention a certification only if you're actually preparing for it.