CloudFormation vs Terraform awareness in AWS - Visual Side-by-Side Comparison

Process Flow - CloudFormation vs Terraform awareness

Write Infrastructure Code

↓

CloudFormation

↓

Upload Template

↓

Create/Update Stack

↓

AWS Manages State

↓

Resources Created

↓

Infrastructure Ready

Shows the choice between CloudFormation and Terraform, their deployment steps, and how state is managed.

Execution Sample

AWS

1. Write CloudFormation YAML template
2. Upload template to AWS
3. AWS creates stack and resources

Deploy infrastructure using CloudFormation by uploading a template and letting AWS manage the deployment.

Process Table

Step	Action	Tool	State Management	Result
1	Write infrastructure code	Both	Local file	Code ready
2	Choose tool	Decision	N/A	Select CloudFormation or Terraform
3	Upload template	CloudFormation	AWS manages	Template uploaded
4	Init and plan	Terraform	User manages	Plan created
5	Create or update stack	CloudFormation	AWS manages	Stack created/updated
6	Apply changes	Terraform	User manages	Resources created
7	Manage state	CloudFormation	AWS manages	State stored in AWS
8	Manage state	Terraform	User manages	State stored locally or remote
9	Infrastructure ready	Both	N/A	Resources available
10	Exit	Both	N/A	Deployment complete

💡 Deployment completes after resources are created and state is managed.

Status Tracker

Variable	Start	After Step 3	After Step 5	After Step 6	Final
Infrastructure Code	Not written	Written	Written	Written	Written
Template Uploaded	No	Yes	Yes	Yes	Yes
Stack Created	No	No	Yes	Yes	Yes
Plan Created	No	No	No	Yes	Yes
Resources Created	No	No	Yes	Yes	Yes
State Location	None	None	AWS	User	User or AWS

Key Moments - 3 Insights

Why does CloudFormation manage state automatically but Terraform requires user management?

CloudFormation stores state inside AWS as part of the stack, so users don't handle it directly (see steps 7 and 8 in execution_table). Terraform stores state files locally or remotely, so users must manage them.

What happens after uploading a CloudFormation template?

AWS creates or updates the stack automatically, managing resources and state (step 5 and 7 in execution_table). This differs from Terraform which requires a separate apply step.

Why is there a planning step in Terraform but not in CloudFormation?

Terraform's plan step (step 4) shows changes before applying, giving users control. CloudFormation applies changes directly after upload, so no separate plan step exists.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does Terraform create resources?

A Step 3

B Step 6

C Step 5

D Step 7

💡 Hint

Check the 'Action' and 'Tool' columns for Terraform resource creation.

According to variable_tracker, where is the state stored after step 7 for CloudFormation?

A Locally on user machine

B Not stored

C In AWS managed service

D In Terraform Cloud

💡 Hint

Look at 'State Location' variable after step 7.

If you skip the plan step in Terraform, what changes in the execution_table?

A Step 4 would be missing

B Step 3 would be missing

C Step 6 would be missing

D Step 5 would be missing

💡 Hint

Plan step is step 4 in execution_table.

Concept Snapshot

CloudFormation and Terraform both deploy infrastructure as code.
CloudFormation uses AWS templates and manages state automatically.
Terraform uses its own language, requires init, plan, and apply steps.
Terraform state is managed by the user locally or remotely.
CloudFormation stacks are managed fully by AWS.
Choose based on control needs and environment.

Full Transcript

This visual execution compares CloudFormation and Terraform deployment flows. Both start by writing infrastructure code. Then you choose the tool. CloudFormation requires uploading a template to AWS, which manages the stack and state automatically. Terraform requires initialization and planning steps before applying changes, with the user managing state files. The execution table shows each step, the tool involved, how state is managed, and the result. Variable tracking shows how code, templates, stacks, plans, resources, and state locations change over time. Key moments clarify why CloudFormation manages state automatically, the role of the plan step in Terraform, and what happens after uploading a CloudFormation template. The quiz tests understanding of when resources are created, where state is stored, and the effect of skipping Terraform's plan step. The snapshot summarizes key differences and usage notes.

Practice

1. Which statement best describes the main difference between AWS CloudFormation and Terraform?

easy

A. CloudFormation works only with AWS, while Terraform supports multiple cloud providers.

B. Terraform is only for AWS, CloudFormation supports all clouds.

C. Both tools only work with AWS services.

D. CloudFormation supports multiple clouds, Terraform is AWS-only.

Solution

1. Step 1: Understand CloudFormation scope

   CloudFormation is designed specifically for AWS and manages AWS resources only.

2. Step 2: Understand Terraform scope

   Terraform supports many cloud providers like AWS, Azure, Google Cloud, and more.

3. Final Answer:

   CloudFormation works only with AWS, while Terraform supports multiple cloud providers. -> Option A

4. Quick Check:

   CloudFormation = AWS-only, Terraform = multi-cloud [OK]

Hint: CloudFormation = AWS-only; Terraform = many clouds [OK]

Common Mistakes:

• Thinking Terraform only works with AWS
• Believing CloudFormation supports multiple clouds
• Confusing both as identical tools

2. Which of the following is the correct way to define a resource in AWS CloudFormation?

easy

A. resource "aws_ec2_instance" "web" {}

B. resource "aws_instance" "web" {}

C. AWS::EC2::Instance:

D. resource "ec2_instance" "web" {}

Solution

1. Step 1: Identify CloudFormation syntax

   CloudFormation uses YAML or JSON with resource types like 'AWS::EC2::Instance'.

2. Step 2: Recognize Terraform syntax

   Terraform uses 'resource "aws_instance" "name" {}'.

3. Final Answer:

   CloudFormation resource types use 'AWS::Service::Resource' format. -> Option C

4. Quick Check:

   CloudFormation uses AWS:: notation [OK]

Hint: CloudFormation uses AWS::Service::Resource format [OK]

Common Mistakes:

• Confusing Terraform resource syntax with CloudFormation
• Using Terraform resource blocks in CloudFormation
• Misnaming resource types

3. Given this Terraform snippet:

resource "aws_s3_bucket" "bucket" {
  bucket = "my-unique-bucket"
  acl    = "private"
}

What will happen when you run terraform apply?

medium

A. Creates a public S3 bucket named 'my-unique-bucket' in AWS.

B. Fails because bucket names cannot be unique.

C. Throws a syntax error due to missing region.

D. Creates a private S3 bucket named 'my-unique-bucket' in AWS.

Solution

1. Step 1: Analyze Terraform resource block

   The resource defines an AWS S3 bucket with name 'my-unique-bucket' and ACL set to 'private'.

2. Step 2: Understand Terraform apply behavior

   Terraform will create the bucket with the specified name and private access control.

3. Final Answer:

   Creates a private S3 bucket named 'my-unique-bucket' in AWS. -> Option D

4. Quick Check:

   ACL 'private' means private bucket [OK]

Hint: ACL 'private' means bucket is private [OK]

Common Mistakes:

• Assuming default ACL is public
• Expecting syntax error without region (region is set elsewhere)
• Thinking bucket names cannot be unique (they must be unique)

4. You wrote this CloudFormation snippet:

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-bucket
      AccessControl: PublicRead

But deployment fails with an error about bucket name. What is the likely cause?

medium

A. BucketName must be globally unique and 'my-bucket' is already taken.

B. AccessControl property is invalid in CloudFormation.

C. Resource type AWS::S3::Bucket is incorrect.

D. BucketName cannot be specified in CloudFormation.

Solution

1. Step 1: Understand S3 bucket naming rules

   S3 bucket names must be globally unique across all AWS accounts.

2. Step 2: Analyze error cause

   If 'my-bucket' is already used, deployment fails due to name conflict.

3. Final Answer:

   BucketName must be globally unique and 'my-bucket' is already taken. -> Option A

4. Quick Check:

   S3 bucket names are global and unique [OK]

Hint: S3 bucket names must be globally unique [OK]

Common Mistakes:

• Thinking AccessControl is invalid (it is valid)
• Assuming resource type is wrong
• Believing BucketName is optional or disallowed

5. Your team wants to manage infrastructure across AWS, Azure, and Google Cloud with one tool. Which approach is best?

hard

A. Use AWS CloudFormation for all clouds to keep consistency.

B. Use Terraform because it supports multiple cloud providers.

C. Use separate CloudFormation stacks for each cloud provider.

D. Use manual console setup for each cloud to avoid tool complexity.

Solution

1. Step 1: Identify tool cloud support

   CloudFormation only supports AWS, so it cannot manage Azure or Google Cloud.

2. Step 2: Choose tool for multi-cloud management

   Terraform supports AWS, Azure, Google Cloud, and others in one tool.

3. Step 3: Evaluate other options

   Separate CloudFormation stacks or manual setup increase complexity and reduce automation benefits.

4. Final Answer:

   Use Terraform because it supports multiple cloud providers. -> Option B

5. Quick Check:

   Terraform = multi-cloud support [OK]

Hint: Terraform supports many clouds; CloudFormation is AWS-only [OK]

Common Mistakes:

• Assuming CloudFormation works outside AWS
• Thinking manual setup is simpler for multi-cloud
• Believing separate CloudFormation stacks can manage non-AWS clouds