[BUG] cidrHost/cidrSubnet fail during Bicep expansion when address prefixes are assigned outside the template

GetBicepParamResources から開始し、参照されたリソースを解決できない場合に使用される汎用 mock レイヤーを追跡します。2 つの cidrHost/cidrSubnet の失敗を再現し、その後、型付きプレースホルダーによって一覧にあるアドレスプロパティの展開が維持されることを確認します。一方で、無関係な未指定プロパティと厳密な CIDR 検証は現在の動作を維持します。

Existing rule

N/A — this affects Bicep expansion rather than a specific rule.

Description of the issue

When a virtual network, subnet, or IPAM pool gets its address prefixes assigned outside the template being analyzed, the properties.addressPrefixes value cannot be resolved during expansion. PSRule for Azure creates a generic mock for the unresolved reference, and unknown string properties on that mock resolve to an empty string.

The cidr*() functions validate their input strictly, so any expression that consumes such a value fails expansion of the whole deployment:

The specified CIDR '' is not valid.

This is increasingly common with Azure Virtual Network Manager IPAM. The prefixes are allocated by IPAM at deploy time via ipamPoolPrefixAllocations, so they are genuinely not knowable from the source. Anything derived from them with cidrHost() or cidrSubnet() — a static private frontend IP for an Application Gateway is the typical case — cannot be analyzed at all today.

The generic mock already knows the resource type of the reference. That is enough to supply a well-formed placeholder for a small set of well-known address properties, so expansion can continue instead of failing outright.

Two related gaps make this worse than it first appears:

1. Existing (existing = {}) resources are registered as deployment symbols but are not added to the resource ID lookup, so reference('vnet::subnet') can fall back to a mock built from the bare symbolic name and lose the resource type entirely.
2. When a resource declares a partial properties object (for example a subnet that sets ipamPoolPrefixAllocations but not addressPrefixes), the properties are wrapped in a plain mock object. Resource type context is lost, so missing sibling properties cannot be inferred even when the type is known.

Importantly, a fix here should not relax the cidr*() functions themselves. Keeping them strict is what still catches genuine authoring mistakes such as passing id instead of an address prefix, or passing addressPrefixes without indexing it.

Error messages

Failed to expand bicep source 'deploy.bicepparam'. Exception calling "GetBicepParamResources" with "2" argument(s):
"Unable to expand resources because the source file 'deploy.bicepparam' was not valid.
The deployment 'root/example' with symbolic name 'example' failed.
An error occurred evaluating expression '[cidrHost(reference('vnet::subnet').addressPrefixes[0], 3)]'
at path 'properties.frontendIPConfigurations[1].properties.privateIPAddress'.
The function 'cidrHost' failed. The specified CIDR '' is not valid."

An error occurred evaluating expression '[cidrSubnet(reference('networkManager::platformPool').addressPrefixes[0], 23, 0)]'.
The function 'cidrSubnet' failed. The specified CIDR '' is not valid."

Reproduction

Both cases below fail expansion.

Case 1 — subnet address prefix allocated by IPAM

targetScope = 'resourceGroup'

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' existing = {
  name: 'vnet-example'

  resource subnet 'subnets' = {
    name: 'ApplicationGatewaySubnet'
    properties: {
      ipamPoolPrefixAllocations: [
        {
          numberOfIpAddresses: '256'
          pool: { id: '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-example/providers/Microsoft.Network/networkManagers/vnm-example/ipamPools/pool-example' }
        }
      ]
      defaultOutboundAccess: true
    }
  }
}

// Fails: The specified CIDR '' is not valid.
output privateFrontendIP string = cidrHost(vnet::subnet.properties.addressPrefixes[0], 3)

Case 2 — IPAM pool address prefix

targetScope = 'resourceGroup'

resource networkManager 'Microsoft.Network/networkManagers@2024-05-01' existing = {
  name: 'vnm-example'

  resource platformPool 'ipamPools' existing = {
    name: 'pool-example'
  }
}

// Fails: The specified CIDR '' is not valid.
output reservation string = cidrSubnet(networkManager::platformPool.properties.addressPrefixes[0], 23, 0)

The same failure occurs for a virtual network whose properties.addressSpace.addressPrefixes is IPAM-allocated.

Version of PSRule

2.9.0

Version of PSRule for Azure

1.48.0-B0231

Additional context

A targeted fix would be to give the existing mock layer source awareness: a small table mapping resource type plus normalized property path to a typed placeholder, so only well-known address properties return a valid placeholder CIDR and everything else keeps today's behaviour.

Using the reserved documentation range from RFC 5737 (192.0.2.0/24) makes placeholders obvious in output and avoids colliding with plausible customer address space.

The minimal set that unblocks the IPAM scenarios:

• Microsoft.Network/virtualNetworks → properties.addressSpace.addressPrefixes[]
• Microsoft.Network/virtualNetworks/subnets → properties.addressPrefix
• Microsoft.Network/virtualNetworks/subnets → properties.addressPrefixes[]
• Microsoft.Network/networkManagers/ipamPools → properties.addressPrefixes[]

A table-driven approach keeps this easy to extend later to other resources that expose address-like outputs (network interfaces, public IPs, firewalls, DNS resolver inbound endpoints) without reworking the mock layer, and without requiring full ARM property schemas.

I have a working implementation of this and will follow up with a PR.