bicep-registry-modules VS AzDocs

We have a separate parameter file for every landing zone instance (our implementation is a bare-bones CAF landing zone, kinda like https://github.com/Azure/bicep-registry-modules/tree/main/modules/lz/sub-vending, which is avaible from bicep public registry), where instance is for example a separate environment (dev/test/prod). This parameter file only represents the configuration, so things like subnets, nsgs and so on, and it has nothing to do with the landing zone implementation as such.

As you point out, it is another layer of abstraction that can make it more complex. Specifically it will add a pain point with the replication of the modules from /ResourceModules to the private repo. (I dont have a good solution for that at the moment) Microsoft has a public container registry (https://github.com/Azure/bicep-registry-modules) that someday may be updated to contain everything in /ResourceModules

Still a work in progress, but the official bicep registry - https://github.com/Azure/bicep-registry-modules

At most larger companies were I worked they provided a Repo which was maintained by a dedicated (small) team. However the responsibility was at the devops teams themselves, we just considered as a open source project, so if you want to add or fix things you could create a Pull request. Actual the last company I worked for made their project real open source: https://github.com/AzDocs/AzDocs

You can use many "prefab", bicep Templates, the one I use, and is maintained by the organization I work for: https://github.com/AzDocs/AzDocs They are mostly based on existing Bicep Templates, but somewhat hardened. I would recommend to use one big Bicep Template, but use a deployment per Resource.