# IaC Change Risk Review Guide

Use this reference when reviewing CloudFormation, CDK, SAM, Terraform, Serverless Framework, change sets, drift, stack policies, StackSets, and production deployment preflights.

## What people get wrong

The lazy story is:

> The plan/change set is the source of truth, so read it and decide.

Wrong. Plans and change sets are necessary but not sufficient. They can miss live drift, parameter context, provider behavior, replacement side effects, data retention, and organizational guardrails.

Common bad assumptions:

- `No changes` means no operational risk.
- Replacement is acceptable if CloudFormation can perform it.
- Terraform destroy/create is safe when names stay similar.
- Drift is separate from the proposed change.
- Stack policies and rollback triggers are optional.
- IAM diffs can be reviewed by action count alone.

## IaC-review failure modes

- Resource replacement deletes state, changes DNS, rotates identity, or breaks consumers.
- IAM, KMS, security group, route, bucket, or trust-policy changes widen blast radius.
- Parameter/default changes alter multiple environments unexpectedly.
- StackSets or modules propagate a risky pattern across accounts/Regions.
- Drift means the apply will not behave like the repo diff.
- Rollback would fail because stateful resources, migrations, or retained resources are not handled.

## Minimum safe workflow

1. Identify IaC tool, target environment, account/Region scope, and deployment mechanism.
2. Review repo diff plus generated template/plan/change set, not only source files.
3. Classify each material change as add, modify, replace, delete, permission widen, exposure, stateful, or rollback-sensitive.
4. Check drift, parameters, stack policies, rollback triggers, and cross-stack/module dependencies where applicable.
5. Require validation evidence: lint, synth, plan/change set, policy checks, and test outputs.
6. Return go/no-go with blockers, risky resources, mitigation, owner, and rollback evidence.
7. Keep deployment/apply/destroy outside this review unless a separate guarded approval path is invoked.

## Verification targets

- CloudFormation/SAM template diff, change set replacement/delete details, drift detection, stack policy, rollback trigger, and events
- CDK synth/diff output, bootstrap environment, asset changes, and security approval prompts
- Terraform fmt/validate/plan, provider lockfile, state backend, targeted apply risk, and destroy/replacement markers
- IAM/KMS/security group/network/storage/database diffs and policy validation output
- StackSets, modules, nested stacks, parameters, exports/imports, and environment overlays
- rollback plan: previous template, state backup, retained resources, migration reversal, and data restore point

## When to push back

Push back if the user asks to:

- approve apply from source diff only
- ignore replacement/delete risk because validation passed
- skip drift detection for production stacks
- widen IAM/network controls as a quick fix
- use targeted apply/destroy without dependency analysis
- combine unrelated cleanup with a risky production change

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/drift-aware-change-sets.html
- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/event-detail-stack-drift-detection-change.html
- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html
- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-policy.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- CloudFormation drift-aware change sets support three-way comparison and `REVERT_DRIFT` for supported resources.
- CloudFormation drift-detection status change events expose drift status, drifted resource counts, operation status, and client request tokens as event evidence.

Sampled live evidence:
- Read-only regional availability sampling reported AWS CloudFormation and AWS Config as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `CloudFormation+CreateChangeSet`, `CloudFormation+DetectStackDrift`, and `CloudFormation+ValidateTemplate` were reported `isAvailableIn` in those regions.

Review implications:
- IaC safety review must inspect planned diff, replacement/delete risk, IAM/security policy impact, network exposure, data loss, drift, rollback, and approval evidence.
- A valid template or available change-set API does not prove the proposed change is safe.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- IaC engine, generated artifact, target account/Region/environment, and deployment mechanism
- Create/update/delete/replacement scope, drift state, stack policy, rollback triggers, and manual out-of-band changes
- IAM, KMS, security group, route, public exposure, data store, backup/logging, and secret changes
- Validation commands, change-set or plan evidence, approval gate, execution order, and rollback path

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS IaC Change Safety Review: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```