HARBOR CLOUD / 05 / PRACTICE GUIDE
IaC, plan review and drift management
Move from formatting checks to actual change decisions. Assess Terraform plan/state sensitivity, the applied plan and console drift independently.
Download guide and workpapersOriginal AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.
CODE REVIEW DESK
See the decision through the test.
Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.
Right format, wrong plan / Weak code
Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.
s=>s.formattedFormatting does not establish that the reviewed plan was applied. Unknown risk values or a changed plan require review; this model does not execute Terraform.
Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.
01 / EXPLANATION
From source to applied change
Passing formatting or validation does not prove an appropriate business change. Review module origin, provider version, actual plan and unknown risk fields. Bind the plan applied in production to the reviewed plan; do not silently reuse approval after regeneration. This material runs no planning commands and searches no environment variables, cloud profiles or credentials.
02 / EXPLANATION
State and output sensitivity
Keeping state out of Git is insufficient protection. Design backend access, encryption, versioning, locking and audit together. Terraform show -json can expose sensitive values in plaintext; do not move real output into shared reports or this exercise. Use a fictional change table instead. Include backup state copies and CI artifacts in the sensitive-data inventory.
03 / EXPLANATION
Drift and emergency changes
An unchanged repository can coexist with a new console-created network rule. Track live differences, approval and reconciliation separately. Emergency changes need ownership, expiry and rollback. Do not assume a later plan deleting an unfamiliar change is automatically correct. Assess security and service impact before returning to approved state, and learn why manual intervention was needed.
04 / EXPLANATION
Worked example: a different plan after approval
A reviewer approves plan P1, then the pipeline changes a variable and generates P2. Formatting does not create approval for P2. appliedPlanMatched=false rejects this case. Adding state to .gitignore cannot fix a publicly readable backend; the second model exposes backend access. Record plan identity/digest, provider version, risk-field knownness and authorized decision in the workpaper. Examples use abstract evidence fields and do not claim to parse Terraform JSON plan format.
Build the evidence yourself.
Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.
Full guide with code, outputs and reasoning ↓Primary references
Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.