Microsoft CI/CD, Release Engineering & GitOps interview questions

The fetch and pull half is a warm-up. The rebase half is where candidates either show they understand that rebasing rewrites commits or reveal that they have only ever followed instructions.

Most candidates narrate the YAML. The scoring starts underneath: who schedules what, where artifacts live between jobs, and why disposable runners rewrite how you think about caching and trust.

Deployment and release are two decisions, not one. The flag patterns that buy you instant reversibility, and the retirement discipline most teams skip.

Quarantine is a holding cell with an expiry date, not a landfill. Per-test flake rates, entry evidence, an enforced expiry review, and the cap that turns fixing into priority.

Green PRs can still break main because they were validated against a stale tip. Merge queues revalidate the exact combination that lands, trading latency for certainty.

Reciting metric names scores low. Naming the definition decisions that corrupt each one, and the gaming that starts when targets appear, scores high.

Build graphs identify affected targets only when their dependencies are complete. The ladder from build-everything to content-addressed caching, hermeticity audits, and where undeclared inputs rot correctness.

One cadence for every team is the naive answer. Cadence follows constraints: store review for mobile, compatibility windows for APIs, contracts and embedded realities for trains.

The code did not change, the data did. That inverts what triggers the pipeline, what the tests assert, and what a rollback means.

A token naming the right repository does not prove that the approved deployment workflow ran. Bind the caller, deployment context and called workflow into the cloud trust contract.

The interviewer does not want the three definitions. They want a decision, the number that justifies it, and what you do when the canary looks fine for nine minutes and then does not.

A question about developer experience as much as engineering. Measure before optimising, and notice that the trust problem and the duration problem may have different causes.

The deployment question that has a real answer and a real trap. Code and schema deploy at different speeds, and any step where they must change together is the step that causes the outage.

A question where both answers are defensible and the reasoning is the entire score. The operational consequences are concrete: what happens when a shared library needs a security patch.

Testing is a pipeline design problem in this role, not a QA one. The constraint is the question: you cannot run everything on every commit, so what you choose to defer is the answer.

The security argument for GitOps is more specific than 'Git is the source of truth'. Pull deployment can remove cluster credentials from CI, and that single fact is most of the case.