Context: Small company with a dev team of ~10 to 15 people. 1 "infra" guy. 4 Data/ML guys. The dat/ML guys would like to have their own Pulumi code in their own repo. How can we governance this from the Infra PoV? Azure policies? Creating Pulumi libraries/modules?

Yes, I think the “infra” chappy should build modules as regards “infra” topics (networking, logging, etc) for the data team to download. At least that was the advice I got from an Azure evangelist/employee at a recent Meetup I attended here in Brighton, UK.

We're a consultancy working with multiple clients but the challenge is pretty much similar where we want to keep things standardized and be able to utilize same IaC code across multiple clients/teams. This is what we decided to do...: • Single IaC library repo with reusable components and workloads ◦ Components -> Building blocks with sane/secure defaults – an abstraction of a single cloud resource and it’s closest dependencies, examples: ▪︎ Container Registry ▪︎ Log Workspace ▪︎ SQL Database ▪︎ Container App ◦ Workloads -> Deployable set of 2 or more components –configurable templates for common infra use cases ▪︎ Workloads are configured via Pulumi Stack configurations. Here you can apply “guardrails” or validation on what configuration parameters are accepted. ▪︎ Examples: • App Zone -> Could consist all the components mentioned above, with authentication/logging integrated deployable as an artifact/stack • Networking -> Set of vnet/subnet/nsg/vpn components ◦ IaC library is versioned and published for downstream usage. Breaking changes should be avoided but if downstream projects pin a certain version they don’t break and can integrate upstream changes/improvements • In downstream projects (which can live in other repositories) ◦ Simple Pulumi programs which only consists of: ▪︎ Dependency on the IaC library ▪︎ Pulumi Stack configurations ▪︎ Basically executes a workload’s deploy() interface and provides a stack config ▪︎ Adding standalone code / resource configurations to these projects should be avoided unless there is a very specific use case which you don’t want to implement as a standard feature in the IaC library’s workload template