DevOps interview questions: what happens after you press deploy

Most interview topics let you be right in the abstract. DevOps mostly doesn't, because every answer has a production system behind it, and production is where a plausible answer and a working one come apart. Interviewers know this, so the questions are built around failure. The pipeline you describe is fine. What they want to know is what it does on the day it's wrong, and how you'd find out.

The questions below come up again and again in senior screens, and they share one spine: for any mechanism you name, what does it depend on, and what happens when that dependency isn't there? If you'd rather work through the topic than read about it, the DevOps track covers the same ground one idea at a time.

Question 1: the deploy doubled the error rate. Roll it back.

This is the question that sorts candidates fastest, because the obvious answer is correct about half of the system and says nothing about the other half.

The pattern that makes rollback safe has a name, expand and contract, and it's worth being able to sketch. You never change a schema in the same release that depends on the change. You widen it first, move the code across in steps, and narrow it only once nothing deployed still reads the old shape.

-- Release 1 (expand): add the new column. Old code ignores it.
ALTER TABLE users ADD COLUMN display_name text;

-- Release 2: code writes both columns and reads the new one.
-- Backfill in batches, never in one giant transaction.
UPDATE users SET display_name = full_name
WHERE display_name IS NULL AND id BETWEEN 1 AND 10000;

-- Release 3: code stops touching full_name entirely.

-- Release 4 (contract): drop it, once nothing deployed reads it.
ALTER TABLE users DROP COLUMN full_name;

Say the cost out loud, because the interviewer is waiting to see if you know it. Four releases for a rename is slow, and for a table nobody else touches it can be overkill. The point is knowing which changes need it: anything that removes or renames something the running code reads. Adding a nullable column never does. The migration side of this goes deeper in the database round, and it's a common place for a DevOps interview to wander into.

Question 2: what does your health check actually check?

Health checks look like monitoring, so candidates treat them as a nice-to-have. They aren't. The load balancer or the orchestrator reads the check before it decides whether to send you traffic, which makes it an availability dependency. If the check is wrong, the app can be perfectly healthy and the site still goes down.

That last detail is worth having in your pocket as a general rule rather than a war story. Anything that can gate traffic has to be exercised in the environment it will run in. A green test suite checks your application. It says nothing about the container, the port the platform injects, or the probe config, and those are exactly the things that take a site down while every dashboard in CI stays green.

Question 3: blue-green or canary?

Everyone can define these. The senior answer is about what each one needs before it's worth anything.

Feature flags come up around here too, and it's worth being precise about what they buy. A deploy puts code on servers. A flag decides who runs it. Separating the two means turning a feature off doesn't need a release, and that's usually the fastest rollback you have. The cost is that every flag is a branch nobody tests in both directions for long, so a senior answer mentions cleaning them up.

Question 4: what would you page someone for?

The question is about alerting, and the interviewer is listening for whether you've ever been woken up by a bad alert.

• Page on symptoms, not causes. Users feel errors and slowness. They don't feel 90% CPU. A box running hot while every request succeeds is a ticket for the morning, not a phone call at 3am.
• Every page needs an action. If the right response to an alert is to look at it and go back to sleep, it isn't an alert, it's noise, and noise trains people to ignore the next page, including the real one.
• Alert on a ratio over a window. Five failed requests means nothing without knowing whether that was five out of ten or five out of a million, and a single bad minute usually isn't worth waking anyone.
• Mind your cardinality. Putting a user id or a full URL on a metric label creates a new time series per value, and the monitoring bill or the metrics store is what finds out first.

Frameworks help here if you use them to reason rather than to recite. RED (rate, errors, duration) fits request-driven services. USE (utilisation, saturation, errors) fits resources like disks and queues. Naming one is fine. Showing which signal from it you'd actually page on, for the service they described, is what earns the point.

Question 5: tell me about an incident

This one sounds behavioural, and it's graded on engineering. The interviewer wants to hear the order you did things in, because the order is where most incidents go wrong.

Notice the senior answer is shorter on the technical fix and longer on detection and process. That's deliberate, and it's the same move covered in how to talk about trade-offs: the interviewer can guess how you fixed a slow query. They can't guess how you run an incident unless you tell them.

Question 6: someone fixed it by hand in the console

Infrastructure as code gets asked about in terms of tools, and answered better in terms of what it guarantees. It guarantees nothing if people change things by hand.

Say what you'd actually do. A manual fix during an incident is often the right call, and nobody wants a lecture about process while the site is down. The failure is leaving it there. Now the code describes a system that doesn't exist, and the next apply either quietly reverts the fix or fails in a way nobody understands. So the rule is that a console change during an incident becomes a pull request the same day, and ideally the production console is read-only the rest of the time. Drift detection on a schedule catches whatever slips through. Mentioning that your tool keeps state, and that the state file itself needs locking and backing up, is a detail that tells the interviewer you've run it on a team.