Scaling Azure Bicep beyond small projects requires treating repository structure as an operating model decision, not just a technical one. Key patterns include separating platform-owned foundations (management groups, policy, networking) from product-team workloads using a mono-repo for the platform and separate repos per product team. Modules should be designed as APIs with opinionated defaults, and orchestration templates should be split by lifecycle and Azure scope. Parameter files serve as environment contracts rather than scattered conditionals. Azure Landing Zones implementation follows layered deployment (management groups → policy → connectivity → identity → workloads), with Azure Verified Modules recommended for composability. CI/CD pipelines are treated as first-class architecture components, requiring what-if analysis, ordered stages, and approval gates for sensitive scopes. The post also covers when to use Bicep vs. Terraform, Pulumi, or scripts.
