---

name: converting-to-strong-types description: Converts loosely typed Bicep parameters using object or array to strongly typed alternatives like string[], user-defined types, or resource-derived types. Use when user mentions type safety, weak typing, object parameters, array parameters, resourceInput, resourceOutput, or asks to improve parameter definitions.

Converting to Strong Types

Replaces loose object and array parameter types with strong alternatives for compile-time validation and autocompletion.

Conversion Workflow

1. Identify loose types

   • Search for param <name> object and param <name> array declarations.

2. Analyze parameter usage

   • Examine how the parameter is used in the template to determine expected structure.

3. Choose conversion strategy

1. Define types and update parameters

   • Place type definitions above parameters.

2. Validate

   • Run command bicep build <.bicep file> --stdout --no-restore to verify syntax and type correctness.

Quick Reference

Simple Arrays

Copy// Before
param addresses array

// After
param addresses string[]

Union Types (Constrained Values)

Copyparam environments ('dev' | 'staging' | 'prod')[]
param skuName 'Standard_LRS' | 'Premium_LRS'

User-Defined Types

Copytype subnetType = {
  name: string
  addressPrefix: string
  nsgId: string?  // Optional property
}

param subnets subnetType[]

Type Best Practices

• Use ? for optional properties: description: string?
• Use @sealed() to prevent extra properties at deployment
• Use @description() on types and properties
• Use constraints: @minLength(), @maxLength(), @minValue(), @maxValue()
• Compose complex types from simpler types

MCP Tools

Edge Cases

Dynamic objects (unknown keys): Use wildcard { *: string }

Mixed-type arrays: Use union (string | int | bool)[]

Optionality and backwards compatibility: Use optional types ? for new properties

Resource-Derived Types

Use resourceInput<> and resourceOutput<> to derive types directly from Azure resource schemas. Prioritise this approach over custom user-defined types.

Syntax

CopyresourceInput<'<resourceType>@<apiVersion>'>   // Writable properties
resourceOutput<'<resourceType>@<apiVersion>'>  // Readable properties (includes computed)

When to Use

• Parameter must match resource property structure exactly
• Want to avoid maintaining custom types that mirror resource properties

Examples

Full Properties Block

Copyparam storageAccountProps resourceInput<'Microsoft.Storage/storageAccounts@2023-01-01'>.properties = {
  accessTier: 'Hot'
  minimumTlsVersion: 'TLS1_2'
  allowBlobPublicAccess: false
  supportsHttpsTrafficOnly: true
}

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorageacct'
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: storageAccountProps
}

Output Types

Copyoutput endpoints resourceOutput<'Microsoft.Storage/storageAccounts@2024-01-01'>.properties.primaryEndpoints

Do not do this

Do not use a type definition for resource-derived types but define them directly in parameters or outputs.

Copytype managedRulesDefinitionType = resourceInput<'Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies@2024-07-01'>.properties.managedRules
type customRulesType = resourceInput<'Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies@2024-07-01'>.properties.customRules
type policySettingsType = resourceInput<'Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies@2024-07-01'>.properties.policySettings
type wafPolicyTagsType = resourceInput<'Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies@2024-07-01'>.tags