Cloud Provider IaC Comparison Exercises

1 / 5

An AWS-focused team says: "We use CloudFormation because it has native integration with all AWS services on day 1."

What is the main trade-off of choosing CloudFormation over Terraform for this team?

CloudFormation and Terraform serve overlapping needs with distinct trade-off profiles:

Dimension	CloudFormation	Terraform
Provider support	AWS-only; new services supported on day 1	Multi-cloud; community provider may lag new AWS services
State management	AWS manages state — no .tfstate to secure	Team manages state file (S3 + DynamoDB pattern)
Change preview	Change Sets — review before deploying	`terraform plan` — equivalent preview mechanism
Lock-in risk	High — templates are AWS-specific	Low — HCL patterns portable across providers
Drift detection	Built-in CloudFormation drift detection	`terraform refresh` + plan comparison

Key vocabulary: provider lock-in, Change Set, day-2 operations (ongoing management after initial deployment).

2 / 5

A team is evaluating Pulumi as an alternative to Terraform. What is the key differentiator of Pulumi compared to Terraform and CloudFormation?

Pulumi's core differentiator is using real programming languages rather than a domain-specific language like HCL or YAML.

Capability	HCL (Terraform)	Pulumi (TypeScript/Python)
Loops	`for_each`, `count`	Native `for` loops
Conditionals	Ternary expressions only	Full `if/else`, `switch`
Unit testing	Limited (Terratest in Go)	Standard language test frameworks (Jest, pytest)
Type safety	Limited HCL type system	Full language type system + IDE autocomplete

Trade-offs: Pulumi's ecosystem is smaller than Terraform's; the learning curve is higher for teams without strong programming backgrounds. Key vocabulary: SDK-based IaC, programmatic infrastructure, Pulumi state backend.

3 / 5

An engineer says: "We're using AWS CDK to define our infrastructure."

What does CDK stand for and how does it relate to CloudFormation?

AWS CDK = Cloud Development Kit. The CDK acts as a higher-level abstraction over CloudFormation:

Write infrastructure in a real programming language using CDK construct libraries
cdk synth — synthesises the code into a CloudFormation template (JSON/YAML)
cdk deploy — deploys the synthesised CloudFormation template to AWS

Construct level	Description	Example
L1 (low)	1:1 mapping to CloudFormation resource	`CfnBucket`
L2 (high)	Opinionated abstraction with sensible defaults	`s3.Bucket` with encryption by default
L3 / pattern	Multi-resource architecture pattern	`ApplicationLoadBalancedFargateService`

4 / 5

A team migrating from Ansible to Terraform for cloud provisioning is told: "Ansible is a configuration management tool, not a provisioning tool."

What is the functional distinction between provisioning and configuration management in an IaC context?

These are complementary tool categories, not competing ones — most mature infrastructure teams use both:

Layer	Tool category	Examples	Typical tasks
Infrastructure	Provisioning	Terraform, CloudFormation, Pulumi	Create EC2s, VPCs, RDS instances, IAM roles
OS & software	Configuration management	Ansible, Chef, Puppet, Salt	Install nginx, configure systemd units, manage users

Golden AMI — an alternative pattern: bake all configuration into a pre-built AMI image at build time, removing the need for runtime config management
Immutable vs. mutable infrastructure — immutable: replace servers rather than configuring live ones; mutable: configure running servers in place

5 / 5

An engineer says: "We use Terragrunt to manage multiple Terraform modules across 20 environments."

What problem does Terragrunt solve that vanilla Terraform does not?

Terragrunt is a thin wrapper around Terraform that adds DRY patterns for managing large multi-module, multi-environment repositories.

Terragrunt feature	Problem it solves
Inherited backend config	Backend S3 bucket/DynamoDB table defined once in root `terragrunt.hcl`, inherited by all child modules
dependency blocks	Declare that module B depends on module A's outputs — Terragrunt enforces correct apply order
run-all	Apply or plan all modules in a directory tree with one command, respecting dependency order
Environment hierarchy	`envs/prod/terragrunt.hcl` inherits from root, overrides only environment-specific values

Key vocabulary: DRY terraform, terragrunt.hcl, dependency ordering, run-all apply.