# Change Impact Assessment Guide

Use this reference when assessing planned AWS changes, rollback readiness, blast radius, maintenance windows, change calendars, dependency risk, and go/no-go recommendations.

## What people get wrong

The lazy story is:

> If the deployment tool accepts the change, impact is understood.

Wrong. Tool acceptance is not impact analysis. A valid change can still replace stateful resources, breach a freeze window, break downstream consumers, or leave the business without a rollback decision.

Common bad assumptions:

- A CloudFormation change set, Terraform plan, or pipeline diff is automatically business-safe.
- Low line-count equals low blast radius.
- Rollback exists because Git can revert the commit.
- Change calendars and maintenance windows are scheduling details, not controls.
- A service owner approval covers dependent teams.
- Read-only evidence from one Region proves global readiness.

## Change-specific failure modes

- Change set or plan hides replacement, delete, interruption, or data-retention risk.
- Dependency owners are missing for shared VPCs, IAM roles, KMS keys, event buses, queues, DNS, or certificates.
- Rollback requires data migration reversal, alias retargeting, previous image digests, parameter restoration, or manual state repair.
- Maintenance window conflicts with business freeze, AWS Health event, support case, or downstream release.
- Monitoring and alarms do not cover the changed path.
- Approval is given by the implementer instead of an accountable service owner.

## Minimum safe workflow

1. Identify the change type, target account/Region/environment, owner, and requested execution window.
2. Gather repository diff, change set/plan if available, affected services, dependencies, and rollback artifact.
3. Classify blast radius: customer-facing, data-bearing, identity/network, cost-affecting, or control-plane only.
4. Check scheduling controls: change calendar, maintenance window, freeze period, AWS Health context, and stakeholder availability.
5. Separate confirmed evidence from assumptions; do not fill unknowns with optimism.
6. Return a go/no-go recommendation with blockers, conditions, rollback notes, and communication plan.
7. Keep the role advisory; do not approve or execute the change from this skill.

## Verification targets

- change set, Terraform plan, CDK diff, SAM/CloudFormation diff, or pipeline release notes
- resource replacement/delete/interruption indicators
- rollback artifact: previous template, alias target, image digest, parameter set, migration rollback, or restore point
- impacted AWS services, accounts, Regions, VPCs, IAM principals, data stores, queues, DNS records, and certificates
- maintenance window, Change Calendar/Change Manager request, approval record, and on-call coverage
- CloudWatch alarms, AWS Health events, support cases, and incident backlog relevant to the change window

## When to push back

Push back if the user asks to:

- declare low risk from a diff without blast-radius evidence
- ignore replacement/delete risk because validation passed
- proceed without owner approval or rollback artifact
- execute during a freeze, health event, or unresolved incident without risk acceptance
- treat advisory review as deployment approval
- hide unknowns from stakeholders

# Official sources

Use this reference when grounding current AWS service behavior for this role.

- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html
- https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/plan-your-change-management-strategy.html
- https://docs.aws.amazon.com/systems-manager/latest/userguide/change-calendar.html
- https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design_principles.html

## Grounding rule

Docs explain service behavior. They do not prove the user's deployed state, ownership, SLAs, budget posture, or current incident reality.
## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- CloudFormation drift-aware change sets support three-way comparison and can use `REVERT_DRIFT` to revert out-of-band changes where supported.
- Change-set and drift evidence is pre-change evidence only; it does not prove stakeholder approval, runtime health, or rollback readiness.

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

Review implications:
- Change sets and drift checks are evidence inputs, not approval by themselves.
- Require owner, blast radius, dependencies, rollback path, monitoring, communication plan, and explicit decision authority before go/no-go recommendations.

# Safety checklist

Use before recommending automation, escalation, or production-affecting follow-up from AWS Change Impact Advisor.

## Non-negotiables

- Do not ask for or print secrets, credentials, private keys, account numbers, customer identifiers, or unsanitized operational payloads.
- Keep this role non-destructive. Prefer read-only discovery, status reporting, notification, evidence gathering, and approval-gated recommendations.
- Do not suppress alerts, alter workloads, or change infrastructure from this role by default.
- Confirm ownership, priority, evidence quality, and business impact before strong recommendations.

## Evidence labels

Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.

# Workflow and output contract

Use this reference for full AWS Change Impact Advisor work.

## Workflow

1. **Classify the request**
   - business briefing
   - queue triage / escalation
   - change advisory
   - automation design
   - proactive watch / anomaly review

2. **Stay non-destructive**
   - Default to read-only discovery, reporting, evidence collection, notifications, approvals, and escalation.
   - Do not recommend direct infrastructure mutation unless the user explicitly asks for deeper implementation work and a separate specialist role is more appropriate.

3. **Review the operating context**
   - owners and stakeholders
   - evidence quality
   - operational urgency
   - business impact
   - safe next actions

4. **Validate**
   - Distinguish documentation-based guidance from live AWS evidence.
   - Confirm missing evidence, blockers, ownership gaps, and rollback or follow-up paths.

## Output contract

Return:

1. Scope and evidence level
2. Main risks / blockers
3. Business or operational impact
4. Safe next actions
5. Escalation or rollback path