Plan, Apply, and Destroy

What you will be able to do

• Distinguish configuration intent from state context in a realistic plan, apply, and destroy case.
• Interpret the delivery evidence and boundary associated with plan review.
• Choose an appropriate action involving apply execution without exceeding the named operational scope.
• Verify destroy boundary through an observable service result and reproducible handoff.

01

Frame Plan, Apply, and Destroy

Use the OpenTofu plan, apply, and destroy workflow to separate preview from mutation, approve exact actions, and protect resource scope during removal.

A test environment needs one server added, reviewed, and later removed. The operator must prevent an unrelated shared network from entering the change scope.

Keep the delivery target, declared intent, execution evidence, reliability boundary, and recovery choice separate. Start with observable state and preserve enough context for another operator to reproduce the decision.

02

Configuration intent

Configuration defines the desired resource arguments evaluated by the workflow. Within plan, apply, and destroy, this role answers a separate delivery or reliability question and keeps its own evidence.

Add only the test server declaration to the reviewed module. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not edit the shared network ownership during this task. The observable result is specific: the configuration diff contains one bounded server change.

03

State context

State connects resource addresses with remote object identities and recorded attributes. Within plan, apply, and destroy, this role answers a separate delivery or reliability question and keeps its own evidence.

Confirm the selected backend and workspace before planning. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not apply against an unidentified state collection. The observable result is specific: the state context belongs to the test environment.

04

Plan review

A plan previews the actions OpenTofu proposes without applying those infrastructure mutations. Within plan, apply, and destroy, this role answers a separate delivery or reliability question and keeps its own evidence.

Review every action and important property before approval. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not approve a plan containing an unexplained replacement or deletion. The observable result is specific: the saved decision contains only the expected server creation.

05

Apply execution

Apply executes an accepted plan and updates state as operations complete. Within plan, apply, and destroy, this role answers a separate delivery or reliability question and keeps its own evidence.

Apply the reviewed plan and retain its result evidence. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not alter configuration between saved plan review and apply. The observable result is specific: the test server is created and state records it.

06

Destroy boundary

Destroy proposes removal of resources managed by the selected configuration and state scope. Within plan, apply, and destroy, this role answers a separate delivery or reliability question and keeps its own evidence.

Review the removal plan and prove the shared network is excluded. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not run destroy from an uncertain directory or workspace. The observable result is specific: only the owned test server is removed and verified absent.

07

Apply Plan, Apply, and Destroy to One Service Change

Use one bounded delivery decision: A test environment needs one server added, reviewed, and later removed. The operator must prevent an unrelated shared network from entering the change scope.

First, add only the test server declaration to the reviewed module. Then, confirm the selected backend and workspace before planning. Keep both observations attached to the exact revision, environment, or service window.

Next, review every action and important property before approval. After that, apply the reviewed plan and retain its result evidence. Close the work only after you review the removal plan and prove the shared network is excluded.

08

Recap Before Practice and Prove

Configuration intent: Configuration defines the desired resource arguments evaluated by the workflow. In this service case, add only the test server declaration to the reviewed module. Preserve the boundary: do not edit the shared network ownership during this task.

State context: State connects resource addresses with remote object identities and recorded attributes. In this service case, confirm the selected backend and workspace before planning. Preserve the boundary: do not apply against an unidentified state collection.

Plan review: A plan previews the actions OpenTofu proposes without applying those infrastructure mutations. In this service case, review every action and important property before approval. Preserve the boundary: do not approve a plan containing an unexplained replacement or deletion.

Apply execution: Apply executes an accepted plan and updates state as operations complete. In this service case, apply the reviewed plan and retain its result evidence. Preserve the boundary: do not alter configuration between saved plan review and apply.

Destroy boundary: Destroy proposes removal of resources managed by the selected configuration and state scope. In this service case, review the removal plan and prove the shared network is excluded. Preserve the boundary: do not run destroy from an uncertain directory or workspace.