Why Cloud Engineers Explain Automation Scripts Aloud

WITHOUT EXPLAINING ALOUD:

You skim a Bash deploy script:

  set -e
  aws s3 sync ./build s3://prod-bucket --delete
  aws cloudfront create-invalidation \
    --distribution-id $DIST_ID \
    --paths "/*"

Your brain fills in the gaps:
"Looks fine. It syncs the build and
invalidates the cache."

You deploy.

2 minutes later:
- Wrong bucket (prod-bucket vs prod-bucket-v2)
- --delete wiped uploaded user files
- Invalidation hit a different distribution

Why it failed:
❌ Skimming hides wrong variable names
❌ --delete is destructive — you missed it
❌ No confirmation step before destructive sync

WITH EXPLAINING ALOUD:

You read the same script out loud:

"Set -e, so the script stops on any error.
Next: aws s3 sync from ./build to
s3://prod-bucket with --delete.

Wait — prod-bucket? Our production bucket
is prod-bucket-v2. And --delete will remove
anything in the bucket that isn't in ./build.
That includes user uploads.

I should:
- Fix the bucket name
- Remove --delete or scope it to a prefix
- Add a confirmation prompt

Then: aws cloudfront create-invalidation
for $DIST_ID, all paths. Let me check
DIST_ID is set for prod, not staging."

Why it works:
✅ Saying the bucket name out loud caught the typo
✅ Saying "--delete" out loud caught the destructive flag
✅ Saying "$DIST_ID" out loud prompted a check
✅ You fixed three bugs before deploying

TERRAFORM — READ ALOUD:

resource "aws_s3_bucket" "data" {
  bucket = "myapp-data-prod"
}

resource "aws_s3_bucket_versioning" "data" {
  bucket = aws_s3_bucket.data.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_public_access_block" "data" {
  bucket                  = aws_s3_bucket.data.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

WHAT YOU SAY ALOUD:
"This creates an S3 bucket called
myapp-data-prod in the default region.
Then it enables versioning — good, so
deletes are recoverable.
Then it blocks all public access.
What if the bucket already exists? The
resource will fail or try to adopt it.
What if someone uploads and we delete?
Versioning protects us. Blast radius:
this bucket holds production data — if
it's public, we leak customer data. The
public access block is critical."

WHAT IT CATCHES:
✅ Confirms region is set elsewhere
✅ Confirms versioning protects deletes
✅ Confirms public access is blocked
✅ Reminds you to check bucket existence

PYTHON BOTO3 — READ ALOUD:

import boto3

ec2 = boto3.client("ec2")

def stop_idle_instances():
    response = ec2.describe_instances(
        Filters=[{"Name": "instance-state-name",
                  "Values": ["running"]}]
    )
    for reservation in response["Reservations"]:
        for instance in reservation["Instances"]:
            tags = {t["Key"]: t["Value"]
                    for t in instance.get("Tags", [])}
            if tags.get("Environment") != "prod":
                continue
            if tags.get("AutoStop") == "true":
                ec2.stop_instances(
                    InstanceIds=[instance["InstanceId"]]
                )

WHAT YOU SAY ALOUD:
"It describes all running instances.
For each one, it reads tags.
If the Environment tag isn't 'prod',
skip it — good.
If AutoStop is 'true', it stops it.
Wait — what if tags are missing? Then
.get returns [], tags is empty, and we
hit the continue. Good.
What if AutoStop is 'true' but the app
is in the middle of a batch job? We stop
it. That's risky. I should add a check
for a 'DoNotStop' tag or a batch window.
Blast radius: this stops production
instances. If a tag is wrong, we could
take down a service."

WHAT IT CATCHES:
✅ Missing tag edge cases
✅ Risk of stopping active batch jobs
✅ Need for a kill-switch tag

TERRAFORM PLAN — READ ALOUD:

Terraform will perform the following actions:

  # aws_db_instance.main must be replaced
-/+ resource "aws_db_instance" "main" {
      ~ engine_version = "14.7" -> "15.2" # forces replacement
      ...
    }

  # aws_s3_bucket.logs will be destroyed
  - resource "aws_s3_bucket" "logs" {
      - bucket = "myapp-logs" -> null
    }

WHAT YOU SAY ALOUD:
"Two changes. First, the RDS instance will
be replaced because the engine version is
changing — that means the database is
destroyed and recreated. All data is lost
unless I've taken a snapshot.
Second, the logs bucket will be destroyed.
That deletes all log history.
Both of these are destructive. I need to:
- Take a manual snapshot before applying
- Or change the version in place instead
- Export logs before destroying the bucket
Blast radius: production database and
all historical logs."

WHAT IT CATCHES:
✅ Forced replacement = data loss
✅ Bucket destruction = log loss
✅ Need for snapshot + export before apply

IAM POLICY — READ ALOUD:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

WHAT YOU SAY ALOUD:
"This allows s3:* — that's every S3 action,
including DeleteBucket and PutBucketPolicy.
On Resource *, that's every bucket in the
account, including production buckets that
hold customer data.
If this policy is attached to a Lambda or
an EC2 role, a compromise means the attacker
can delete or exfiltrate every bucket.
Blast radius: the entire S3 footprint of
the account.
I should:
- Scope actions to the minimum needed
  (e.g., s3:GetObject, s3:PutObject)
- Scope resources to a specific prefix
- Add a condition (e.g., aws:SourceVpc)"

WHAT IT CATCHES:
✅ Wildcard actions and resources
✅ Blast radius of a compromised role
✅ Need for least-privilege scoping

Explain-Aloud Habit Checklist:

BEFORE RUNNING:
☐ Read the script/plan line by line aloud
☐ Say the blast radius out loud
☐ Ask "what if?" after each step
☐ Say the rollback plan aloud
☐ Say what's NOT in the plan

DURING REVIEW:
☐ Explain the change to a teammate aloud
☐ Say the data flow end to end
☐ Say the IAM and network boundaries
☐ Say the cost impact

AFTER DEPLOY:
☐ Say what changed in production
☐ Say the monitoring checks you'll watch
☐ Write a one-paragraph "what I explained" note
☐ Share the note in the PR or ticket

Why this works:
- Speaking slows you down
- Saying names catches typos
- Saying "delete" catches destructive actions
- Saying blast radius catches scope
- Saying rollback catches missing plans

30-DAY HABIT PLAN:

Week 1 — Terraform only
☐ Read every terraform plan aloud before apply
☐ Say "create", "update", "destroy", "replace" aloud
☐ Say the blast radius for each change

Week 2 — Add scripts
☐ Read every Bash/Python deploy script aloud
☐ Say destructive flags aloud (--delete, rm)
☐ Say what each variable holds

Week 3 — Add reviews
☐ Explain one PR aloud to a teammate
☐ Record yourself explaining a plan
☐ Listen back and note gaps

Week 4 — Make it routine
☐ Add "explained aloud" to your PR template
☐ Pair with a teammate weekly
☐ Write a short note after each deploy

Signs it's working:
✅ You catch a typo before running
✅ You catch a destructive flag
✅ You catch a missing rollback
✅ Reviews are faster and calmer
✅ Fewer "why did this change?" incidents