Step 3 — Deployment Automation

Manual changes are how environments quietly drift apart until nobody trusts what’s actually running in production. This step is about the tooling that keeps infrastructure reproducible and patched, and lets you operate on fleets of instances without SSH keys scattered across a dozen laptops.

CloudFormation: Stacks, Change Sets, and Drift

A CloudFormation stack is a unit of deployed infrastructure defined in a template. The exam cares less about template syntax and more about the operational lifecycle around a stack once it exists.

Change Sets — Preview Before You Commit

Updating a stack directly is how you find out at 2 p.m. on a Friday that a property change requires replacing your production database. A change set shows you exactly what CloudFormation intends to do — modify in place, or replace the resource — before anything actually happens.

Current Stack                Proposed Template Change
──────────────                ─────────────────────────
RDS instance class:            RDS instance class:
db.t3.medium                   db.r5.large

              ┌──────────────────────┐
              │   Change Set Preview  │
              ├──────────────────────┤
              │ Action: Modify        │
              │ Replacement: False    │  ← safe, in-place resize
              └──────────────────────┘

vs.

              ┌──────────────────────┐
              │   Change Set Preview  │
              ├──────────────────────┤
              │ Action: Modify        │
              │ Replacement: True     │  ← new resource, old one deleted
              └──────────────────────┘

Some property changes force replacement (a new physical resource is created, the old one deleted) rather than an in-place update. Reviewing the change set’s Replacement field before executing is the difference between a routine deploy and an unplanned database rebuild.

Drift Detection — Finding What Console Cowboys Broke

Drift happens the moment someone edits a stack’s resource directly in the console instead of through the template — bumping a security group rule, changing an instance type, adjusting a tag. CloudFormation has no visibility into that change until you explicitly run drift detection, which compares the current live configuration against what the template declares.

Template declares:  SecurityGroupIngress → port 443 only
Live resource has:   SecurityGroupIngress → port 443, port 22 (added manually)

Drift Detection Result:
  Resource: WebServerSG
  Status: MODIFIED
  Property: SecurityGroupIngress
  Expected: [{Port: 443}]
  Actual:   [{Port: 443}, {Port: 22}]

Drift status comes back as IN_SYNC, MODIFIED, DELETED, or NOT_CHECKED (for resource types that don’t support drift detection at all — not every resource type does). Run drift detection on a schedule via EventBridge, not just reactively after an incident, so config drift surfaces before it causes one.

StackSets — One Template, Many Accounts and Regions

StackSets deploy a single template across multiple accounts and regions from one operation — the pattern for org-wide guardrails like a mandatory logging bucket, a baseline IAM role, or a security group standard that every account needs regardless of what team owns it. Updates propagate centrally rather than requiring per-account changes.

Systems Manager: The Operational Control Plane

Systems Manager (SSM) is less a single service and more a collection of operational tools unified under one console and one agent running on your instances.

Session Manager — Access Without the Key Sprawl

Session Manager gives you a shell into an instance through the SSM agent and IAM, with no inbound port 22 or 3389 required, no bastion host to maintain, and no SSH key to lose track of. Every session is logged — command history can stream to CloudWatch Logs or S3, which closes an audit gap that traditional SSH access usually leaves wide open.

Operator ──► IAM auth ──► SSM Service ──► SSM Agent (on instance)
                                                  │
                                     No open inbound ports required
                                     Session log ──► CloudWatch Logs / S3

For instances in fully private subnets with no NAT path, Session Manager still works via VPC endpoints for the SSM service — the agent talks to SSM over PrivateLink instead of the public internet, so “no internet route” is no longer a blocker for access.

Automation — Runbooks Instead of Tribal Knowledge

An Automation document (runbook) codifies a multi-step operational task — patch an AMI, remediate a non-compliant resource, rotate a credential, restart a service and verify health — as a repeatable, auditable workflow instead of a wiki page someone wrote two years ago and never updated.

Automation Runbook: "AMI-Patch-And-Test"
  Step 1: Launch instance from base AMI
  Step 2: Run Patch Manager baseline
  Step 3: Run smoke test script via Run Command
  Step 4: If pass → create new AMI
  Step 5: If fail → terminate, notify via SNS

Runbooks can trigger from a CloudWatch alarm, an EventBridge rule, or a Config compliance failure — turning “someone noticed and manually fixed it” into “the platform fixed it and told someone afterward.”

Patch Manager — Patching Without the Spreadsheet

Patch Manager applies OS and application patches on a schedule, governed by patch baselines that define what gets auto-approved and after how long. A common pattern: security patches auto-approve after 7 days (giving vendors time to catch showstopper bugs), while other updates wait longer or require manual approval.

Maintenance windows control when patching runs, and patch groups (via tags) let you stagger rollout — patch the dev fleet first, then a canary slice of production, then the rest — instead of patching every instance simultaneously and finding out the hard way that a patch breaks something.

Blue/Green vs Rolling Deployments

Both patterns solve “how do I ship a new version without an outage,” but they trade off differently.

ROLLING                              BLUE/GREEN
────────                              ──────────
Old  Old  Old  Old   (start)          Blue (100% traffic, old version)
New  Old  Old  Old   (batch 1)        Green (0% traffic, new version, fully deployed)
New  New  Old  Old   (batch 2)              │
New  New  New  Old   (batch 3)        Traffic cutover (instant or weighted)
New  New  New  New   (done)                 │
                                       Blue kept warm briefly for instant rollback

Rolling replaces capacity in batches — cheaper, since you’re not running two full environments, but rollback means rolling backward through the same batches, which is slower under pressure. Blue/Green stands up an entirely new environment and cuts traffic over, often via Route 53 weighted routing or an ALB target group swap — rollback is close to instant because the old environment is still sitting there warm, but you’re paying for double capacity during the transition window.

The exam scenario usually tells you which property matters more — “must roll back instantly” points to blue/green; “minimize cost during deployment” points to rolling.

Exam Focus: What Questions Test From This Step

• Reading a change set and identifying whether a property change causes replacement or an in-place update
• What drift detection actually compares, and the meaning of MODIFIED, IN_SYNC, DELETED, NOT_CHECKED
• StackSets as the tool for deploying one template across many accounts/regions
• Session Manager’s core value proposition: no open inbound ports, no bastion, full session logging
• How Session Manager reaches fully private instances via VPC endpoints
• Automation runbooks triggered by alarms, EventBridge, or Config remediation
• Patch Manager concepts: patch baselines, auto-approval delays, maintenance windows, patch groups for staggered rollout
• Choosing blue/green vs rolling based on rollback speed vs cost constraints in a scenario