Open trylvis opened 1 week ago
[!IMPORTANT] The "Needs: Triage :mag:" label must be removed once the triage process is complete!
[!TIP] For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.
[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.
[!TIP]
- To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
- To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!
Check for previous/existing GitHub issues
Description
Greetings all,
Recently began working on an IaC project using Bicep, where we're often referencing Azure Verified Modules (AVM) for new modules. During a review of these modules, I noticed that several of them use "preview" API versions for various resources.
My understanding is that AVM modules are intended to be production-ready and fully supported by Microsoft. However, I’m concerned about the use of preview API versions in these modules. Are these modules genuinely production-ready if they rely on preview APIs, or should they be considered less stable?
Examples:
An example; Container App Environments, using Key Vault to store Certificate in relation to Custom Domain - is a preview feature - by just looking at the Bicep module blindly, without looking at the Container App Environment docs, one could start using this feature - as it is implemented in an AVM module that should be safe, while it actually is an preview-feature.
If issues arise with these preview APIs, would Microsoft provide support, or should these modules be limited to non-production environments until stable API versions are available?
Thank you for any input on this!