Infrastructure as Code Security: Drift, State Files and Policy as Code

Infrastructure as code means your servers, networks and firewall rules are defined in text files that live in version control, and a tool builds the real thing from those files. That single change — infrastructure described in reviewable, diffable text — is what makes cloud environments auditable at all. It also introduces failure modes that do not exist when someone clicks through a console.

Declarative vs Imperative

This distinction shows up on Cloud+ and Security+ alike.

Declarative code describes the end state: "there should be three web servers in this subnet with this security group." The tool compares that to reality and makes whatever changes close the gap. Terraform and CloudFormation work this way.

Imperative code describes the steps: install this package, edit this file, restart this service. Shell scripts are imperative; Ansible playbooks sit closer to declarative but can do either.

Declarative is generally preferred for infrastructure because it is idempotent — running it twice produces the same result as running it once. Imperative scripts frequently are not, which is how you end up with a service installed three times.

Configuration Drift

Drift is the gap between what the code says and what is actually running. It appears the moment someone makes an emergency change in the console at 2 a.m. and never puts it back into the repository.

Drift matters for security because it silently invalidates your evidence. Your code says port 22 is closed to the internet. An auditor reads the code and agrees. The live security group says otherwise, because someone opened it for troubleshooting nine months ago.

Two defenses:

• Drift detection — run a plan or diff on a schedule and alert when reality and code disagree.
• Immutable infrastructure — never patch a running instance. Build a new image, deploy it, destroy the old one. Drift cannot accumulate on a server that only lives for a week.

Immutable deployment depends on elastic capacity, which is why it pairs naturally with rapid elasticity.

State Files Are Credentials

Declarative tools keep a state file mapping code resources to real cloud objects. That file routinely contains database passwords, generated keys and connection strings in plaintext, because the tool needed those values to create the resources.

The recurring mistake is committing state to the same Git repository as the code. Store it in an encrypted remote backend with access control and locking instead, and keep real secrets in a dedicated secrets manager that the code references rather than embeds.

Scan the repository itself too. Hard-coded keys in IaC files are among the most common findings in public repository leaks, and they are trivially discoverable at scale.

Policy as Code

If infrastructure is code, the rules it must satisfy can be code as well. Policy-as-code engines evaluate a proposed change before it is applied and block anything that violates a rule: no unencrypted storage buckets, no security group open to 0.0.0.0/0 on management ports, no untagged resources.

This is preventive rather than detective control, and it is a meaningful upgrade over the older model of scanning production and filing tickets. It is the same philosophy as SCAP-based configuration assessment, moved earlier in the lifecycle.

Where IaC Fits in the Pipeline

A mature pipeline runs several checks before anything is deployed:

• Static analysis of the IaC templates for insecure settings
• Secret scanning on the commit
• Policy evaluation against the plan output
• Container image scanning where the deployment ships images
• Dependency and SBOM generation for what the infrastructure will run

Note what is missing from that list: manual review as the only gate. Human review still matters, but it does not scale to a hundred merges a week and it does not catch a subtly wrong CIDR block reliably.

Shared Responsibility Still Applies

IaC does not change who owns what. The provider secures the hypervisor and the physical estate; your templates decide whether the storage bucket is public. Misconfiguration remains the dominant cause of cloud data exposure, and IaC makes misconfiguration repeatable — one bad module replicated across thirty environments. Review the shared responsibility model with that in mind, and the same logic extends across providers in multi-cloud deployments.

Exam Focus

Expect to identify drift from a scenario describing a working environment that no longer matches its documentation. Expect declarative versus imperative and idempotency as direct definitional questions. Expect state file exposure as the answer when a scenario mentions credentials found in a repository. And expect immutable infrastructure as the mitigation when the problem is accumulated manual change.

The short version: IaC makes your infrastructure reviewable, which is the prerequisite for making it secure. It does not do the second part for you.