Microsoft Azure DevOps Engineer interview questions

YAML pipelines live in the repo, so they are versioned, reviewed in pull requests and reusable through templates. Classic pipelines are UI-based and harder to review. New work should be YAML.

What they are checking: Pipelines as code mindset.

Likely follow-up: How do you share steps between pipelines?

Quality gates: unit tests and code coverage thresholds in CI, security and dependency scans, deploy to test environments first, and environment approvals and checks before production. Use deployment strategies such as canary with automatic rollback on health signals.

What they are checking: Layered gates and safe release strategy.

Likely follow-up: Where would you put manual approvals?

Trunk-based development with short-lived feature branches and pull requests into main, protected by branch policies (review, build validation). Use feature flags to ship incomplete features safely. Long-lived release branches only if you support several versions.

What they are checking: A reasoned recommendation, not a memorised model.

Likely follow-up: What problems does GitFlow cause with continuous delivery?

Link Azure Key Vault to a variable group or use a service connection with workload identity federation, so no secret is stored at all. Mark variables secret, limit who can edit pipelines, and rotate credentials.

What they are checking: No secrets in code, modern federated auth.

Likely follow-up: What is workload identity federation?

Keep Bicep or Terraform in the repo, run validation and a what-if or plan on pull requests so reviewers see the change, then apply after approval. Store Terraform state remotely with locking.

What they are checking: Plan/what-if review before apply.

Likely follow-up: What happens if two pipelines apply Terraform at once?

Differences between environments: agent image and tool versions, missing environment variables or secrets, file path case sensitivity on Linux agents, and network access to package feeds. Run with system.debug to see detailed logs.

What they are checking: Systematic comparison of environments.

Likely follow-up: When would you use a self-hosted agent?

Watch application telemetry in Application Insights (error rate, latency, dependency failures) and business metrics after the deploy, with alerts tied to release annotations. Define success criteria before releasing.

What they are checking: Thinking about outcomes, not just a green pipeline.

Likely follow-up: What are DORA metrics?

A private feed for packages (NuGet, npm, Maven, Python, Universal) so teams share internal libraries and cache public ones through upstream sources, which protects builds if a public registry is down or a package is removed.

What they are checking: Dependency management awareness.

Likely follow-up: How do upstream sources help supply-chain security?

Make the right thing automatic: branch policies that require a passing build and review, coverage checks, and quick feedback. Then talk to the developer to understand why (time pressure, slow tests) and fix the cause, rather than blaming.

What they are checking: Process fixes plus good teamwork.

Likely follow-up: How do you make slow test suites faster?

Use deployment slots: deploy to a staging slot, warm it up and test it, then swap with production. The swap is near-instant and you can swap back to roll back. Slot-specific settings keep connection strings correct.

What they are checking: Practical knowledge of slots and rollback.

Likely follow-up: Which settings should be slot-sticky?