$npx -y skills add github/awesome-copilot --skill azure-deployment-preflightPerforms 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 su
| 1 | # Azure Deployment Preflight Validation |
| 2 | |
| 3 | This skill validates Bicep deployments before execution, supporting both Azure CLI (`az`) and Azure Developer CLI (`azd`) workflows. |
| 4 | |
| 5 | ## When to Use This Skill |
| 6 | |
| 7 | - Before deploying infrastructure to Azure |
| 8 | - When preparing or reviewing Bicep files |
| 9 | - To preview what changes a deployment will make |
| 10 | - To verify permissions are sufficient for deployment |
| 11 | - Before running `azd up`, `azd provision`, or `az deployment` commands |
| 12 | |
| 13 | ## Validation Process |
| 14 | |
| 15 | Follow these steps in order. Continue to the next step even if a previous step fails—capture all issues in the final report. |
| 16 | |
| 17 | ### Step 1: Detect Project Type |
| 18 | |
| 19 | Determine the deployment workflow by checking for project indicators: |
| 20 | |
| 21 | 1. **Check for azd project**: Look for `azure.yaml` in the project root |
| 22 | - If found → Use **azd workflow** |
| 23 | - If not found → Use **az CLI workflow** |
| 24 | |
| 25 | 2. **Locate Bicep files**: Find all `.bicep` files to validate |
| 26 | - For azd projects: Check `infra/` directory first, then project root |
| 27 | - For standalone: Use the file specified by the user or search common locations (`infra/`, `deploy/`, project root) |
| 28 | |
| 29 | 3. **Auto-detect parameter files**: For each Bicep file, look for matching parameter files: |
| 30 | - `<filename>.bicepparam` (Bicep parameters - preferred) |
| 31 | - `<filename>.parameters.json` (JSON parameters) |
| 32 | - `parameters.json` or `parameters/<env>.json` in same directory |
| 33 | |
| 34 | ### Step 2: Validate Bicep Syntax |
| 35 | |
| 36 | Run Bicep CLI to check template syntax before attempting deployment validation: |
| 37 | |
| 38 | ```bash |
| 39 | bicep build <bicep-file> --stdout |
| 40 | ``` |
| 41 | |
| 42 | **What to capture:** |
| 43 | - Syntax errors with line/column numbers |
| 44 | - Warning messages |
| 45 | - Build success/failure status |
| 46 | |
| 47 | **If Bicep CLI is not installed:** |
| 48 | - Note the issue in the report |
| 49 | - Continue to Step 3 (Azure will validate syntax during what-if) |
| 50 | |
| 51 | ### Step 3: Run Preflight Validation |
| 52 | |
| 53 | Choose the appropriate validation based on project type detected in Step 1. |
| 54 | |
| 55 | #### For azd Projects (azure.yaml exists) |
| 56 | |
| 57 | Use `azd provision --preview` to validate the deployment: |
| 58 | |
| 59 | ```bash |
| 60 | azd provision --preview |
| 61 | ``` |
| 62 | |
| 63 | If an environment is specified or multiple environments exist: |
| 64 | ```bash |
| 65 | azd provision --preview --environment <env-name> |
| 66 | ``` |
| 67 | |
| 68 | #### For Standalone Bicep (no azure.yaml) |
| 69 | |
| 70 | Determine the deployment scope from the Bicep file's `targetScope` declaration: |
| 71 | |
| 72 | | Target Scope | Command | |
| 73 | |--------------|---------| |
| 74 | | `resourceGroup` (default) | `az deployment group what-if` | |
| 75 | | `subscription` | `az deployment sub what-if` | |
| 76 | | `managementGroup` | `az deployment mg what-if` | |
| 77 | | `tenant` | `az deployment tenant what-if` | |
| 78 | |
| 79 | **Run with Provider validation level first:** |
| 80 | |
| 81 | ```bash |
| 82 | # Resource Group scope (most common) |
| 83 | az deployment group what-if \ |
| 84 | --resource-group <rg-name> \ |
| 85 | --template-file <bicep-file> \ |
| 86 | --parameters <param-file> \ |
| 87 | --validation-level Provider |
| 88 | |
| 89 | # Subscription scope |
| 90 | az deployment sub what-if \ |
| 91 | --location <location> \ |
| 92 | --template-file <bicep-file> \ |
| 93 | --parameters <param-file> \ |
| 94 | --validation-level Provider |
| 95 | |
| 96 | # Management Group scope |
| 97 | az deployment mg what-if \ |
| 98 | --location <location> \ |
| 99 | --management-group-id <mg-id> \ |
| 100 | --template-file <bicep-file> \ |
| 101 | --parameters <param-file> \ |
| 102 | --validation-level Provider |
| 103 | |
| 104 | # Tenant scope |
| 105 | az deployment tenant what-if \ |
| 106 | --location <location> \ |
| 107 | --template-file <bicep-file> \ |
| 108 | --parameters <param-file> \ |
| 109 | --validation-level Provider |
| 110 | ``` |
| 111 | |
| 112 | **Fallback Strategy:** |
| 113 | |
| 114 | If `--validation-level Provider` fails with permission errors (RBAC), retry with `ProviderNoRbac`: |
| 115 | |
| 116 | ```bash |
| 117 | az deployment group what-if \ |
| 118 | --resource-group <rg-name> \ |
| 119 | --template-file <bicep-file> \ |
| 120 | --validation-level ProviderNoRbac |
| 121 | ``` |
| 122 | |
| 123 | Note the fallback in the report—the user may lack full deployment permissions. |
| 124 | |
| 125 | ### Step 4: Capture What-If Results |
| 126 | |
| 127 | Parse the what-if output to categorize resource changes: |
| 128 | |
| 129 | | Change Type | Symbol | Meaning | |
| 130 | |-------------|--------|---------| |
| 131 | | Create | `+` | New resource will be created | |
| 132 | | Delete | `-` | Resource will be deleted | |
| 133 | | Modify | `~` | Resource properties will change | |
| 134 | | NoChange | `=` | Resource unchanged | |
| 135 | | Ignore | `*` | Resource not analyzed (limits reached) | |
| 136 | | Deploy | `!` | Resource will be deployed (changes unknown) | |
| 137 | |
| 138 | For modified resources, capture the specific property changes. |
| 139 | |
| 140 | ### Step 5: Generate Report |
| 141 | |
| 142 | Create a Markdown report file in the **project root** named: |
| 143 | - `preflight-report.md` |
| 144 | |
| 145 | Use the template structure from [references/REPORT-TEMPLATE.md](references/REPORT-TEMPLATE.md). |
| 146 | |
| 147 | **Report |