Validated API parameters

Treat template parameters and embedded ARM calls as a client-facing API contract. Validate inputs and constrain the “request schema” so invalid values can’t be sent, and keep compatibility/UX aligned with how the template is consumed.

Apply:

• Prefer enumerations/allowed lists for values that map to platform-supported modes (e.g., security type).
• Avoid freeform strings for fields that must match a known set of endpoints; instead provide a selectable list (or validate/derive internally). Freeform inputs create incorrect-request failures.
• Define the portal UX contract explicitly (e.g., via uiDefinition) when you need a guided customer flow without forcing re-entry of all existing configuration.
• Pin ARM API versions to ones that work in the target environment(s) (e.g., US Gov) and use the correct intrinsic/method patterns for consistent outputs.

Example (constrained mode + dependent settings):

@description('Security type')
@allowed([
  'Standard'
  'TrustedLaunch'
])
param securityType string = 'TrustedLaunch'

@description('Secure Boot (only valid when securityType is TrustedLaunch)')
param secureBoot bool = true

Example (use correct method/intrinsic for consistent outputs):

value storageKey = storageAccount.listKeys().keys[0].value