If you are new to AWS, the phrase "manage infrastructure as code" might sound abstract. This guide explains what CloudFormation is, why it exists, and how it works — using everyday analogies so anyone can understand.
What is CloudFormation?
Think of building a house. No experienced builder starts stacking bricks without a blueprint first. The blueprint tells everyone where the rooms go, where the doors are, and allows you to build identical houses from the same design.
CloudFormation is the blueprint for your AWS infrastructure. You write a template file that describes everything you want — EC2 servers, S3 storage buckets, databases, networking rules — and CloudFormation reads that file and automatically creates all those resources for you.
This is what IaC (Infrastructure as Code) means: instead of clicking around in the AWS console to manually set things up, you describe what you want in a text file, and the system builds it for you.
Why does this matter? Imagine you run an online store. You need three separate environments: development (where engineers test new features), staging (where you do final checks), and production (where real customers shop). Setting each one up by hand takes hours and you will inevitably forget to set something the same way in all three. With CloudFormation, you deploy from the same template every time, and all three environments are guaranteed to be identical.
The Key Sections of a Template
A CloudFormation template is a YAML or JSON file organized into sections — like chapters in a recipe book.
| Section | Role | Example | |---------|------|---------| | Parameters | Values you provide at deployment time | Instance type, environment name (dev/prod) | | Mappings | Lookup tables for conditional values | Different AMI IDs per region | | Resources | The AWS resources to create (the only required section) | EC2 instance, S3 bucket, RDS database | | Outputs | Values exported after the stack is created | Load balancer DNS name | | Conditions | Rules for whether to create certain resources | Only create a NAT Gateway in production |
A recipe analogy helps here. Parameters are like "how many servings do you want to make?" Mappings are like "the ingredient list varies by country." Resources are the actual cooking steps. Outputs are "what plate do you serve this on?" Conditions are "if it is a party, add the garnish."
Exam tip: Only the Resources section is required. All others are optional. The pattern of using Parameters for input, Mappings to look up region-specific values, and Conditions to create environment-specific resources comes up often.
Change Sets — Preview Before You Commit
When you shop online, you review your cart before clicking "Pay Now." Change Sets work the same way for AWS infrastructure changes.
Picture this scenario: you modified your CloudFormation template to change a security group rule on your running server. But you are not sure whether this change will cause your database to restart or just update a setting quietly. Create a Change Set and CloudFormation will show you a list: "this resource will be modified, that resource will be replaced, this other resource will be deleted." You can review it calmly before deciding.
Creating a Change Set does not apply any changes. Nothing happens until you click "Execute." If you do not like what you see, just delete the Change Set and nothing was touched.
Exam tip: "You want to review the impact of an infrastructure update before it happens" — the answer is Change Sets.
Stack Policies — Protecting Critical Resources
Imagine you have a production database containing years of customer orders. You want to make sure no one accidentally deletes or replaces it when updating the CloudFormation stack. Stack Policies give you that protection.
A Stack Policy is a set of rules attached to a CloudFormation stack that controls which resources can be updated. It is like putting a double lock on a bank vault. Once a Stack Policy is in place, only resources explicitly listed as "allowed to update" can be changed — everything else is protected.
One important behavior to remember: a Stack Policy cannot be completely removed after it is set. However, you can replace it with a policy that allows all updates, which effectively removes the restriction.
Exam tip: "Protect a critical resource like an RDS database from accidental modification" — the answer is Stack Policy.
Drift Detection — Finding Unauthorized Changes
You carefully built your infrastructure with CloudFormation. Then one day a colleague logs into the AWS console and manually changes a security group rule on an EC2 instance. Now the actual state of your AWS environment no longer matches your CloudFormation template. This gap between the template and reality is called "drift."
Drift is like having a building blueprint that says there are three windows, but someone added a fourth window to the actual building. The blueprint is out of date.
When you run Drift Detection, CloudFormation checks each resource's current configuration against what the template says it should be. The result for each resource is either IN_SYNC (matches the template) or DRIFTED (differs from the template). For drifted resources, you can see exactly which properties changed and what the current versus expected values are.
Exam tip: "You want to find differences between your CloudFormation template and manually made changes in the console" — the answer is Drift Detection.
StackSets — Deploy to Multiple Accounts and Regions at Once
Your company grew and now has fifteen AWS accounts — one per team or business unit. You need to deploy the same security baseline to all of them. Logging into each account and deploying separately would take all day. StackSets solves this.
StackSets lets you deploy a single CloudFormation template to multiple AWS accounts and multiple regions simultaneously. Think of it as a headquarters sending the same operations manual to every branch office at once.
Here is how it works: you create a StackSet in your administrator account, specify the target accounts or AWS Organizations OUs, and CloudFormation automatically creates a stack instance in each target. You can also configure how many accounts get deployed to simultaneously and how many failures are acceptable before the operation stops.
Exam tip: "Deploy the same CloudFormation stack to multiple accounts and regions" — the answer is StackSets.
Understanding the ROLLBACK_COMPLETE State
If something goes wrong while CloudFormation is creating a stack, it will automatically attempt to roll back — meaning it tries to delete any resources it already created so you are not left with a partial deployment.
But what if the rollback itself also fails? The stack ends up in the ROLLBACK_COMPLETE state. This is a dead-end state. You cannot update a stack in ROLLBACK_COMPLETE. The only action available is to delete the stack, fix whatever caused the original failure, and then create a fresh stack.
Common causes include insufficient IAM permissions, hitting AWS service limits, or invalid parameter values.
Exam tip: "How do you recover a stack in ROLLBACK_COMPLETE state?" — delete it, fix the error, and recreate it from scratch.
cfn-init, cfn-signal, and CreationPolicy
Suppose you want CloudFormation to create an EC2 instance and automatically install Apache and PHP on it. You also want CloudFormation to wait until the installation is complete before declaring the stack successfully created.
cfn-init reads a metadata section in your template that lists which packages to install, which files to create, and which services to start. When the EC2 instance launches, cfn-init runs those steps automatically.
cfn-signal is a command you put at the end of your installation script. When the installation finishes successfully, cfn-signal sends a "done" message back to CloudFormation.
CreationPolicy is a setting on the resource that tells CloudFormation "do not mark this resource as complete until you receive the signal." You also specify a timeout — if the signal does not arrive within that time, the stack creation fails.
These three work as a team. cfn-init does the work, cfn-signal reports completion, and CreationPolicy makes CloudFormation wait for the report.
Nested Stacks and AWS CDK
As your application grows, a single CloudFormation template can become hundreds of lines long and difficult to manage. Nested Stacks solve this by breaking one large template into smaller reusable modules.
For example, you might have a network stack (VPC, subnets, routing), a security stack (security groups, IAM roles), a compute stack (EC2, Auto Scaling), and a database stack (RDS). A parent stack references and assembles all of these. Each individual stack can be reused in other projects.
AWS CDK (Cloud Development Kit) takes a different approach. Instead of writing YAML or JSON directly, you write infrastructure code in Python, TypeScript, Java, or other familiar languages. When you run the CDK, it generates the CloudFormation template for you. Developers who are comfortable coding tend to find CDK faster and less error-prone than writing raw templates.
Exam Key Points
"Preview the impact of an infrastructure change before it happens" -- Change Sets
"Find differences between the template and manually made console changes" -- Drift Detection
"Deploy the same stack to multiple accounts and regions" -- StackSets