CI/CD for application code is well understood. Applying the same principles to infrastructure code, automatic testing, staged promotion, and deployment automation, is the discipline that cloud-native operations requires.
The infrastructure pipeline
An infrastructure CI/CD pipeline: lint and validate (terraform validate, tflint, checkov) on every PR, plan in a staging environment and post the plan as a PR comment for review, apply to staging on merge to main, automated smoke tests, manual approval gate, apply to production. The pipeline ensures: no unreviewed changes reach production, plan diffs are visible before apply, staging provides a preview of production changes.
Environment promotion
Infrastructure changes flow through environments in the same way application changes do: dev, staging, production. The same Terraform module is deployed to each environment with environment-specific variable files. Environment promotion is controlled by the pipeline: a successful staging deployment (with automated smoke tests passing) triggers the production deployment pending manual approval.
Drift detection
Infrastructure drift (manual changes to cloud resources outside the IaC pipeline) is detected by running terraform plan against production environments on a schedule and alerting if the plan shows changes. CloudTrail (AWS) and Azure Activity Log track manual API changes to cloud resources. Reconciling drift requires either updating the Terraform state to match reality (terraform import) or reverting the manual change.
Secrets in the pipeline
CI/CD pipelines for infrastructure need cloud credentials to deploy. The pattern: use federated credentials (OIDC) instead of long-lived service principal secrets, the CI/CD platform authenticates to Azure or AWS using its own identity (GitHub Actions with Azure Workload Identity, GitLab with AWS OIDC). Federated credentials do not expire and are not secrets that can be leaked from the pipeline configuration.