Designing and Implementing Microsoft DevOps Solutions (AZ-400) — Practice Questions and Mock Exam

Azure Pipelines deployment jobs support three strategies: runOnce, rolling, and canary. runOnce executes each lifecycle hook (preDeploy, deploy, routeTraffic, postRouteTraffic) exactly once. rolling replaces application instances on a fixed set of VMs in batches controlled by maxParallel and is currently supported only for VM resources. canary is the advanced strategy for incremental exposure: it runs preDeploy once, then iterates deploy, routeTraffic, and postRouteTraffic for each increment (for example 10%, then 20%), monitoring health in postRouteTraffic before promoting to 100%. The strategy.increment variable is available during those iterating hooks. Note blueGreen is not a built-in deployment-job strategy keyword. Exam tip: phased percentage rollout with health checks between increments equals canary; VM batch replacement equals rolling; single execution equals runOnce.

A linear commit history on the main branch means no merge commits — each commit follows sequentially. The squash merge policy in Azure Repos achieves this by combining all commits from a pull request into a single commit on the target branch. When enabled as a branch policy on the main branch, all PRs must use squash merge, ensuring the main branch never contains merge commits or branching history. This creates a clean, linear history that is easy to read and bisect. Rebase merge also creates a linear history by replaying commits instead of creating merge commits. Basic merge creates merge commits and does not maintain linearity. Fast-forward merge maintains linearity but only works when the branch is directly ahead. Exam tip: Squash merge = single commit per PR (linear history); rebase = replay commits (linear); basic merge = merge commit (non-linear).