# Rehearse your first approved fix

> Open a test security-group rule, let the agent prepare its fix, release it through one approval, roll it back and clean up.

_How-to · Updated 2026-10-24 · Describes release 0.1.164_

The smallest end-to-end fix to try on a new workspace: a world-open SSH rule on a test security group that nothing uses.

**Before you start:** it needs the AWS write connection from [Write connections and approved fixes](/help/setup-write-connections.md) with **Allow use for approved plans** on, **Platform checks (EST-01..06)** ticked on the read connection, and a person with `approvals.decide`.

## Rehearse one fix {#rehearse-one-fix}

1. In the write connection's account and region, create the tagged test group and open port 22 to any address:

   ```bash
   aws ec2 create-security-group --group-name aiops-rehearsal --description "AIOps rehearsal" \
     --vpc-id <vpc-id> --region <region> \
     --tag-specifications 'ResourceType=security-group,Tags=[{Key=aiops-managed,Value=true}]'
   aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 22 \
     --cidr 0.0.0.0/0 --region <region>
   ```

2. Under **Security posture → Audit & coverage → Frameworks**, press **Re-check automated controls** (`incidents.act`). The scan runs every automated control. Each check of your estate that fails opens its own incident and, when the check is P1 or P2 (a `high` check such as EST-03) and `aiops_compliance_auto_triage` is on (the default), one paid analysis of it, so a new account can start several; a P3/P4 check waits for **Analyse**. **You should see** EST-03 fail and an incident titled **[EST-03] No world-open security groups: …** under **Security posture → Posture**, with the test group under **Resources EST-03 flagged**. If other groups are listed too, the plan can name them as well: rehearse where the test group is the only one.
3. Wait for the analysis to finish; press **Analyse** on the incident if none started. An EST-03 incident opens at P2, so its fix is released at L2 on one approval. **You should see** a **Prepared change** whose **Exact changes and execution method** names `aws.security_group.revoke_ingress`, the test group's rule (`sgr-…`) and the write connection. If the incident also shows a **Recommended first** card, it pinned a recorded change as the suspect, most likely your own `authorize-security-group-ingress` from step 1; for this rehearsal the prepared fix is still the one to release.
4. Press **Review fix**, check the target, before-state and recovery plan, then **Approve & run**. An operator sees **Request approval** instead; an approver then opens it from **Needs you** and releases it on the incident. **You should see** the rule gone from the test group and, on the change's **Validation plan** card, a verdict badged **platform verdict** from the compiled read about 30 seconds after the write.
5. On the change, press **Roll back** and confirm (`approvals.decide`). A one-step plan whose before-state was captured restores the rule through the same write connection and reads it back. **You should see** the port-22 rule on the test group again.
6. Delete the test group with `aws ec2 delete-security-group --group-id <sg-id> --region <region>`. **You should see** EST-03 pass at the next platform check; an EST-03 incident still open then resolves.

## Next steps {#next-steps}

- [Change windows, emergency changes and rollback](/help/change-control.md) — when a release waits for a window, and what a rollback restores.
- [Runbooks and automatic fixes](/help/runbooks-and-automatic-fixes.md) — turn a fix you trust into a certified runbook.
- [Approve and run a fix](/help/approve-and-run-a-fix.md) — every action on the incident page, and who may release what.