Skip to main content
rule official · GitHub

generate-modern-terraform-code-for-azure

This rule guides GitHub Copilot when it works on Azure Terraform files, from provider selection to validation. Use it to shape infrastructure code in .tf files.

Install into GitHub Copilot · Manually: put the files in place All methods and platforms ↓
.github/instructions/generate-modern-terraform-code-for-azure.instructions.md
Open on GitHub

What generate-modern-terraform-code-for-azure does

The rule applies to **/*.tf files. It recommends separating resources, inputs and outputs into main.tf, variables.tf and outputs.tf, and grouping reusable infrastructure in modules. It favors azurerm for most cases; azapi is for newer Azure features or resources that azurerm does not yet support.

It also guides provider versioning, dependency choices and idempotent configurations. Before applying changes, run terraform validate and inspect terraform plan; a second terraform apply should produce no changes. The rule recommends a remote backend such as Azure Storage with state locking, and says not to commit state files. Review the plan before applying: it can reveal unintended infrastructure changes.

What it helps with

  • organize Azure Terraform code across core files
  • move reusable Azure resources into a module
  • choose between azurerm and azapi
  • inspect a Terraform plan before applying changes
  • store Terraform state in a remote backend

Example prompts for the agent

  • Create an Azure Terraform setup using main.tf, variables.tf and outputs.tf.
  • Move reusable Azure resources into a module and explain which provider you chose.
  • Run terraform validate and review the terraform plan output for this configuration.

How to install generate-modern-terraform-code-for-azure

Manually: put the files in place

.github/instructions/generate-modern-terraform-code-for-azure.instructions.md

The applyTo field sets which files it applies to

Step by step, with commands for each platform: AGENTS.md vs CLAUDE.md: what they are and which one to use

Questions about generate-modern-terraform-code-for-azure

How do I install generate-modern-terraform-code-for-azure in GitHub Copilot?

Add .github/instructions/generate-modern-terraform-code-for-azure.instructions.md to your project. The rule applies to **/*.tf files.

What does generate-modern-terraform-code-for-azure do?

It guides Terraform code generation for Azure, covering file layout, modules, provider selection, state handling and checks before applying changes.

When should I use azapi instead of azurerm?

Use azapi for newer Azure features or resources not yet supported by azurerm. For most other cases, the rule favors azurerm.

Source text

generate-modern-terraform-code-for-azure.instructions.md · MIT
---
description: 'Guidelines for generating modern Terraform code for Azure'
applyTo: '**/*.tf'
---

## 1. Use Latest Terraform and Providers
Always target the latest stable Terraform version and Azure providers. In code, specify the required Terraform and provider versions to enforce this. Keep provider versions updated to get new features and fixes.

## 2. Organize Code Cleanly
Structure Terraform configurations with logical file separation:

- Use `main.tf` for resources
- Use `variables.tf` for inputs
- Use `outputs.tf` for outputs
- Follow consistent naming conventions and formatting (`terraform fmt`)

This makes the code easy to navigate and maintain.

## 3. Encapsulate in Modules

Use Terraform modules to group reusable infrastructure components. For any resource set that will be used in multiple contexts:

- Create a module with its own variables/outputs
- Reference it rather than duplicating code
- This promotes reuse and consistency

## 4. Leverage Variables and Outputs

- **Parameterize** all configurable values using variables with types and descriptions
- **Provide default values** where appropriate for optional variables
- **Use outputs** to expose key resource attributes for other modules or user reference
- **Mark sensitive values** accordingly to protect secrets

## 5. Provider Selection (AzureRM vs AzAPI)

- **Use `azurerm` provider** for most scenarios – it offers high stability and covers the majority of Azure services
- **Use `azapi` provider** only for cases where you need:
  - The very latest Azure features
  - A resource not yet supported in `azurerm`
- **Document the choice** in code comments
- Both providers can be used together if needed, but prefer `azurerm` when in doubt

## 6. Minimal Dependencies

- **Do not introduce** additional providers or modules beyond the project's scope without confirmation
- If a special provider (e.g., `random`, `tls`) or external module is needed:
  - Add a comment to explain
  - Ensure the user approves it
- Keep the infrastructure stack lean and avoid unnecessary complexity

## 7. Ensure Idempotency

- Write configurations that can be applied repeatedly with the same outcome
- **Avoid non-idempotent actions**:
  - Scripts that run on every apply
  - Resources that might conflict if created twice
- **Test by doing multiple `terraform apply` runs** and ensure the second run results in zero changes
- Use resource lifecycle settings or conditional expressions to handle drift or external changes gracefully

## 8. State Management

- **Use a remote backend** (like Azure Storage with state locking) to store Terraform state securely
- Enable team collaboration
- **Never commit state files** to source control
- This prevents conflicts and keeps the infrastructure state consistent

## 9. Document and Diagram

- **Maintain up-to-date documentation**
- **Update README.md** with any new variables, outputs, or usage instructions whenever the code changes
- Consider using tools like `terraform-docs` for automation
- **Update architecture diagrams** to reflect infrastructure changes after each significant update
- Well-documented code and diagrams ensure the whole team understands the infrastructure

## 10. Validate and Test Changes

- **Run `terraform validate`** and review the `terraform plan` output before applying changes
- Catch errors or unintended modifications early
- **Consider implementing automated checks**:
  - CI pipeline
  - Pre-commit hooks
  - Enforce formatting, linting, and basic validation

© github · MIT · github/awesome-copilot

Similar IDE rules

All IDE rules for DevOps and infrastructure →

From the same set770

The whole set →

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor