bicep-registry-modules VS PSRule

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

As for the actual usage of Private Registry, we have two separate Azure DevOps pipelines; one for pull requests, that generates a simple markdown doc for the parametrs and runs psrule scan on the module(s). Another pipeline then pushes the modules to the private registry with az bicep publish.