Terraform vs CloudFormation: What is the Difference?
Compare Terraform and CloudFormation on scope, state management, and language, and learn when to choose each — DevOps interview guide.
Expected Interview Answer
Terraform is a cloud-agnostic, open-source infrastructure-as-code tool by HashiCorp that manages resources across many providers using its own HCL language and external state, while CloudFormation is AWS’s native IaC service that manages only AWS resources using JSON or YAML templates with state tracked internally by AWS.
Because Terraform uses a provider plugin model, the same workflow and language can manage AWS, Azure, GCP, Kubernetes, Datadog, and hundreds of other providers in one configuration, which matters heavily for multi-cloud or hybrid organizations. CloudFormation, by contrast, is deeply integrated with AWS: it understands AWS service quotas and rollback behavior natively, requires no external state file since AWS stores and manages the stack state for you, and gets first-day support for new AWS features before third-party providers catch up. Terraform’s plan step gives an explicit preview of every change before apply, and its module ecosystem via the public registry is broader than CloudFormation’s nested-stack and StackSets approach. Teams already fully committed to AWS with tight IAM-based governance often lean CloudFormation or the higher-level CDK, while teams needing multi-cloud consistency, faster access to community modules, or a single tool across heterogeneous infrastructure typically choose Terraform.
- Terraform: single tool and language across many cloud providers
- CloudFormation: no external state file to manage, natively AWS-integrated
- Terraform: large public module registry accelerates reuse
- CloudFormation: automatic rollback on stack failure built into AWS
AI Mentor Explanation
Terraform is like a universal coaching certification recognized across cricket boards worldwide — the same coaching license lets you train teams in Australia, India, or England using one consistent syllabus. CloudFormation is like a certification issued and only recognized by one specific national board, deeply tailored to that board’s exact rules and pitch conditions, with the board itself keeping the official player registry for you. A coach wanting to work across multiple countries picks the universal license; a coach committed entirely to one board’s system benefits from that board’s native tooling and support. Neither is wrong — it depends on whether you are coaching in one system or many.
Step-by-Step Explanation
Step 1
Choose the scope
Decide whether infrastructure spans multiple clouds/providers (favors Terraform) or is AWS-only (favors CloudFormation).
Step 2
Author the configuration
Terraform uses HCL across providers; CloudFormation uses JSON/YAML templates scoped to AWS resource types.
Step 3
Preview and apply
Terraform runs an explicit plan before apply; CloudFormation creates/updates a stack with AWS-managed rollback on failure.
Step 4
Track state
Terraform requires an external state file/backend; CloudFormation state is tracked internally by AWS per stack.
What Interviewer Expects
- Clear distinction: multi-cloud/provider-agnostic vs AWS-native scope
- Understanding of state management differences (external file vs AWS-managed)
- Awareness of language differences: HCL vs JSON/YAML
- Ability to give a reasoned recommendation based on organizational context
Common Mistakes
- Claiming one tool is strictly superior instead of discussing tradeoffs
- Forgetting CloudFormation has built-in automatic rollback on stack failure
- Not mentioning Terraform needs external state management and locking
- Ignoring that CDK can generate CloudFormation, blurring the comparison
Best Answer (HR Friendly)
“Terraform is a tool that works across many cloud providers using one common language, which is great if we operate across AWS, Azure, or GCP. CloudFormation is AWS’s own native tool, deeply integrated with AWS services and managed entirely by AWS, which is a strong choice if we are fully committed to AWS and want automatic rollback and no external state file to maintain.”
Code Example
# Terraform (HCL) - main.tf
# resource “aws_s3_bucket” "data" {
# bucket = "my-app-data-bucket"
# }
# CloudFormation (YAML) - template.yaml
Resources:
DataBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: my-app-data-bucketFollow-up Questions
- How does state management differ between Terraform and CloudFormation?
- What is AWS CDK and how does it relate to CloudFormation?
- How would you migrate an existing CloudFormation stack to Terraform?
- What happens automatically when a CloudFormation stack update fails?
MCQ Practice
1. What is the main scope difference between Terraform and CloudFormation?
Terraform uses a provider plugin model spanning many clouds and services, while CloudFormation is scoped entirely to AWS.
2. How does CloudFormation manage state compared to Terraform?
AWS manages CloudFormation stack state internally, whereas Terraform requires an explicit state file or remote backend.
3. What happens by default when a CloudFormation stack update fails?
CloudFormation has built-in automatic rollback behavior on failed stack updates, native to the AWS service.
Flash Cards
What language does Terraform use? — HashiCorp Configuration Language (HCL), across many cloud providers.
What language does CloudFormation use? — JSON or YAML templates, scoped to AWS resources only.
Who manages state in CloudFormation? — AWS manages stack state internally; no external state file is needed.
Who manages state in Terraform? — The user, via a local file or remote backend such as S3 with locking.