Domain Retirement Guard: Log Intent Before a Destructive Automation Operation

There is a subtle concurrency requirement behind this example. Completed plus RecordBeforeExecution must be backed by a store that can claim an operation ID atomically; two workers cannot both pass a read and then create independent claims. The interface is abbreviated so the deletion policy remains visible, but the production implementation should make the claim unique and treat the operation ID as immutable. Reusing an ID for a different zone must be rejected. I’m not sure which transaction primitive fits your control plane without seeing its datastore; a uniqueness constraint, conditional write, or compare-and-set can each work if the claim and its target are bound together.

Test refusals before testing success

The test matrix should begin with cases that never call ZoneRemover: platform-owned zone, absent approval, empty operation ID, a customer-owned zone outside the allowlist, and an operation ID already bound to another target. Then test the happy path and duplicate delivery. This ordering matters because a mock that merely confirms one successful call can leave the actual guard untested.

Use example data that resembles the production boundary. A table makes the review compact:

Also inject failures into the intent store. If recording intent fails, deletion must not begin. Verify that invariant directly with a remover that counts calls. For retry tests, deliver the same operation ID twice and assert that a completed operation does not produce a second removal call. Then race two workers against the same ID; this is where an in-memory test double can give false confidence if it does not model atomic claims.

Watch the denials in production. Counters by reason are useful, but zone names may be sensitive operational data, so put full targets in the access-controlled intent record rather than in every metric label. Alert on repeated ownership mismatches and out-of-scope requests. A single rejection may be an operator correcting a plan; a run of them can mean the migration inventory was built from the wrong account or dataset.

Release the migration as a bounded change

Generate the allowlist from the reviewed migration plan, freeze it for the run, and show a dry-run diff before accepting approval. The approval should cover that immutable plan, not whatever a fresh discovery call happens to return later. If discovery changes after review, stop and produce a new plan.

Roll out with a small customer-owned batch and reconcile intent records against completed operations before expanding. Keep platform-owned zones in a separate inventory with no route to the removal adapter. After cutover, retain the audit record according to your organization’s policy and remove the temporary permission that allowed the migration worker to delete zones.

This is slower than a raw loop over provider results. Good. Destructive DNS automation should optimize for a bounded blast radius and an explainable decision trail; throughput comes after the guard can refuse the wrong work.

Sources

• https://datatracker.ietf.org/doc/html/rfc7489