Skills

Skill 47 of 200

Azure Deployment Preflight

Performs comprehensive preflight validation of Bicep deployments to Azure, including template syntax validation, what-if analysis, and permission checks.

3 minutes · 643 words · 15 sections

Install

$ npx skills add github/awesome-copilot --skill azure-deployment-preflight

$ npx skills add github/awesome-copilot

» /plugin marketplace add github/awesome-copilot

The first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.

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, or az deployment commands

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.yaml in the project root
- If found → Use azd workflow
- If not found → Use az CLI workflow
Locate Bicep files: Find all .bicep files 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)
Auto-detect parameter files: For each Bicep file, look for matching parameter files:
- <filename>.bicepparam (Bicep parameters - preferred)
- <filename>.parameters.json (JSON parameters)
- parameters.json or parameters/<env>.json in 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 (opens in a new tab).

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 (opens in a new tab) 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 with azure.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.bicep and infra/main.bicepparam
Agent runs bicep build infra/main.bicep --stdout
Agent runs azd provision --preview
Agent generates preflight-report.md in project root
Agent summarizes findings to user

About this skill

Trigger

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.

The verbatim description from this skill’s front matter — the string an agent matches on to decide whether to load it.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/github/awesome-copilot, branch main, last pushed 24 September 2026.

Licence

MIT — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

200 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. 2 distinct layouts observed: .github/skills/*/SKILL.md, skills/*/SKILL.md.

Authorship

3 of 200 skills are installed into the repository rather than published from it. They are shelved in the closing “Credited skills” part and remain the work of their own authors. A skill counts as credited when its only copy lives under one agent’s dot directory; visible directories, per-agent mirror sets, and skills installable from this repository on skills.sh all count as published.

Issue colours

Resolved from a curated brand profile — hue 295°, chroma 0.190. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

1 repair applied to this skill so the document has one h1 and no skipped levels:

Shifted “15 headings” from h1 to h2 so the skill title is the only h1.

Spec compliance

Every skill satisfies the Agent Skills specification’s frontmatter rules.

Images

Images inside a skill come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Marketplace

A plugin manifest is published at .github/plugin/marketplace.json by GitHub, declaring 162 plugins. It is read for editorial metadata only — never as the skill index, which is always the repository tree.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /github/awesome-copilot.md, and each skill at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

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, or az deployment commands

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.yaml in the project root
- If found → Use azd workflow
- If not found → Use az CLI workflow
Locate Bicep files: Find all .bicep files 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)
Auto-detect parameter files: For each Bicep file, look for matching parameter files:
- <filename>.bicepparam (Bicep parameters - preferred)
- <filename>.parameters.json (JSON parameters)
- parameters.json or parameters/<env>.json in 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 (opens in a new tab).

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 (opens in a new tab) 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 with azure.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.bicep and infra/main.bicepparam
Agent runs bicep build infra/main.bicep --stdout
Agent runs azd provision --preview
Agent generates preflight-report.md in project root
Agent summarizes findings to user

About this skill

Trigger

Colophon

Appendix 47.1–47.3

ReferencesMarkdown · 3 files

About this skill

Trigger

Colophon

Appendix 47.1–47.3

ReferencesMarkdown · 3 files