Best Practice
Keep Terraform apply separated from application deployment stages. Provision infrastructure first, then let AKS and Helm release workflows consume the resulting platform.
Terraform in CI/CD
Integrate Terraform with Azure DevOps and GitHub Actions so infrastructure changes follow the same safe, reviewable delivery model as application code.
🧒 Simple Explanation (ELI5)
Instead of one engineer running Terraform from a laptop, CI/CD lets the team use shared automation. That means everyone can review the plan, approvals can be enforced, and production changes are traceable.
🤔 Why Do We Need It?
- Shared environments need auditability and approvals.
- Automation makes plan and apply consistent.
- Pipelines integrate Terraform into the same delivery flow as applications.
🔧 Technical Explanation
A mature Terraform pipeline usually separates validation, plan, and apply. Plan runs on pull requests. Apply is gated and often uses the reviewed plan artifact. Environment protections help prevent accidental production mutation.
yaml
trigger:
- main
stages:
- stage: validate
jobs:
- job: terraform_validate
steps:
- script: terraform fmt -check
- script: terraform init -backend=false
- script: terraform validate
- stage: plan
jobs:
- job: terraform_plan
steps:
- script: terraform init
- script: terraform plan -out=tfplan
- stage: apply
condition: succeeded()
jobs:
- deployment: terraform_apply
environment: prod
strategy:
runOnce:
deploy:
steps:
- script: terraform apply tfplan| Pipeline Stage | Goal |
|---|---|
| Validate | Catch formatting and configuration issues early |
| Plan | Show intended changes for review |
| Apply | Execute approved infrastructure changes |
💡
🌍 Real-World Use Case
An Azure DevOps pipeline runs Terraform for the network and AKS platform. After approval, it applies infrastructure changes and publishes outputs. A later pipeline stage or separate pipeline deploys Kubernetes workloads into the newly updated cluster using Helm.
🛠️ Hands-on
Design a Safe Pipeline
- Run
fmtandvalidateon every change. - Generate plan artifacts for review.
- Protect apply with environment approvals.
- Use dedicated identities and remote state in the pipeline context.
🐛 Debugging Scenario
Problem: The pipeline works locally but fails in CI.
- Compare authentication methods and environment variables.
- Check whether backend configuration is available in the pipeline.
- Verify the pipeline agent has the correct Terraform and provider versions.
⚠️
Pipeline Pitfall
Local success often relies on hidden context like cached credentials or a developer’s Azure CLI session. CI does not have that safety net.
📋 Interview Questions
Beginner
Why run Terraform in CI/CD?
To make infrastructure changes reviewable, auditable, consistent, and safer than one-off local execution.
What stages are common in a Terraform pipeline?
Validate, plan, and apply are the most common stages.
Why protect apply with approvals?
Because apply changes real infrastructure and may affect production availability or cost.
What should a PR pipeline usually do for Terraform?
Run formatting, validation, and plan so reviewers can inspect infrastructure impact before merge.
Can Azure DevOps and GitHub Actions both run Terraform well?
Yes. The important part is the workflow design, identity, state management, and approvals rather than the brand of CI system.
Intermediate
Why apply the saved plan instead of rerunning plan during apply?
Because it reduces the chance that the reviewed intent changes between review and execution.
What CI/CD pattern helps separate infrastructure and application delivery?
Use one workflow to manage Terraform infrastructure changes and another to deploy application workloads such as Helm charts into AKS.
Why is remote state essential in pipelines?
Because pipelines need a shared source of truth that is not tied to any one machine and supports safe locking and consistency.
How should pipeline identities differ across environments?
They should reflect environment scope and least privilege so dev automation does not implicitly control production.
How does this lesson connect to Azure DevOps and GitHub Actions modules?
Those modules show the CI/CD platforms in depth, while this lesson focuses specifically on how Terraform should behave inside them.
Scenario-Based
A team wants developers to run production applies manually because it feels faster. What is your stance?
I would push back. Speed without control is a weak tradeoff for infrastructure. Approved automation is usually the better operating model.
A pipeline plan looks fine in dev but disastrous in prod. What do you inspect?
I inspect environment-specific variables, backend key selection, provider credentials, and differences in live infrastructure or imported resources.
Why should Terraform outputs feed later deployment jobs carefully?
Because downstream jobs depend on those outputs as contracts. Unstable or excessive outputs create brittle automation.
How would you explain the plan stage to a non-technical approver?
It is the preview of the infrastructure change before anything is actually modified.
What is a healthy sign of a mature Terraform delivery workflow?
Infrastructure changes are reviewed, approved, reproducible, environment-aware, and separate from application release churn.
🧾 Summary
Terraform belongs in CI/CD because infrastructure changes should be as disciplined as application releases. Good pipelines make Terraform safer, more reviewable, and easier to operate at scale.