Beginner

Understanding Destructive Commands

Before you can protect your infrastructure, you need to know exactly which commands can destroy it. This lesson catalogs the most dangerous cloud CLI operations and analyzes their blast radius.

Taxonomy of Destructive Operations

Destructive operations across cloud providers use common verb patterns. Teach your team (and your AI agents) to recognize these keywords as danger signals:

Verb Pattern AWS CLI Azure CLI Google Cloud CLI
delete delete-*, remove-* delete, remove delete
destroy terminate-instances N/A (uses delete) N/A (uses delete)
purge N/A purge (Key Vault) N/A
remove deregister-*, remove-* remove remove-iam-policy-binding
force --force, --no-dry-run --yes, --force-string --quiet, --force

Irreversible vs Recoverable Operations

Not all destructive commands are equally dangerous. Understanding recoverability helps you prioritize your safety controls:

⚠
Irreversible Operations (No Undo):
  • gcloud projects delete — Entire GCP project gone after 30-day grace period
  • aws s3 rb --force — Bucket and all objects permanently deleted
  • az keyvault purge — Key Vault permanently destroyed (even soft-deleted keys gone)
  • terraform destroy -auto-approve — All managed resources destroyed without confirmation
✅
Potentially Recoverable Operations:
  • aws ec2 terminate-instances — Instance gone, but AMIs and EBS snapshots may survive
  • az group delete — Resources deleted, but some may have soft-delete enabled
  • aws rds delete-db-instance — Recoverable if final snapshot was created
  • gcloud compute instances delete — Instance deleted, but persistent disks can be preserved

Blast Radius Analysis

The "blast radius" of a command describes how many resources are affected by a single operation. This is critical for AI agent safety because agents often choose the most "efficient" (and broadest) command:

Single Resource (Low Blast)

aws ec2 terminate-instances --instance-ids i-abc123
Affects exactly one EC2 instance. Damage is contained and recoverable with AMI backups.

Resource Group (Medium Blast)

az group delete --name my-rg --yes
Deletes every resource inside the group — VMs, databases, storage, networking. Can affect dozens of services.

Account/Project Wide (High Blast)

gcloud projects delete my-project
Destroys the entire project including all resources, IAM bindings, APIs, and billing configuration.

Infrastructure State (Critical Blast)

terraform destroy -auto-approve
Destroys everything Terraform manages. If your state covers production, staging, and shared services, all of them are gone.

Common Dangerous Command Patterns

These are the specific commands that AI agents are most likely to run — and the damage they cause:

AWS - High-Danger Commands
# Delete ALL objects in a bucket, then the bucket itself
aws s3 rb s3://my-production-bucket --force

# Terminate multiple EC2 instances at once
aws ec2 terminate-instances --instance-ids i-abc123 i-def456 i-ghi789

# Delete an RDS database without final snapshot
aws rds delete-db-instance --db-instance-identifier prod-db \
  --skip-final-snapshot

# Delete a CloudFormation stack and all its resources
aws cloudformation delete-stack --stack-name production-stack

# Delete an EKS cluster
aws eks delete-cluster --name production-cluster
Azure - High-Danger Commands
# Delete entire resource group (cascading delete of all resources)
az group delete --name production-rg --yes --no-wait

# Delete a SQL database
az sql db delete --name prod-db --resource-group prod-rg \
  --server prod-sql --yes

# Delete an AKS cluster
az aks delete --name prod-cluster --resource-group prod-rg --yes

# Purge a soft-deleted Key Vault (truly irreversible)
az keyvault purge --name prod-vault
GCP - High-Danger Commands
# Delete an entire GCP project
gcloud projects delete my-production-project --quiet

# Delete a Cloud SQL instance
gcloud sql instances delete prod-instance --quiet

# Delete a GKE cluster
gcloud container clusters delete prod-cluster \
  --zone us-central1-a --quiet

# Delete a Cloud Storage bucket and all objects
gsutil rm -r gs://production-data-bucket
Terraform / Pulumi - High-Danger Commands
# Destroy ALL infrastructure managed by this state
terraform destroy -auto-approve

# Destroy specific resource (still dangerous if dependencies exist)
terraform destroy -target=aws_rds_instance.production -auto-approve

# Remove resource from state (orphans it - unmanaged but still running)
terraform state rm aws_instance.web_server

# Pulumi destroy all resources
pulumi destroy --yes --skip-preview

How Innocent Commands Become Catastrophic

Sometimes the danger is not obvious. These commands look harmless but can be devastating:

Seemingly Innocent But Dangerous
# "Just updating a security group" - removes all inbound rules
aws ec2 revoke-security-group-ingress --group-id sg-abc123 \
  --ip-permissions '[{"IpProtocol":"-1","IpRanges":[{"CidrIp":"0.0.0.0/0"}]}]'

# "Just cleaning up old snapshots" - deletes ALL snapshots
aws ec2 describe-snapshots --owner self --query 'Snapshots[].SnapshotId' \
  --output text | xargs -n 1 aws ec2 delete-snapshot --snapshot-id

# "Just resetting IAM" - removes all inline policies from a role
aws iam list-role-policies --role-name prod-role --query 'PolicyNames[]' \
  --output text | xargs -I {} aws iam delete-role-policy \
  --role-name prod-role --policy-name {}
💡
Next Up: Now that you understand the threat landscape, the next lesson covers the first line of defense: configuring least-privilege permissions so AI agents cannot execute these destructive commands even if they try.