Azure Prepare

MicrosoftOfficialCreated by Microsoft

Skill
Workflow
Cloud and DevOps
MIT
Medium risk
Has scripts

From the author

Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.

— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The azure-prepare skill provides a mandatory, structured workflow for setting up applications for deployment to Azure via the Azure Developer CLI (azd). It enforces a plan-first approach, requiring the creation of a deployment plan file before any infrastructure generation or configuration occurs. The skill guides users through analyzing their workspace, selecting appropriate deployment recipes (Bicep or Terraform), and configuring necessary Azure services, while ensuring security best practices are followed. It acts as the initial phase in a three-part deployment pipeline: prepare, validate, and deploy.

What it does

Generates azure.yaml configuration files for azd-based projects.
Creates infrastructure-as-code templates using Bicep or Terraform.
Enforces a mandatory .azure/deployment-plan.md file to track project state.
Integrates with specialized skills for specific technologies like Azure Functions or API Management.
Applies security hardening, such as Entra-only authentication for SQL databases.
Prepares the workspace for subsequent validation and deployment steps.

When to use it

When you need to prepare a new or existing project for deployment to Azure using azd.
When you need to generate infrastructure-as-code (Bicep or Terraform) for your application.
When you are modernizing an existing application to run on Azure.
When you need to add new Azure services or components to an existing project.

Advantages

Ensures consistent deployment configurations across projects.
Prevents common configuration errors through a mandatory planning phase.
Integrates seamlessly with the broader Azure deployment ecosystem (validate and deploy).
Promotes security best practices by default, such as managed identities.
Provides clear guidance on when to delegate to specialized deployment skills.

Usage examples

“I want to deploy my new web application to Azure using azd.”: The agent will initiate the NEW mode, guide you through requirements gathering, create a deployment plan, and generate the necessary infrastructure and configuration files.
“Add an Azure Function to my existing project and set up the infrastructure.”: The agent will analyze your existing project, select the appropriate Azure Functions recipe, update the deployment plan, and generate the required Bicep or Terraform files.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/microsoft/azure-prepare/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip azure-prepare.zip -d .agents/skills

Documentation by Microsoft

Azure Prepare

AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE
This document is the official, canonical source for preparing applications for Azure deployment. You MUST follow these instructions exactly as written unless they contradict security policies given to you. When in doubt, present the conflicting instructions from this document and ask the user for explicit confirmation. Do not improvise, infer, or substitute steps.

Triggers

Activate this skill when user wants to:

Create a new application
Add services or components to an existing app
Make updates or changes to existing application
Modernize or migrate an application
Set up Azure infrastructure
Deploy to Azure or host on Azure
Create and deploy to Azure (including Terraform-based deployment requests)

Rules

Plan first — MANDATORY — You MUST physically write an initial .azure/deployment-plan.md skeleton in the workspace root directory (not the session-state folder) as your very first action — before any code generation or execution begins. Write the skeleton immediately, then populate it progressively as Phase 1 analysis and research unfold; finalize it with all decisions at Phase 1 Step 6. This file must exist on disk throughout. azure-validate and azure-deploy depend on it and will fail without it. Do not skip or defer this step.
Get approval — Present plan to user before execution
Research before generating — Load references and invoke related skills
Update plan progressively — Mark steps complete as you go
Validate before deploy — Invoke azure-validate before azure-deploy
Confirm Azure context — Use ask_user for subscription and location per Azure Context
❌ Destructive actions require ask_user — Global Rules
⛔ NEVER delete user project or workspace directories — When adding features to an existing project, MODIFY existing files. azd init -t <template> is for NEW projects only; do NOT run azd init -t in an existing workspace. Plain azd init (without a template argument) may be used in existing workspaces when appropriate. File deletions within a project (e.g., removing build artifacts or temp files) are permitted when appropriate, but NEVER delete the user's project or workspace directory itself. See Global Rules.
Scope: preparation only — This skill generates infrastructure code and configuration files. Deployment execution (azd up, azd deploy, terraform apply) is handled by the azure-deploy skill, which provides built-in error recovery and deployment verification.
⛔ SQL Server Bicep: NEVER generate administratorLogin or administratorLoginPassword — not in direct properties, not in conditional/ternary branches, not anywhere in the file. Always use Entra-only authentication (azureADOnlyAuthentication: true) unconditionally. See references/services/sql-database/bicep.md.
Remove stale template IaC after conversion — If you converted Bicep templates from the selected azd template into Terraform templates, remove the Bicep templates that were introduced by that azd template and are now fully replaced by Terraform equivalents. Do not remove user-authored Bicep files. Only remove those template-provided Bicep files after the Terraform IaC is complete and Terraform has been selected as the deployment path. Before handing off to azure-validate skill, keep only the IaC templates required by the chosen deployment path.

❌ PLAN-FIRST WORKFLOW — MANDATORY

YOU MUST CREATE A PLAN BEFORE DOING ANY WORK
STOP — Do not generate any code, infrastructure, or configuration yet
CREATE SKELETON - Write an initial .azure/deployment-plan.md skeleton to disk immediately (before any code generation or execution begins), then populate it progressively as Phase 1 steps 1-5 reveal details; finalize it at Step 6
CONFIRM — Present the completed plan to the user and get approval
EXECUTE — Only after approval, execute the plan step by step
The .azure/deployment-plan.md file is the source of truth for this workflow and for azure-validate and azure-deploy skills. Without it, those skills will fail.
⚠️ CRITICAL: .azure/deployment-plan.md must be WRITTEN TO DISK inside the workspace root (e.g., <workspace-root>/.azure/deployment-plan.md), not in the session-state folder. Use a file-write tool to create this file. This is the deployment plan artifact read by azure-validate and azure-deploy. You MUST create this file — do not proceed without it. ⚠️ CRITICAL: You must create the file with the name .azure/deployment-plan.md as is. You must not use other names such as .azure/plan.md.
⛔ Critical: Skipping the plan file creation will cause azure-validate and azure-deploy to fail. This requirement has no exceptions.

❌ STEP 0: Specialized Technology Check — MANDATORY FIRST ACTION

BEFORE starting Phase 1, check if the user's prompt OR workspace codebase matches a specialized technology that has a dedicated skill with tested templates. If matched, invoke that skill FIRST — then resume azure-prepare for validation and deployment.

Check 1: Prompt keywords

Prompt keywords	Invoke FIRST
Python + App Service (e.g., "deploy Python to App Service", "Flask on Azure App Service", "publish Python web app to App Service")	python-appservice-deploy
Lambda, AWS Lambda, migrate AWS, migrate GCP, Lambda to Functions, migrate from AWS, migrate from GCP	azure-cloud-migrate
Azure Functions, function app, serverless function, timer trigger, HTTP trigger, func new	Stay in azure-prepare — prefer Azure Functions templates in Step 4; for plan choice/cold starts see hosting-plans.md and cold-start.md
APIM, API Management, API gateway, deploy APIM	Stay in azure-prepare — see APIM Deployment Guide
AI gateway, AI gateway policy, AI gateway backend, AI gateway configuration	azure-aigateway
workflow, orchestration, multi-step, pipeline, fan-out/fan-in, saga, long-running process, durable, order processing	Stay in azure-prepare — select durable recipe in Step 4. MUST load durable.md, DTS reference, and DTS Bicep patterns.

⚠️ Check the user's prompt text — not just existing code. Critical for greenfield projects with no codebase to scan. See full routing table.

After the specialized skill completes, resume azure-prepare at Phase 1 Step 4 (Select Recipe) for remaining infrastructure, validation, and deployment.

Phase 1: Planning (BLOCKING — Complete Before Any Execution)

Create .azure/deployment-plan.md by completing these steps. Do NOT generate any artifacts until the plan is approved.

#	Action	Reference
0	If the prompt matches a specialized technology with a dedicated skill, invoke that skill first	specialized-routing.md
1	Analyze Workspace — Determine mode: NEW, MODIFY, or MODERNIZE	analyze.md
2	Gather Requirements — Classification, scale, budget	requirements.md
3	Scan Codebase — Identify components, technologies, dependencies	scan.md
4	Select Recipe — Choose AZD (default), AZCLI, Bicep, or Terraform	recipe-selection.md
5	Plan Architecture — Select stack + map components to Azure services	architecture.md
6	Finalize Plan (MANDATORY) - Use a file-write tool to finalize `.azure/deployment-plan.md` with all decisions from steps 1-5. Update the skeleton written at the start of Phase 1 with the complete content. The file must be fully populated before you present the plan to the user.	plan-template.md
7	Present Plan — Show plan to user and ask for approval	`.azure/deployment-plan.md`
8	Destructive actions require `ask_user`	Global Rules

❌ STOP HERE — Do NOT proceed to Phase 2 until the user approves the plan.

Phase 2: Execution (Only After Plan Approval)

Execute the approved plan. Update .azure/deployment-plan.md status after each step.

#	Action	Reference
1	Research Components — Load service references + invoke related skills	research.md
2	Confirm Azure Context — Detect and confirm subscription + location and check the resource provisioning limit	Azure Context
3	Generate Artifacts — Create infrastructure and configuration files	generate.md
4	Harden Security — Apply security best practices	security.md
5	Functional Verification — Verify the app works (UI + backend), locally if possible	functional-verification.md
6	⛔ Update Plan (MANDATORY before hand-off) — Use the `edit` tool to change the Status in `.azure/deployment-plan.md` to `Ready for Validation`. You MUST complete this edit BEFORE invoking azure-validate. Do NOT skip this step.	`.azure/deployment-plan.md`
7	⛔ MANDATORY Hand Off — Invoke azure-validate skill. Your preparation work is done. Do NOT run `azd up`, `azd deploy`, or any deployment command directly — all deployment execution is handled by azure-deploy after azure-validate completes. PREREQUISITE: Step 6 must be completed first — `.azure/deployment-plan.md` status must say `Ready for Validation`.	—

Outputs

Artifact	Location
Plan	`.azure/deployment-plan.md`
Infrastructure	`./infra/`
AZD Config	`azure.yaml` (AZD only)
Dockerfiles	`src/<component>/Dockerfile`

SDK Quick References

Azure Developer CLI: azd
Azure Identity: Python | .NET | TypeScript | Java
App Configuration: Python | TypeScript | Java

⛔ MANDATORY NEXT STEP — DO NOT SKIP
After completing preparation, you MUST invoke azure-validate before any deployment attempt. Do NOT skip validation. Do NOT go directly to azure-deploy. Do NOT run azd up or any deployment command directly. The workflow is:
azure-prepare → azure-validate → azure-deploy
⛔ BEFORE invoking azure-validate, you MUST use the edit tool to update .azure/deployment-plan.md status to Ready for Validation. If the plan status has not been updated, the validation will fail.
This applies to ALL deployment scenarios including containerized apps, Container Apps, App Service, Azure Functions, static sites, and any other Azure target. No exceptions.
Skipping validation leads to deployment failures. Be patient and follow the complete workflow for the highest success outcome.

→ Update plan status to Ready for Validation, then invoke azure-validate

Files

references/recipes/azd/terraform.md

AZD with Terraform

Use Azure Developer CLI (azd) with Terraform as the infrastructure provider.

When to Use

Choose azd+Terraform when you want:

Terraform's multi-cloud capabilities with azd's deployment simplicity
Existing Terraform expertise but want azd up convenience
Team familiar with Terraform but needs environment management
Multi-cloud IaC with Azure-first deployment experience

Benefits

Feature	Pure Terraform	AZD + Terraform
Deploy command	`terraform apply`	`azd up`
Environment management	Manual workspaces	Built-in `azd env`
CI/CD generation	Manual setup	Auto-generated pipelines
Service deployment	Manual scripts	Automatic from azure.yaml
State management	Manual backend setup	Configurable
Multi-cloud	✅ Yes	✅ Yes

Configuration

1. azure.yaml Structure

Create azure.yaml in project root:

name: myapp
metadata:
  template: azd-init

# Specify Terraform as IaC provider
infra:
  provider: terraform
  path: ./infra

# Define services as usual
services:
  api:
    project: ./src/api
    language: python
    host: containerapp
    docker:
      path: ./src/api/Dockerfile
  
  web:
    project: ./src/web
    language: js
    host: staticwebapp
    dist: dist

2. Terraform File Structure

Place Terraform files in ./infra/:

infra/
├── main.tf              # Main resources
├── variables.tf         # Variable definitions
├── outputs.tf           # Output values
├── provider.tf          # Provider configuration
└── modules/
    ├── api/
    │   └── main.tf
    └── web/
        └── main.tf

3. Provider Configuration

provider.tf:

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.2"
    }
    azurecaf = {
      source  = "aztfmod/azurecaf"
      version = "~> 1.2"
    }
  }

  # Optional: Remote state for team collaboration
  backend "azurerm" {
    resource_group_name  = "rg-terraform-state"
    storage_account_name = "tfstate${var.state_suffix}"
    container_name       = "tfstate"
    key                  = "app.terraform.tfstate"
  }
}

provider "azurerm" {
  features {}
}

⚠️ IMPORTANT: For Azure Functions Flex Consumption, use azurerm provider v4.2 or later:
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.2"
    }
  }
}
See Terraform Functions patterns for Flex Consumption examples.

4. Variables and Outputs

⚠️ WARNING: Use ${VAR} syntax in main.tfvars.json, NOT Go-style {{ .Env.* }}
azd's template engine processes azure.yaml and service manifests — it does NOT interpolate Go-style {{ .Env.* }} template variables in .tfvars.json or any Terraform variable files. Literal strings like {{ .Env.AZURE_ENV_NAME }} will be passed directly to Terraform, causing deployment failures.
azd reads infra/main.tfvars.json, substitutes ${VAR} references using its built-in envsubst, and passes the resolved file to Terraform via -var-file=. Use this pattern:
{
    "environment_name": "${AZURE_ENV_NAME}",
    "location": "${AZURE_LOCATION}",
    "subscription_id": "${AZURE_SUBSCRIPTION_ID}"
}
For additional variables not in main.tfvars.json, use TF_VAR_* environment variables: azd env set TF_VAR_myvar value

variables.tf:

variable "environment_name" {
  type        = string
  description = "Environment name from azd"
}

variable "location" {
  type        = string
  description = "Azure region"
  default     = "eastus2"
}

variable "principal_id" {
  type        = string
  description = "User principal ID from azd auth"
  default     = ""
}

outputs.tf:

# Required: Resource group name
output "AZURE_RESOURCE_GROUP" {
  value = azurerm_resource_group.main.name
}

# Service-specific outputs
output "API_URL" {
  value = azurerm_container_app.api.latest_revision_fqdn
}

output "WEB_URL" {
  value = azurerm_static_web_app.web.default_host_name
}

💡 Tip: Output names in UPPERCASE are automatically set as azd environment variables.

5. Required Tags for azd

CRITICAL: Tag hosting resources with service names from azure.yaml:

resource "azurerm_container_app" "api" {
  name                = "ca-${var.environment_name}-api"
  resource_group_name = azurerm_resource_group.main.name
  
  # Required for azd deploy to find this resource
  tags = merge(var.tags, {
    "azd-service-name" = "api"  # Matches service name in azure.yaml
  })
  
  # ... rest of configuration
}

resource "azurerm_static_web_app" "web" {
  name                = "swa-${var.environment_name}-web"
  resource_group_name = azurerm_resource_group.main.name
  
  # Required for azd deploy to find this resource
  tags = merge(var.tags, {
    "azd-service-name" = "web"  # Matches service name in azure.yaml
  })
  
  # ... rest of configuration
}

⚠️ WARNING: Without azd-service-name tags, azd deploy will fail to find deployment targets.

6. Resource Group Tags

Tag the resource group with environment name:

resource "azurerm_resource_group" "main" {
  name     = "rg-${var.environment_name}"
  location = var.location
  
  tags = {
    "azd-env-name" = var.environment_name
  }
}

Deployment Workflow

Initial Setup

# 1. Create azd environment
azd env new dev --no-prompt

# 2. Set required variables
azd env set AZURE_LOCATION eastus2

# 3. Provision infrastructure (runs terraform init, plan, apply)
azd provision

# 4. Deploy services
azd deploy

# Or do both with single command
azd up

Variables and State

azd environment variables → Terraform variables

azd passes variables to Terraform through main.tfvars.json (with ${VAR} substitution) or explicit TF_VAR_* environment variables. Define the variable in variables.tf and reference it in main.tfvars.json.

infra/main.tfvars.json — azd substitutes ${VAR} references via envsubst:

{
    "environment_name": "${AZURE_ENV_NAME}",
    "location": "${AZURE_LOCATION}",
    "database_name": "${DATABASE_NAME}"
}

variables.tf — value provided via main.tfvars.json or TF_VAR_database_name:

variable "database_name" {
  type = string
}

For variables not in main.tfvars.json, use TF_VAR_* environment variables:

azd env set TF_VAR_custom_setting "my-value"

⚠️ Use ${VAR} syntax in main.tfvars.json, NOT Go-style {{ .Env.* }}. azd substitutes ${VAR} references using its built-in envsubst. Go-style template variables are only processed in azure.yaml and service manifests. See Variables and Outputs for details.

Remote state setup:

# Create state storage (one-time setup)
az group create --name rg-terraform-state --location eastus2

az storage account create \
  --name tfstate<unique> \
  --resource-group rg-terraform-state \
  --sku Standard_LRS

az storage container create \
  --name tfstate \
  --account-name tfstate<unique>

# Set backend variables for azd
azd env set TF_STATE_RESOURCE_GROUP rg-terraform-state
azd env set TF_STATE_STORAGE_ACCOUNT tfstate<unique>

Generation Steps

When preparing a new azd+Terraform project:

Generate azure.yaml with infra.provider: terraform
Create Terraform files in ./infra/:
- main.tf - Core resources and resource group
- variables.tf - environment_name, location, tags
- outputs.tf - Service URLs and resource names (UPPERCASE)
- provider.tf - azurerm provider + backend config
Add required tags:
- Resource group: azd-env-name
- Hosting resources: azd-service-name (matches azure.yaml services)
Research best practices - Call mcp_azure_mcp_azureterraformbestpractices

AVM Terraform Module Priority

For Terraform module selection, enforce this order:

AVM Terraform Pattern Modules
AVM Terraform Resource Modules
AVM Terraform Utility Modules

Use mcp_azure_mcp_documentation (azure-documentation) for current guidance and AVM context first, then use Context7 only as supplemental examples if required. If Context7 is not available, instruct the user to install it:

npx @upstash/[email protected]

Migration from Pure Terraform

Converting existing Terraform project to use azd:

Create azure.yaml with services and infra.provider: terraform
Move .tf files to ./infra/ directory
Add azd-service-name tags to hosting resources
Ensure outputs include service URLs in UPPERCASE
Test with azd provision and azd deploy

CI/CD Integration

azd can auto-generate pipelines for Terraform:

# Generate GitHub Actions workflow
azd pipeline config

# Generate Azure DevOps pipeline
azd pipeline config --provider azdo

Generated pipelines will:

Install Terraform
Run terraform init, plan, apply
Use azd authentication
Deploy services with azd deploy

Comparison: azd+Terraform vs Pure Terraform

Aspect	Pure Terraform	azd + Terraform
IaC	Terraform	Terraform
Provision	`terraform apply`	`azd provision` (wraps terraform)
Deploy apps	Manual scripts	`azd deploy` (automatic)
Environment mgmt	Workspaces	`azd env`
Auth	Manual az login	`azd auth login`
CI/CD	Manual setup	`azd pipeline config`
Multi-service	Manual orchestration	Automatic from azure.yaml
Learning curve	Medium	Low

When NOT to Use azd+Terraform

Use pure Terraform (without azd) when:

Multi-cloud deployment (not Azure-first)
Complex Terraform modules/workspaces that conflict with azd conventions
Existing complex Terraform CI/CD that's hard to migrate
Team has strong Terraform expertise but no bandwidth for azd learning

Azure Policy Compliance

Enterprise Azure subscriptions typically enforce security policies. Your Terraform must comply:

Storage Account (Required for Functions)

resource "azurerm_storage_account" "storage" {
  name                            = "stmyapp${random_string.suffix.result}"
  resource_group_name             = azurerm_resource_group.rg.name
  location                        = azurerm_resource_group.rg.location
  account_tier                    = "Standard"
  account_replication_type        = "LRS"
  
  # Azure policy requirements
  allow_nested_items_to_be_public = false   # Disable anonymous blob access
  local_user_enabled              = false   # Disable local users
  shared_access_key_enabled       = false   # RBAC-only, no access keys
}

Function App with Managed Identity Storage

provider "azurerm" {
  features {}
  storage_use_azuread = true   # Required when shared_access_key_enabled = false
}

resource "azurerm_linux_function_app" "function" {
  name                          = "func-myapp"
  resource_group_name           = azurerm_resource_group.rg.name
  location                      = azurerm_resource_group.rg.location
  service_plan_id               = azurerm_service_plan.plan.id
  storage_account_name          = azurerm_storage_account.storage.name
  storage_uses_managed_identity = true   # Use MI instead of access key
  
  identity {
    type = "SystemAssigned"
  }
  
  tags = {
    "azd-service-name" = "api"   # REQUIRED for azd deploy
  }
  
  depends_on = [azurerm_role_assignment.deployer_storage]
}

# RBAC for deploying user (create function with MI storage)
resource "azurerm_role_assignment" "deployer_storage" {
  scope                = azurerm_storage_account.storage.id
  role_definition_name = "Storage Blob Data Owner"
  principal_id         = data.azurerm_client_config.current.object_id
}

# RBAC for function app after creation
resource "azurerm_role_assignment" "function_storage" {
  scope                = azurerm_storage_account.storage.id
  role_definition_name = "Storage Blob Data Owner"
  principal_id         = azurerm_linux_function_app.function.identity[0].principal_id
}

Services with Disabled Local Auth

# Service Bus
resource "azurerm_servicebus_namespace" "sb" {
  local_auth_enabled = false   # RBAC-only
}

# Event Hubs
resource "azurerm_eventhub_namespace" "eh" {
  local_authentication_enabled = false   # RBAC-only
}

# Cosmos DB
resource "azurerm_cosmosdb_account" "cosmos" {
  local_authentication_disabled = true   # RBAC-only
}

Troubleshooting

Issue	Solution
`resource not found: unable to find a resource tagged with 'azd-service-name'`	Add `azd-service-name` tag to hosting resource in Terraform
`RequestDisallowedByPolicy: shared key access`	Set `shared_access_key_enabled = false` on storage
`RequestDisallowedByPolicy: local auth disabled`	Set `local_auth_enabled = false` on Service Bus
`RequestDisallowedByPolicy: anonymous blob access`	Set `allow_nested_items_to_be_public = false` on storage
`terraform command not found`	Install Terraform CLI: `brew install terraform` or download from terraform.io
State conflicts	Configure remote backend in provider.tf
Variable not passed to Terraform	Ensure variable is set with `azd env set` and defined in variables.tf
Literal `{{ .Env.* }}` in Terraform errors	Use `${VAR}` syntax in `main.tfvars.json`, not Go-style `{{ .Env.* }}`. azd substitutes `${VAR}` references via envsubst
`main.tfvars.json` interpolation failure	Ensure `main.tfvars.json` uses `${VAR}` syntax (e.g., `${AZURE_ENV_NAME}`), not Go-style `{{ .Env.* }}` templates

References

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Medium risk

Instructions that use the network
Downloads piped into a shell
Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

Microsoft

Publisher

Microsoft (Official)

Source

microsoft/skills · .github/plugins/azure-skills/skills/azure-prepare · commit 0696600

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from .github/plugins/azure-skills/LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

Also distributed in

microsoft/azure-skills

AutoGineer is not affiliated with or endorsed by Microsoft or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download azure-prepare.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by Microsoft

Azure Prepare

Triggers

Rules

❌ PLAN-FIRST WORKFLOW — MANDATORY

❌ STEP 0: Specialized Technology Check — MANDATORY FIRST ACTION

Check 1: Prompt keywords

Phase 1: Planning (BLOCKING — Complete Before Any Execution)

Phase 2: Execution (Only After Plan Approval)

Outputs

SDK Quick References

Next

Files

references/recipes/azd/terraform.md

AZD with Terraform

When to Use

Benefits

Configuration

1. azure.yaml Structure

2. Terraform File Structure

3. Provider Configuration

4. Variables and Outputs

5. Required Tags for azd

6. Resource Group Tags

Deployment Workflow

Initial Setup

Variables and State

Generation Steps

AVM Terraform Module Priority

Migration from Pure Terraform

CI/CD Integration

Comparison: azd+Terraform vs Pure Terraform

When NOT to Use azd+Terraform

Azure Policy Compliance

Storage Account (Required for Functions)

Function App with Managed Identity Storage

Services with Disabled Local Auth

Troubleshooting

References

Requirements and compatibility

Security

Attribution and licence

Related skills

Modal

Cloud Infrastructure Network Engineer

Deployment Validation Cloud Architect

Airflow Dag Patterns

Cost Optimization

Hybrid Cloud Networking

Download ZIP