[AVM Module Issue]: custom_data validation rejects gzipped cloud-init

[V1TO-C]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Bug

(Optional) Module Version

0.19.3

(Optional) Correlation Id

No response

Description

When passing gzipped, base64-encoded cloud-init user data (via data.cloudinit_config.rendered with gzip = true) to the module’s custom_data input, variable validation fails. Azure VMs and cloud-init support gzipped user-data, so the module should accept it.

Example

data "cloudinit_config" "this" {
  gzip          = true
  base64_encode = true

  part {
    content_type = "text/cloud-config"
    content      = file("cloud-init.yaml")
  }
}

module "virtual_machine" {
  source  = "Azure/avm-res-compute-virtualmachine/azurerm"
  version = "0.19.3"

  # … other inputs …
  custom_data = data.cloudinit_config.this.rendered
} 

Actual behavior

Terraform fails during variable validation for custom_data, indicating the value is invalid because the decoded bytes are not valid UTF-8 when gzip is enabled.

│ Error: Invalid value for variable
│ 
│   on main.tf line 15, in module "virtual_machine":
│   15:   custom_data                = data.cloudinit_config.this.rendered
│     ├────────────────
│     │ var.custom_data is "xxx"
│ 
│ The `custom_data` must be either `null` or a valid Base64-Encoded string.
│ 
│ This was checked by the validation rule at
│ .terraform/modules/virtual_machine/variables.tf:443,3-13.

Expected behavior

The module should accept gzipped, base64-encoded custom_data and pass it to the VM resource unchanged so cloud-init can decompress and process it on first boot.

• Gzip is commonly used with cloud-init to stay under Azure’s 64 KB customData limit after decoding, so blocking gzip prevents standard usage patterns.

• Azure/cloud-init handle gzip automatically on supported Linux images, so the module’s validation should not prohibit this.

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the Terraform Issue Triage documentation.

[microsoft-github-policy-service]

Warning

Tagging the AVM Core Team (@Azure/avm-core-team-technical-terraform) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

Tip

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage 🔍" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service]

Caution

**This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-terraform) immediate attention as it hasn't been responded to within 6 business days. **

Tip

• To avoid this rule being (re)triggered, the "Needs: Triage 🔍" and "Status: Response Overdue 🚩" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention ‼️" label once the issue has been responded to.