CloudFormation for CloudOps Certification: The Operational Study Guide

Why CloudFormation matters for CloudOps certification

CloudFormation is AWS's native infrastructure-as-code service. The certification path does not ask you to write a perfect template from memory. It asks what happens when an update fails, how to recover a drifted stack, when to use StackSets versus nested stacks, and how to protect stateful resources during deployment.

Think of CloudFormation as a desired-state control plane. You submit a template, CloudFormation provisions a stack, and every later action is a comparison between the template and reality.

[AWS CloudFormation concepts](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html)

The core model: template, stack, change set, drift

A template is a declarative YAML or JSON document. A stack is the live set of resources provisioned from that template. A change set is a preview of changes before an update executes. Drift is the gap between the template and the actual resource state.

The operational sequence that matters most for CloudOps:

1. Create a change set.

2. Inspect proposed changes for replacements.

3. Execute the change set.

4. Monitor the update.

5. Run drift detection after changes settle.

6. Remove old resources only after the new path is stable.

Example minimal template:

Resources:
  AppSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow HTTPS
      VpcId: vpc-0abc123def4567890
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0

Change sets and update semantics

A change set is a dry run, not a deployment. CloudFormation labels each resource update as one of:

Update with no interruption

Update with some interruption

Replacement

Create or Delete

For stateful resources, replacement is the main source of production incidents. If an update changes a property that forces replacement for an RDS instance or an EC2 instance with an instance store volume, CloudFormation replaces the resource unless a stack policy or `UpdateReplacePolicy` prevents it.

Use `aws cloudformation create-change-set` to create the dry run, then `aws cloudformation describe-change-set` to inspect it. Execute only after confirming that no protected resource is marked for replacement.

`aws cloudformation create-change-set --stack-name prod-api --change-set-name prod-api-add-queue --template-body file://template.yaml`

Stack policies: blast radius control

Stack policies are not IAM policies. They are attached to a stack and restrict updates to protected resource logical IDs. The classic exam scenario is allowing an update to an Auto Scaling group while preventing any update to the production database.

The mental model is simple: a Deny statement over `Update:*` for `LogicalResourceId/ProductionDatabase` means CloudFormation refuses to modify that resource during stack updates. If the resource must change, adjust the policy temporarily, perform the update, then reapply the protective policy.

[AWS stack policy docs](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/protect-stack-resources.html)

Drift detection: find the console changes

Drift is what happens when someone modifies a resource using the AWS Console, CLI, or SDK after CloudFormation created it. CloudFormation detects drift by comparing current state with the expected template state for supported resource types.

Important: drift detection is read-only. It does not remediate. You have to bring resources back to their template-defined state, update the template to match reality, or import the resource.

Exam answer pattern: if a security group rule changed manually and the stack is now inconsistent, run drift detection first. Do not assume the template is wrong or immediately run a broad update.

[AWS drift detection docs](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)

StackSets: multi-account, multi-region operations

Use StackSets when one template must deploy across many accounts or regions. The administrator account creates the StackSet; target accounts receive stack instances. Two permission modes exist:

Self-managed permissions: you create roles in admin and target accounts manually.

Service-managed permissions: use AWS Organizations and let CloudFormation manage the roles.

Operational knobs include `MaxConcurrentAccounts`, `FailureToleranceCount`, and region concurrency settings. If an operation fails in one region, the StackSet can roll back or continue depending on the failure tolerance.

For certification scenarios with AWS Organizations, service-managed permissions are usually the expected answer.

[AWS StackSets docs](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)

Nested stacks and modules

Nested stacks use the `AWS::CloudFormation::Stack` resource. They help when a single template grows beyond size limits or when you want reusable infrastructure components. The parent stack passes parameters to the child; child outputs become accessible to the parent.

Use nested stacks when you need separate lifecycle boundaries within one account and region. Use StackSets when the target is multi-account and multi-region. This distinction is heavily tested.

CloudFormation modules are reusable template fragments registered in the CloudFormation registry. They are less commonly tested than nested stacks, but they appear in automation-heavy environments.

Rollback and deletion semantics

Create failure: default behavior is `ROLLBACK`. CloudFormation deletes the resources it created. You can set `OnFailure` to `DO_NOTHING` when you need to preserve partially created resources for debugging.

Update failure: CloudFormation rolls back to the last known good state by default. If the rollback also fails, the stack enters `UPDATE_ROLLBACK_FAILED`. You must resolve the underlying issue and use `ContinueUpdateRollback` to move the stack back to a stable state.

Deletion and replacement policies:

`DeletionPolicy` controls what happens when a resource is deleted.

`UpdateReplacePolicy` controls what happens when a resource is replaced during an update.

`Retain` keeps the resource, `Snapshot` creates a snapshot if supported.

Operational tooling

CloudFormation templates are code. At Sapior, we lint and test before applying because a bad YAML indentation is enough to put an entire stack into a failed state.

Use `cfn-lint` for static validation and `aws cloudformation validate-template` for schema-level validation. Use TaskCat to test actual provisioning. CloudFormation Guard can enforce policy-as-code rules on templates.

`cfn-lint template.yaml`

`aws cloudformation validate-template --template-body file://template.yaml`

[AWS cfn-lint](https://github.com/aws-cloudformation/cfn-lint)

Certification-focused study checklist

Define stack, change set, drift, and StackSet in one sentence each.

Know which resource updates cause replacement versus in-place update for EC2, RDS, S3, and Lambda.

Know how to protect a database from updates with a stack policy.

Know the default rollback behavior on create and update failure.

Know when to use StackSets versus nested stacks.

Know the difference between `DeletionPolicy` and `UpdateReplacePolicy`.

Know how to recover from `UPDATE_ROLLBACK_FAILED`.

Know how to use service-managed StackSets with AWS Organizations.

Know how to read a change set for replacement resources.

CloudFormation is not just a topic on the exam; it is the control plane that determines how safe your AWS operations are.