All jobs / DevOps / SRE / cloud
CI/CD interview questions
CI/CD questions a DevOps / SRE / cloud can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A teammate wants to “save CI minutes” by running tests only before release. What do you say?
The strongest answer: Run the fast tests on every push — a broken main is more expensive than the minutes — and keep a longer suite on a schedule or a label
Why it works: Exactly. Fast signal on every change. Long suites are a different knob.
- Fast tests on every push.
- Longer suite on a slower train.
- Do not wait for release day.
- Do not make the gate unbearable.
The Jenkins jobs are configured by clicking through the web UI. What is wrong with that?
The strongest answer: The pipeline is not versioned or reviewed; it belongs in the repo as code — a Jenkinsfile, a GitHub Actions workflow, .gitlab-ci.yml or azure-pipelines.yml — and changes through pull requests like the app
Why it works: Exactly — pipeline as code means the build definition is reproducible, diffable and travels with the branch that needs it.
- The pipeline is code in the repo.
- Jenkinsfile, workflows, .gitlab-ci.yml.
- Change it through pull requests.
- No clicking in production CI.
A deploy goes bad. What is a rollback?
The strongest answer: Put the last known-good artifact back in service — I do not “roll forward” by hot-editing the box unless that is the only path and I say so
Why it works: Exactly. Last good bits, already built. Git on a laptop is not the environment.
- Redeploy the last good artifact.
- Know how to find that artifact.
- Do not pet the box as plan A.
- Say when you must roll forward instead.
Who builds the artifact we put in production?
The strongest answer: CI, from a tagged commit, on a clean runner — not a laptop that “has the right Node version”
Why it works: Exactly. Clean, tagged, repeatable. Laptops are for development.
- CI builds the artifact.
- Tag the commit.
- Clean runner.
- Do not copy a laptop folder into the image.
When is a Friday production deploy a bad idea?
The strongest answer: When we cannot watch it and we have no rollback — the weekday is a risk knob, not a superstition; a quiet, reversible change with people awake can still ship
Why it works: Exactly. Staffing and rollback matter more than the calendar. Skipping checks is the red flag.
- Ask who is awake.
- Ask how we roll back.
- Do not skip checks for the calendar.
- Do not worship Monday either.
What belongs in a CI/CD pipeline before production?
The strongest answer: Build a unique artifact, test it, scan what you reasonably can, and deploy that same artifact — I do not rebuild on the way to prod
Why it works: Exactly. One artifact, promoted. Rebuilds on the path are new unknowns.
- Build once.
- Test that artifact.
- Promote it.
- Do not rebuild for prod.
Staging is good. How do those bits get to production?
The strongest answer: The same image / bundle id is promoted — I do not `docker build` again on the prod runner “to be sure”
Why it works: Exactly. Promote the digest. A second build is a second artifact.
- Promote by digest.
- Config differs; bits do not.
- Do not rebuild for prod.
- Do not trust latest over time.
What is blue/green, in one sentence you would say in a room?
The strongest answer: Two production environments; we switch traffic when the new one is healthy, and we can switch back — it costs two worlds and buys a fast undo
Why it works: Exactly. Two worlds, a switch, an undo. Say the cost too.
- Two prod worlds.
- Switch when healthy.
- Switch back if not.
- Name the double-cost.
What is a canary deploy, as opposed to blue/green?
The strongest answer: A small slice of real traffic on the new bits, watch the SLO, then expand or abort — I do not call a 100% Friday a canary
Why it works: Exactly. Small real traffic, watch, expand. 100% is not a canary.
- Small real traffic.
- Watch the SLO.
- Expand or abort.
- 100% is not a canary.
A bad change is already live. The store / the cluster is slow to revert. What is faster?
The strongest answer: A feature flag or config you can dark without a new artifact — I still keep a real rollback for the cases a flag cannot save
Why it works: Exactly. Flags are a tourniquet. Binaries still matter. TLS-off is not a flag.
- Ship kill-switches.
- Keep a real rollback too.
- Do not flag away security.
- Do not make users the rollback.
The team wants true continuous deploy to production. What do you still insist on?
The strongest answer: An automated gate that matches the risk (tests, a canary, a halt) and an owner who can stop the train — CD is not “no judgement”
Why it works: Exactly. Automate the judgement you already trust. CAB-on-every-commit is the opposite failure.
- Automate the gate.
- Keep a halt.
- Do not CAB every commit.
- Do not drop signing.
Every squad has a unique pipeline. You want a paved road. What do you standardise first?
The strongest answer: The parts that leak or lie: secrets, artifact promotion, and the prod gate — they can keep their test runner if the road is honest
Why it works: Exactly. Standardise the dangerous bits. A vendor rewrite is a year. A merge-bottleneck is a queue.
- Pave secrets and promotion.
- Pave the prod gate.
- Allow local test flavour.
- Do not bottleneck every merge.
The runbook says “rollback.” The schema migrated forward. What do you actually do?
The strongest answer: I say so: the app can roll back only if the schema is compatible, otherwise we roll the app forward or run a written down-migration — I do not pretend a button undoes data
Why it works: Exactly. Expand/contract. A button does not rewind rows. Restoring yesterday is a new incident.
- Name schema compatibility.
- Expand/contract migrations.
- Do not restore-over writes as “rollback.”
- Write the true undo.
Blue/green is easy for stateless pods. What do you say about the database?
The strongest answer: The data plane is shared or carefully expanded — two writers is a different product, and I will not draw two databases and call it blue/green without a story
Why it works: Exactly. Stateless switch ≠ two data worlds. Say the shared-store story.
- Name the data plane.
- Prefer expand/contract on one store.
- Do not dual-write casually.
- Do not failover the DB to match a colour.
A canary looks “fine” on CPU. Users on the canary cannot check out. What was wrong?
The strongest answer: I canaried the wrong SLO — I need checkout errors / latency on the canary slice, not a host pulse
Why it works: Exactly. The canary inherits the product SLO. CPU is a cause graph.
- Slice the user SLO.
- Watch errors and latency there.
- CPU is secondary.
- Real traffic, real path.
Who aborts a canary, and on what?
The strongest answer: A written rule (error rate / SLO burn on the slice) and a human override — I do not leave it to “whoever is scared in Slack”
Why it works: Exactly. A rule, plus a human who can pull the brake. Always-finish is a dice roll.
- Write the abort metric.
- Name the override.
- Do not always-finish.
- Do not abort on vibes only.
Squads go around your CI templates. What is the diagnosis?
The strongest answer: The road is slower or less capable than a side path — I will fix the road or officially bless an escape, I will not punish the squad in Slack
Why it works: Exactly. A platform is a product. Circumvention is a ticket on the road.
- Treat the road as a product.
- Ask why they left.
- Bless or fix.
- Do not punish your way to adoption.
CI is a queue of 90-minute jobs. What do you change at company scale?
The strongest answer: A graph: PR gets fast signal, merge gets more, nightly gets the rest, with caches that do not poison — I do not buy 4× runners as the first move
Why it works: Exactly. Split time by question. Hardware is the second knob. Skipping main is how you go dark.
- Fast on PR.
- More on merge.
- Slow on nightly.
- Honest caches, then hardware.
When is a deploy freeze a grown-up tool, not folklore?
The strongest answer: When a named risk (a peak, a freeze window, a spent budget) has a start, an end, and an emergency path — I do not freeze “because it is December” without a reason
Why it works: Exactly. Bounded, reasoned, with an emergency path. Calendar folklore is how you skip real risk.
- Name the risk.
- Bound the window.
- Keep an emergency path.
- Do not freeze by folklore.
Backend engineers will keep owning their services. What do you still own as platform?
The strongest answer: The road they cannot safely invent: identity, promotion, observe, the prod gate — I do not own their business logic, and I do not disappear
Why it works: Exactly. Pave the dangerous bits. Mini-SRE-everywhere is how you get twelve truths. Owning their code is a queue.
- Own the dangerous road.
- Do not own their domain code.
- Do not vanish.
- Do not make twelve SREs by accident.
When do you say no to continuous deploy for a given path?
The strongest answer: When we cannot observe it, cannot roll it back, or cannot accept the blast (payments, irreversible data) — I say what gate would change my mind
Why it works: Exactly. Observe, undo, blast. A dated no with a path to yes is senior. Always-CD is a slogan.
- No observe → no CD.
- No undo → no CD.
- Huge blast → a slower gate.
- Say what would change your mind.
When is GitOps the production door, and when is it theatre?
The strongest answer: When the cluster only takes what the repo + the pipeline signed, with drift detection — a Git folder we apply by hand on Fridays is theatre
Why it works: Exactly. The door is signature + desired state. A repo souvenir is not GitOps.
- Cluster takes signed desired state.
- Detect drift.
- A repo without a door is theatre.
- Do not skip review and signature.
How do you know the paved road is winning?
The strongest answer: Squads use it without a ticket, shadows shrink, and the prod gate is the same bits CI built — I do not count wiki stars or a framework we announced
Why it works: Exactly. Usage, less shadow, honest promotion. Announcements are not adoption.
- Usage without a ticket.
- Shrinking shadows.
- Same bits to prod.
- Do not count announcements.