DevOps Engineer interview questions and answers

For a Node.js API at a fintech startup, a push to a feature branch triggered GitHub Actions to install dependencies, run linting and unit tests, and run a dependency vulnerability scan. On merge to main, it built a Docker image tagged with the commit SHA, scanned the image, and pushed it to Amazon ECR. Then it deployed to a staging namespace in our EKS cluster using Helm, ran smoke and API tests, and waited for a manual approval. Production deployment used the same image and Helm chart with production values, a rolling update and readiness probes. If health checks failed, Helm rolled back to the previous release automatically.

An image is a read-only template made of layers, built from a Dockerfile, that contains the application and its dependencies. A container is a running instance of an image with its own writable layer, process space and network. Many containers can run from one image. To keep images small, I use multi-stage builds, so compilers and build tools stay in the build stage and only the final artefact is copied into a slim runtime image such as an alpine, slim or distroless base. I add a .dockerignore file, combine related RUN steps, clean package caches in the same layer, and order instructions so dependency layers are cached between builds.

CrashLoopBackOff means the container starts and exits repeatedly. I run kubectl describe pod to check events, the last state, the exit code and the reason. Exit code 137 with OOMKilled means the memory limit is too low or there is a leak. Then kubectl logs with the previous flag to see the output from the crashed container, since the current one may have no logs yet. Common causes I check are a missing environment variable, ConfigMap or Secret, a wrong command or entrypoint, the app failing to reach its database, and a liveness probe that kills the container before it finishes starting. If needed, I run the image locally or with a debug container.

A rolling deployment replaces instances gradually, a few at a time. It is the Kubernetes default and needs no extra capacity, but old and new versions run together and rollback is another rollout. Blue-green runs a full new environment alongside the old one, then switches traffic at the load balancer. Rollback is instant, but it doubles capacity during the release, and database changes must work for both versions. Canary sends a small share of traffic, say five percent, to the new version, watches error rates and latency, then increases gradually. I use rolling for routine services, blue-green for critical systems needing instant rollback, and canary for high-traffic user-facing changes.

Terraform state is a file that maps resources in my code to real resources in the cloud, with their IDs and attributes. Terraform uses it to work out what to create, change or destroy. In a team it must be stored remotely, for example in an S3 bucket with versioning and encryption, or in Terraform Cloud, never in Git, because it can contain secrets like database passwords. Locking prevents two people or pipelines from running apply at the same time and corrupting the state. With S3 this has commonly been done with a DynamoDB table. I also split state by environment and component, so one mistake cannot affect everything.

Secrets never go into Git, Docker images or pipeline logs. I store them in a secrets manager such as AWS Secrets Manager, HashiCorp Vault or Azure Key Vault, with access controlled by IAM roles per service and environment. In Kubernetes I use the External Secrets Operator to sync them into Kubernetes Secrets, with encryption at rest enabled for etcd. Pipelines use short-lived credentials, for example OIDC federation from GitHub Actions to AWS instead of long-lived access keys. I enable rotation for database passwords, and I run secret scanning on repositories to catch anything committed by mistake. If a secret leaks, I rotate it first and investigate afterwards.

I run df -h to see which filesystem is full, and df -i to check whether inodes are exhausted rather than space. Then du -sh on the top-level directories, drilling down with sort to find what is large. Common culprits are application or system logs in /var/log, old Docker images and volumes, and core dumps. If df shows full but du does not add up, a process may be holding a deleted file open, which I find with lsof and the deleted filter, then restart that process. To fix it, I clear or compress safe files, then set up logrotate and monitoring alerts at around 80 percent, so it does not happen again.

I start with the four golden signals for the service: latency, traffic, errors and saturation. Then I define service level objectives with the product team, for example 99.9 percent of checkout requests succeeding and 95 percent completing under 500 milliseconds over 30 days. Alerts that page someone are based on how fast we are burning the error budget, not on raw CPU, because high CPU with happy users is not an emergency. Infrastructure metrics and logs go to dashboards for investigation. I review every page after on-call weeks: alerts that were not actionable get tuned or removed. Each alert has a runbook link explaining what to check first.

Merge combines two branches by creating a merge commit, keeping the full history as it happened. Rebase replays my branch’s commits on top of another branch, giving a straight, cleaner history, but it rewrites commit hashes. So I never rebase a branch that others are already working on. I use rebase to update my own feature branch before opening a pull request, and merge or squash merge into main. For most teams I prefer trunk-based development: short-lived feature branches, small pull requests, required checks and reviews, and feature flags for unfinished work. Long-lived branches like in GitFlow tend to cause painful merges and slower releases.

The Horizontal Pod Autoscaler periodically compares a metric, usually average CPU or memory utilisation as a percentage of the pods’ resource requests, against a target, and adjusts the number of replicas within a minimum and maximum. It can also use custom metrics, such as queue length or requests per second. Common reasons it fails: metrics-server is not installed, pods have no CPU requests set so utilisation cannot be calculated, the maximum replicas is already reached, or new pods stay Pending because there is no node capacity. For the last case, a cluster autoscaler or Karpenter adds nodes. I also tune scale-down stabilisation so traffic spikes do not cause flapping.

I would use a VPC across at least two, preferably three, availability zones, with public subnets for the load balancer and private subnets for the application and database. An Application Load Balancer sends traffic to containers on ECS or EKS, or to an EC2 Auto Scaling group, spread across zones with health checks. The database would be RDS with Multi-AZ for automatic failover, automated backups and point-in-time recovery, plus read replicas if reads are heavy. Static files go to S3 behind CloudFront. Sessions live in ElastiCache or a database, not on instances. I would agree recovery time and recovery point objectives, and test restores and failover regularly.

One night our payments API started returning errors for about a third of requests. I acknowledged the page, opened an incident channel and posted updates every fifteen minutes for support. Dashboards showed errors only from pods on two new nodes. Those nodes had come up with a wrong security group from a recent Terraform change, so they could not reach the database. I cordoned and drained them, which restored service within about twenty-five minutes, then fixed the Terraform module. In the blameless review we added a pipeline check for security group changes and a synthetic database connectivity test on new nodes before they accept traffic.

Early in my role, I ran terraform apply against what I thought was the staging workspace and deleted a production queue that matched a renamed resource. A background job started failing. I told my lead immediately, recreated the queue from code within about fifteen minutes, and replayed the failed jobs from logs. Nothing was lost for customers. Then I fixed the process, not just my habits: we moved applies into the pipeline only, added a plan review step showing any destroy actions in red, and enabled deletion protection on stateful resources. I also wrote a short guide for new engineers on how workspaces were set up.

Our developers were deploying by SSHing into servers and running scripts, and they resisted a move to containers and pipelines because it seemed like extra work. I picked one team with frequent deployment problems, worked with them for two weeks and built a pipeline template that deployed their service with one merge. Their deploy time dropped from about forty minutes to under ten, and they stopped needing server access. They presented it at our engineering meeting. Then I turned the setup into a reusable template with documentation, and held office hours twice a week. Within a few months most services had moved.

Our monthly AWS bill had grown steadily and nobody owned it. I enabled cost allocation tags, then built a simple breakdown by team and service. Three things stood out: development environments running all night and at weekends, oversized RDS instances, and old EBS snapshots. I scheduled non-production clusters to scale down outside working hours, right-sized databases based on two weeks of metrics, set a snapshot retention policy, and moved steady workloads to Savings Plans. The bill dropped by roughly a third over two months, with no incidents. We also added a monthly cost review so each team saw its own spend.

In my internship, our team needed to deploy a small Python service on Kubernetes, and I had only used Docker. I gave myself a week. I installed kind on my laptop, followed the official tutorials for deployments, services and ConfigMaps, and then wrote manifests for our actual service rather than a sample app. I kept notes of every error and how I fixed it, such as image pull errors from a private registry. By the end of the week the service ran on our test cluster, and my notes became the team’s getting-started guide. My lead then asked me to convert the manifests into a Helm chart.

In my first DevOps role, I supported four product teams, and requests came through chat at all hours: new environments, permission changes, pipeline failures. I was switching tasks constantly and missing my own deadlines. I proposed a simple system to my lead: all requests through a ticket form, with production issues marked urgent and handled immediately, and everything else reviewed twice a day. I also wrote short self-service guides for the five most common requests, like rerunning a failed pipeline. Request volume dropped noticeably, teams knew when to expect a response, and I finished our planned monitoring work on time.

I am comfortable with it. I have been on a one-week-in-four rotation for the last two years. I take it seriously: laptop and charger with me, reachable within the agreed response time, and no long travel during my week. I would like to understand how often I would be on call, how pages typically come in each week, whether there is a secondary on-call, and how on-call time is compensated or given back as time off. I also care about improving the rotation itself, for example by fixing noisy alerts, because a calmer on-call week means better decisions when a real incident happens.

I read your engineering blog about moving from virtual machines to Kubernetes and building an internal developer platform so product teams can deploy without filing tickets. That is the work I enjoy most. In my current role I built pipeline templates and Terraform modules that teams use themselves, and I want to do that at a larger scale with more services. I also noticed you run a blameless postmortem culture and publish learnings internally, which matches how I like to work. And your stack of AWS, EKS, Terraform and GitHub Actions overlaps closely with mine, so I could contribute quickly.

My current CTC is ₹14 lakh with four years in DevOps, mostly on AWS and Kubernetes, including on-call for production systems. This role adds ownership of the Kubernetes platform and the observability stack, so I am looking for ₹18 to 19 lakh fixed, plus the on-call allowance. I am open to discussing the structure. My notice period is 60 days. I have already documented most of my current work, so I could ask for a shorter period if needed, but I would want to finish handing over the on-call runbooks properly before leaving.