cloud-resource-post-provisioning-validation-and-drift-detection

Cloud Resource Post-Provisioning Validation and Drift Detection

Purpose

Infrastructure-as-code declares intent, but the running cloud account is the only source of truth for what's actually there — and the two diverge constantly: a console click-fix during an incident that never made it back into Terraform, a policy exemption granted temporarily and forgotten, a resource created by an entirely separate pipeline or a different team that the "official" IaC state doesn't know about. Left unchecked, this drift compounds until nobody can say with confidence what a terraform apply will actually change, whether tag/policy guardrails from the landing zone are still being enforced, or whether a resource flagged in a security review was ever actually remediated. This skill covers detecting that divergence — via terraform plan drift detection, AWS Config conformance packs, Azure Policy compliance scans, and tag/policy checks against a declared baseline — as a recurring operational practice, distinct from validating a deploy's success at deploy time (covered in the CI/CD-specific skills) and distinct from designing the guardrails being checked against (covered in the landing-zone skills).

When to use

• Confirming that infrastructure provisioned by a recent change (a Terraform apply, a manual console change, an incident hotfix) matches what was actually intended/declared.
• Running a scheduled or ad hoc drift check to catch out-of-band console changes before they cause a surprising terraform apply diff later.
• Auditing tag/label compliance against the organization's tagging policy (see cloud-cost-finops-optimization) or Azure Policy/AWS Config/GCP Organization Policy compliance.
• Investigating "why does the console show a resource/setting Terraform doesn't know about" or "why did terraform plan show unexpected changes on an otherwise-untouched module."
• Preparing evidence for a compliance/security review that guardrails (encryption-at-rest, public-access blocks, required tags) are actually enforced across the account/subscription, not just declared in policy documents.
• Validating, after a landing-zone or IAM-hardening change, that the new guardrail is actually taking effect on real resources.