DevOps Engineer Interview Questions

I start by understanding what the team needs to ship safely and quickly, not by picking tools first. I map out the stages the code needs to pass through: build, test, security scan, package, deploy to staging, and promote to production. I automate each stage and define clear promotion criteria so nothing moves forward without meeting quality gates. For a typical project I would use something like GitHub Actions or GitLab CI for the pipeline itself, with containerised builds to keep environments consistent. I include automated unit and integration tests early in the pipeline so failures surface fast and cheaply. I also build in security scanning at the image and dependency level rather than treating it as a post-deployment concern. The goal is to make every commit to the main branch deployable. I treat the pipeline as code and version it alongside the application.

I treat infrastructure as code as a first principle, not an optimisation. If infrastructure is not in version control, it cannot be reviewed, tested, or reliably reproduced. My preferred tool for cloud-agnostic infrastructure is Terraform because of its declarative syntax, provider ecosystem, and strong community. For configuration management I use Ansible when I need to manage state on existing machines, and for Kubernetes I use Helm for packaging and ArgoCD for GitOps-style delivery. I organise Terraform into modules by domain, which keeps things composable and reusable across environments. I also enforce a plan before apply workflow in CI so infrastructure changes get reviewed like code changes.

I think about observability in terms of the three pillars: metrics, logs, and traces. Metrics tell you something is wrong, logs tell you what happened, and traces tell you where in a distributed system the problem originated. My standard approach is to instrument applications with structured logging from the start, export metrics to a time-series database like Prometheus, and use distributed tracing with something like OpenTelemetry to understand request flows. I build dashboards that reflect the four golden signals: latency, traffic, errors, and saturation. I also configure alerts on symptoms that matter to users rather than on low-level resource thresholds. The test I use for any alert is: if this fires at 3am, is it worth waking someone up? If not, it should be a warning, not a page.

We had a database connection pool exhaustion that took down our primary service for 35 minutes on a weekday afternoon. I was on call and took incident command. My first step was to declare the incident formally, open a dedicated communication channel, and page the relevant engineers without flooding the channel with noise. I kept the internal and external communications separate and gave our head of engineering a short factual update every 10 minutes. The immediate mitigation was a restart and a connection pool limit increase, which restored service in 12 minutes. The root cause was a recent background job with a missing connection release under an error condition. The process change was adding a connection pool metric to our core dashboard and a circuit breaker test to our pre-production load tests.

When I joined my previous team, production deployments happened once a week on Friday afternoons and required a 30-minute manual runbook. I built a fully automated pipeline with automated smoke tests, blue-green deployment on our Kubernetes cluster, and automatic rollback if smoke tests failed. Within two months we were deploying multiple times a day with no manual steps and a mean time to recover from a bad deploy of under four minutes. Deployment frequency is one of the DORA metrics, and improving it directly correlated with a reduction in change failure rate because smaller, more frequent changes are easier to diagnose and roll back.

When I joined a start-up with no on-call process, I introduced a lightweight on-call rotation and a simple incident response template. I ran a blameless post-mortem after the first significant incident and explicitly recognised the engineer who had surfaced a design flaw honestly. Over the following quarter I ran three internal learning sessions on SRE principles, each under 30 minutes, and published an operational readiness checklist for new services. By the end of the year every team had an on-call rotation, incident response times had improved, and engineers were voluntarily running post-mortems on near-misses. The change was gradual and practical.

I never store secrets in environment variables hardcoded into deployment manifests or source code, and I never commit them to version control. My preferred approach in a Kubernetes environment is to use a secrets management tool like HashiCorp Vault or AWS Secrets Manager, with the application retrieving secrets at runtime via a sidecar or init container. I rotate secrets regularly and automate rotation where the provider supports it. For CI/CD pipelines I use the secrets management built into the platform. I also follow the principle of least privilege for all service accounts: each service should only be able to read the specific secrets it needs.

Container security starts at the image level. I use minimal base images, scan images in CI for known vulnerabilities using a tool like Trivy or Snyk, and enforce a policy that blocks deployment of images above a severity threshold. In Kubernetes I apply network policies to restrict traffic between pods, use RBAC to limit what service accounts can do, and run pods as non-root users with read-only root filesystems where possible. I use admission controllers to enforce policies at the cluster level. For secrets I use a dedicated secrets store rather than Kubernetes Secrets, which are only base64-encoded unless you configure encryption at rest.

I start with visibility: you cannot optimise what you cannot see. I set up cost dashboards that break down spend by team, service, and environment. For right-sizing, I look at actual resource utilisation over a 30-day window before making changes. I use horizontal autoscaling for stateless workloads and reserved or committed use discounts for predictable baseline load. I also schedule non-production environments to shut down outside working hours. For storage I enforce lifecycle policies to move infrequently accessed data to cheaper tiers automatically. Engineers who understand that cloud costs are real make better architectural decisions.