AZ-400 · Domain 3: Design and implement build and release pipelines · 54% of the exam
Task 3.4: Design and implement deployments
Blue-green, canary, ring and progressive exposure, feature flags with App Configuration and A/B tests, ordered dependency deployments, zero-downtime techniques, hotfix paths, and deploying containers, binaries, scripts and databases.
Study it
Deployment strategies: blue-green, canary, rings, feature flags and A/B tests
Try each one before opening the answer. Every option is explained, with the Microsoft documentation page that proves it.
Question 1 · choose 1
A web app runs on Linux in an App Service plan on the Premium tier. Releases must cause no cold starts for users, the new build must be checked with the production slot's settings applied before it takes traffic, and the previous version must be one action away if the release misbehaves. What should you do?
ADeploy to a staging slot with auto swap into production turned on for that slot
BDeploy to a staging slot and complete a swap with preview after checking it
CDeploy straight to production and restart the instances one at a time to avoid a full outage
DDeploy to a second app in another plan and switch a Traffic Manager profile from priority 1 to priority 2
Show the answer and why
ADeploy to a staging slot with auto swap into production turned on for that slot
Incorrect
Auto swap isn't supported for web apps on Linux, and it swaps without a pause to check the build under production settings.
BDeploy to a staging slot and complete a swap with preview after checking it
Correct
Swap with preview applies the target slot's settings to the staging slot, warms it, and pauses for validation; swapping again restores the previous version.
CDeploy straight to production and restart the instances one at a time to avoid a full outage
Incorrect
Each restarted instance cold-starts in front of users, and rolling back means redeploying the old build.
DDeploy to a second app in another plan and switch a Traffic Manager profile from priority 1 to priority 2
Incorrect
A second app doubles the cost, and switching DNS isn't the one-action rollback the team wants.
Deployment slots on the Standard, Premium or Isolated tiers let you warm a build in a staging slot and swap it into production without downtime. A swap with preview applies the target slot's settings and pauses so you can validate before completing; swapping back returns the previous build. Auto swap isn't supported in web apps on Linux or Web App for Containers.
A new search experience is already deployed but hidden. Product owners want it on for every employee in the Contoso Staff group and for 10 percent of customers, raising the percentage over the next weeks, all without deploying code again. What should you configure in Azure App Configuration?
AA feature flag with a time window filter that turns the feature on for one hour a day, widening the window each week
BA key-value for each customer and group, labeled on or off, read by the app at startup
CA snapshot of the key-values, replaced by one with a higher percentage when the rollout is widened
DA feature flag with a targeting filter that includes the group and a default percentage of 10
Show the answer and why
AA feature flag with a time window filter that turns the feature on for one hour a day, widening the window each week
Incorrect
A time window filter turns a feature on between dates or times; it doesn't pick a group or a percentage of users.
BA key-value for each customer and group, labeled on or off, read by the app at startup
Incorrect
Per-customer keys don't scale to a growing percentage, and values read only at startup need restarts.
CA snapshot of the key-values, replaced by one with a higher percentage when the rollout is widened
Incorrect
Snapshots don't target users.
DA feature flag with a targeting filter that includes the group and a default percentage of 10
Correct
A targeting filter enables a feature for listed users and groups and for a percentage of everyone else, and you change it without a deployment.
Targeting is a feature management strategy for progressive rollout. An audience is made of specific users, groups and a percentage of the remaining user base, and you can include or exclude users and groups. Feature flags decouple releasing a feature from deploying code.
The team ships from release branches cut from main each sprint, and release branches never merge back into main. releases/M42 is in production. A security fix is needed today. It must reach production quickly, must still pass review and branch policies, and must not be lost when releases/M43 is cut from main next week. What should the team do?
ACommit the fix directly to releases/M42 with policies bypassed, and rely on the next sprint to pick it up
BFix it in a branch created from releases/M42, merge it there through a pull request, then merge releases/M42 into main
CMerge the fix into main through a pull request, then cherry-pick it into releases/M42 with a new pull request
DCreate a hotfix branch from main and deploy that branch directly, without a pull request
Show the answer and why
ACommit the fix directly to releases/M42 with policies bypassed, and rely on the next sprint to pick it up
Incorrect
Bypassing review defeats the policies, and a fix that never reaches main comes back as a bug when M43 is cut.
BFix it in a branch created from releases/M42, merge it there through a pull request, then merge releases/M42 into main
Incorrect
Release branches never merge back into main here, and that merge would also bring the rest of the release branch along.
CMerge the fix into main through a pull request, then cherry-pick it into releases/M42 with a new pull request
Correct
Fixing main first guarantees the next release has it, and the cherry-pick pull request still goes through review and policies.
DCreate a hotfix branch from main and deploy that branch directly, without a pull request
Incorrect
Deploying an unreviewed branch skips the branch policies, and main now differs from what runs in production.
In the release flow Microsoft uses, a hotfix starts in main through the normal pull request, and the pull request page then cherry-picks it into the release branch as a new pull request that is reviewed, built and merged. Fixing only the release branch would let the bug recur when the next release branches from main.
A release has four stages: Database, Api, Web and Smoke. Api and Web both need the new schema, so neither may start until Database succeeds, but they should deploy in parallel with each other. Smoke must start only after both Api and Web succeed. Which dependsOn values should you set?
ANo dependsOn on any stage, so they run in the order they appear in the file
BApi: Database; Web: Api; Smoke: Web, so each stage waits for the one before it
CApi: []; Web: []; Smoke: [Database, Api, Web], so all three start together
DApi: Database; Web: Database; Smoke: [Api, Web]
Show the answer and why
ANo dependsOn on any stage, so they run in the order they appear in the file
Incorrect
Without dependsOn, stages run one after another, so Api and Web wouldn't deploy in parallel.
BApi: Database; Web: Api; Smoke: Web, so each stage waits for the one before it
Incorrect
Chaining Web after Api makes them run one after the other instead of in parallel.
CApi: []; Web: []; Smoke: [Database, Api, Web], so all three start together
Incorrect
An empty dependsOn lets Api and Web start before the schema change has finished.
DApi: Database; Web: Database; Smoke: [Api, Web]
Correct
Api and Web fan out from Database and run in parallel; Smoke fans in and runs only when both succeed.
Stages run sequentially in file order unless you add dependencies; with dependsOn they run in the order of their requirements. A stage that depends on several stages starts only when all of them succeed, which models fan-out and fan-in, and an empty list lets a stage start immediately.
An AKS service is deployed with the KubernetesManifest task. The team wants a small canary next to the stable version, compares the canary with a baseline of the current version, then either rolls the change out fully or removes it, from the same pipeline. How should the pipeline use the task?
Aaction deploy with strategy none for the canary, then action scale to change the replica count of the new version
Baction patch on the stable deployment to change its image on a portion of its pods
Caction deploy with strategy canary and a percentage, then a later action promote or reject
Daction bake to render the manifests, then a deployment job with the runOnce strategy
Show the answer and why
Aaction deploy with strategy none for the canary, then action scale to change the replica count of the new version
Incorrect
Deploying with no strategy replaces the stable workload at once, so there's no canary or baseline to compare.
Baction patch on the stable deployment to change its image on a portion of its pods
Incorrect
A patch changes the whole deployment's template; Kubernetes rolls it out to every pod, not a portion.
Caction deploy with strategy canary and a percentage, then a later action promote or reject
Correct
The canary strategy creates baseline and canary workloads; promote replaces the stable version and reject removes the canary.
Daction bake to render the manifests, then a deployment job with the runOnce strategy
Incorrect
Baking renders manifests from Helm or Kustomize; runOnce deploys once with no canary step.
The KubernetesManifest task supports a canary strategy: deploy with strategy canary and a percentage creates baseline and canary workloads beside the stable one. After evaluation, the promote action rolls the change out as the new stable version, and reject removes the canary and baseline.
Schema changes for an Azure SQL database live in a SQL database project. The pipeline must apply the schema from the project's build output on every release, and the deployment must stop rather than run when a change could drop or truncate data. What should you use?
AThe Azure SQL Database deployment task with the DACPAC and the additional arguments /p:DropObjectsNotInSource=True /p:BlockOnPossibleDataLoss=False
BA script task that runs every SQL migration file in the repository in alphabetical order against the target database
CThe Azure SQL Database deployment task with the DACPAC and the additional arguments /p:BackupDatabaseBeforeChanges=True /p:BlockOnPossibleDataLoss=False
DThe Azure SQL Database deployment task with the DACPAC and no additional SqlPackage arguments
Show the answer and why
AThe Azure SQL Database deployment task with the DACPAC and the additional arguments /p:DropObjectsNotInSource=True /p:BlockOnPossibleDataLoss=False
Incorrect
With the block turned off, changes that lose data run, and objects that aren't in the project are dropped as well.
BA script task that runs every SQL migration file in the repository in alphabetical order against the target database
Incorrect
Hand-run scripts aren't compared with the target, so nothing stops a destructive change.
CThe Azure SQL Database deployment task with the DACPAC and the additional arguments /p:BackupDatabaseBeforeChanges=True /p:BlockOnPossibleDataLoss=False
Incorrect
The backup property doesn't apply to Azure SQL Database, and with the block turned off, changes that lose data still run.
DThe Azure SQL Database deployment task with the DACPAC and no additional SqlPackage arguments
Correct
The task publishes the DACPAC with SqlPackage, and BlockOnPossibleDataLoss defaults to True, so publishing stops if a change could lose data.
A DACPAC packages a database schema; the Azure SQL Database deployment task (SqlAzureDacpacDeployment) publishes it with SqlPackage, and its additional arguments override publish properties. The BlockOnPossibleDataLoss property defaults to True and terminates the operation during schema validation when changes could lose data; setting it to False removes that protection.
An Azure Container Apps app must move to a blue-green release model. Testers must reach the new version at its own stable URL before it gets any production traffic, the switch must move all traffic at once, and rolling back must route traffic to the old version without redeploying it. What should you configure?
ASingle revision mode, deploying each release as a new revision that replaces the old one
BTwo separate container apps behind a load balancer whose backend pool the pipeline edits at release time
CA Container Apps job that runs the new image and moves traffic to it when tests pass
DMultiple revision mode, labels blue and green on the revisions, and traffic weights of 100 and 0
Show the answer and why
ASingle revision mode, deploying each release as a new revision that replaces the old one
Incorrect
In single revision mode the old revision is deactivated, so there is no green version to test and no blue one to roll back to.
BTwo separate container apps behind a load balancer whose backend pool the pipeline edits at release time
Incorrect
Two apps and manual pool edits aren't needed; one app can hold both revisions.
CA Container Apps job that runs the new image and moves traffic to it when tests pass
Incorrect
Jobs run tasks to completion; they don't serve traffic beside the app's revisions.
DMultiple revision mode, labels blue and green on the revisions, and traffic weights of 100 and 0
Correct
The green label gives the new revision its own address, and changing the weights moves traffic or sends it back to blue.
Container Apps supports blue-green deployment by combining revisions, traffic weights and revision labels. With activeRevisionsMode set to multiple, the green revision is reachable through its labeled FQDN while blue takes all traffic; you then shift the weight, and revert it to roll back.
A feature flag has been on for every user for six months and the old code path behind it is no longer used. What should the team do with the flag?
AKeep it forever as a safety switch for the feature
BRemove the flag and the unused code path
CTurn it off to see whether anyone notices
DConvert it to a time window filter that never ends
Show the answer and why
AKeep it forever as a safety switch for the feature
Incorrect
A flag left in place beyond its purpose keeps branching logic alive and becomes technical debt.
BRemove the flag and the unused code path
Correct
Retiring obsolete toggles keeps code complexity and technical debt from building up.
CTurn it off to see whether anyone notices
Incorrect
Turning it off would disable the feature for everyone.
DConvert it to a time window filter that never ends
Incorrect
A different filter still leaves the flag and both code paths in place.
Feature toggles add conditional code and increase complexity. Teams should plan each toggle's lifetime and remove it, with the code it guards, once the feature is stable.
After slot swaps, the first requests to production are slow because the app loads caches when /health is first called, but swap warm-up only pings the root path. The swap should wait until /health returns 200. What should you configure on the app?
AAuto swap from the staging slot
BAlways On in the production slot
CThe x-ms-routing-name cookie set to staging
DWEBSITE_SWAP_WARMUP_PING_PATH set to /health and WEBSITE_SWAP_WARMUP_PING_STATUSES set to 200
Show the answer and why
AAuto swap from the staging slot
Incorrect
Auto swap triggers the swap after a deployment; it doesn't change what warm-up checks.
BAlways On in the production slot
Incorrect
Always On keeps the app loaded; it doesn't change swap warm-up.
CThe x-ms-routing-name cookie set to staging
Incorrect
That cookie routes a client's requests to a slot; it doesn't affect warm-up.
DWEBSITE_SWAP_WARMUP_PING_PATH set to /health and WEBSITE_SWAP_WARMUP_PING_STATUSES set to 200
Correct
These settings make swap warm-up ping the given path and accept only the listed status codes before swapping.
Swap warm-up pings the application root by default. The app settings WEBSITE_SWAP_WARMUP_PING_PATH and WEBSITE_SWAP_WARMUP_PING_STATUSES set a custom path and the valid response codes; the swap stops if the code isn't in the list.
A release includes a one-way data migration on Azure SQL Database that can't be reversed by redeploying the previous build. The rollback plan must be able to get the data back to its state just before the migration. What should the plan rely on?
AA point-in-time restore of the database to just before the migration
BSwapping the App Service slots back
CRedeploying the previous DACPAC
DRe-running the migration with the inverse SQL statements
Show the answer and why
AA point-in-time restore of the database to just before the migration
Correct
Azure SQL Database automated backups support restoring a database to an earlier point in time.
BSwapping the App Service slots back
Incorrect
A swap returns the previous code; it doesn't undo changes to data.
CRedeploying the previous DACPAC
Incorrect
Deploying a DACPAC applies a schema and its packaged scripts; it doesn't return the migrated rows to their earlier state.
DRe-running the migration with the inverse SQL statements
Incorrect
A one-way migration has no reliable inverse.
Rolling back data changes is harder than rolling back code. Azure SQL Database keeps automated backups that support point-in-time restore within the retention period, which a rollback plan for stateful changes can rely on.
A pipeline rebuilds the application from source in its test stage and again in its production stage, and a dependency update once made production differ from what was tested. What should the pipeline do instead?
ARebuild in each stage with a pinned compiler version
BRun the production build at night when fewer dependencies change
CBuild once, publish a pipeline artifact, and download that artifact in each later stage
DCache the dependency folder between the two builds
Show the answer and why
ARebuild in each stage with a pinned compiler version
Incorrect
Rebuilding still compiles again, so other inputs can change between stages.
BRun the production build at night when fewer dependencies change
Incorrect
Timing doesn't stop inputs from changing between builds.
CBuild once, publish a pipeline artifact, and download that artifact in each later stage
Correct
Deploying the same published artifact means production gets exactly the binaries that were tested.
DCache the dependency folder between the two builds
Incorrect
A cache speeds builds up; it isn't a guarantee that both builds match.
Publish the build output once as a pipeline artifact and download it in later stages and jobs. Versioned build artifacts make it possible to roll back and roll forward with the same binaries that passed testing.