Execution Planning and State Control
🌟 Objective
Ensure that all Infrastructure as Code (IaC) projects maintain consistent, secure and traceable control of the infrastructure state and of the execution plans (plan) generated before any change.
This practice makes it possible to:
- Prevent drift and unauthorised changes;
- Avoid concurrency and conflicts between multiple operators;
- Enable secure auditing and rollback;
- Enable integration with CI/CD pipelines and approval processes;
- Ensure integrity and compliance with execution policies.
📌 What must be done
- Configure an authenticated remote backend to store the state (
terraform.tfstate, or equivalent);
- Enable a locking mechanism to avoid concurrency during
apply;
- Generate and version execution plans (
plan) before applying changes;
- Associate
plans with approval mechanisms (e.g. Pull Request, Change Request);
- Store plan artefacts and execution logs with verifiable integrity;
- Detect and alert on drift (the difference between actual and expected state);
- Prohibit manual local executions outside a validated and controlled context.
⚙️ How to apply
| Action | Prescription |
|---|
| Remote backend | S3 + DynamoDB (AWS), Azure Blob + CosmosDB, or GCS, with strong authentication |
| Locking | lock = true + a mechanism such as DynamoDB, Consul or equivalent |
| CI/CD execution | Prohibit manual apply; plan generated and versioned in the pipeline |
| Traceability | Tags, branches, PR/MR ID, release name and readable output in the diff |
| Auditing | Keep plan and logs with hashes and metadata (timestamp, hash, author) |
| Drift detection | terraform plan -detailed-exitcode, driftctl, tfsec, or scheduled CI |
🕒 When to apply
| Moment | Expected action |
|---|
| Start of the IaC project | Define and document backend, environment and locking |
New apply in production | Generate plan, submit for approval, version the artefact |
| After a rollback, error or patch | Validate the current state and correct any divergence |
| Periodically (e.g. scheduled CI) | Check for drift between expected state and reality |
👥 Profiles involved
| Role | Responsibility |
|---|
| DevOps/Cloud | Backend configuration, execution via pipeline |
| Security | Definition of the controlled execution policy |
| Architecture | Approval of environments and isolation mechanisms |
| GRC/Compliance | Verification of traceability and audit mechanisms |
🧪 Practical examples
terraform backend "s3" with encrypt = true, lock_table and versioning;- Pipeline with a job that runs
terraform plan, stores the .plan and waits for approval before apply;
- DynamoDB table configured for locking, with TTL and per-project tags;
- Storage of plans and logs in a versioned bucket (
branch + timestamp + PR as the artefact name).
✅ Good practices
- Never execute
terraform apply locally in production environments;
- Validate and record
plan before any significant change;
- Use artefacts with integrity hashes and cross-traceability with the PR or release;
- Periodically monitor divergences between the actual and the expected state (drift detection);
- Establish a formal organisational policy on controlled infrastructure execution.
🔗 Cross-references
| Document | Relation to this practice |
|---|
08-rastreabilidade-vulnerabilidades.md | Reinforces auditing and traceability |
04-integracao-ci-cd.md | Automated execution and validation of plans |
02-matriz-requisitos-iac.md | Requirements IAC-001, REQ-004, REQ-005 |
| SSDF (PW.5) / SLSA (Build L2) | Normative requirements on controlled execution |
🔐 This control is essential to ensure integrity, traceability and compliance in the lifecycle of infrastructure as code - being one of the pillars of maturity in secure IaC according to the SbD-ToE model.