AZ-400 - Design and Implement Build and Release Pipelines - Section 3.10

Design a deployment strategy, including blue-green, canary, ring, progressive exposure, feature flags, and A/B testing.

Distinguish blue-green deployment, canary deployment, ring deployment, and progressive exposure, weighing rollback speed, blast radius, and infrastructure cost for each. Use feature flags via App Configuration Feature Manager to decouple code deployment from feature release and enable controlled A/B testing.

blue-green deploymentcanary deploymentring deploymentfeature flagsApp Configuration Feature Manager

Practice question for this objective

Free sampleDesign and Implement Build and Release Pipelineshard

A team practising trunk-based development merges an unfinished checkout redesign into main and deploys it to production every day, but the redesign must stay invisible to customers until the product owner decides to release it, and it must be switchable off in seconds without a new deployment. Which technique satisfies the need to deploy the code yet control its release independently?

AWrap the redesign in a feature flag evaluated at runtime, ship the flag off so the code deploys daily but stays hidden, and let the product owner flip it on or off instantly with no redeploy. Correct
BKeep the redesign on a long-lived feature branch and merge it to main only on the day the product owner approves release, then deploy that merge to production.
CWrap the redesign behind a feature flag stored in a deployment-time pipeline variable, and run a fresh release with the variable set to on when the product owner approves the change.
DPlace the redesign inside a separate microservice that is only started in production once the product owner is ready for customers to begin using the new checkout experience.

Use runtime feature flags to decouple deployment of code from its release so exposure can be toggled without redeploying. A feature flag evaluated at runtime lets code be merged and deployed continuously while remaining inert until the flag is turned on. Because the flag state lives outside the build and is read at request time, the owner can enable or disable the feature in seconds, which is the core deploy-versus-release decoupling the scenario needs.

Why A is correct: A runtime feature flag separates deploy from release, so the unfinished code reaches production behind an off flag every day and the product owner toggles exposure instantly without any new deployment, exactly as required.

Why B is wrong: A long-lived feature branch defers the merge but conflicts with the trunk-based daily-deploy practice stated, and it still ties release to a deployment rather than giving a runtime switch the owner can flip instantly.

Why C is wrong: A pipeline variable can gate code, but because it is bound at deployment time, flipping it on or off requires a new release, so it fails the requirement to switch the feature in seconds without deploying again.

Why D is wrong: Splitting the work into a microservice that is started on demand is heavier architecture and changes the deployment unit, which does not match a single trunk-based service needing a simple runtime on-off switch.

See more AZ-400 practice questions, answers explained.

More in this domain

Back to all Design and Implement Build and Release Pipelines objectives, or the AZ-400 cert hub.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.