Azure Developer CLI (azd) organizes an application, Azure infrastructure, service deployment, environment configuration, and pipeline setup into one developer workflow. It can use Bicep or Terraform and supports templates. Treat a template as executable supply-chain code: review its infrastructure, hooks, scripts, permissions, and costs before running it.
Method note: This chapter is specifically about the Azure Developer CLI workflow. Its Bicep and Terraform engines are alternatives inside an azd project, while standalone IaC workflows are covered in the two preceding infrastructure chapters.
Developers often need a repeatable sequence: create environment → provision cloud resources → build/deploy services → inspect endpoints/logs → delete. azd standardizes that sequence while letting teams own the underlying IaC and application code.
azure.yaml declares service names, hosts, project paths, and hooks. It does not replace App Service, Container Apps, AKS, or Functions; it orchestrates deployment to them.
Install from the official page, then:
To use a template:
Before azd up, inspect every file, expected resources, regions, SKUs, role assignments, hooks, and post-provision scripts. Templates from a gallery or GitHub are still third-party code from your environment's perspective.
Preview support varies by IaC/provider and azd version. If the wrapper cannot show enough detail, run Bicep what-if or Terraform plan directly.
Use azd deploy to redeploy application services without reprovisioning unchanged infrastructure. Separate infrastructure and application changes in CI where permissions and approvals differ.
Each azd environment stores non-secret deployment context and outputs. Keep developer environments isolated by name, resource group, and cloud data. Use Key Vault or pipeline secret stores for secrets. Review .azure content before deciding what can be committed; local environment files can expose IDs, endpoints, or sensitive values.
Hooks can run before or after provisioning/deployment. They are powerful enough to execute arbitrary local commands. Keep hooks short, cross-platform where required, reviewed, deterministic, and free of secret echoing. Do not use a hook to make hidden manual changes that the IaC cannot reproduce.
azd pipeline config can scaffold GitHub Actions or Azure Pipelines integration and identity. Review the generated workflow, federated credential scope, environment protection, roles, and variables. Treat scaffolding as a first draft, not automatic production approval.
Read the confirmation carefully. Verify the resource group and separately created identities, role assignments, custom domains, DNS, shared registries, and retained data. Never point a disposable azd environment at shared production resources without explicit ownership boundaries.
Skip it when a mature platform already provides a different paved road, when resources do not fit its service model, or when an extra orchestration layer would hide required controls. The underlying Bicep/Terraform and CI practices remain the source of truth.