The problem
The platform team supported a large Azure estate for an automotive retailer with dozens of Terraform and infrastructure repos in Azure DevOps. There were source-module repos, landing-zone and network foundations, governance and Microsoft Entra Privileged Identity Management repos, Azure Virtual Desktop work, and workload repos for business applications, data platforms, analytics, and shared platform workloads.
That spread created a platform problem: shared modules had to move fast enough for workload teams, but every module change had to stay compatible with real business-unit deployments. A one-off repo patch or portal repair might unblock a team for a day, but it left the platform harder to operate the next time the same pattern appeared.
The approach
I worked across both sides of the estate: the shared Azure Terraform module source and the workload repos that consumed it. The work was not just writing modules in isolation. It was making each pattern usable in the places that needed it, then moving the corrected version back into the shared source.
In the shared module source, I authored or extended modules around Azure RBAC role assignments, Azure Storage accounts, Azure Key Vault, Azure Cosmos DB, Azure NAT Gateway, hub-and-spoke Azure networking, Azure Data Factory, Azure Cache for Redis, Azure Monitor activity log alerts, Azure Monitor alerting, Azure Application Gateway with Azure Web Application Firewall, Azure Functions, Azure App Service plans, Azure App Service for Linux container web apps, Azure App Service for Windows, Azure virtual machines, naming, and subscription-scoped Azure RBAC. Newer work included an Azure Windows virtual machine module with endpoint agent installation and an Azure App Service for Windows path with deployment slot and .NET Framework support.
The pipeline work mattered as much as the Terraform. Azure DevOps validation ran module changes through apply and destroy checks before they became shared platform code. I updated backend configuration, provider pinning, branch-versus-tag module sourcing, and pipeline parameters so module consumers could test changes through the same path they used to deploy them.
Identity and access were a recurring thread. I worked through Microsoft Entra ID group lookups, group membership, subscription-scoped Azure RBAC, Azure virtual machine ownership, Azure Key Vault roles, Azure Storage account access, and project security groups so access stayed expressed as code instead of being repaired manually after deploys.
The workload work kept the platform honest. Business application workloads needed Azure Application Gateway listener changes, Azure Web Application Firewall policy updates, certificate handling, Azure Private Endpoint resources, Azure Private DNS virtual network links, Azure App Service for Windows web apps, and Azure Monitor action groups. Data and analytics workloads needed Microsoft Entra-backed Azure RBAC, Azure Key Vault access, Azure virtual machine sizing and ownership fixes, and Microsoft Entra app registration work for SSO. Shared platform repos needed Azure Storage account, quota, and access fixes that reflected what was actually running in production.
The outcome
The module platform became more usable because fixes landed where the reuse happened: in the shared source modules and in the workload repos consuming them. Application, networking, Azure Monitor, and Azure RBAC changes moved through reviewable Terraform instead of portal repair work.
The practical result was a cleaner path for business-unit teams. New work could start from the platform modules, validation pipelines, and environment patterns already in git, while fixes from real workloads could be pushed back into shared modules for the next team instead of becoming another local fork.