Microsoft CI/CD, Release Engineering & GitOps interview questions

Four nested things and one rule that explains most confusion: jobs run on different machines and share nothing unless you make them. Everything about artifacts and caching follows from that.

Stages, jobs, steps, and a pool that supplies the machine. The piece that decides most real designs is the agent pool, because Microsoft-hosted agents cannot reach a private network and most enterprise deployments need to.

Git merges by comparing both branches against their common ancestor. A conflict means both sides changed the same region, and the resolution nobody checks is the one that compiles and is semantically wrong.

Follow commit identities through a rebase, recover a collaborator’s work with an explicit boundary, and explain the limits of force-with-lease and revert.

Follow scheduling eligibility, job isolation and artifact transfer, then diagnose a queued job whose available runners cannot satisfy its requirements.

Deployment and release are two decisions, not one. Choose stable cohorts, test failure defaults and propagation, and retire temporary flags without breaking older application versions.

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 extra validation work for coverage of combined changes.

Define the five delivery measures from explicit events, distinguish failure from rework, and expose uncertain attribution and small samples.

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.

Compare proxy, hosted and group repositories. Trace a tested artifact into production, and understand when a cache can keep builds running during an upstream outage.

The opener in most DevOps interviews, and the one most people answer as a list of nouns. What earns the follow-up is saying what each stage is allowed to fail for and how long it takes.

Pipeline as code moved the build definition into the repository, where it is reviewed and versioned with the thing it builds. Declarative is the default answer, and knowing when scripted still earns its place is the follow-up.

Jenkins is mostly plugins, they have a dependency graph nobody drew, and the controller is a single point of failure for every team. The answer is a rehearsal against a copy of production, not a maintenance window and hope.

Compare rollout capacity, traffic exposure and state compatibility, then work through a payments canary with too little evidence to promote.

Calculate the pipeline critical path, separate runner queues from execution, and improve feedback time without hiding flaky or skipped checks.