4.1.5. Third-Party IaC: Terraform and Git Integration
š” First Principle: AWS-native tools (CloudFormation, CDK) are optimized for AWS but don't help you when half your infrastructure is on Azure or GCP. Terraform is the IaC tool of choice for multi-cloud organizations because it uses the same workflow and language (HCL) regardless of which cloud provider you're provisioning. The SOA-C03 exam recognizes that CloudOps engineers increasingly operate in Terraform environments.
Terraform Core Concepts:
| Concept | Description |
|---|---|
| Provider | Plugin that knows how to talk to an API (e.g., hashicorp/aws) |
| Resource | An infrastructure object to be managed (e.g., aws_instance) |
| Module | Reusable group of resources with inputs and outputs |
| State file | terraform.tfstate ā tracks what Terraform has provisioned |
| Plan | Preview of changes (terraform plan) |
| Apply | Execute the plan (terraform apply) |
Terraform Workflow:
| Command | Effect |
|---|---|
terraform init | Download providers, initialize backend |
terraform plan | Preview changes (what will be created/modified/destroyed) |
terraform apply | Execute the changes |
terraform destroy | Destroy all managed resources |
terraform state | Inspect and manipulate state |
State Management: Terraform tracks provisioned resources in a state file. In team environments, state must be stored remotely and locked to prevent concurrent modifications. For AWS environments, the standard backend is:
- S3 for state storage (versioned bucket for history)
- DynamoDB for state locking (prevents simultaneous applies)
Git Integration: Infrastructure as code in Terraform should be version-controlled in Git, following GitOps practices:
- Infrastructure changes proposed as pull requests
- Automated
terraform planruns on PRs to show change preview - Merges to main trigger
terraform apply - State is always the source of truth for what's actually deployed
Infrastructure Drift: When someone makes a manual change in the AWS console that Terraform doesn't know about, the state file no longer matches reality. terraform plan will show this as a change (Terraform wants to revert the manual change). The fix is either: update the Terraform code to match the manual change, or let Terraform revert it.
ā ļø Exam Trap: The SOA-C03 exam is unlikely to ask deep Terraform syntax questions ā that's beyond scope. It will test conceptual understanding: Terraform uses state files, state should be in S3+DynamoDB for teams, terraform plan is non-destructive, and Terraform can manage AWS resources alongside CloudFormation stacks (they don't conflict as long as they don't manage the same resources).
Reflection Question: A team uses Terraform to manage their AWS VPC and EC2 instances. A network engineer manually added an inbound rule to a security group via the console. What happens the next time terraform plan is run, and what are the two ways to resolve the state drift?
