# Non-Destructive Automation Patterns Guide

Use this reference when designing AWS automation for reporting, evidence gathering, notification, approvals, and coordination without direct remediation or destructive mutation.

## What people get wrong

The lazy story is:

> It only automates an operator task, so it is safe.

Wrong. Automation changes risk shape. A read-only inventory flow can become destructive if it adds broad IAM, invokes remediation runbooks, changes approvals, or leaks sensitive evidence into messages.

Common bad assumptions:

- Systems Manager Automation is non-destructive by default.
- Step Functions orchestration is safe because each step is small.
- EventBridge rules cannot cause incidents if the target is serverless.
- Notifications may include raw logs, ARNs, account IDs, or secret-looking values.
- Manual approval steps are enough without least-privilege execution roles.
- Retry policies are harmless for ticket creation or notifications.

## Automation-specific failure modes

- Runbook step calls mutating APIs such as update, delete, stop, detach, revoke, or put-policy.
- Lambda or Step Functions role has wildcard permissions beyond read/report/notify.
- EventBridge rule fans out noisy events into duplicate tickets or alert storms.
- SNS/SQS messages expose sensitive log excerpts or customer identifiers.
- Approval path is bypassable because the automation role can execute the final action directly.
- Retry/catch logic hides partial failure or repeats side effects.

## Minimum safe workflow

1. Classify every step as read, calculate, notify, approve, ticket, or mutate.
2. Reject or isolate mutate steps; this skill should design non-destructive flows only.
3. Choose the simplest orchestration: EventBridge schedule/rule, Lambda report, Step Functions approval flow, SNS/SQS fanout, or Systems Manager Automation read-only runbook.
4. Define least-privilege role boundaries and data-redaction rules before workflow shape.
5. Add idempotency, deduplication, retry limits, and failure visibility.
6. Make human approvals explicit and external to any role that could perform mutation.
7. Provide implementation guidance as design or repo patch only; live deployment remains approval-gated.

## Verification targets

- IAM policy actions: prove no destructive verbs are needed for the workflow
- EventBridge pattern/schedule and target list
- Step Functions states, retries, catches, approval waits, and terminal failure paths
- Lambda/reporting code paths and sanitized output fields
- Systems Manager Automation document steps and `assumeRole` permissions
- SNS/SQS topic/queue policy, retention, DLQ, and message content boundaries
- evidence contract: what is collected, redacted, stored, and sent to whom

## When to push back

Push back if the user asks to:

- include remediation in a non-destructive automation
- grant wildcard IAM because the workflow is “just reporting”
- send raw logs, credentials, account IDs, or customer data into notifications
- suppress alarms/tickets automatically instead of routing them
- make approval a checkbox while the automation can still mutate directly
- deploy the automation without testing event volume and retry behavior

# 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/systems-manager/latest/userguide/automation-troubleshooting.html
- https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html
- https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html
- https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.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:
- Systems Manager Automation troubleshooting highlights common failures such as IAM PassRole errors, assume-role misconfiguration, VPC errors, RunInstances failures, and timeouts.
- Automation runbooks can still perform mutations; non-destructive advisory work must distinguish read-only discovery from execution steps.

Sampled live evidence:
- Read-only regional availability sampling reported AWS Systems Manager as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `SSM+DescribeAutomationExecutions` and `SSM+GetAutomationExecution` were reported `isAvailableIn` in those regions.

Review implications:
- Recommend automation only after identifying read-only commands, mutation boundaries, approval gates, rollback path, and operator confirmation points.
- Do not present a runbook as safe because it is managed; inspect actions, permissions, targets, and outputs.

# Safety checklist

Use before recommending automation, escalation, or production-affecting follow-up from AWS Non-Destructive Task Automation 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 Non-Destructive Task Automation 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