DevOps Interview Questions and Answers

It removes the wall between the people who write software and the people who run it. Before DevOps those two groups had opposing incentives — developers were paid to ship change, operations to prevent it — so work piled up at the handover. DevOps makes one team own the whole path from commit to production, which is why speed and stability stop being a trade-off.

What the interviewer is checking: whether you see DevOps as a way of organising work, or as a job title with a CI server attached.

⚠Common trap: answering "it's CI/CD and automation". That's the output, not the problem being solved.

DevOps is the philosophy — shared ownership between building and running. SRE is one concrete implementation of it, with reliability expressed as measurable SLOs and error budgets. Platform engineering is the newest layer: instead of embedding an ops person in every team, you build an internal platform that product teams use themselves without filing tickets.

What the interviewer is checking: whether you can place the three on a spectrum rather than treating them as competing buzzwords.

⚠Common trap: saying they're the same thing with different names, or that platform engineering "replaced" DevOps.

Continuous integration is developers merging to a shared mainline many times a day, with every merge verified by an automated build and tests. Continuous delivery extends that so every green build is genuinely releasable and reaching production is a business decision, not an engineering project. Continuous deployment removes even that button — every change that passes the pipeline goes to production automatically.

What the interviewer is checking: precision. These three are constantly used interchangeably and getting them right is a cheap credibility signal.

⚠Common trap: saying "CD means continuous deployment" and never distinguishing the two.

I default to trunk-based: short-lived branches merged to main within a day, which keeps integration pain small and is what the delivery research correlates with high performance. GitFlow earns its complexity when you genuinely support multiple released versions in parallel — shipped desktop software, firmware, an on-premise product with long-lived release branches. For a web service deployed continuously, GitFlow mostly adds merge overhead.

What the interviewer is checking: whether you can defend a default and still name where it doesn't apply.

⚠Common trap: "GitFlow is outdated" with no acknowledgement of the versioned-product case.

Flaky tests are worse than no tests, because they teach the team to ignore red. I'd quarantine them out of the blocking suite immediately so the pipeline regains trust, then treat each one as a real bug with an owner and a deadline — most are timing assumptions, shared state between tests, or a genuine race in the code. What I won't do is add a blanket retry, which hides the failure and keeps the bug.

What the interviewer is checking: whether you protect the signal or just make the red go away.

⚠Common trap: "we retry them three times" offered as the whole answer.

Rolling is the sensible default: replace instances gradually, no extra capacity, but both versions serve traffic during the rollout so they must be compatible. Blue-green gives you an instant cutover and an instant rollback at the cost of running two full environments — worth it when downtime is expensive and the change is risky. Canary is what you pick when you want production evidence before committing: a small share of real traffic, watched, then widened.

What the interviewer is checking: whether you can match a strategy to a constraint rather than name three of them.

⚠Common trap: defining all three correctly but never saying when you'd actually choose one.

You split a breaking change into three deployments. Expand: add the new column or table while the old one still exists, and have the application write to both. Migrate: backfill existing rows and switch reads to the new shape. Contract: once nothing reads the old column, drop it. At every step the previous application version still works, so you can roll back at any point without touching data.

What the interviewer is checking: whether you can name a concrete technique, not just say "backward compatible".

⚠Common trap: describing two steps and skipping the dual-write window, which is where the safety comes from.

Because infrastructure becomes reviewable, reproducible and auditable — the same properties we already demand of application code. Without it you get servers nobody can rebuild, changes with no history of who did what and why, and environments that differ in ways nobody can enumerate. The moment you need to recreate production in another region, hand-built infrastructure turns into an archaeology project.

What the interviewer is checking: whether you can justify the practice to someone who thinks clicking in a console is faster.

⚠Common trap: answering "automation" alone — a shell script is automation too, without the review or history.

Secrets live in a dedicated store, never in the repository and never in the image, and applications get them at runtime through an identity the platform proves — a workload identity or a mounted short-lived token rather than a static key in an environment variable. Each environment has its own separate values, rotation is automated, and access is audited. If a secret ever touched a Git history, I treat it as compromised and rotate it.

What the interviewer is checking: whether you know the identity problem underneath — a secret to fetch secrets is still a secret.

⚠Common trap: "we put them in environment variables" without saying how they get there.

An SLI is the measurement — the actual number, like the fraction of requests served under 300 milliseconds. An SLO is the target you set for that indicator internally, say 99.9 percent over 30 days. An SLA is the contract with a customer, with financial consequences when you miss it. The important relationship is that your SLO should be stricter than your SLA, so you find out you're in trouble before the customer does.

What the interviewer is checking: whether you get the ordering right. These three are the most commonly muddled terms in the field.

⚠Common trap: defining SLA as "uptime target" and never mentioning the contractual consequence.

Someone takes the incident commander role immediately and does not debug — they coordinate, decide and keep the timeline. Underneath that: an operations lead doing the hands-on investigation, and a communications lead handling stakeholders so the responders aren't answering questions. First priority is mitigation, not root cause: restore service by rolling back or failing over, then diagnose afterwards with the pressure off.

What the interviewer is checking: whether you know incident response is a coordination problem before it's a technical one.

⚠Common trap: describing only the debugging and never naming who is in charge.

The assumption that everyone acted reasonably given what they knew at the time, so the question is never who made the mistake but what made the mistake easy to make and hard to catch. In practice that means writing about systems and conditions rather than people, and treating a human error as a signal about a missing guardrail. The test is whether the person closest to the outage would happily write it up themselves.

What the interviewer is checking: whether you understand the goal is candour — people hide information in blaming cultures, and hidden information causes the next outage.

⚠Common trap: "we just don't name anyone" — anonymising a blaming document doesn't change the culture.

I'd start with a modular monolith almost every time: one deployment, one database, no network between your own functions, and you learn the real domain boundaries by building it. Microservices earn their cost when you need independent deployment and scaling per component, or when several teams keep blocking each other in one codebase. What you're buying is team autonomy, and what you're paying is distributed-systems complexity.

What the interviewer is checking: whether you evaluate architecture by cost rather than by fashion.

⚠Common trap: "microservices scale better" as if that were free and unconditional.

Vertical is a bigger machine — simple, no code changes, but there's a ceiling and usually a restart to get there. Horizontal is more machines, which gives you effectively unbounded headroom and redundancy, but only works if the workload is stateless or the state is shared. In practice I scale databases vertically until it hurts because sharding is expensive, and application tiers horizontally because they're designed for it.

What the interviewer is checking: whether you notice that horizontal scaling also buys availability, not just capacity.

⚠Common trap: "horizontal is always better" without the statelessness precondition.

Platform engineering builds an internal product — a paved road of tooling, templates and self-service infrastructure — that product teams consume without filing tickets. The difference from classic DevOps is who does the work: DevOps says every team owns its own delivery, which doesn't scale past a certain size because each team rebuilds the same pipeline. Platform engineering makes that capability a product with users and a roadmap.

What the interviewer is checking: whether you can articulate why this role appeared, not just that it exists.

⚠Common trap: "it's DevOps with a new name" — that misses self-service and the product framing entirely.

A golden path is the supported, opinionated way to do a common task — create a service, deploy it, rotate a secret — with the pipeline, observability and manifests already wired in. It gets used when it's genuinely faster than doing it yourself, when it's maintained so it doesn't rot, and when it stays opinionated rather than becoming a configuration menu. The moment it lags behind what teams need, they route around it.

What the interviewer is checking: whether you understand adoption is earned. Golden paths fail socially far more often than technically.

⚠Common trap: describing the template and never addressing why anyone would choose it.

An SBOM is the ingredient list — every component and version inside an artifact, so when a vulnerability lands you can answer "are we affected?" in minutes instead of weeks. SLSA is about provenance: it attests how the artifact was built, by which pipeline, from which source commit. They're complementary — the SBOM tells you what's inside, SLSA tells you the box came from the factory you think it did.

What the interviewer is checking: whether you can separate the two, since they're routinely conflated.

⚠Common trap: describing an SBOM as a security scan. It's an inventory — scanning is what you do with it.

By treating AI as an amplifier of whatever your delivery system already is. If review, testing and rollback are strong, more code moving through them is a win; if they're weak, you're now generating defects faster than you can catch them. So the answer isn't to slow down AI use — it's to make sure the change failure rate and recovery time are watched as closely as throughput, and to invest in the checks before you scale up generation.

What the interviewer is checking: whether you can discuss AI with evidence rather than enthusiasm or dismissal.

⚠Common trap: an unqualified "AI makes teams faster" — the same research found what it costs.

Start with the breakdown by service and by tag to see whether it's one thing or everything, then line that up against the change timeline — deployments, autoscaling events, traffic. Most jumps are one of a few shapes: a scaling policy that stopped scaling down, data egress from a new integration, forgotten non-production environments, or logging volume from a change in verbosity. Then set an anomaly alert so the next one doesn't wait for an invoice.

What the interviewer is checking: whether you'd debug cost the way you debug an incident.

⚠Common trap: jumping to "buy reserved instances" before knowing what grew.