AWS CloudFormation Stack Creation, Updates, Change Sets, and Deletion – SAP-C02 Study Guide

Purpose of This Lesson

AWS CloudFormation lets you define AWS infrastructure in templates and deploy it as a managed stack. This lesson focuses on the operational workflow for creating a stack, updating it safely with change sets, observing resource events, and deleting the stack when it is no longer needed.

The same workflow applies to much more complex production environments. The example uses an Amazon EC2 instance, an EC2 security group, an Amazon EBS volume, and an Amazon S3 bucket.

Key Concepts

CloudFormation templates and stacks

A CloudFormation template describes the desired resources and their configuration. Templates are commonly written in YAML or JSON. YAML is often easier to read, particularly when templates contain intrinsic functions and nested properties.

A stack is the deployed instance of a template. CloudFormation tracks the resources declared in that template and manages their lifecycle as a group.

Templates can be supplied in several ways:

• Upload a local template file.
• Use a template stored in an accessible location such as Amazon S3.
• Start from a sample template.
• Build a template with the visual designer.

For practical engineering work, teams generally maintain templates as code and modify or reuse established templates rather than building infrastructure manually in the visual designer.

Resources, logical IDs, and physical IDs

Each resource in a template has a logical ID. The logical ID is the identifier used inside the template and by other resources that need to reference it.

CloudFormation also displays a physical ID after creating the resource. The physical ID identifies the actual AWS resource, such as:

• An EC2 instance ID.
• A security group ID.
• An EBS volume ID.
• An S3 bucket name.

The logical ID is stable within the template, while the physical resource may be replaced during an update if a property change cannot be applied in place.

Intrinsic references and dependencies

CloudFormation intrinsic functions allow resources to refer to other template resources. A common example is Ref, which can retrieve a resource’s identifier or another resource-specific value.

For example, an EC2 instance can reference a security group declared in the same template instead of hard-coding a security group ID. CloudFormation then understands the relationship and can create resources in a valid order.

An EBS volume must be created in the same Availability Zone as the EC2 instance to which it will be attached. The template can reference the instance’s Availability Zone so that the volume and instance remain aligned.

Dependencies can be:

• Implicit: Created through references such as Ref or Fn::GetAtt.
• Explicit: Declared with DependsOn when CloudFormation cannot infer the required ordering.

Stack creation and rollback

During stack creation, the Events view shows resource operations and status transitions. Typical statuses include creation in progress, creation complete, update in progress, and update complete.

By default, if stack creation fails, CloudFormation rolls back the operation and deletes resources that it created as part of the failed attempt. This prevents a partially deployed stack from being left behind, although it can make troubleshooting more difficult because failed resources may disappear.

For troubleshooting, CloudFormation provides options such as preserving successfully provisioned resources on failure in supported workflows. In production, choose failure behavior deliberately based on whether rapid cleanup or investigation is more important.

Change sets

A change set previews how a modified template differs from the currently deployed stack. It is not an update by itself.

A typical change-set workflow is:

1. Modify the template.
2. Create a change set for the existing stack.
3. Review the proposed additions, modifications, replacements, and deletions.
4. Execute the change set only after approving the impact.
5. Monitor stack events until the update completes or fails.

For example, changing a stack from an EC2 instance and security group to the same resources plus an EBS volume produces a preview showing the new volume and its attachment. The resources are not created until the change set is executed.

Change sets are particularly useful for detecting potentially disruptive changes, but they do not guarantee that an update will succeed. Some runtime conditions, service limits, or resource-specific failures are only discovered during execution.

Stack deletion and deletion policies

Deleting a stack normally deletes the resources managed by that stack. The actual behavior can be modified with a resource DeletionPolicy.

Common deletion policies include:

• Delete: Remove the resource when the stack is deleted. This is the default for many resource types.
• Retain: Keep the resource after the stack is deleted. The resource becomes unmanaged by that stack.
• Snapshot: Create a snapshot before deletion for resource types that support it.

Deletion is dependency-aware. For example, CloudFormation may remove an attached EBS volume before terminating the associated EC2 instance, depending on the resource relationships and policies.

A deletion that appears stuck should be investigated through stack events and status reasons. Common causes include retained resources, dependency conflicts, failed custom resources, or resources whose deletion is blocked by an external configuration.

Exam-Relevant Takeaways

• A CloudFormation stack is the deployed collection of resources represented by a template.
• A template update is not automatically a safe in-place change. Some property changes cause resource replacement, which can result in downtime or data loss.
• A change set previews intended changes but does not apply them until it is explicitly executed.
• Review change sets for additions, modifications, replacements, and removals before execution.
• CloudFormation uses references and dependencies to determine resource creation and deletion order.
• EBS volumes and their attached EC2 instances must be in the same Availability Zone.
• CloudFormation rollback can delete resources from a failed creation attempt.
• DeletionPolicy: Retain is important for data-bearing resources that must survive stack deletion, such as an S3 bucket or database.
• A logical ID identifies a resource in the template; a physical ID identifies the real AWS resource.
• An AMI ID is region-specific and can become outdated. Templates should use a valid AMI for the target Region and architecture.
• Opening SSH from 0.0.0.0/0 is technically valid but is generally an insecure design. Restrict access to a trusted CIDR, VPN, bastion, or Systems Manager Session Manager where appropriate.

Architecture Decision Guide

Requirement	CloudFormation approach	Important consideration
Deploy a repeatable group of AWS resources	Create a stack from a YAML or JSON template	Keep the template version-controlled and parameterized where appropriate
Review infrastructure changes before applying them	Create and inspect a change set	A change set previews changes but does not validate every runtime failure
Add a resource without replacing existing resources	Update the template and execute a change set	Confirm the new resource’s dependencies and required properties
Preserve data when deleting a stack	Apply DeletionPolicy: Retain or Snapshot where supported	Retained resources must be tracked and managed separately after deletion
Ensure resources are created in the correct order	Use references or DependsOn	Prefer implicit dependencies through resource references when possible
Attach an EBS volume to an EC2 instance	Set the volume Availability Zone from the instance’s Availability Zone	EBS volumes cannot be attached across Availability Zones
Allow administrative SSH access	Use port 22 in a security group	Avoid unrestricted internet access; use a narrowly scoped source or Systems Manager
Recover from a failed stack creation	Use rollback behavior and inspect stack events	Preserve resources during troubleshooting when investigation is required

Common Exam Traps

Confusing a change set with an executed update

Creating a change set only calculates and displays the proposed changes. The update begins only after the change set is executed.

Assuming every update is non-disruptive

CloudFormation may replace a resource when a property cannot be modified in place. A replacement can change the physical ID and may affect availability, data, or dependent resources.

Deleting a stack without protecting stateful resources

Stack deletion can remove resources such as S3 buckets, EBS volumes, or databases, depending on their deletion behavior. Use DeletionPolicy deliberately and verify resource-specific requirements.

Using an AMI from the wrong Region or architecture

AMI IDs are not universally portable. An AMI that works in one Region, account, or CPU architecture may be invalid in another deployment context.

Treating 0.0.0.0/0 as a harmless SSH setting

A security group rule allowing SSH from every IPv4 address exposes the service to the internet. The rule may satisfy a lab requirement but is not an appropriate default for a secure architecture.

Assuming rollback removes every related object

Rollback follows CloudFormation’s management and deletion rules. Retained resources, externally managed dependencies, and failed custom-resource cleanup can leave resources behind.

Ignoring stack events

The stack status alone may not explain a failure. Stack events and status reasons identify which resource failed and often provide the service error needed for remediation.

Real-World Engineer Notes

• Treat CloudFormation templates as application code: review them, test them, and store them in source control.
• Use parameters, mappings, Systems Manager Parameter Store values, or other controlled mechanisms instead of repeatedly editing Region-specific values such as AMI IDs.
• Use CloudFormation change sets as an approval checkpoint for production deployments.
• Establish a policy for stateful resources. A retained resource can protect data, but it can also create orphaned infrastructure and ongoing cost.
• Use stack termination protection for critical stacks when accidental deletion is a concern.
• Apply least privilege to CloudFormation deployments. A deployment role with narrowly defined permissions is easier to audit than relying on broad user permissions.
• For sensitive or production workloads, avoid direct public SSH when Systems Manager Session Manager or a controlled private access path can provide administration.
• Test updates in a non-production environment first, especially when changing properties that may trigger replacement.
• Monitor for resources that remain after deletion. Retained resources and manually created dependencies are outside the normal stack lifecycle.

Quick Reference Summary

• Template: Declarative YAML or JSON definition of infrastructure.
• Stack: Deployed collection of resources managed from a template.
• Logical ID: Template-level identifier used for references.
• Physical ID: Identifier of the actual AWS resource.
• Change set: Preview of a stack update; it requires explicit execution.
• Rollback: Cleanup behavior after a failed operation.
• Ref: Intrinsic function commonly used to reference another resource or value.
• DeletionPolicy: Controls whether a resource is deleted, retained, or snapshotted during stack deletion.
• Events: Primary place to monitor resource-level progress and diagnose failures.
• EBS placement rule: An EBS volume and its EC2 instance must use the same Availability Zone.

Flashcards

1. Q: What is a CloudFormation stack?

A: A deployed collection of AWS resources managed from a CloudFormation template.

1. Q: What does a change set do?

A: It previews the resource changes that would result from a modified template without applying them.

1. Q: What action applies a change set?

A: Explicitly executing the change set.

1. Q: What is the difference between a logical ID and a physical ID?

A: A logical ID identifies a resource in the template; a physical ID identifies the actual deployed AWS resource.

1. Q: How can CloudFormation infer resource dependencies?

A: Through intrinsic references such as Ref and attribute references such as Fn::GetAtt.

1. Q: When should DependsOn be used?

A: When an ordering dependency exists that CloudFormation cannot infer automatically.

1. Q: Why must an EBS volume share an Availability Zone with its EC2 instance?

A: EBS volumes are zonal resources and cannot be attached across Availability Zones.

1. Q: What commonly happens when stack creation fails?

A: CloudFormation rolls back and deletes resources created by the failed operation, unless different failure behavior is selected.

1. Q: Which deletion policy preserves a resource when its stack is deleted?

A: DeletionPolicy: Retain.

1. Q: What does DeletionPolicy: Snapshot do?

A: It creates a snapshot before deleting a supported resource.

1. Q: Why should a template’s AMI ID be checked before deployment?

A: AMI IDs are Region- and architecture-specific and may become invalid or outdated.

1. Q: Where should an engineer look for the cause of a failed stack operation?

A: The CloudFormation Events view and the resource status reason.

Practice Questions

Question 1

A solutions architect updates a CloudFormation template to add an EBS volume to an existing EC2 instance. The architect wants to inspect the proposed changes before anything is provisioned. What should be done?

A. Update the stack directly and monitor the Events tab
B. Create a change set and execute it immediately
C. Create a change set, review it, and execute it only after approval
D. Delete the stack and create a new stack from the updated template

Correct answer: C

Explanation: A change set provides a preview without applying the update. Execution is a separate step, allowing the architect to review resource additions, modifications, and replacements first.

Question 2

A CloudFormation template creates an EC2 instance and an EBS volume. The volume is created in a different Availability Zone from the instance, and the stack update fails. What is the most likely cause?

A. EBS volumes must use a different Availability Zone from the instance
B. EBS volumes are zonal and must be in the same Availability Zone as the instance
C. EBS volumes can only be created by EC2 user data
D. CloudFormation cannot manage EBS volumes

Correct answer: B

Explanation: EBS volumes are tied to a single Availability Zone. The volume must be created in the instance’s Availability Zone before it can be attached.

Question 3

A company deletes a CloudFormation stack containing an S3 bucket with important log data. The company wants the bucket and its contents to remain after stack deletion. Which configuration best meets the requirement?

A. Add DeletionPolicy: Retain to the bucket resource
B. Add DependsOn to the bucket resource
C. Create a change set before deletion
D. Enable rollback on the stack

Correct answer: A

Explanation: DeletionPolicy: Retain causes CloudFormation to leave the bucket in place when the stack is deleted. The bucket then requires separate lifecycle and governance management.

Question 4

A stack creation fails halfway through deployment. The operations team wants to determine why a security group was created but the EC2 instance was not. Which source provides the most useful initial diagnostic information?

A. The S3 console
B. CloudFormation stack events and the failed resource’s status reason
C. The account’s billing dashboard
D. The CloudFormation template’s file name

Correct answer: B

Explanation: Stack events show resource-level status transitions and error messages. The failed resource’s status reason commonly identifies the immediate cause of the failure.

Question 5

A development template permits SSH access from 0.0.0.0/0 to simplify testing. The same template is proposed for a production workload. What is the best architectural recommendation?

A. Keep the rule because security groups automatically block malicious clients
B. Change SSH to port 80
C. Restrict the source CIDR or use a controlled private administration path such as Systems Manager Session Manager
D. Remove the security group and rely on the default VPC security group

Correct answer: C

Explanation: SSH should not be broadly exposed to the internet. Restricting the source or using a private, auditable administration mechanism reduces attack surface and improves operational control.