Terraform will click immediately if you think of it as migrations for infrastructure. You write a declarative description of what you want -- a VPC, a database, a load balancer -- and Terraform figures out how to get from the current state to the desired state. State files are your schema.rb. terraform plan is your dry-run migration. terraform apply is rails db:migrate. The mental model maps almost perfectly.
The key insight that takes people too long to learn: Terraform state is sacred. Lose the state file and Terraform no longer knows what it manages. Corrupt it and you are in for a bad weekend. Remote state backends (S3 + DynamoDB locking) are not optional for teams. Treat state like you treat your production database -- back it up, lock it, and never edit it by hand.
Ansible is the imperative counterpart. Where Terraform says "I want three servers," Ansible says "on each server, do these things." Playbooks feel like Rake tasks for servers -- step-by-step instructions executed in order. The two are complementary, not competing. Terraform provisions infrastructure, Ansible configures it. In practice, many teams use Terraform for cloud resources and Docker/Packer for machine configuration, which makes Ansible less essential than it was five years ago. But understanding both paradigms is valuable.
GitOps with ArgoCD is the pattern that ties this together. Your infrastructure definitions live in Git. A change to the repo triggers a reconciliation loop that makes the real infrastructure match the repo. It is CI/CD for infrastructure, and it is elegant once you grok the feedback loop. Pull-based deployment instead of push-based. The cluster watches the repo, not the other way around.
This module transforms you from someone who clicks buttons in the AWS console to someone who can reconstruct an entire environment from a Git repository. That is a staff-level capability.