# Do not let the next apply undo incident containment

Before resuming deployments, compare emergency cloud changes with the checked-in definition. Preserve the intended protection through a reviewed reconciliation.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Pause the conflicting automation

If a deployment would overwrite an active containment measure, pause that affected path under the incident procedure. Keep unrelated safe work separate where the scope is clear.

Record the live change, its purpose and the person responsible for the incident decision. A console screenshot alone may not show the full resource state or dependency.

Capture enough evidence to reproduce the intended configuration without exposing secrets.

## Determine the lasting state

Ask whether the emergency change should remain, be narrowed or be removed after another fix. The incident owner and service owner should agree on that decision.

For example, a temporary network restriction may be needed until a vulnerable endpoint is patched. Restoring the old rule before the patch is verified would reopen the problem.

Set a condition for removal rather than leaving an indefinite comment that the rule is temporary.

## Reconcile code and managed state

Update the maintained definition to express the chosen configuration or prepare a deliberate reversal. Use the infrastructure tool's supported process for any state reconciliation.

Inspect the resulting plan for replacement, deletion and unrelated changes. A refresh-only operation can update recorded observations without adopting the same values into configuration, so verify what the next normal plan will do.

Keep the reviewed artefact tied to the intended code and current environment. Re-plan when intervening changes invalidate the earlier evidence.

## Resume with verification

Apply through the normal controlled path and check both the containment requirement and application health. Re-enable scheduled deployment work only once it will preserve the intended state.

Close temporary access and update the incident record with the code change and final configuration.

If the same kind of emergency edit recurs, improve the normal delivery or containment tooling. The goal is to make urgent action supportable without leaving every future deployment dependent on someone remembering a console change.

## Sources

- [HashiCorp: managing resource drift](https://developer.hashicorp.com/terraform/tutorials/state/resource-drift)