Deployment And Delivery Design — Azure Administrator (AZ-104)
Deployment strategy is a risk management decision
Architecture requirement: deploy a web application update with the ability to roll back within five minutes if error rates spike. Competing choices: blue-green slot swap on App Service, rolling deployment via Azure DevOps, canary traffic split via Application Gateway, or full redeployment via ARM template. The deciding constraint is rollback speed — slot swap is near-instant; rolling deployment requires reversing changes across instances; ARM redeployment adds pipeline latency. The exam tests whether rollback SLA drives the deployment model choice.
What This Pattern Tests
Azure deployment questions test pipeline architecture with Azure-native tools. Azure Pipelines uses multi-stage YAML pipelines with environments that enforce approval gates and deployment history. For AZ-400, deployment strategies include slot swaps on App Service (zero-downtime blue/green), canary releases with Traffic Manager weighted routing, and ring-based deployments to progressively larger user groups. Azure Artifacts manages NuGet, npm, and Maven packages with upstream sources. For AI-300, Azure ML pipelines handle model training, evaluation, and registration, while managed online endpoints support blue/green deployment by splitting traffic between model versions. GitHub Actions with Azure-native actions provide an alternative to Azure Pipelines with tighter GitHub integration. The trap is using a single release pipeline without environments and approvals, or deploying ML models through a generic CI/CD pipeline instead of Azure ML pipelines.
Decision Axis
Workload type determines pipeline tooling: application code uses Azure Pipelines with slot swaps, ML models use Azure ML pipelines, infrastructure uses Bicep with what-if previews.
Associated Traps
More Top Traps on This Exam
Decision Rules
Whether declarative simplicity—one Bicep file plus environment-specific parameter files—outweighs the apparent modularity benefit of nested or linked ARM templates for a deployment scope that does not require cross-team template reuse.
Whether to use a single Bicep file with environment-specific parameter files or a nested/linked ARM template set to satisfy repeatable, environment-separated deployment at the lowest ongoing maintenance cost.
Whether to use a single Bicep file with per-environment parameter files or a nested/linked ARM template hierarchy to satisfy idempotent, environment-separated deployment with minimal maintenance overhead.
Whether to replace imperative New-Az* resource-creation cmdlets with a single New-AzResourceGroupDeployment call targeting an ARM template, accepting the declarative model's built-in idempotency over the familiar imperative scripting pattern already in use.
Whether Bicep modules (compile-time local resolution, no external hosting required) or ARM linked templates (runtime HTTPS URL resolution, requires remotely hosted fragment storage) best satisfies the modularity-plus-no-new-infrastructure constraint.
Domain Coverage
Difficulty Breakdown