Quick Note — Recommend an Automated Deployment Solution for Applications
AZ-305 › Unit 4: Design infrastructure solutions › Design an application architecture › Recommend an automated deployment solution for applications
Quick Note — Recommend an Automated Deployment Solution for Applications
A platform team supports 40 services across 3 business units. Every team deploys by clicking "Publish" in Visual Studio and emailing the rest of the company. Tuesday afternoons a service goes down for 35 minutes because two engineers redeployed the same module within a minute of each other and the second wiped the first's hotfix. The architect's response is one decision: every production deployment must come from Azure Pipelines running a versioned Bicep file in source control, with blue-green slots and an automated rollback gate.…
Retrieval target
- Recommend an Automated Deployment Solution for Applications
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Bicep | Microsoft's DSL for Azure Resource Manager — a clean, declarative syntax that compiles to ARM JSON. Modules for reuse, parameter / output declarations, type inference, idempotent deploys. Bicep is Microsoft's recommended IaC for Azure-only stacks — same engine and feature parity as ARM JSON but vastly more readable. |
ARM template | The original Azure IaC format: JSON describing resources, parameters, variables, outputs that the Azure Resource Manager engine deploys idempotently. Verbose vs Bicep but identical capability. Still used where existing templates exist; new projects prefer Bicep for authoring and emit ARM JSON only as a build artefact. |
Terraform on Azure | HashiCorp's multi-cloud IaC via the azurerm provider. Authored in HCL; maintains a state file (in Azure Storage or Terraform Cloud) tracking what's deployed. Strengths: multi-cloud / multi-provider in one config, mature module ecosystem, broad community. Trade-offs: state-file management, occasional provider lag behind Azure features (Bicep tracks ARM same-day). |
Deployment Slot (App Service) | An App Service Plan feature that gives the app isolated 'staging' slots sharing the plan's VMs. Deploy new code to a slot, warm it up (the slot has its own URL), then swap with prod — the routing flips with zero downtime and the previous prod becomes the new staging (instant rollback). Available on Standard tier and up. The foundation of safe App Service deploys. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.