4 of the 22 questions we have for this objective, shown with the answer and the reasoning.
Design and implement deployments
Tamarind Foods packages its inventory service for AKS as a Helm chart stored in Azure Container Registry, and its build agents use Helm 3. The pipeline must install the release if it does not exist, upgrade it otherwise, wait until the pods are ready, and automatically roll back to the previous release revision if the upgrade fails, with no manual steps.
Which command should the deployment step run?
- Ahelm install inventory oci://acrtamarind.azurecr.io/helm/inventory --version 2.4.0helm install fails if the release already exists and does not roll back on failure.
- Bhelm upgrade --install inventory oci://acrtamarind.azurecr.io/helm/inventory --version 2.4.0 --atomic --wait --timeout 10mupgrade --install handles both first install and upgrade, --wait waits for resources to be ready, and --atomic rolls back to the previous revision automatically if the upgrade does not succeed within the timeout.
- Ckubectl apply -f inventory.yaml followed by kubectl rollout undo if the step failsThis abandons the Helm chart and release history, and rollback relies on a separate failure handler rather than Helm's built-in atomic behavior.
- Dhelm upgrade inventory oci://acrtamarind.azurecr.io/helm/inventory --version 2.4.0 --dry-run--dry-run only simulates the upgrade and never deploys, and without --install it fails on a first deployment.
Why: Helm tracks each release as numbered revisions, which makes rollback a first-class operation. In a pipeline, helm upgrade --install makes the step idempotent across first and later runs, and --atomic combined with --wait turns a failed or timed-out upgrade into an automatic rollback. The HelmDeploy task in Azure Pipelines exposes the same arguments. Plain kubectl or helm install lose either the release history or the idempotency the pipeline needs.
Design and implement deployments
Birchfield Grocers has a new delivery slot picker behind a feature flag named SlotPickerV2 in Azure App Configuration Feature Manager. Product management wants about 15 percent of all requests to see the new picker, with no code deployment needed to change the share later. The users do not sign in, so there is no user identity.
Which feature filter should you add to SlotPickerV2?
- ATargeting filter with a default rollout percentage of 15The targeting filter relies on a user or group identity to make consistent decisions, which is not available here.
- BTime window filter with a start time of todayA time window filter enables the flag for everyone during a period, not for a share of requests.
- CPercentage filter with a value of 15The built-in percentage filter enables the feature for the stated percentage of evaluations and needs no user identity; the value can be changed in App Configuration at any time.
- DA label named 15percent on the feature flagLabels separate flag values by environment or version; they do not split traffic.
Why: Feature Manager evaluates feature filters to decide whether a flag is on for a given request. The percentage filter turns the feature on for a random share of evaluations, which suits anonymous traffic, while the targeting filter uses user and group identity for consistent per-user rollout. The time window filter enables a feature between start and end times. Because filter parameters live in App Configuration, the share can change without a redeploy.
Design and implement deployments
Fenwick Health ships a clinician desktop sync service to 12,000 users. Releases must reach the internal IT team first, then a group of 200 volunteer clinics, then all remaining customers. Each group must run the release for at least 48 hours with no Sev1 incidents before the next group receives it, and promotion must be automated in Azure Pipelines.
Which design should you implement?
- AA single stage that deploys to all users with a canary strategy of increments [1, 2]Canary increments shift traffic percentages within one target, not between named user groups, and they do not enforce a 48-hour soak per group.
- BA multi-stage YAML pipeline with one stage per ring, where each ring's stage ends with an agentless job that runs the Delay task for 48 hours, and each ring's environment has a Query Azure Monitor alerts check for Sev1 alertsRing-based deployment maps each audience to a stage and environment. The Delay task holds the pipeline for the soak period after a ring is deployed, and the Query Azure Monitor alerts check on the next ring's environment blocks that stage while any Sev1 alert rule is active, so promotion between rings is automatic.
- CA blue-green deployment that swaps all users to the new version after the IT team approves itBlue-green switches everyone at once, so it cannot expose the release to the volunteer clinics separately.
- DThree separate pipelines triggered manually by the release manager after checking incident reportsManual triggering and manual incident checks fail the requirement that promotion is automated.
Why: Ring-based deployment, a form of progressive exposure, releases to successively larger audiences and uses evidence from each ring to decide whether to continue. In Azure Pipelines each ring becomes a stage that deploys to its own environment. Environment checks such as Query Azure Monitor alerts enforce health criteria before a stage starts, while a soak period is enforced inside the pipeline, for example with the Delay task in an agentless job, because there is no delay check on environments. Canary deployments shift a percentage of traffic on one target, which is related but does not model named audiences. Blue-green moves everyone at once, which removes the staged blast-radius control the scenario needs.
Design and implement deployments
Juniper Books wants to compare two versions of its product recommendation panel, ShelfA and ShelfB, to learn which one produces more purchases. Each signed-in user must consistently see the same version across sessions, and the results must be measured in Application Insights. Both versions are already in the same build of the ASP.NET Core app, which reads settings from Azure App Configuration.
What should you implement?
- AA blue-green deployment with two slots, one for each version, swapped weeklySwapping weekly shows every user the same version at the same time, so there is no simultaneous comparison between two groups.
- BA canary deployment that routes 50 percent of requests to a slot containing ShelfBRequest-level routing does not guarantee a user sees the same version on each visit, and both versions already ship in one build.
- CA variant feature flag in App Configuration that allocates users 50/50 to ShelfA and ShelfB, with feature evaluation events sent to Application InsightsVariant feature flags assign each targeted user to a variant consistently, and the feature management telemetry integration records which variant each user saw so purchase outcomes can be compared.
- DA ring deployment that gives ShelfB to internal users and ShelfA to customersRings separate audiences by risk, not at random, so the two groups differ systematically and the comparison would be biased.
Why: A/B testing is an experiment: two variants are shown to comparable groups at the same time and a business metric decides the winner. That needs consistent per-user assignment and telemetry that ties each user's variant to outcomes. Variant feature flags in Azure App Configuration with the .NET feature management library provide both, because allocation is based on the user identity and evaluation events flow to Application Insights. Blue-green, canary, and ring strategies manage release risk, but they do not produce a controlled comparison of two experiences.