How do you build and manage hundreds of cloud servers, databases, and security rules without forgetting one single setting or introducing manual errors? That is the exact problem Infrastructure as Code solves, and it is a core skill tested in the DOP-C02 exam. In plain terms, Infrastructure as Code (IaC) means you write and store the configuration of your entire cloud environment as code files, which you can review, share, re-run, and change safely, just like your application code.
Jump to a section
A simple way to picture Infrastructure as Code with AWS CloudFormation
Have you ever watched someone build a house entirely by memory, only to realise later that the kitchen window faces a brick wall? That is what managing cloud infrastructure without Infrastructure as Code feels like.
Imagine you are an architect designing a house. You could walk onto a construction site and shout directions to the builders: 'Put a door here! Add a window there! Paint this wall blue!' But if you get distracted, leave for an hour, or try to explain it differently to a second builder, chaos erupts. The doors end up in the wrong rooms, the paint is mismatched, and nobody knows who changed what.
Now imagine instead, you write a single, detailed blueprint. That blueprint says: 'Front door is exactly 1 metre wide, positioned 3 metres from the left corner. The kitchen has two south-facing windows of 1.2 metres each. The living room walls are painted #F5F5DC.' You hand this blueprint to the builders, and they follow it precisely. If you want to change something, you edit the blueprint, not shout new orders. The blueprint is your source of truth, repeatable, version-controlled, and un-misunderstandable.
In cloud computing, AWS CloudFormation is that blueprint for your entire digital house — servers, databases, networks, security rules — all defined in a template file. You never click buttons in a console again. You write the template, and AWS builds exactly what you specified, every single time, without mistakes.
Infrastructure as Code (IaC) is a way to manage and provision cloud resources through machine-readable definition files, rather than using a web console (pointing and clicking) or running manual commands one-by-one. AWS CloudFormation is Amazon's native IaC service that lets you describe exactly what you want — servers (EC2 instances), databases (RDS), networks (VPCs), security groups, load balancers — in a single file called a template.
Before IaC, IT teams would log into the AWS Console, click around to launch a server, configure its size, pick an operating system, set up networking, and then repeat that process for every single new server. This manual approach is slow, error-prone (one wrong checkbox can expose data to the internet), and impossible to reproduce consistently. If a server broke and you needed an identical replacement, you would have to remember every setting you chose, hoping you did not miss one.
CloudFormation replaces this by using what is called a 'declarative' approach. Declarative means you simply declare the final state you want — for example: 'I want one t2.micro EC2 instance, with 20 GB of gp2 storage, in the us-east-1a availability zone, behind a load balancer, with security group allowing HTTPS only.' You do not tell AWS the step-by-step commands to achieve it (that would be 'imperative'). Instead, CloudFormation figures out the order and dependencies automatically.
A CloudFormation template is a text file written in JSON or YAML format. YAML is more human-readable and is the preferred format for most DevOps engineers. The template has several major sections:
AWSTemplateFormatVersion: declares which version of the template language you are using (usually '2010-09-09').
Description: a free-text field explaining what the template does.
Parameters: where you define inputs that the user can provide when launching the stack (like instance size or environment name). This makes templates reusable across different environments (dev, test, production).
Mappings: a static lookup table, like mapping AWS region names to their corresponding Amazon Machine Image (AMI) IDs.
Conditions: logic that determines whether certain resources should be created, for example, 'Create a larger database only if the environment is production'.
Resources: the most important section. Here you define every AWS resource you want to create. Each resource has a logical name (like 'MyWebServer') and a Type (like 'AWS::EC2::Instance'), plus properties specific to that resource type.
Outputs: information you want to return after the stack is created, such as the public IP address of the new web server.
When you submit a template to CloudFormation, it creates something called a 'stack'. A stack is a collection of AWS resources that you manage as a single unit. If you need to delete everything, you delete the stack, and CloudFormation removes all resources in the correct order. This is a massive safety improvement over manually deleting each component and risking leaving behind orphaned storage or security groups.
One critical concept is 'stack updates'. When your requirements change, you modify the template and run a stack update. CloudFormation analyses the differences between the current stack and the new template, and then makes only the necessary changes — adding, removing, or modifying resources — while leaving everything else untouched. It uses something called a 'change set' to show you exactly what will change before you commit.\
Another essential feature is 'stack sets', which let you deploy a single template across multiple AWS accounts and regions from one central location. For example, a company might want to enforce the same security rules (like encryption at rest) across every account in every region. A stack set does that in one operation.
CloudFormation also integrates with 'AWS CloudFormation Designer', a visual tool that helps you sketch out your architecture and generate templates, though most professionals write templates by hand using a code editor. Because the template is just a text file, you store it in a version control system like Git. This gives you a complete history of every change to your infrastructure, who made it, and why — something impossible with manual clicking.
Finally, CloudFormation is not the only IaC tool — alternatives include Terraform (from HashiCorp) and AWS CDK (Cloud Development Kit). The DOP-C02 exam focuses specifically on CloudFormation, so you need to master its syntax, update strategies, and troubleshooting patterns.
1. Define the Template Structure
Create a new file with a .yaml or .json extension. Start with the AWSTemplateFormatVersion (always '2010-09-09') and an optional Description. Then define Parameters, Mappings, Conditions, Resources, and Outputs. The Resources section is mandatory — at least one resource must be defined.
2. Add Resource Definitions
For each AWS resource you need (like an EC2 instance, RDS database, or S3 bucket), write a logical name (e.g., 'MyWebServer') and a resource type (e.g., 'AWS::EC2::Instance'). Add properties such as ImageId, InstanceType, SecurityGroups, etc. Use the Ref and Fn::GetAtt intrinsic functions to reference other resources within the template.
3. Validate the Template
Use the AWS CLI command 'aws cloudformation validate-template' or the 'Validate Template' button in the AWS console. This checks for syntax errors, missing required properties, and valid resource types. Fix any errors before proceeding.
4. Create the Stack
Run 'aws cloudformation create-stack' with the template file URL or the inline template. CloudFormation then creates the stack and all defined resources. You can monitor the progress in the CloudFormation console. The stack status will change from CREATE_IN_PROGRESS to CREATE_COMPLETE or CREATE_FAILED.
5. Update the Stack When Requirements Change
When your infrastructure needs change, edit the template file. Use 'aws cloudformation create-change-set' to generate a change set that lists exactly what will be added, modified, or replaced. Review it, then run 'aws cloudformation execute-change-set' to apply the changes. CloudFormation handles dependencies and minimises downtime.
6. Delete the Stack When No Longer Needed
To remove all resources created by the stack, run 'aws cloudformation delete-stack'. By default, CloudFormation deletes every resource it created. If you want to retain specific resources (like an S3 bucket with data), set the 'DeletionPolicy' attribute to 'Retain' in the template before deletion.
Picture this: you work for a growing e-commerce company called 'ShopStream'. The company runs its payment processing system on AWS. Currently, the infrastructure was set up manually by a senior engineer who left the company six months ago. No one knows exactly how all the pieces connect. This week, an audit reveals that the payment database is not encrypted, which violates PCI compliance standards.
Your manager asks you to fix it. Without IaC, your day goes like this:
You log into the AWS Console and find the database instance ID by guessing from a list of twenty similar-looking names.
You click 'Modify' and enable encryption, but the console warns that encryption can only be enabled during creation, not modification. So you must create a new encrypted database, migrate the data manually, update the application's connection string, and delete the old database — a high-risk, multi-step process with many opportunities for error.
You document the steps in a Word document, which will be outdated within a week.
If instead, the infrastructure was managed with CloudFormation, your day looks completely different:
You find the existing CloudFormation template stored in the company's Git repository. You open it in your editor.
You locate the 'AWS::RDS::DBInstance' resource and add the line: StorageEncrypted: true.
You also notice the template uses an 'AWS::EC2::SecurityGroup' with a rule that allows SSH (port 22) from anywhere (0.0.0.0/0). That is a security risk. You change the CIDR IP to your office's static IP.
You commit the change to a new Git branch, open a pull request, and your colleague reviews the diff (the changes). They spot a typo: you wrote 'StorageEncrypted: treu' instead of 'true'. They fix it before it ever touches production.
After approval, you run 'aws cloudformation update-stack' from the command line. CloudFormation generates a change set showing two changes: the database will be replaced with an encrypted one, and the security group rule will be updated. No other resources are affected.
You apply the change set. CloudFormation handles the database replacement, data migration, and security update in the correct order, automatically.
After completion, you tag your Git commit with the version number.
In this scenario, the company benefits from version control (you know who changed what), code review (catching errors before deployment), automation (no manual clicking), and consistency (the template can be used to rebuild the entire environment in a disaster recovery situation within minutes).
The DOP-C02 exam expects you to understand this workflow in detail. You will be asked about how to propagate changes across stacks, how to handle dependencies between resources, and what happens when a stack update fails (rollback behaviour).
The DOP-C02 exam tests your ability to design, implement, and troubleshoot CloudFormation templates and stack management. You will not be asked to write a full template from scratch, but you will need to interpret template snippets and predict the outcome of changes.
Key exam topics include:
Resource dependencies: CloudFormation automatically determines the order of creation based on the Ref and DependsOn attributes. Exam questions often present a template and ask: 'Which resource is created first?' or 'What happens if resource A depends on resource B, but B fails?'
Change sets: You must know the difference between direct stack updates and generating a change set to review before applying. A common question: 'A company wants to review the impact of a change before implementing it. Which feature should they use?' The answer is 'Change sets'.
Stack updates: Know the four update behaviours: Update with No Interruption, Update with Some Interruption, Update by Replacement, and Update with Replacement (where CloudFormation creates a new resource and deletes the old one). The exam tests which behaviour applies to specific resource property changes. For example, changing the instance type of an EC2 instance triggers a replacement (stop and start), which causes downtime.
Nested stacks: A single stack can reference other templates as nested stacks. This is useful for reusing common components like a VPC base. The exam asks about limits (maximum number of nested stacks) and output passing between parent and child stacks.
Stack sets: Know that StackSets allow you to deploy stacks across multiple accounts and regions from a single template. A typical question: 'A company has 50 accounts and wants to enforce the same encryption policy in all regions. Which service should they use?' Answer: CloudFormation StackSets.
Drift detection: Over time, people might manually change a resource (like resizing a database in the console). Drift detection compares the current state of the stack to the template and reports differences. The exam tests your ability to identify when drift has occurred and how to remediate it (by updating the stack or updating the template).
Termination protection: By default, deleting a stack deletes all its resources. Termination protection prevents accidental deletion of critical stacks. A classic exam trap: 'A developer cannot delete a stack. What is the likely cause?' The answer is termination protection is enabled.
Stack policies: These are JSON documents that define which resources in a stack can be updated or deleted during a stack update. They protect critical resources like production databases from accidental modification.
Intrinsic functions: You must understand functions like Ref, Fn::GetAtt, Fn::Join, Fn::Select, and Fn::Sub. Questions often present a YAML snippet using one of these functions and ask what value it returns or what it does.
Common exam traps:
Confusing 'Parameters' (user-provided values at launch) with 'Mappings' (hardcoded lookup tables).
Assuming that all resource properties can be changed without replacement. Many exam questions intentionally describe a change that requires a full resource replacement, causing downtime. The correct answer often acknowledges the downtime and suggests a strategy to minimise it.
Forgetting that CloudFormation requires an IAM role to create resources, or that resource creation might fail because of service quotas or permissions.
Mixing up 'UpdateStack' and 'CreateStack' API calls. The exam expects you to know which operation to use when you are modifying an existing infrastructure.
Memorise this pattern: When a new version of a template is submitted for an existing stack, CloudFormation performs an 'UpdateStack' operation, which compares the new template to the current template and calculates the minimal set of changes needed. If you want to see the changes without applying them, you use 'CreateChangeSet' and then 'ExecuteChangeSet'.
CloudFormation is a declarative Infrastructure as Code service that lets you define all AWS resources in a single template file, eliminating manual errors and enabling repeatable deployments.
A CloudFormation stack is a collection of AWS resources managed as a single unit; deleting the stack removes all its resources by default.
Stack updates use change sets to preview the impact of modifications before applying them, which is critical for production environments.
StackSets allow you to deploy identical stacks across multiple AWS accounts and regions from a single template, ensuring consistency at scale.
Drift detection compares the actual state of resources to the template definition, revealing unauthorised manual changes.
Intrinsic functions like Ref, Fn::GetAtt, Fn::Join, and Fn::Sub are essential for creating dynamic and reusable templates.
Termination protection prevents accidental deletion of critical stacks by adding a layer of confirmation before deletion.
CloudFormation templates are stored as text files in Git, giving you full version control, code review, and audit trail for all infrastructure changes.
These come up on the exam all the time. Here's how to tell them apart.
CloudFormation
All infrastructure defined in a version-controlled text file
Supports drift detection to identify unauthorised changes
Stack updates are automated and can include rollback on failure
Manual AWS Console
Infrastructure state lives only in the engineer's memory or documentation
No automatic drift detection; manual audit required
Changes are implemented by clicking buttons one at a time, prone to error
Nested Stacks
One template includes another template as a resource within the same stack
Used for reusing common components like VPC or security group templates
Parent stack manages the lifecycle of all nested stacks together
Cross-Stack References
Separate stacks share values using Fn::ImportValue from stack outputs
Used for sharing resource identifiers like VPC ID or database endpoint
Each stack is managed independently; deletion order must be manual
Stack Update with Change Set
Generates a detailed list of changes before applying them
Requires an additional step (create then execute)
Recommended for production environments to avoid surprises
Stack Update Without Change Set
Changes are applied immediately when update-stack is called
Single step process, faster for development
No preview; potential for unintended modifications
DeletionPolicy: Retain
Preserves the resource even when the stack is deleted
Useful for databases, S3 buckets with important data
Resource becomes orphaned and must be managed outside CloudFormation
Default Deletion (Delete)
Every resource created by the stack is deleted when the stack is deleted
Ensures clean state and avoids hidden ongoing costs
Requires careful consideration for stateful resources
Parameters
Input values provided by the user when launching or updating a stack
Allow template reusability across environments (e.g., different instance sizes)
Values can be referenced using Ref function
Mappings
Static lookup tables defined inside the template
Used for region-specific values like AMI IDs or availability zones
Values are referenced using Fn::FindInMap function
Mistake
CloudFormation templates are executed like a script in order, so the first resource defined in the template is always created first.
Correct
CloudFormation automatically resolves dependencies and creates resources in the correct order — not the order they appear in the template. You can use the DependsOn attribute to explicitly override the automatic order if needed.
People familiar with procedural programming assume that the order of lines in a file defines execution order. CloudFormation is declarative, so it analyses the entire template to determine dependencies.
Mistake
If I delete a CloudFormation stack, the resources inside it are never actually deleted; they just become orphaned.
Correct
By default, deleting a CloudFormation stack deletes all the resources that were created by the stack during stack creation. This includes EC2 instances, databases, S3 buckets (if not empty), etc. There is a feature called 'Retain' on a resource that prevents deletion, but you must explicitly set it.
Some beginners come from environments where manual deletion is required, and they underestimate the power of CloudFormation's automated lifecycle management.
Mistake
CloudFormation templates can only be written in JSON, because YAML is not supported.
Correct
CloudFormation supports both JSON and YAML formats. YAML is often preferred because it is cleaner and more readable for complex templates. The DOP-C02 exam tests both formats.
Many older online tutorials were written before YAML support was added, and some learners assume YAML is only for Terraform.
Mistake
Once a stack is created, you cannot change the template — you must delete the stack and recreate it.
Correct
You can use the UpdateStack operation to modify an existing stack. CloudFormation calculates the difference between the existing stack and the new template, and applies only the necessary changes. This is one of the most powerful features of CloudFormation.
This misconception comes from beginners confusing CloudFormation with an immutable infrastructure tool, when in fact it supports both creation and incremental updates.
Mistake
Nested stacks and cross-stack references are the same thing and can be used interchangeably.
Correct
Nested stacks are when one template includes another template as a resource within the same stack. Cross-stack references use the Fn::ImportValue function to share outputs between completely separate stacks. They are different mechanisms with different use cases and limitations.
The names sound similar and both involve multiple templates, so new learners mix them up. The exam tests the distinction.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A template is the JSON or YAML file that defines your infrastructure resources. A stack is the live, running collection of resources created from that template. You can have multiple stacks from the same template (e.g., one for dev and one for production).
Not directly, but you can use 'AWS CloudFormer' or the 'Resource Import' feature (stack import) to bring existing resources into an existing or new stack. You must create a template that matches the current configuration of the resource.
By default, CloudFormation performs a 'rollback on failure'. It automatically reverts all changes made during the update attempt, restoring the stack to its previous state. You can disable this behaviour with the 'DisableRollback' flag, but it is rarely recommended in production.
Never hardcode secrets in the template. Use the 'AWS Systems Manager Parameter Store' or 'AWS Secrets Manager' to store secrets, and reference them using the 'dynamic reference' syntax (e.g., '{{resolve:ssm:/myapp/dbpassword:1}}') in the template properties.
Yes, AWS CloudFormation itself has no additional cost. You only pay for the underlying resources that CloudFormation creates (e.g., EC2 instances, RDS databases, storage).
The maximum template size is 512 KB for a template file, or 460 KB for a template URL. If your template is larger, you can break it into nested stacks or use template snippets stored in Amazon S3.
CloudFormation is designed only for AWS resources. For multi-cloud or on-premises resources, you would use tools like Terraform or Pulumi. CloudFormation Registry does support third-party resource types via extensions, but it is primarily an AWS-native tool.
You've finished Infrastructure as Code with AWS CloudFormation. Continue through the DOP-C02 study guide to build a complete picture of the exam.
Done with this chapter?