azure-deployment-preflight
github/awesome-copilot
Validate Bicep deployments to Azure before execution with syntax checks, what-if analysis, and permission verification.
What is azure-deployment-preflight?
This skill performs comprehensive preflight validation of Bicep deployments to Azure, including template syntax validation, what-if analysis, and permission checks. Use it before any deployment to preview changes, identify issues, and ensure deployment success.
- Detects project type (azd or standalone Bicep) and locates deployment files
- Validates Bicep syntax using bicep CLI with detailed error reporting
- Runs what-if analysis to preview resource changes (create, modify, delete, unchanged)
- Checks deployment permissions and falls back to ProviderNoRbac if RBAC validation fails
- Generates comprehensive Markdown report with issues, recommendations, and what-if results
How to install azure-deployment-preflight
npx skills add https://github.com/github/awesome-copilot --skill azure-deployment-preflight- Azure CLI (version 2.76.0+ recommended)
- Azure Developer CLI (azd) for projects with azure.yaml
- Bicep CLI for syntax validation
- Azure credentials configured (az login or azd auth login)
How to use azure-deployment-preflight
- 1.Run the skill when validating a Bicep deployment or before executing azd provision/az deployment commands
- 2.The skill automatically detects project type by checking for azure.yaml
- 3.Provide resource group name, subscription, or environment name if prompted
- 4.Review the generated preflight-report.md in the project root for validation results, issues, and what-if changes
- 5.Address any errors or warnings in the report before proceeding with actual deployment
Use cases
- Preview infrastructure changes before running azd up or az deployment commands
- Validate Bicep templates for syntax errors and configuration issues before committing
- Check if current Azure credentials have sufficient permissions for deployment
- Identify resources that will be created, modified, or deleted by a deployment
- Prepare deployment validation reports for infrastructure review and approval workflows
- Infrastructure engineers deploying to Azure
- DevOps teams using Azure Developer CLI (azd) workflows
- Cloud architects reviewing Bicep infrastructure-as-code
- Developers preparing infrastructure changes for production deployment
azure-deployment-preflight FAQ
The skill auto-detects project type by looking for azure.yaml. For azd projects, it runs azd provision --preview. For standalone Bicep files, it uses az deployment what-if commands with the appropriate scope (resourceGroup, subscription, managementGroup, or tenant).
The skill falls back to ProviderNoRbac validation level if Provider validation fails due to RBAC restrictions. This is noted in the report so you know permissions may be limited.
The skill notes the issue in the report and continues with Azure-side validation via what-if analysis. Azure will validate syntax during the what-if step.
The preflight-report.md is generated in the project root and includes a summary, tools executed, all issues found, what-if results, and recommendations.
Yes, the skill automatically detects all .bicep files in the project (infra/ directory for azd projects, or common locations for standalone) and validates each one.
Full instructions (SKILL.md)
Source of truth, from github/awesome-copilot.
name: azure-deployment-preflight description: 'Performs comprehensive preflight validation of Bicep deployments to Azure, including template syntax validation, what-if analysis, and permission checks. Use this skill before any deployment to Azure to preview changes, identify potential issues, and ensure the deployment will succeed. Activate when users mention deploying to Azure, validating Bicep files, checking deployment permissions, previewing infrastructure changes, running what-if, or preparing for azd provision.'
Azure Deployment Preflight Validation
This skill validates Bicep deployments before execution, supporting both Azure CLI (az) and Azure Developer CLI (azd) workflows.
When to Use This Skill
- Before deploying infrastructure to Azure
- When preparing or reviewing Bicep files
- To preview what changes a deployment will make
- To verify permissions are sufficient for deployment
- Before running
azd up,azd provision, oraz deploymentcommands
Validation Process
Follow these steps in order. Continue to the next step even if a previous step fails—capture all issues in the final report.
Step 1: Detect Project Type
Determine the deployment workflow by checking for project indicators:
-
Check for azd project: Look for
azure.yamlin the project root- If found → Use azd workflow
- If not found → Use az CLI workflow
-
Locate Bicep files: Find all
.bicepfiles to validate- For azd projects: Check
infra/directory first, then project root - For standalone: Use the file specified by the user or search common locations (
infra/,deploy/, project root)
- For azd projects: Check
-
Auto-detect parameter files: For each Bicep file, look for matching parameter files:
<filename>.bicepparam(Bicep parameters - preferred)<filename>.parameters.json(JSON parameters)parameters.jsonorparameters/<env>.jsonin same directory
Step 2: Validate Bicep Syntax
Run Bicep CLI to check template syntax before attempting deployment validation:
bicep build <bicep-file> --stdout
What to capture:
- Syntax errors with line/column numbers
- Warning messages
- Build success/failure status
If Bicep CLI is not installed:
- Note the issue in the report
- Continue to Step 3 (Azure will validate syntax during what-if)
Step 3: Run Preflight Validation
Choose the appropriate validation based on project type detected in Step 1.
For azd Projects (azure.yaml exists)
Use azd provision --preview to validate the deployment:
azd provision --preview
If an environment is specified or multiple environments exist:
azd provision --preview --environment <env-name>
For Standalone Bicep (no azure.yaml)
Determine the deployment scope from the Bicep file's targetScope declaration:
| Target Scope | Command |
|---|---|
resourceGroup (default) | az deployment group what-if |
subscription | az deployment sub what-if |
managementGroup | az deployment mg what-if |
tenant | az deployment tenant what-if |
Run with Provider validation level first:
# Resource Group scope (most common)
az deployment group what-if \
--resource-group <rg-name> \
--template-file <bicep-file> \
--parameters <param-file> \
--validation-level Provider
# Subscription scope
az deployment sub what-if \
--location <location> \
--template-file <bicep-file> \
--parameters <param-file> \
--validation-level Provider
# Management Group scope
az deployment mg what-if \
--location <location> \
--management-group-id <mg-id> \
--template-file <bicep-file> \
--parameters <param-file> \
--validation-level Provider
# Tenant scope
az deployment tenant what-if \
--location <location> \
--template-file <bicep-file> \
--parameters <param-file> \
--validation-level Provider
Fallback Strategy:
If --validation-level Provider fails with permission errors (RBAC), retry with ProviderNoRbac:
az deployment group what-if \
--resource-group <rg-name> \
--template-file <bicep-file> \
--validation-level ProviderNoRbac
Note the fallback in the report—the user may lack full deployment permissions.
Step 4: Capture What-If Results
Parse the what-if output to categorize resource changes:
| Change Type | Symbol | Meaning |
|---|---|---|
| Create | + | New resource will be created |
| Delete | - | Resource will be deleted |
| Modify | ~ | Resource properties will change |
| NoChange | = | Resource unchanged |
| Ignore | * | Resource not analyzed (limits reached) |
| Deploy | ! | Resource will be deployed (changes unknown) |
For modified resources, capture the specific property changes.
Step 5: Generate Report
Create a Markdown report file in the project root named:
preflight-report.md
Use the template structure from references/REPORT-TEMPLATE.md.
Report sections:
- Summary - Overall status, timestamp, files validated, target scope
- Tools Executed - Commands run, versions, validation levels used
- Issues - All errors and warnings with severity and remediation
- What-If Results - Resources to create/modify/delete/unchanged
- Recommendations - Actionable next steps
Required Information
Before running validation, gather:
| Information | Required For | How to Obtain |
|---|---|---|
| Resource Group | az deployment group | Ask user or check existing .azure/ config |
| Subscription | All deployments | az account show or ask user |
| Location | Sub/MG/Tenant scope | Ask user or use default from config |
| Environment | azd projects | azd env list or ask user |
If required information is missing, prompt the user before proceeding.
Error Handling
See references/ERROR-HANDLING.md for detailed error handling guidance.
Key principle: Continue validation even when errors occur. Capture all issues in the final report.
| Error Type | Action |
|---|---|
| Not logged in | Note in report, suggest az login or azd auth login |
| Permission denied | Fall back to ProviderNoRbac, note in report |
| Bicep syntax error | Include all errors, continue to other files |
| Tool not installed | Note in report, skip that validation step |
| Resource group not found | Note in report, suggest creating it |
Tool Requirements
This skill uses the following tools:
- Azure CLI (
az) - Version 2.76.0+ recommended for--validation-level - Azure Developer CLI (
azd) - For projects withazure.yaml - Bicep CLI (
bicep) - For syntax validation - Azure MCP Tools - For documentation lookups and best practices
Check tool availability before starting:
az --version
azd version
bicep --version
Example Workflow
- User: "Validate my Bicep deployment before I run it"
- Agent detects
azure.yaml→ azd project - Agent finds
infra/main.bicepandinfra/main.bicepparam - Agent runs
bicep build infra/main.bicep --stdout - Agent runs
azd provision --preview - Agent generates
preflight-report.mdin project root - Agent summarizes findings to user
Reference Documentation
Related skills
More from github/awesome-copilot and the wider catalog.
git-commit
Execute semantic git commits with conventional message analysis and intelligent staging.
excalidraw-diagram-generator
Generate Excalidraw diagrams from natural language descriptions.
documentation-writer
Create structured technical documentation using the Diátaxis framework for tutorials, how-to guides, references, and explanations.
gh-cli
GitHub CLI comprehensive reference for repositories, issues, PRs, Actions, projects, releases, and all GitHub operations from the command line.
prd
Generate comprehensive Product Requirements Documents with executive summaries, user stories, technical specs, and risk analysis.
refactor
Surgical code refactoring to improve maintainability without changing behavior.