In general, the rule for what should and should not be supported is encoded in the pipeline generators. The following is not entirely accurate, but as a rule of thumb:

• If an option is supported by an image type, then setting it to some non-default value should have an effect on the generated manifest.
• If an option is not supported by an image type, then setting it to some non-default value (and ignoring the validation) should have no effect on the generated manifest.

We can create a testing framework for this, where all supported_blueprint_options for an image type are set individually, a manifest is generated, and it is checked against a manifest generated without options for changes.
Conversely, the tests could set options not included in the supported list, bypass the config validation, and verify that the manifest does not differ from one created without the option.

Exceptions to these rules can be encoded in the test framework. An exception here would be cases where a manifest is affected by the setting of a non-supported option (indicating it should be supported based on the rules above), but we explicitly do not support it for policy reasons.

An example of such an exception is the azure-eap7-rhui image, for which we do not support any customizations because it is an internal image type that should only ever be built in its default configuration. Because it shares pipelines with all the other disk image types however, bypassing the validation would in fact modify the image.