Study smarter with Fiveable
Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.
Infrastructure as Code (IaC) isn't just a convenience—it's the foundation of modern DevOps practices that you'll be tested on throughout this course. When exam questions ask about automation, repeatability, version control, and scalability, they're really asking whether you understand how teams move from manually clicking through cloud consoles to treating infrastructure like software. These platforms demonstrate core principles like declarative vs. imperative approaches, idempotency, state management, and configuration drift prevention.
Don't fall into the trap of memorizing tool names and syntax details. Instead, focus on understanding what problem each category of tool solves and when you'd choose one approach over another. If an FRQ asks you to design a CI/CD pipeline or explain how to ensure consistent environments across development and production, you need to know which tools handle provisioning versus configuration—and why that distinction matters.
These tools focus on defining the desired end state of your infrastructure rather than the steps to get there. The underlying principle: you describe what you want, and the tool figures out how to make it happen.
Compare: Terraform vs. CloudFormation—both are declarative provisioning tools, but Terraform offers multi-cloud portability while CloudFormation provides deeper AWS-native integration. If an FRQ asks about vendor lock-in versus ecosystem depth, this is your go-to comparison.
These tools handle what happens after infrastructure exists—installing software, managing files, and ensuring systems stay in their desired state. The key principle: idempotency, meaning running the same configuration multiple times produces identical results.
Compare: Ansible vs. Puppet—both ensure configuration consistency, but Ansible's agentless, push-based approach suits ad-hoc tasks and CI/CD pipelines, while Puppet's agent-based, pull model excels at continuous enforcement in large, stable environments.
These tools define how containerized applications run and scale. The principle here: declarative container management that handles scheduling, networking, and self-healing automatically.
docker-compose upCompare: Kubernetes YAML vs. Docker Compose—both use declarative YAML, but Docker Compose targets local development and simple deployments, while Kubernetes handles production-grade orchestration with scaling, self-healing, and distributed workloads. Know when to recommend each.
| Concept | Best Examples |
|---|---|
| Multi-cloud provisioning | Terraform |
| Cloud-native IaC (vendor-specific) | CloudFormation, ARM Templates, Deployment Manager |
| Agentless configuration management | Ansible |
| Agent-based configuration management | Puppet, Chef, SaltStack |
| Declarative syntax (HCL/YAML) | Terraform, Ansible, Kubernetes YAML, Docker Compose |
| Imperative/programmatic approach | Chef (Ruby DSL) |
| Container orchestration | Kubernetes YAML, Docker Compose |
| State file management | Terraform, CloudFormation (stacks) |
Provisioning vs. Configuration: If you need to create a new EC2 instance, which category of tool would you use? If you need to install and configure Nginx on that instance, which category applies?
Compare and Contrast: Both Terraform and AWS CloudFormation are declarative provisioning tools. What's the key trade-off when choosing between them for a new project?
Architecture Differences: Ansible and Puppet both manage configuration, but one is push-based and agentless while the other is pull-based with agents. Which is which, and when would you prefer each approach?
Idempotency in Practice: Why is idempotency critical for configuration management tools? What problems would occur if running a playbook twice produced different results?
FRQ Scenario: Your team needs to set up identical development, staging, and production environments across AWS and Azure. Which IaC tools would you recommend for provisioning, and how would you ensure configuration consistency after the infrastructure is created?