[AVM Module Issue]: `flag_platform_landing_zone` Logic is Inverted — the example Code and README Contradict Each Other

[r-sabari10]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Bug

(Optional) Module Version

No response

(Optional) Correlation Id

No response

Description

Module: terraform-azurerm-avm-ptn-aiml-landing-zone
Area: examples / default
Type: Bug

---

Description

The variable flag_platform_landing_zone is implemented with inverted boolean logic. The module's own README example descriptions correctly document the intended behaviour, but the flag values assigned in those examples are swapped — meaning the code does the opposite of what the README says it does.

https://github.com/Azure/terraform-azurerm-avm-ptn-aiml-landing-zone/blob/main/examples/default/main.tf
https://github.com/Azure/terraform-azurerm-avm-ptn-aiml-landing-zone/blob/main/examples/standalone/main.tf

Definitive Evidence: README vs Code Contradiction

The module's example READMEs state:

default example (flag_platform_landing_zone = true):

"the assumption is that a hub VNet hosting DNS has been provided and that the landing zone will attach to a hub VNet for all the standard network services (DNS, Hybrid Connectivity, Firewalls, etc.)"

standalone example (flag_platform_landing_zone = false):

"all supporting services are included as part of the AI landing zone deployment"

However, the actual code behaviour is the opposite:

When flag_platform_landing_zone = true the code:

• Enables AzureBastionSubnet and AzureFirewallSubnet in the spoke VNet
• Creates new Private DNS Zones locally
• Deploys a local jumpbox VM

AzureBastionSubnet.enabled  = var.flag_platform_landing_zone == true ? true : false
AzureFirewallSubnet.enabled = var.flag_platform_landing_zone == true ? true : false
JumpboxSubnet.enabled       = var.flag_platform_landing_zone == true ? true : false
private_dns_zones           = var.flag_platform_landing_zone == true ? local.private_dns_zone_map : {}
count                       = var.flag_platform_landing_zone && var.jumpvm_definition.deploy ? 1 : 0

This is standalone behaviour — deploying all supporting infrastructure locally. Yet the README says true means hub-connected.

When flag_platform_landing_zone = false the code:

• Disables Bastion, Firewall, and Jumpbox subnets
• References existing DNS zones from an external resource group (existing_zones_resource_group_resource_id)

private_dns_zones_existing = var.flag_platform_landing_zone == false ? { for key, value in local.private_dns_zone_map : key => {
  name        = value.name
  resource_id = "${coalesce(var.private_dns_zones.existing_zones_resource_group_resource_id, "notused")}/providers/Microsoft.Network/privateDnsZones/${value.name}"
}} : {}

This is hub-connected behaviour — consuming existing centralised platform resources. Yet the README calls this standalone.

---

Summary Table

	README intent	Code behaviour
true	Hub-connected spoke	Standalone (deploys Bastion, Firewall, DNS locally)
false	Standalone	Hub-connected (references existing DNS, no local infra)

The README is correct in describing the intended design. The code has the boolean inverted.

---

Impact

Any user following the module README and examples as documented will:

1. Set flag_platform_landing_zone = true expecting to connect to their existing ALZ hub
2. Instead get a standalone deployment with Bastion, Firewall subnets, and local DNS zones created in their spoke — directly conflicting with their existing hub infrastructure
3. Suffer broken private endpoint DNS resolution as local zones override centralised hub zones
4. Incur unexpected cost from duplicate hub-level infrastructure in the spoke

This is a silent misconfiguration — no error is thrown, but the deployed architecture does not match the documented intent.

---

Additional Context

The reference architecture diagram for AI Landing Zone with Platform Landing Zone, shows the AI/ML workload deployed as a spoke with a jumpbox in the spoke connecting outward to a centralized hub hosting DNS zones, Firewall, and Bastion. This aligns with the README intent (true = hub-connected spoke) and further confirms the code boolean is inverted.

https://github.com/Azure/AI-Landing-Zones?tab=readme-ov-file

[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)!