Seal Bicep input objects when extra properties must fail validation

Source facts

Bicep user-defined types require CLI version 0.12.X or later and enable language-version 2.0 code generation. By default, an object type accepts additional properties; a likely misspelling can produce BCP089 as a warning rather than an error.

Applying @sealed() to the object type or parameter elevates that warning to an error. Azure Resource Manager also validates sealed parameters and fails deployment validation when they contain extra properties. Microsoft Learn.

Applicability

Identify the pipeline’s Bicep version and which input objects have a deliberately closed schema. Do not apply a closed contract to an extension field that callers are intentionally allowed to populate freely.

DSE recommendation

DSE recommends reviewing accepted property names with the module’s callers before sealing an input. Make the desired treatment of unknown fields explicit in the contract. Include a misspelled optional property and a genuinely additional property in the validation cases. Plan the change with existing callers rather than assuming every previously accepted input remains compatible.

Verification

Run the current pipeline against valid input and the two invalid cases in a controlled scope. Retain compiler diagnostics and parameter-validation outcomes separately. Confirm that the expected valid properties still work and that an unrecognized field is not silently treated as an approved setting. Record the tested tool version with the contract change so later pipeline upgrades can repeat the same checks.

Official references

Microsoft Learn: User-defined types in Bicep. Source retrieved September 9, 2026.