What is infrastructure as code?
Infrastructure as code (IaC) replaces clicking through a cloud console, or configuring servers by hand, with text files that describe the infrastructure. A file might declare two virtual networks, a load balancer, a database, the firewall rules between them and the permissions each component holds. A tool reads the file and creates or changes real resources until they match it. Because the definition is code, it lives in version control, is reviewed in pull requests and is applied by an automated pipeline, the same way application code is.
Common IaC tools
| Tool | Format | Notes |
|---|---|---|
| Terraform and OpenTofu | HCL | Work across many cloud providers; OpenTofu is an open-source fork of Terraform |
| AWS CloudFormation | JSON or YAML | AWS only |
| Azure Bicep and ARM templates | Bicep or JSON | Azure only |
| Ansible | YAML playbooks | Mostly configures existing systems over SSH or WinRM, with no agent installed |
Most of these are declarative: you state the end result and the tool works out the steps. Applying the same definition twice should leave the environment unchanged, a property called idempotence.
Why IaC helps security
- Consistency: every environment is built from the same reviewed definition, so test matches production and hardening is applied everywhere.
- Review and audit: every change is a commit with an author, a reviewer and a timestamp.
- Fast recovery: a destroyed or compromised environment can be rebuilt from code, then its data restored from backups.
- Early checks: insecure settings can be caught before anything is deployed.
Example: one template, three findings
A developer writes a Terraform resource for an orders database. An IaC scanner such as Checkov, Trivy or KICS, run on the pull request, would flag three of its lines:
publicly_accessible = truegives the database an internet-reachable address.storage_encrypted = falseleaves the data unencrypted at rest.password = "Orders2026!"hardcodes a credential that will stay in the repository history.
The module is reused by twelve teams, so merging it unchecked would create twelve exposed databases, and fixing the template fixes all of them. The password belongs in a secrets manager, referenced by name, and it has to be rotated, because deleting it from the file does not remove it from earlier commits.
IaC risks to manage
- Repeated mistakes: an insecure module spreads to every environment built from it.
- Secrets in code and state: Terraform state files can hold resource secrets in plain text, so state belongs in an encrypted remote backend with tight access.
- Powerful pipelines: the credentials that apply IaC can create or destroy everything, so the pipeline deserves the protection given to an administrator account.
- Third-party modules: community modules are dependencies; pin their versions and review them.
- Drift: changes made by hand in the console make the live environment differ from the code. A risky change, such as a port opened while troubleshooting, escapes review, and a protective one made by hand disappears at the next apply. Run drift detection on a schedule and write emergency fixes back into the code.
Infrastructure as code on the CompTIA Security+ exam
Infrastructure as code is one of the architecture models compared in SY0-801 objective 3.1. Scenario wording such as environments are built from templates stored in a repository or every new account gets the same network definition describes IaC, and the right controls are scanning templates before deployment, keeping secrets out of code, protecting the pipeline and detecting drift. A common trap is fixing a misconfiguration by hand in the console: the next deployment from the unchanged template puts the mistake back, so the fix belongs in the code. If live settings no longer match the template, the term is drift.