Exam objective 3.1 focuses on automating infrastructure provisioning and configuration management. This chapter explains how Infrastructure as Code (IaC) transforms the way IT professionals build and manage cloud resources, turning a manual, error-prone process into one that is automated, consistent, and scalable. For the SAP-C02 exam, understanding IaC is not optional; it is a core requirement for designing resilient, efficient architectures.
Jump to a section
A simple way to picture Automating Operations with Infrastructure as Code
Have you ever watched a building being constructed and wondered how the builders know exactly where to place every brick, pipe, and wire?
Imagine you're a developer who needs to build a 20-storey apartment building. Instead of giving the construction crew a single blueprint and then shouting instructions from the ground floor every time a worker asks where to put the next window, you write a detailed, digital master plan. This plan describes every wall, every socket, every pipe, and every light switch in the entire building. It’s a single file that the construction team reads and follows exactly. If you want to change the colour of the lobby floor from grey marble to white tiles, you don't run down to the site and tell each tiler individually. You edit the master plan. The crew automatically gets the new instructions, and all future tiling follows the updated plan. If you need a second identical building next door, you don't hire a new architect and start from scratch. You copy the master plan, give it to a new crew, and they build an exact replica. Infrastructure as Code (IaC) is that digital master plan for your cloud environment. You write a file that describes your virtual servers, networks, databases, and security settings. When you need to change something, you edit the file, not the live system. This approach makes building, changing, and copying your entire IT setup predictable, repeatable, and far less error-prone than the old way of manually clicking around a web dashboard.
Infrastructure as Code (IaC) is the practice of managing and provisioning computing infrastructure through machine-readable definition files, rather than through physical hardware configuration or interactive configuration tools. Think of it as treating your servers, networks, and databases exactly like software code.
Before IaC, setting up a new server was a manual process. An IT worker would log into a cloud provider's web console, click through several pages to select an operating system, choose a server size, configure network settings, and then maybe run a script to install software. This is called 'click-ops', and it is slow, inconsistent, and prone to human error. If you needed fifty identical servers, you had to repeat that manual process fifty times, or build a golden image—a pre-configured server snapshot—which was brittle and hard to update.
IaC changes everything. You write a declarative configuration file—using a tool like AWS CloudFormation or Terraform—that describes exactly what you want your infrastructure to look like. For example, you specify: 'I want one virtual private cloud (a logically isolated network), with two subnets (segments of that network), each containing three virtual servers running Linux, with a security group (a virtual firewall) that allows web traffic on port 80.' This file becomes the single source of truth.
When you submit this file to an IaC service, the service reads it, compares it to the current state of your infrastructure, and makes the necessary changes to bring the real world into alignment with your file. This process is called 'desired state configuration'. The tool handles the creation, modification, or deletion of resources automatically. If you need to add a new server, you simply add a line to your file and run the tool again. The IaC service figures out what needs to change and applies it safely.
The key benefits of IaC are:
Repeatability: You can deploy the exact same environment hundreds of times. This is crucial for testing because you can spin up a copy of your production environment, run tests, and then tear it down, all without manual effort.
Version Control: Because your infrastructure definition is a text file, you can store it in a version control system like Git. This means you have a complete history of every change made to your infrastructure. You can roll back to a previous version if a change causes problems.
Automation: IaC enables continuous integration and continuous delivery (CI/CD) pipelines. When you commit a change to your IaC file, it can automatically trigger a deployment that updates your live infrastructure. This is the foundation of modern DevOps practices.
Consistency: There is no more 'it works on my machine' problem. Everyone on the team uses the same configuration file, so development, staging, and production environments are identical.
Documentation: The IaC file itself becomes living documentation of your infrastructure. Anyone on the team can read the file and understand exactly how the environment is configured.
There are two main approaches to IaC: declarative and imperative. A declarative approach (used by CloudFormation and Terraform) defines the end state you want, and the tool decides how to achieve it. An imperative approach (using scripts) defines the exact steps to execute. AWS recommends a declarative approach because it is simpler, safer, and more aligned with automation principles.
Configuration management tools like AWS OpsWorks (which uses Chef or Puppet) or AWS Systems Manager are separate but related concepts. While IaC provisions the infrastructure itself (servers, networks, databases), configuration management tools install software and manage settings on those servers after they are built. For the SAP-C02 exam, you need to understand the distinction: IaC creates the house; configuration management paints the walls and installs the appliances.
For SAP-C02, the prime IaC service to understand is AWS CloudFormation, but you should also be aware of AWS Elastic Beanstalk (which abstracts much of the infrastructure for you, but can still be customised with configuration files) and AWS OpsWorks. AWS Service Catalog extends IaC by allowing organisations to create a curated catalogue of approved infrastructure templates that end users can deploy on demand.
Define the desired infrastructure state
You write a CloudFormation template (in YAML or JSON) that describes every resource you need: VPCs, subnets, servers, databases, security groups, IAM roles, and so on. This template becomes the single source of truth for your environment.
Store the template in version control
You commit the template file to a Git repository (like AWS CodeCommit or GitHub). This gives you a full history of changes, enables team collaboration, and allows you to roll back to a previous version if something goes wrong.
Create a CloudFormation stack
You submit the template to the CloudFormation service. CloudFormation reads the template and begins to provision the resources in the correct order, respecting dependencies. For example, it creates the VPC before creating subnets inside it.
Review changes with a change set
Before updating a running stack, you can create a change set. This is a summary of every resource that will be added, modified, or deleted. You review it to ensure no unintended changes will occur, then execute it to apply the update.
Update the stack with a new template
When you need to change the infrastructure, you edit the template in version control and then trigger a stack update. CloudFormation compares the new template to the current stack and makes only the necessary changes, minimising disruption.
Monitor for drift
Periodically, you run drift detection on your stack. If any resource has been manually modified outside of CloudFormation (for example, someone changed a security group rule via the console), you are alerted. You can then either revert the manual change or update the template to incorporate it.
Delete the stack when no longer needed
When the environment is no longer required, you delete the CloudFormation stack. CloudFormation automatically deletes all resources that were created by the stack, preventing orphaned resources and unnecessary costs.
Consider a large e-commerce company that is preparing for a major sales event like Black Friday. The current platform runs on a manually configured set of AWS resources. The operations team dreads the event because scaling up requires a frantic weekend of manual work: launching new Amazon EC2 instances, attaching them to the load balancer, adjusting database connection pools, and updating DNS records. One person making a typo in a security group rule could take down the entire site.
The company decides to adopt Infrastructure as Code. A senior solutions architect writes a set of AWS CloudFormation templates that define the entire application stack: a Virtual Private Cloud (VPC) with public and private subnets, an Application Load Balancer, an Auto Scaling group for web servers, a relational database in a private subnet, and all the necessary security groups and IAM roles. The template is stored in a Git repository and is the single source of truth for the production environment.
When the sales event approaches, the team does not panic. They commit a small change to the template to increase the minimum and maximum size of the Auto Scaling group. Then they trigger a pipeline that updates the production stack. Within minutes, the new configuration is live. Because the template is version-controlled, they can easily revert the change after the event.
A new developer joins the team. Previously, they would need a senior engineer to spend a half-day manually creating a development environment for them. Now, the developer checks out the Git repository, runs a single command to create a new CloudFormation stack from the template, and has a fully functional copy of the entire application environment running in under an hour. When they are done testing, they run another command to delete the stack, which automatically tears down all the resources, saving the company money.
During a security audit, the auditor asks to see a record of all infrastructure changes. The team points to the Git commit history. Every change to the production environment is logged, with a timestamp, author, and a clear description of what was changed. The auditor is satisfied immediately.
In a more advanced scenario, the company uses AWS Service Catalog to create a product portfolio of approved CloudFormation templates. Different teams can browse the catalogue and deploy pre-approved stacks without needing to write their own IaC. This enforces security best practices across the entire organisation.
Steps an IT professional would take to set up IaC for this scenario:
Design the infrastructure architecture and create a CloudFormation template (in YAML or JSON) that describes all resources.
Store the template in a version-controlled repository (like AWS CodeCommit or GitHub).
Set up a CI/CD pipeline (using AWS CodePipeline) that automatically deploys the template to a test environment whenever a change is pushed.
Use AWS CodeDeploy to manage application deployments to the infrastructure created by CloudFormation.
Implement change sets in CloudFormation to preview the impact of a change before applying it.
Use stack sets to deploy the same infrastructure across multiple AWS regions for disaster recovery.
The SAP-C02 exam heavily tests your understanding of Infrastructure as Code, specifically AWS CloudFormation. You must think like an architect designing for automation, not an operator managing servers by hand. The exam expects you to choose IaC solutions over manual processes in nearly every scenario where repeatability, reliability, or compliance is a concern.
Key exam topics related to IaC:
CloudFormation template structure: You need to understand the main sections of a template: AWSTemplateFormatVersion, Description, Metadata, Parameters, Mappings, Conditions, Resources (the required section), Outputs. You will not be asked to write a template from scratch, but you may need to identify correct syntax or understand how conditionals and intrinsic functions (like Fn::If, Fn::Select, Fn::Join) work.
Stack policies: These are JSON documents that define what resources in a stack can be updated or deleted. The exam tests scenarios where you need to protect critical resources (like a production database) from accidental modification during a stack update. A stack policy overrides the update permissions of the IAM user performing the update.
Change sets: These allow you to review the changes CloudFormation will make to your stack before executing them. The exam tests the difference between a change set and a direct update, and when to use each. Change sets are not required for every update; they are a safety mechanism for complex or risky changes.
Nested stacks: For complex architectures, you can break your template into multiple smaller, reusable templates called nested stacks. The exam tests when to use nested stacks versus a single large template. Nested stacks are useful for isolating components (like a database layer) so they can be updated independently.
Stack sets: These let you deploy CloudFormation stacks across multiple accounts and regions from a single template. This is critical for multi-region disaster recovery and for organisations using AWS Organizations. The exam tests the permission model: you need a service-linked role or a correctly configured IAM execution role in the target accounts.
Drift detection: Over time, manual changes made outside of CloudFormation can cause your infrastructure to deviate from the template. Drift detection identifies these differences. The exam tests that you know how to detect and remediate drift.
AWS Systems Manager Automation and State Manager: While not pure IaC, these services automate operational tasks and enforce desired configurations across instances. The exam sometimes presents scenarios where a combination of CloudFormation for provisioning and Systems Manager for ongoing configuration is the correct answer.
Common traps set by the exam:
Confusing CloudFormation with Elastic Beanstalk. Elastic Beanstalk is a PaaS (Platform as a Service) service that abstracts infrastructure management. It uses CloudFormation under the hood, but for fine-grained control, the exam expects you to choose CloudFormation directly.
Assuming IaC is only for initial deployment. The exam tests that IaC is also the correct approach for updates, scaling, and disaster recovery. Any scenario involving 'repeatability' or 'environment parity' points to IaC.
Overlooking stack policies. A question may describe a situation where a junior engineer accidentally deletes a critical resource during a stack update. The correct answer is to implement a stack policy that denies delete for that resource type.
Forgetting that CloudFormation templates can be parameterised. Questions often ask how to deploy a stack to different environments (dev, test, prod) without duplicating templates. The answer is to use parameters and mappings.
Key definitions to memorise:
Declarative programming: You specify the 'what', not the 'how'. The IaC tool determines the steps to reach the desired state.
Idempotent: An operation that can be applied multiple times without changing the result beyond the initial application. CloudFormation is idempotent—running the same template twice will not create duplicate resources.
Orchestration: The coordination of multiple automated tasks. CloudFormation orchestrates the creation of interdependent resources in the correct sequence.
Infrastructure state: The current configuration of all your cloud resources. IaC aims to keep the actual state identical to the desired state defined in templates.
Infrastructure as Code treats your cloud resources like application code, enabling version control, automated deployment, and consistent environments.
AWS CloudFormation is the primary IaC service tested on SAP-C02; its declarative templates define the desired state of your entire stack.
Stack policies protect critical resources from accidental modification during CloudFormation stack updates.
Change sets allow you to preview the impact of a CloudFormation change before applying it, reducing the risk of unintended modifications.
Nested stacks enable modular, reusable templates that simplify complex multi-tier architectures.
Stack sets allow you to deploy identical CloudFormation stacks across multiple AWS accounts and regions from a single template.
Drift detection identifies resources that have been manually changed outside of CloudFormation, helping you maintain consistency.
IaC is not a set-it-and-forget-it solution; ongoing monitoring, patch management, and incident response still require attention.
These come up on the exam all the time. Here's how to tell them apart.
CloudFormation Stack Policy
Applies only to resources within a single CloudFormation stack.
Prevents modification or deletion of specific resources during stack updates.
Overrides IAM permissions for stack operations; even an admin cannot bypass it.
Used specifically for protecting infrastructure during automated updates.
IAM Policy
Applies to all actions a user or role can perform across AWS.
Controls who can create, update, or delete resources in general.
Can be overridden by a stack policy for stack-specific operations.
Used for general security and access control across all services.
AWS CloudFormation
Provides fine-grained control over every infrastructure resource.
Requires you to define each resource explicitly in a template.
Best for complex architectures with custom networking and security needs.
Supports stack sets, change sets, and drift detection.
AWS Elastic Beanstalk
Abstracts infrastructure management; you upload code and it handles the platform.
Uses CloudFormation internally but hides the underlying template from you.
Best for standard web applications where you do not need custom infrastructure.
Simplifies deployment but limits architectural flexibility.
Declarative IaC (CloudFormation)
You define the desired end state; the tool decides how to achieve it.
Idempotent: running the same template multiple times produces the same result.
Safer for production because the tool handles dependencies and order.
Simpler to read and reason about; the template is the documentation.
Imperative IaC (Scripts with CLI)
You define the exact steps to execute; the tool follows your script.
Not inherently idempotent; you must write logic to avoid duplicate actions.
Higher risk of error because you must manage ordering and dependencies manually.
More flexible for complex logic but harder to maintain and audit.
CloudFormation Change Set
Creates a preview of changes before applying them.
Does not modify any resources until you explicitly execute the change set.
Useful for reviewing risky changes or changes to critical infrastructure.
Adds a review step to the deployment process.
Direct Stack Update
Applies changes immediately without a separate review step.
Modifies resources as soon as you submit the update.
Suitable for low-risk changes or automated pipelines with built-in testing.
Faster because it skips the preview step.
Mistake
IaC is only useful for very large, complex environments with hundreds of servers.
Correct
IaC is valuable even for small setups because it ensures consistency, version control, and fast recovery. A single-server WordPress site benefits from being defined in CloudFormation because you can recreate it instantly if something goes wrong.
Beginners often assume that automation is overkill for small projects, not realising that the biggest value of IaC is in preventing manual errors and enabling disaster recovery, which scales down just as well as it scales up.
Mistake
Once you set up IaC, you never need to log into a server again.
Correct
IaC provisions and configures infrastructure, but ongoing management (like monitoring, patching, and incident response) often still requires manual intervention or other automation tools like AWS Systems Manager. IaC reduces manual work but does not eliminate it entirely.
The promise of 'automation' can be misleading. Beginners think it means fully hands-off, but IaC focuses on the provisioning and configuration phase, not the entire operations lifecycle.
Mistake
AWS CloudFormation and Terraform are completely interchangeable and work the same way.
Correct
While both are IaC tools, CloudFormation is deeply integrated with AWS, offering features like change sets and stack policies that Terraform does not natively match. Terraform is multi-cloud and uses a different state management model. They are not drop-in replacements.
Beginners hear 'both do IaC' and assume they are equivalent. In the AWS SAP-C02 exam, CloudFormation is the focus, and understanding its unique features is essential.
Mistake
If you use IaC, you do not need to worry about security groups or IAM roles anymore because the template handles it.
Correct
IaC templates define security group rules and IAM roles, but you still have to design them correctly. A poorly written template can create resources that are less secure than manually configured ones. Security is not automatic; the template is just the vehicle for implementing your security design.
Automation can create a false sense of security. Beginners think 'the tool will handle it', but the tool only executes what you tell it to do. If you tell it to open every port, it will.
Mistake
CloudFormation templates must be written in JSON because YAML is not supported.
Correct
Both JSON and YAML are fully supported for CloudFormation templates. YAML is generally preferred because it is more readable and supports comments, but JSON is also valid.
Older resources and some documentation still favour JSON, leading beginners to believe YAML is not an option. This is an outdated belief.
Mistake
A CloudFormation stack update always causes downtime.
Correct
CloudFormation can perform rolling updates across resources, which minimises downtime. It can also create replacement resources before deleting old ones, depending on the update policy. With careful template design, zero-downtime updates are achievable.
Beginners associate any change with downtime because manual changes often require reboots or reconfiguration. They do not understand that IaC tools can orchestrate changes intelligently to avoid disruption.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CloudFormation is an AWS-native IaC service that is deeply integrated with AWS and supports features like stack policies and change sets. Terraform is a multi-cloud IaC tool that can manage resources across AWS, Azure, and Google Cloud, but it uses a different state management model and is not directly integrated with AWS services.
You need to understand the structure of CloudFormation templates and be able to read simple examples in both JSON and YAML, but you are not expected to write a full template from scratch. Focus on understanding the purpose of each section (Parameters, Conditions, Resources, etc.) and common intrinsic functions.
Yes, CloudFormation can perform rolling updates, which update a subset of resources at a time. It can also create replacement resources before deleting old ones, depending on the update policy. With careful design, zero-downtime updates are achievable.
A stack policy is a JSON document that defines which resources in a stack can be updated or deleted. You should use one when you want to protect critical resources, such as a production database, from accidental modification during a stack update, even if the IAM user has full permissions.
Yes, using CloudFormation Stack Sets. Stack Sets allow you to deploy stacks across multiple accounts and regions from a single template. You need to set up the correct IAM execution role in the target accounts for this to work.
CloudFormation deletes all resources that were created by the stack. If you have set a stack policy to prevent deletion of certain resources, those will be retained. Always use drift detection to ensure no manual resources are left behind.
CloudFormation maintains a stack concept that tracks the resources it created. It does not store a separate state file like Terraform; it queries the AWS API to determine the current state of resources and compares this to the template. This is why drift detection is necessary.
You've finished Automating Operations with Infrastructure as Code. Continue through the SAP-C02 study guide to build a complete picture of the exam.
Done with this chapter?