Azure Platform Engineering¶

Platform engineering is the discipline of building the shared foundation that workload teams build on — the management group hierarchy, subscription factory, identity model, and shared services that make it possible for development teams to operate quickly and safely.

What the platform team owns¶

The platform team is responsible for the infrastructure that every other team depends on. This is not application code — it is the foundation layer that provides governance, security boundaries, networking, and identity to workload teams.

Governance & structure

Management group hierarchy aligned to the Microsoft CAF enterprise-scale pattern
Azure Policy assignments at management group scope to enforce organisational standards
Subscription lifecycle — creation, naming, placement, and decommissioning

Identity & access

Entra ID security groups for platform-level access (engineers, FinOps, read-only)
Per-subscription RBAC groups provisioned automatically as part of subscription vending
Federated OIDC credentials for all Terraform pipelines — no secrets stored anywhere

Shared services (in progress)

Hub networking — VNets, ExpressRoute, DNS, firewalls
Central logging — Log Analytics workspace
Budget alerts per subscription

How it is built¶

Everything the platform team manages is defined in code and deployed via GitLab CI/CD pipelines using Terraform. There are no manual clicks in the Azure Portal for platform resources.

graph TD
    SUB["azure-subscriptions<br/>sp-terraform-azure-subscriptions"]
    MG["azure-management-groups<br/>sp-terraform-azure-management-groups"]
    ID["azure-platform-identity<br/>sp-terraform-azure-platform-identity"]

    SUB --> S["Subscription creation"]
    SUB --> SA["State storage accounts"]
    SUB --> BS["Bootstrap: SP, OIDC, RBAC groups"]
    SUB --> GP["GitLab deployment projects"]

    MG --> H["Management group hierarchy"]
    MG --> RP["MG role assignments"]

    ID --> GRP["Platform Entra groups"]
    ID --> MBR["Group membership"]
    ID --> MRA["Management group RBAC"]
    ID --> NES["Nest platform groups into subscription groups"]

Each deployment project has its own service principal with scoped permissions — the platform team's Terraform pipelines can only touch what they need to touch.

Design principles¶

Everything in code. No resource exists without a Terraform source. If it cannot be version-controlled, it should not be created.

Least privilege. Every service principal has the minimum permissions needed. Roles are scoped as narrowly as possible — container-level for state, subscription-level for workload deployment, management-group-level for platform governance.

Separation of concerns. Management group hierarchy, subscription vending, and identity management are three separate deployments with three separate service principals. A credential compromise in one cannot affect the others.

Predictable structure. Every subscription gets the same RBAC group structure, the same state storage pattern, and the same pipeline scaffold. Workload teams know what to expect before they write a single line of code.

CAF alignment. The hierarchy, naming conventions, and governance model follow the Microsoft Cloud Adoption Framework enterprise-scale architecture — proven patterns rather than bespoke designs.