ExamFinch.com My Study

Study guide

5.4 CloudFormation and Infrastructure as Code

Practice this exam

AWS Solutions Architect Associate SAA-C03

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the AWS Solutions Architect Associate (SAA-C03) Exam Study Strategies and Exam Tips for SAA-C03 The AWS Well-Architected Framework

2 Domain 1: Design Secure Architectures (30%)

1.1 IAM Fundamentals — Users, Groups, Roles, and Policies 1.2 AWS Organizations, SCPs, and Multi-Account Strategy 1.3 VPC Security — Security Groups, NACLs, and VPC Endpoints 1.4 Encryption, KMS, and Secrets Management 1.5 AWS WAF, Shield, and Network Firewall 1.6 GuardDuty, Inspector, Macie, and Security Hub 1.7 The Shared Responsibility Model for Solutions Architects 1.8 Data Protection, Compliance, and Audit Services

3 Domain 2: Design Resilient Architectures (26%)

2.1 Elastic Load Balancing (ELB) — ALB, NLB, and GWLB 2.2 EC2 Auto Scaling — Dynamic, Predictive, and Scheduled 2.3 Multi-AZ and Multi-Region Architectures 2.4 Disaster Recovery Strategies — RTO and RPO 2.5 Decoupling with SQS, SNS, and EventBridge 2.6 AWS Step Functions and Workflow Orchestration

4 Domain 3: Design High-Performing Architectures (24%)

3.1 EC2 Instance Types, Purchasing Options, and Placement Groups 3.2 Lambda, Serverless Compute, and Container Services 3.3 Amazon S3 - Storage Classes, Lifecycle, and Performance 3.4 Block and File Storage - EBS, EFS, and FSx 3.5 Database Services - RDS, Aurora, DynamoDB, and More 3.6 CloudFront, Route 53, and Global Accelerator 3.7 Data Ingestion and Transformation - Kinesis, Glue, and EMR

5 Domain 4: Design Cost-Optimized Architectures (20%)

4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot 4.2 Storage Cost Optimization — S3 Tiers, EBS, and Data Transfer 4.3 Database Cost Optimization 4.4 AWS Cost Management and Monitoring Tools

6 VPC and Networking Deep Dive

5.1 VPC Architecture — Subnets, Route Tables, and Gateways 5.2 VPC Connectivity — Peering, Transit Gateway, and Direct Connect 5.3 Amazon API Gateway 5.4 CloudFormation and Infrastructure as Code 5.5 AWS PrivateLink and Endpoint Services

7 Migration, Transfer, and Hybrid Services

6.1 The 7 Rs of Cloud Migration 6.2 AWS Snow Family — Snowball Edge Devices 6.3 CloudWatch, CloudTrail, and AWS Config 6.4 Amazon Cognito and Identity Federation 6.5 AWS DataSync and Transfer Family

8 Serverless Architecture and Application Services

7.1 Serverless Architecture Patterns 7.2 Advanced SQS Patterns — DLQ, Backpressure, and FIFO 7.3 Analytics Services — Athena, OpenSearch, and QuickSight 7.4 Container Orchestration — ECS, EKS, and ECR

9 Advanced Topics and Exam Scenarios

8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account 8.2 Caching Strategies and ElastiCache Patterns 8.3 Hybrid Architecture — DNS, Storage, and Compute 8.4 SAA-C03 Scenario Practice — Putting It All Together

5.4 CloudFormation and Infrastructure as Code

Key Takeaways Explain This Topic AI

CloudFormation provisions AWS resources declaratively from JSON/YAML templates; Resources is the only mandatory template section.

Stacks are the deployment unit; StackSets fan a stack out across many accounts and Regions from one operation.

Change Sets preview exactly what will be added, modified, or deleted before you execute an update to a live stack.

Drift detection finds resources changed manually outside CloudFormation; failed creates/updates roll back automatically by default.

AWS CDK lets you write infrastructure in TypeScript/Python/Java and synthesizes CloudFormation; AWS SAM is a CloudFormation extension for serverless apps.

Last updated: June 2026

Quick Answer: CloudFormation is AWS's declarative infrastructure-as-code engine using YAML/JSON templates. A stack is the unit of deployment; StackSets roll a stack out across many accounts and Regions; Change Sets preview changes before you apply them; drift detection flags manual out-of-band edits. CDK lets you author IaC in programming languages, and SAM is a CloudFormation extension tuned for serverless.

Template Anatomy

  • Section Required Purpose
  • AWSTemplateFormatVersion No Only valid value: "2010-09-09"
  • Description No Free-text summary
  • Parameters No Inputs supplied at stack creation
  • Mappings No Static lookups (e.g., AMI ID per Region)
  • Conditions No Create resources conditionally
  • Resources Yes The AWS resources to provision — the only mandatory section
  • Outputs No Values to display or export cross-stack

Intrinsic functions glue templates together: Ref returns a resource's id or a parameter value, Fn::GetAtt pulls an attribute (such as an ALB DNS name), Fn::Sub interpolates variables, and Fn::ImportValue consumes another stack's exported output.

Stacks, StackSets, Change Sets, and Drift

  • Concept What it solves
  • Stack All resources in a template managed as one unit; delete the stack to delete them all
  • StackSet Deploy one template to many accounts and Regions in a single operation
  • Change Set Show exactly what will be added/modified/ deleted before executing an update
  • Drift detection Report resources changed manually outside CloudFormation
  • Nested stacks Factor reusable components into child templates
  • Cross-stack reference Export an output from one stack, import it in another

By default a failed create or update rolls back automatically to the last known-good state, preventing half-built infrastructure. A Change Set is the safe way to touch production: it surfaces destructive replacements (some property changes force resource re-creation) before you commit.

CloudFormation vs. CDK vs. Terraform, and SAM

  • CloudFormation AWS CDK Terraform
  • Language YAML/JSON TypeScript, Python, Java, C#, Go HCL
  • Scope AWS only Synthesizes to CloudFormation Multi-cloud
  • State Managed by AWS Via CloudFormation External state file
  • Drift Built-in Inherits CFN drift terraform refresh

AWS SAM (Serverless Application Model) is a thin CloudFormation extension: shorthand for Lambda, API Gateway, DynamoDB, and Step Functions, plus the SAM CLI for local invoke and debug. SAM templates transform into ordinary CloudFormation at deploy time.

On the Exam: "Deploy identical infrastructure to 15 accounts across 3 Regions" → StackSets . "Preview changes before updating production" → Change Set . "Detect manual changes to managed resources" → drift detection . "Author infrastructure in Python" → CDK . "Simplify a serverless deployment" → SAM .

Deletion Protection, Retention, and Stack Policies

Production CloudFormation usage hinges on a few safety controls the exam likes to probe:

DeletionPolicy on a resource controls what happens when the resource is removed or the stack is deleted. Retain keeps the resource (common for data stores), Snapshot takes a final snapshot (valid for RDS, EBS, ElastiCache, Redshift), and Delete (the default for most resources) removes it. An S3 bucket or RDS instance you must not lose should carry DeletionPolicy: Retain .

Termination protection on the stack blocks accidental DeleteStack calls until it is disabled.

Stack policies are JSON documents that protect specific resources from updates, preventing, for example, an accidental replacement of a production database during an unrelated update.

Reuse, Modularity, and Multi-Account Patterns

Large environments avoid one monolithic template. Nested stacks factor reusable pieces (a standard VPC, a logging stack) into child templates referenced by a parent. Cross-stack references export an output ( Export ) from one stack and Fn::ImportValue it elsewhere — useful for sharing a VPC ID across many application stacks. For organization-wide rollout, StackSets integrate with AWS Organizations so a new account automatically receives baseline stacks (guardrails, IAM roles, logging).

Common Traps

  • Scenario Wrong instinct Correct answer
  • Same template, many accounts/Regions Loop a script StackSets
  • See changes before applying Just update and watch Change Set
  • Find out-of-band manual edits Change Set Drift detection
  • Preserve a database on stack delete Hope it survives DeletionPolicy: Retain/Snapshot
  • Author IaC in TypeScript Hand-write YAML AWS CDK (synthesizes CFN)

Knowing that CDK and SAM both compile down to CloudFormation is the key conceptual takeaway: they change the authoring experience, not the underlying provisioning and state-management engine, which remains CloudFormation across all of them.

Parameters, Pseudo-Parameters, and Reuse Mechanics

Templates become reusable through Parameters (typed inputs like String , Number , or AWS-specific types such as AWS::EC2::KeyPair::KeyName that the console validates against your account) and Mappings (static lookups, classically an AMI ID per Region). Pseudo-parameters such as AWS::Region , AWS::AccountId , and AWS::StackName are supplied automatically and let one template adapt across Regions and accounts without editing.

For sensitive inputs, mark a parameter NoEcho: true so its value is masked in the console and events, and reference values stored in AWS Systems Manager Parameter Store or Secrets Manager rather than hard-coding credentials. Conditions combined with Fn::If let a single template create a small footprint in dev and a full Multi-AZ footprint in prod from one parameter — a frequently tested way to keep environments consistent while varying scale.

Together these features mean one well-authored template can drive an entire fleet of stacks through StackSets, each parameterized per account and Region while sharing identical, version-controlled logic.