DevOps Engineer Interview Questions and Answers

I would make the pipeline stages explicit: build a versioned artifact, run unit and integration tests against a disposable database, then deploy. The important part is the database. I do not run migrations inside the same step as the code deploy, because the two have different rollback properties. I run backward-compatible migrations first as a separate stage, then deploy code that tolerates both old and new schema, then clean up later. That lets me roll back the application without rolling back data. Each deploy is atomic and the previous artifact stays ready, so rollback is a redeploy rather than a rebuild. After deploy I run a smoke test and watch error rate and latency for a few minutes, with automatic rollback if the canary degrades past a threshold.

I start from what a user would notice: can they load the page, is it fast, and does the action succeed. That maps to the four golden signals of latency, traffic, errors and saturation. I instrument those at the service boundary, then add resource and dependency metrics for diagnosis. The key decision is what pages a human at three in the morning. I page on symptoms that affect users, expressed as an SLO burn rate, because a single high CPU reading is a cause that may be harmless. Causes go on dashboards and into runbooks, not into pages. I set thresholds from observed data rather than round numbers, and I review every page that needed no action, because an alert nobody acts on trains the team to ignore the pager.

My first instinct is to stop the bleeding, not to fully understand the cause. If a deploy is the suspected trigger, I roll it back or turn off the feature flag, because restoring service buys time to investigate calmly. In parallel I make sure there is one incident commander coordinating and one person communicating status to stakeholders, so we are not all debugging at once. Once users are recovering, I confirm with the same metric that alerted us and keep watching for a recurrence. Only then do I look at the cause using the deploy diff, logs and traces. The postmortem is blameless and focuses on why the system allowed the change to reach production, with action items like a canary gate or a missing test. I also make sure the rollback we just used gets documented so the next person does not improvise.

The baseline is that no secret lives in a git repository, a container image or a CI variable that everyone can read. I put secrets in a managed store such as Vault or the cloud provider's secret manager, and applications read them at startup through an identity rather than a shared password. Where the platform supports it I use short-lived credentials, such as workload identity or instance roles, so there is nothing long-lived to steal. Each service gets only the secrets it needs, scoped by policy, because one compromised service should not expose the whole environment. I make rotation routine and automated for credentials that support it, and I test that revocation actually takes effect. Finally I audit access logs and alert on unexpected reads, since detection matters as much as prevention.

I start from the workload. A long-running service with steady traffic and predictable resource needs is usually a container on an orchestrator, because it gives portability and fine-grained scaling. A legacy application that expects a full operating system, or one with strict kernel or licensing requirements, is often better on a virtual machine. A short, bursty, event-driven task with low average utilization fits serverless well, because I pay per invocation and someone else manages the fleet. The trade-offs I watch are cold starts on latency-sensitive paths, the real operational burden of running an orchestrator well, and the cost curve at high steady volume, where serverless can become expensive. I choose with the team's expertise in mind and revisit when the workload changes.

For infrastructure as code, the plan output is the review artifact. I read the plan carefully and look specifically for anything marked for destruction or replacement, because a resource replacement can mean downtime even when nothing looks wrong. I stage the change in a non-production workspace that mirrors production, apply it there, and verify. In production I limit blast radius by splitting changes into small applies and keeping state isolated per environment, so a mistake cannot touch everything at once. I apply during a period when the team is available, with a rollback plan that is either a revert of the code or a targeted manual fix. After applying I verify with health checks and metrics, and I record what changed and why. The one rule I never break is editing production by hand and leaving the code behind.

I pick a scaling metric that actually tracks load, usually requests per second, queue depth or concurrency rather than CPU, because CPU can stay low while requests queue. I set a minimum replica count that can absorb a normal spike without waiting for new instances, since scaling up always takes time. I add stabilization windows so the system does not flap between sizes, scaling up quickly and down slowly. For services with a warmup cost, such as a JVM or a large model, I keep a buffer of warm capacity and use a readiness gate so traffic does not reach an instance that is not ready. I validate the whole configuration with a load test that ramps beyond expected peak, watching scale events and latency. The goal is to be boring during a spike, not clever.

First I get visibility, because you cannot optimize what you cannot attribute. I tag resources by service and team and build a cost dashboard so each team sees its own spend. Then I hunt for waste that is safe to remove: idle development environments, oversized instances, orphaned volumes and snapshots, and workloads that could share capacity. Next I look at the predictable baseline and cover it with committed-use discounts or savings plans, careful not to over-commit beyond what we are confident we will use. Throughout this I keep reliability explicit: if a change would reduce redundancy below what the service needs, it is not a saving but a risk transfer. I measure the result per service and recheck after every architectural change, because the cheapest configuration shifts as the workload evolves.

I would not announce that everything becomes code tomorrow, because a big-bang conversion of a live system is a reliable way to cause an outage. I begin by importing the existing resources of one low-risk service into Terraform so the state matches reality, then make a trivial change through code to prove the loop works. I build the pipeline that plans on pull request and applies on merge with approval, so review happens before production. Once that service is stable I use it as the template and migrate the next one, prioritizing environments that change most often because they benefit soonest. I pair with the engineers who know each service, because they catch details the import misses. The measure of success is that nobody edits by hand anymore, not that a migration was announced.

Use the metrics the team already tracks, such as SLO attainment, MTTR, deploy frequency or change failure rate, and give a real before and after.

State what was manual, what replaced it and the time or error rate that changed, since intent alone does not distinguish you from other candidates.

Mention secrets management, least-privilege roles and audit logging, because platform teams increasingly own the security posture of the environment.