CI/CD and Azure DevOps Questions
"Walk me through your deployment process." In an Azure DevOps shop this question is close to mandatory, and it's a gift: it's the one scenario you can fully prepare. The interviewer wants to hear a pipeline story with safety rails — not tool trivia, but evidence you've shipped without breaking things and know what to do when you do.
Branching and PR gates
Describe a simple, defensible model: short-lived feature branches off main, merged by
pull request — and name your gates. A strong list: build + unit tests must pass, at
least one reviewer approval, work-item linkage (public-sector shops love traceability), and
a branch policy that blocks direct pushes to main. If asked GitFlow vs trunk-based, don't
be dogmatic: "long-lived release branches make sense when releases need formal sign-off;
otherwise short-lived branches and frequent merges keep integration pain small." Knowing
why a heavier process exists in government (audit, change control) scores points.
YAML pipelines, environments, approvals
Speak the Azure DevOps vocabulary concretely: a YAML pipeline in the repo (versioned, reviewed like code), a build stage producing an artifact once, then deploy stages that promote the same artifact through dev → test → prod. Key terms to use naturally: environments with approval checks (a human must approve the prod stage), variable groups/Key Vault for secrets (never in the YAML), and service connections for Azure auth. One sentence on deployment style earns extra credit: "we deploy to a staging slot and swap, so cutover is near-instant and swap-back is our rollback."
Databases and rollback — the hard part
This is where interviewers probe, because app rollback is easy and DB rollback isn't. The safe pattern to describe: migrations run as a pipeline step before the app deploys, and schema changes are backward-compatible by default — add the new column, deploy code that writes both, backfill, then remove the old column in a later release (expand/contract). That way the previous app version still works against the new schema, and rolling back means redeploying the old artifact — no frantic down-migration at 2 AM. Say explicitly: "destructive changes get their own release, after the code that depended on the old shape is gone."
Have one true rollback story ready: what broke, how you detected it, how long restore took, and what gate you added afterward. A candidate with a scar and a lesson beats a candidate with a perfect record every time.
Red flags
- "We copy the files to the server" with no pipeline, or describing manual prod edits.
- Secrets in YAML or config files in the repo.
- No answer for "how do you roll back a migration?" — or worse, "we restore the backup" as the only plan.
- Never having watched a deployment land — you push and hope.
Practice prompts
- "Your prod deployment succeeded but the app won't start. Walk me through the next ten minutes."
- "How would you add a required column to a table with 50 million rows, with zero downtime?"
- Sketch (out loud) the stages, triggers, and approvals of the pipeline you'd build for a brand-new MVC app.