The plan you reviewed should be the plan you apply

A Terraform plan can be technically exact and still sit behind a weak approval model.

That was the problem with storing a complete production variable document in a CI secret. The workflow could materialize the secret, produce a saved plan, and later apply that plan. What a reviewer could not do was inspect how the configuration itself had changed.

The plan was reproducible by the machine that received the secret. The decision was not reproducible by the person expected to approve it.

A secret is not reviewable configuration

Secret stores are good at withholding values. They are poor at explaining a proposed change.

A reviewer looking at an opaque settings field cannot answer:

• which production value changed;
• who proposed the change and why;
• whether the plan used the approved value;
• what configuration should be recovered after an incident; or
• whether a later apply used the same inputs that were reviewed.

Keeping the document on an operator laptop fails differently. The values are visible, but the laptop and its unreviewed file become part of ordinary delivery and disaster recovery. A fresh machine cannot reconstruct intent from the repository.

The useful distinction is not “secret” versus “Git.” It is secret values versus private configuration. Credentials belong in provider-native secret stores. Non-secret production coordinates may still be too revealing for a public repository, but they need version history, attribution, review, and recovery.

Review three things together

For RS Platform, the accepted design gives private Terraform configuration its own authority. A private repository holds one configuration document per stack and locks it to an exact commit of the public infrastructure source.

A useful review therefore covers three related artifacts:

1. the proposed configuration diff;
2. the exact infrastructure source commit; and
3. a redacted plan produced from those two inputs.

Approving only the source misses production configuration. Approving only the configuration misses the code that interprets it. Approving a plan summary without binding either input makes the summary a snapshot whose provenance must be taken on trust.

The review boundary is the tuple, not any one file.

Save the plan outside the CI interface

The binary plan is both necessary and sensitive. It is the exact action Terraform will take, but it can also contain private inventory or secret-derived data.

The design stores that plan in encrypted provider storage rather than CI logs, artifacts, comments, or caches. A manifest binds the plan to:

• the configuration commit and canonical configuration digest;
• the locked infrastructure commit;
• the stack and backend coordinates;
• the plan digest and encryption context; and
• the pull request that received review.

The pull request gets a redacted summary. The apply identity gets the binary plan. Neither surface needs to expose the other one’s full material.

That separation also limits authority. The plan role can create a candidate but cannot apply it. The apply role can retrieve an approved candidate but cannot silently substitute a new one.

Applying after review must not mean replanning

Replanning during the apply job feels harmless when the configuration appears unchanged. It still creates a new decision after the approval event.

Provider data may have changed. A dependency may resolve differently. The source or configuration may no longer match the reviewed commits. If the workflow runs terraform plan again, the operator did not approve the artifact being applied; they approved a related intention.

The safer contract is narrower:

Verify the reviewed provenance, then apply exactly the saved plan. If any binding is stale or mismatched, expire it and request another review.

Squash merges make this less trivial than comparing two commit hashes. The protected main commit is not the pull-request head. The workflow must prove merge provenance and reproduce the canonical digest of the authoritative documents. That complexity belongs in the delivery system rather than in an operator’s memory.

Recovery should start from authority, not a workstation

Remote review is also a recovery property.

A fresh checkout should be enough to identify the intended configuration, the infrastructure version it expects, and the remote state it controls. Bootstrap may establish the state backend, encryption, workload identities, and protected delivery environment. It should not become a standing alternate path for ordinary stack changes.

If disaster recovery depends on locating the last laptop with a complete .tfvars file, the configuration authority was never truly remote.

Pausing is part of the control

This design is accepted, but acceptance is not enablement. RS Platform’s remote Terraform delivery remains paused until the private configuration repository, immutable workload identity, protected environments, encrypted plan storage, redaction policy, exact-plan verification, recovery drill, and negative tests exist.

Static validation can prove that the Terraform source is coherent. It cannot prove that production configuration is reviewable or that an approved plan is the one an apply will consume.

That boundary is the point of the design. Approval is not the presence of a button between plan and apply. It is evidence that the exact proposed change survived intact from review to execution.