azure-deployment-preflight — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited azure-deployment-preflight (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Attribution: Sourced from microsoft/azure-skills by Microsoft Azure.
This skill validates Bicep deployments before execution, supporting both Azure CLI (az) and Azure Developer CLI (azd) workflows.
azd up, azd provision, or az deployment commandsFollow these steps in order. Continue to the next step even if a previous step fails—capture all issues in the final report.
Determine the deployment workflow by checking for project indicators:
azure.yaml in the project root.bicep files to validateinfra/ directory first, then project rootinfra/, deploy/, project root)<filename>.bicepparam (Bicep parameters - preferred)<filename>.parameters.json (JSON parameters)parameters.json or parameters/<env>.json in same directoryRun Bicep CLI to check template syntax before attempting deployment validation:
bicep build <bicep-file> --stdoutWhat to capture:
If Bicep CLI is not installed:
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 --previewIf 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 ProviderFallback 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 ProviderNoRbacNote the fallback in the report—the user may lack full deployment permissions.
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.
Create a Markdown report file in the project root named:
preflight-report.mdUse the template structure from references/REPORT-TEMPLATE.md.
Report sections:
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.
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 |
This skill uses the following tools:
az) - Version 2.76.0+ recommended for --validation-levelazd) - For projects with azure.yamlbicep) - For syntax validationCheck tool availability before starting:
az --version
azd version
bicep --versionazure.yaml → azd projectinfra/main.bicep and infra/main.bicepparambicep build infra/main.bicep --stdoutazd provision --previewpreflight-report.md in project root~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.