Platform Engineering and Infrastructure as Code on Microsoft Azure

Azure platform work usually stalls on unresolved decisions rather than on build effort. We resolve them with evidence taken from your own subscriptions.

• Bicep against Terraform, decided. Judged on whether the estate is Azure-only, who maintains the modules, existing Terraform investment and your appetite for protecting state.
• Azure DevOps against GitHub, decided. Compared against how your teams actually work, where repositories, pipelines and boards are already embedded, and what a move would break.
• Activity logs read for portal changes. Azure activity logs used to establish how many resource changes currently arrive outside a pipeline, broken down by subscription and by team.
• Deployed resources reconciled to code. What is unmanaged, duplicated or orphaned listed explicitly, with an owner assigned to each item rather than a total reported.
• Structure and tagging checked first. Management group and subscription structure, naming, tagging and existing Azure Policy assignments reviewed against what the pipeline will need to enforce.
• Sequenced plan with a commercial case. Effort, dependencies, cost and the measures that will define success, ordered so the first increment is worth having on its own.

We build the module library, the pipelines and the runtime foundations together, proving each on a real workload before it becomes the standard.

• A published module library. Versioned Bicep or Terraform modules published to a registry, with pinned versions and a tested upgrade path for the teams consuming them.
• Remote state locked and recoverable. Wherever Terraform is used, state is configured with locking, restricted access and a documented, rehearsed recovery procedure.
• What-if or plan before approval. Pipelines in Azure Pipelines or GitHub Actions run what-if or plan, publish the output for review, gate on environment approval, then apply.
• Registry hardened, deployed by digest. Azure Container Registry with tag locking, retention rules and Defender for Cloud image scanning, then deployment to AKS or Azure Container Apps by digest rather than by floating tag.
• Azure Policy shipped with the module. Policy defined as code alongside the infrastructure modules, so a control arrives with the resource pattern it governs instead of turning up months later.
• Proven by an empty-subscription rebuild. A non-production environment rebuilt into an empty subscription straight from the repository, with the elapsed time recorded as a baseline.

Pipeline identity and secret handling are where Azure delivery platforms most often carry avoidable risk. We remove the standing credentials first, then tighten scope.

• Federated identity, no stored secret. Pipelines moved to Microsoft Entra workload identity federation, so no client secret or certificate is held in Azure DevOps or GitHub at all.
• Deployment identity scoped down. Each identity limited to the subscription, resource group and role it needs, with inherited owner assignments left over from initial setup removed.
• Key Vault with rotation you own. Secrets, keys and certificates stored in Azure Key Vault and referenced at run time, with near-expiry events subscribed and the rotation the vault does not perform scheduled.
• Policy proven before it is enforced. Azure Policy assigned at management group level with deny and audit effects agreed in advance, each proven in a sandbox subscription before promotion.
• Production needs a second person. Branch protection, mandatory review and protected environment approvals, so a release to production is never a single pair of hands.
• Compliance mapped to your framework. Azure Policy compliance and pipeline controls mapped to what your customers ask about, such as the Essential Eight, to support your assurance work. We help you align to a framework rather than certify against one.

The platform succeeds when a delivery team can create a new service without asking permission and without asking how. We build that path, then teach it.

• A template repository to clone. Pipeline, module references, policy checks, Azure Container Registry access and Key Vault wiring already connected, so a new service starts deployable.
• First pipelines built in pairs. The first two or three service pipelines written with your engineers, so the patterns are learned during the build rather than read afterwards.
• Approvers taught to read a plan. Working sessions on what-if and plan output, because an approval given by someone who cannot read the diff is a control on paper only.
• Runbooks for Azure-specific failures. Failed deployments, stuck state locks, rollback in Azure Container Apps and AKS, and a revoked or expired federated credential.
• Hand-over by doing, while we watch. Your team performs a production deployment and a subscription rebuild while we observe and only advise.
• Pipeline share tracked, not asserted. The proportion of Azure resource changes arriving through the pipeline reported against the baseline captured during assessment.

Under an agreed managed scope we keep the Azure platform current, because version pins, policy exemptions and cluster support windows all expire on somebody else's schedule.

• AKS support windows tracked. Version support windows, node image releases and add-on compatibility watched, with upgrades scheduled before a version leaves standard support.
• Versions kept current and tested. Bicep, Terraform provider, module and container base image versions updated on a cadence and tested in a lower environment before production.
• Drift detected across subscriptions. Scheduled drift detection, with each change either returned to code or recorded as an accepted exception carrying a named owner.
• Policy exemptions closed off. Azure Policy compliance and exemptions reviewed monthly, closing the temporary exemptions that have outlived the reason they were granted.
• Pipeline failures acted on. Duration and failure rate tracked in Azure DevOps pipeline analytics or GitHub Actions run history, with Application Insights used to catch releases that degraded the workload after a successful deploy.
• Cost reported by environment. Azure spend broken down by environment and workload, including non-production resources that could be scheduled off, resized or retired.