Intro to IaC

20 min readFeb 18, 2026

An introduction to infrastructure as code.

Introduction

If you aim to get into DevOps/DevSecOps, you may have encountered the term infrastructure as code (IaC). This is because IaC is a fundamental and integral part of DevSecOps. Due to the importance of this topic, there is no shortage of articles, blog posts or papers discussing IaC and its various uses in DevSecOps; however, these resources often brush past the many concepts and tools. This can leave DevSecOps newcomers confused over key IaC terms and lost on which IaC tools to use for what. This room will serve as a paced introduction to infrastructure as code and walk you through these key terms, giving you a foundational knowledge of IaC, which you can grow with the following rooms in this module.

Learning Objectives

Understand why IaC is needed
Understand IaC as a concept, the tools used and their characteristics
Understand the IaC lifecycle and the difference between provisioning and configuring, being able to identify tools for both
Understand how fundamental virtualisation is to IaC
Understand the difference between on-prem IaC vs cloud-based IaC and the benefits of each

IaC — The Concept

Infrastructure Before IaC

Before defining IaC, it’s important to understand why we need it. In other words, what problems is it solving?

Manually provisioning servers (physically installing servers or manually deploying virtual machines)
Network configuration (setting up a network for the infrastructure, including setting up IP addresses, subnets, routing tables and any network components that the infra needs like routers, switches or firewalls)
Installing an OS
Installation, configuration and updating of software (database, web server etc.)
Disaster recovery (DR) (this involves having a backup infrastructure on standby, making a detailed “failover” plan, and having clear procedures in place should the primary data centre go down).

Infrastructure as Code Explained

Instead of provisioning and managing infrastructure manually, as discussed above, infrastructure as code allows the automation of these tasks through code. This code can be used to define a “desired state” for the infrastructure, acting as a blueprint for IaC tools to provision the infrastructure. For example, you may define some resources in your code, such as network components, virtual machines, and a database. An IaC tool will build this blueprint and ensure the infrastructure is always in line with it. Should you want to make an infrastructure change, like increasing the number of VMs, only a simple change needs to be made to the code, which will be reflected in your infrastructure once applied. Compare this to what was previously required to add a VM, which would involve making a manual request through a portal and waiting for that request to be actioned by a systems administrator, and it becomes easy to see the utility of IaC.

The Many Benefits of IaC

Having infrastructure deployed from code also means it can be a collaborative process and a shared responsibility. This means knowledge of infrastructure and its configuration isn’t siloed to a single team member, avoiding knowledge dependencies whilst supporting continuous integration (CI). Continuous deployment (CD) is also supported through the ability to deploy consistent infrastructure across multiple environments. As well as reducing the manual efforts and risk of error, an IaC approach can make it possible to have a reliable infrastructure that is scalable, versionable, and repeatable.

Scalable

This technology begins to make even more sense when you consider the widespread adoption of cloud computing and its elastic nature, with virtual machines and resources being scaled up and down based on demand due to resources being billed per second/minute/hour. With IaC, you can do this scaling with a single command or even automate the process, whereas in the past, this would have involved weeks of work (e.g., logging tickets and manually provisioning and de-provisioning).

Versionable

Infrastructure as code should be treated as any other code and versioned using a version control system. Versioning an infrastructure means it’s self-documenting, allowing infrastructure changes to be tracked and recorded. This benefits the many teams that work with infrastructure with all sorts of tasks, from audits to troubleshooting infrastructure issues. Speaking of infrastructure issues, versioning also means that should your latest infrastructure start having problems, you can redeploy your infrastructure to the last known working version, an example of how IaC allows for reliable infrastructure. Versioning infrastructure can also improve testing capabilities; for example, an application can be tested using a historical infrastructure build.

Repeatable

In the dev world, it is common to work between multiple environments. Developers first build their code in a dev environment before testing it in a staging environment (which mirrors production) and finally deploying the fully functional and tested code into the production environment. In the past, these three environments would require the manual provisioning and configuration of 3 respective infrastructures. With IaC, you can use the same code/configuration to set up identical infrastructures across multiple environments with the push of a button. While saving massive amounts of time, this also ensures consistency/reliability across environments, which is critical when testing software and was very hard to achieve in the days of manual provisioning.

IaC in Practice

IaC is a powerful technology that can streamline and improve business-critical processes if used correctly. To demonstrate this utility, let us take one of the example responsibilities mentioned at the beginning of the task, disaster recovery, and examine how IaC can aid this process. As touched on above, disaster recovery is the process of restoring infrastructure after a catastrophic/disruptive event; for example, if you are working for a company that has a physical on-premises infrastructure located in a data centre, a disaster can range from a simple power outage to extreme examples such as natural disasters like wildfires or hurricanes bringing this “primary” data centre down. Failing over from this primary data centre to a secondary backup data centre, when done manually, is a very time-consuming, high-pressure situation which can lead to many issues. Here are a few ways in which IaC can help with disaster recovery:

Infrastructure Automation: Since IaC allows the automation of the provisioning and configuration of an infrastructure, reprovisioning and re-configuring an infrastructure in a backup data centre is streamlined and less time-consuming.

Data Backup and Recovery: Data loss or corruption is one of the most significant risks associated with disaster recovery and can be very costly to the affected company. Infrastructure as code can be used to automate the backup and recovery of data. Backup procedures can be defined in code, which will be triggered in the event of a disaster to ensure data is restored.

Failover Automation: During a disaster, critical services can become unavailable as they will point to the broken infrastructure. IaC can be used to automate the failover process so critical services use the backup infrastructure, which reduces downtime.

Configuration Consistency: IaC keeps infrastructure consistent and well-documented; this consistency is vital during the disaster recovery process and helps avoid misconfigurations (often caused by simple human error or lack of documentation on the current configuration) during the transition to a backup environment.

Scaling Resources: The recovery process can be resource intensive, and IaC can be used to scale resources to handle the increased workloads (and scale back down afterwards).

These are just some examples of how IaC can aid and streamline processes, with a wide range of teams benefitting from infrastructure as code’s versionable, scalable, and repeatable nature — saving them time and headaches.

Answers:

Your organisation is preparing to launch a new service called FlyNet. The DevSecOps team provisioned an infrastructure and tested this service in the dev environment. Which IaC characteristic will streamline the provisioning of this same infrastructure in staging and production?

Answer: Repeatable

It’s the day before launch, and the latest infra change has started producing strange errors, something about “destroying humanity”. Weird! Which IaC characteristic allows us to go back to the last known working version?

Answer: Versionable

It’s launch day, and it couldn’t have gone better; the service is almost running itself! The FlyNet launch has attracted a lot of new customers! Which IaC characteristic enables us to increase the resources available to our infrastructure to meet this increased demand with ease?

Answer: Scalable

IaC — The Tools Part 1

Get to Know Your Toolkit

Now that we’ve established what IaC is, we can start thinking about some of the tools used for infrastructure as code. Many tools fall under the IaC umbrella, including Terraform, AWS CloudFormation, Google Cloud Deployment Manager, Ansible, Puppet, Chef, SaltStack and Pulumi. It’s important to understand that some of these tools have different use cases, each with its own benefits. Due to the varied use cases of these IaC tools, having infrastructure provisioned, configured and deployed end-to-end will require using a combination of IaC tools rather than a single solution. To better understand these tools, this task will cover some of the key characteristics which distinguish these tools from each other so you know what tool to use and when. Bear in mind that the behaviour of these tools can often depend on exactly how they are used, often leading to debate over some of their characteristics; with this in mind, we will define those characteristics in question and how each tool is generally used.

Declarative vs. Imperative

Declarative

This involves declaring an explicit desired state for your infrastructure, min/max resources, x components, etc.; the IaC tool will perform actions based on what is defined. A state file is kept to ensure your infrastructure’s current state matches the desired state. In other words, it focuses on the what rather than the how. A declarative IaC tool is usually idempotent, meaning the same result will be achieved when run repeatedly. This is because that check is done against the state file, and if the infrastructure is already provisioned, it will make no changes if rerun. Examples of declarative IaC tools are Terraform, AWS CloudFormation, Pulumi and Puppet (Ansible also supports declarative).

Imperative

This approach involves defining specific commands to be run to achieve the desired state; these commands need to be executed in a particular order. Imperative IaC is usually not idempotent in that if you run these tools multiple times, the same result won’t be replicated, or the tool may run into some configuration issues. This is because these commands will be run regardless of the state of your infrastructure, so running these commands on an already provisioned infrastructure may cause additional unwanted infrastructure to be added or may break the configuration of some existing components (depending on the set-up of the infrastructure and the commands being run). Examples of imperative IaC tools: Chef is the best example of an imperative tool; however, SaltStack and Ansible both support imperative programming as well.

Agent-based vs. Agentless

Agent-based

An “agent” will need to be installed on the server that is to be managed. It runs in the background and acts as a communication channel between the IaC tool and the resources that need managing. This agent is responsible for executing and reporting on the state of the infrastructure/managed resources. Note that this agent must be installed on every target system/node that needs to be managed. An agent-based IaC tool can perform tasks even when the system has limited connectivity or is offline, making it a robust choice for automation; however, you need to take care with maintenance when using these tools, monitoring the agent software closely so it can be restarted in the event of a crash.

Another thing to consider with agent-based IaC tools is that some of these tools will require opening ports on the server for inbound and outbound traffic so that the agent can push/pull configuration information; from a security perspective, more open ports are negative. Despite this, they offer a level of granular control over managed resources and can collect more detailed monitoring data. Because of this, they might be ideal if control is an important factor in your setup. Some agent-based IaC tools: Puppet, Chef, and Saltstack.

Agentless

Agentless IaC tools, as you may have guessed, do not require agents to be installed on target systems. Instead, these tools leverage existing communication protocols like SSH, WinRM or Cloud APIs to interact with and provision resources on the target system. Agentless IaC tools benefit from being easier to use; their simplicity during set-up can mean faster deployment time, and their agentless nature can also mean the tool can be deployed across multiple environments without custom agent changes needing to be made based on each environment’s needs, making it a flexible choice. Also, compared to agent-based IaC tools, there is less maintenance and no risks surrounding the securing of an agent. However, agentless IaC tools generally have less control over target systems than agent-based tools. Agentless tools are useful in environments which have to adapt to fluctuating workloads, with resources being created/destroyed to meet these workloads. These newly created resources can be managed without having to rely on pre-installed agents. Agentless IaC tools: Terraform, AWS CloudFormation, Pulumi and Ansible.

Answers:

In the scenario given, which type of IaC tool considers where you are on the map and gives instructions to reach the desired X point?

Answer: Declarative

IaC — The Tools Part 2

Immutable vs. Mutable

Mutable

Mutable infrastructure means you can make changes to that infrastructure in place. So, in our current example, we can upgrade the application on the server it’s currently running on. The advantage here is that no additional resources need to be provisioned for this update, with the resources already being used just needing to be changed. Where mutable infrastructure starts presenting issues is, imagine your web application update contains three changes, and whilst these updates are being made, one of the changes fails to apply. This is a common occurrence in development and can occur for several reasons, such as application misconfiguration or a network dropout. Now running on your server will be a web application version with two of the three changes required to be version 2. In other words, it’s no longer version 1 anymore but not quite version 2 either. When an application is updated in a production environment, it will have been tested first in development and staging environments. What won’t have been tested is this halfway version, leading to all kinds of potential issues. Imagine now that this update was not just rolled out on a single server, but many, maybe some updates succeeded, and some failed with errors in different changes. You can see how this can become an issue very quickly with different versions of the web application existing across many servers.

Immutable

Get Omda404x’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Immutable infrastructure means you cannot make changes to it. Once an infrastructure has been provisioned, that’s how it will be until it’s destroyed. Now, let’s apply that to our example. When this new version 2 of the web application is deployed, an entirely new infrastructure will be deployed with this new version. Now, you have two infrastructures stood up: one with version 1 of the web application and one with version 2. However, if all of the changes are implemented successfully (and only if they ALL are; otherwise, if it fails, the infrastructure will be torn down, and the process will be retried), the version 1 infrastructure can be torn down. This approach has some drawbacks, as having multiple infrastructures stood up side by side or retrying on failed attempts is more resource-intensive than simply updating in place, but it allows for consistency across servers. You know with certainty that x server is running version 2 of the web application.

Immutable IaC tools: Terraform, AWS CloudFormation, Google Cloud Deployment Manager, Pulumi (some of these tools can be configured to be used with a mutable infrastructure but work better with an immutable approach).

Provisioning vs. Configuration Management

Provisioning tools: Terraform, AWS CloudFormation, Google Cloud Deployment Manager, Pulumi

Configuration management tools: Ansible, Chef, Puppet, Saltstack

Put That All Together

Now, you’ve been introduced to the world of infrastructure as code tools and their various uses. Each has its characteristics which best suit different use cases and scenarios. In that way, they are no different to physical tools; you have to assess the problem and choose the best tool to address it. Here’s a little summary of what we’ve discussed, as well as a little bit more information about some of the tools mentioned:

Terraform: is a declarative, agentless infrastructure provisioning tool that works with immutable infrastructure. Terraform is one of the most popular infrastructure provisioning tools out there, allowing for the management of infrastructure across multiple cloud providers like AWS, GCP and Azure.

Ansible: is a hybrid, typically agentless configuration management tool that works with mutable infrastructure. Another example of a massively popular tool in the DevSecOps space. It’s slightly harder to categorise than some of the other tools, because of how this tool functions and what it does can depend on how you employ it. For example, there is much discussion over whether Ansible is an imperative or declarative tool. In reality, Ansible is sort of a hybrid in a sense.

Pulumi: is a declarative, agentless infrastructure provisioning tool that works with immutable infrastructure. Pulumi is similar in nature to Terraform but has become increasingly popular in recent years due to its ability to let users define their desired infrastructure using familiar general-purpose languages like Python, JavaScript, Go, Java and markup languages like YAML.

Aws CloudFormation: is a declarative, agentless infrastructure provisioning tool which can be used to implement an immutable infrastructure on AWS. This is an AWS-managed service and provisions AWS cloud resources using JSON / YAML templates.

Chef: is an imperative, agent-based configuration management tool that works with mutable infrastructure. Chef gets an infrastructure to a desired state by running a series of instructions contained in a file referred to as a ‘Recipe’; a collection of these files is referred to as a ‘Cookbook’.

Puppet: is a declarative, agent-based configuration management tool that works with mutable infrastructure. In Puppet, you define the desired configuration state using their own domain-specific language (DSL), “Puppet Code”; Puppet then automates this configuration through a Puppet primary server and agent.

Answers:

Can you retrieve the location and retrieve the flag?

Answer: thm{l4b_C0mpl3x_co0rds}

Infrastructure as Code Lifecycle

The Lifecycle

Now that it has been established what IaC is and the tools we use to implement it, it’s time to define the lifecycle. There is talk about an IaC lifecycle across forms, blog posts, and academic papers. Still, there is yet to be an agreed-upon and widely adopted lifecycle (as there is for DevOps/DevSecOps). Because we think you, the reader, would benefit from having an IaC lifecycle to use as an educational tool, we have defined one, the infrastructure as code lifecycle (IaCLC). The actions/tasks performed by developers and IaC tools can be broken down into phases, which together make a lifecycle; this lifecycle helps us understand that infrastructure as code has continual and repeatable processes, which don’t simply follow a linear sequence of provision and management tasks. This task will outline the stages of the IaC lifecycle, its phases and how they are connected.

The IaCLC is designed to give DevOps Engineers (or anyone else assigned with the task) guidance on the tasks associated with provisioning infrastructure and the continued support of that infrastructure. Key DevOps practices such as continuous integration and continuous deployment are also parts of best practices throughout the lifecycle.

Due to IaC being a development process, some parallels can be drawn between the IaC lifecycle and the SDLC, which also covers a solution’s planning/designing, implementation, testing, deployment and monitoring. While these parallels exist due to these lifecycles being created on the same foundations (providing developer guidance and improving output quality), they don’t directly fit into each other. Both lifecycles break down tasks into phases. However, due to the frequently changing infrastructure needs, the IaCLC distinguishes between two different types of phases.

The Continual (Best Practice) Phases

Version Control
This phase involves versioning code while defining your infrastructure and making changes. This way, when it comes to the later rollback phase, there are clearly defined versions to fall back on should a new change break something.
Collaboration
When working as part of a team on infrastructure, it is crucial to communicate and collaborate so everyone is on the same page. Otherwise, this can lead to a disconnect between modular infrastructure components or general confusion over infrastructure.
Monitoring/Maintenance
Once an infrastructure has been provisioned/configured, it must be monitored for poor performance, security events, failure events, warnings, etc. Automated maintenance tasks (e.g. disk clean-up) can help avoid some of these events. In certain events, this phase can trigger the rollback phase.
Rollback
In the event of a failure event post-deployment, the infrastructure will need to be rolled back to the last known working version.
Review + Change
Just because an infrastructure works doesn’t mean it’s as efficient as it could be. Perhaps a new security vulnerability has been discovered, or maybe there’s a new business requirement that would benefit from an infrastructure change. Infrastructure should routinely be reviewed to determine if this is the case, and changed if so.

The Repeatable (Infra Creation + Config) Phases

Design
The infrastructure needs to be designed based on needs, taking security into account throughout the whole process (for example, poor scaling policy design can lead to availability issues, which is a huge security concern).
Define
Use the design to define the infrastructure that needs to be provisioned in code.
Test
Using a linter, validate the code for syntax errors or logical issues. Before provisioning is done in production, test the infrastructure in a replica environment (staging).
Provision
Provision the infrastructure that has been defined in the production environment using a provisioning tool, e.g. Terraform.
Configure
Configure the provisioned environment using a configuration management tool, e.g. Ansible.

Answers:

A DevSecOps Engineer at CyberMyne is looking for guidance on developing their next infrastructure. What type of phases provide guidance during the development or configuration of an infrastructure?

Answer: Repeatable

What type of phases ensure best practices throughout infrastructure development and management?

Answer: Continual

The ‘Monitoring/Maintenance’ continual phase can trigger which other continual phase?

Answer: Rollback

Virtualisation & IaC

Virtualisation Levels

When we talk about virtualisation levels, we’re essentially talking about what is being virtualised. Here, we will briefly review the difference between hypervisor-level virtualisation and container-level virtualisation to provide context for upcoming concepts. Hypervisor virtualisation (e.g. VMware) enables multiple virtual machines to run on a single physical server. Imagine a physical server in a data centre. Using a hypervisor, this server’s resources (CPU, storage, etc.) can be divided and dedicated to separate virtual machines within this server. These machines will virtualize everything from the operating system, which can be a different OS than installed on the host, meaning multiple OSs can be installed on a single server; however, deploying a virtual machine at this level can take some time. Containerization (platform example: Docker) is virtualization at an operating system level, meaning the same operating system kernel is used to run multiple containers. Virtualising at this level makes these containers incredibly lightweight, allowing for rapid deployment and scaling.

Use of Virtualisation in IaC

Let’s consider how virtualisation is used in IaC across six areas: Scalability, Resource Isolation, Testing / Snapshots / Rollbacks, Templates, Multi-tenancy, and Portability.

Scalability
IaC uses virtualisation to meet demands (higher or lower levels of demand). If there is a sudden increase in demand (scaling policies can be defined in your code to specify when this would be required) and you need more servers, virtual machines can be created to handle this increased load.
Resource Isolation
Virtualisation enabled resource isolation between different VMs/containers. Using IaC, you can define what components get how much of the available resources. This means if one component starts getting hammered (consuming all of its allocated CPU, memory, bandwidth, etc.), it won’t affect the performance of the other components.
Testing / Snapshots / Rollbacks

The virtualisation of OSs, software configurations and dependencies makes it easy to package them and, using infrastructure as code, deploy them in another identical environment for testing or development. The consistency this provides, combined with the ability to take snapshots of VMs/containers at specific points in time so rollbacks can be done if a deployment goes wrong, streamlines development and testing processes.

Templates

When using virtualisation, you can create a template (or blueprint) for VMs/containers. IaC can use these templates to provision new instances. These templates cut manual provisioning and configuration time down while ensuring consistency across instances.

Multi-tenancy

Virtualisation can support multi-tenancy, meaning multiple customers/tenants can be hosted on the same physical server whilst having their resources isolated. This removes the need for dedicated servers/single-tenant environments (although sometimes they are required), and using IaC means the resources for multiple tenants can be managed using the same underlying infrastructure.

Portability
Virtualisation makes it easier to move infrastructure between cloud providers or data centres. Having this portability, as discussed, can streamline critical business processes like disaster recovery but also allows the flexibility for hybrid cloud organisations to recreate environments regardless of their CSP.

Virtualisation Technology + IaC

Next, we will discuss some virtualisation technologies used in conjunction with IaC to unlock its power, focusing on Kubernetes. Kubernetes (also referred to as K8s) is a containerisation orchestration software, meaning once an application (and its dependencies) have been containerised, Kubernetes can be used to automate its deployment, scaling and management. Using Kubernetes requires a Kubernetes cluster, in other words, an infrastructure made up of a master node and one or many worker nodes (where the containerised applications run). Infrastructure as code tools can provision the underlying infrastructure needed for this Kubernetes cluster and automate the set-up of the required Kubernetes components. Infrastructure as code can also define scaling policies for a Kubernetes cluster, automating the scaling process and allowing pods/nodes to be added or decreased based on resource usage. The infrastructure provisioning/configuration and automation capability of IaC, combined with the ability to orchestrate lightweight rapid deployable containers, make for a very powerful set-up and is ubiquitous in the world of cloud computing.

Consider a practical example from the world of DevOps. Say a DevOps Engineer is planning to deploy a new web application from scratch, and their tech stack includes both Terraform and Kubernetes. They can combine these tools and use Terraform to automate the creation of a new Kubernetes cluster, and once this cluster has been deployed, any other resources that might be needed, like an Nginx web server or a load balancer. This is just a simple, stripped-back example of a task that would even be possible by just using Kubectl (or other CLI-based tools) to manage K8s clusters and resources; however, using an IaC technology like Terraform boasts many benefits when you start to consider DevOps at the scale of a larger company where these tools allow you to define Kubernetes deployments, services, config maps etc. as Terraform modules, which are repeatable across different projects/clients/environments. We’ve also discussed how Terraform is a declarative tool ensuring that the state of the Kubernetes cluster matches the desired state making infrastructure management an easier task. Terraform is also aware of dependencies, meaning if ‘resource x’ is dependent on ‘resource y’ and ‘resource y’ fails to deploy, Terraform won’t attempt the creation of ‘resource x’. Another way in which Terraform can save time is by reducing the need for DevOps Engineers to sift through deployment errors, working out the point of failure. Again, both of these tools are powerful, but when used together, their true power and utility in the DevOps space are unlocked.

Kubernetes is just one example of how virtualisation technologies and IaC can work hand in hand and are nearly essential to each other (at least to get the most out of the respective tool). Some other examples include Vagrant (used by developers to spin up and manage VMs or containers for local development and testing; IaC can make this a consistent process) and OpenStack (an open source cloud computing platform where you can create your own cloud environments where IaC can also be used to automate the provisioning and management of cloud resources).

Answers:

CyberMine is deploying the latest machine model E-1000. This model requires virtualisation at an operating system level to allow for lightweight and rapid deployment behind the scenes! What level of virtualisation would be needed for this?

Answer: Containerisation

CyberMine’s E-100 Model is still very popular for all your extermination needs, this model requires multiple OS to run on a single machine. Which level of virtualisation would be needed for this?

Answer: Hypervisor

The new E-1000 model has a feature that allows it to pass through physical objects. Wild! This new feature, however, is very resource-intensive. Which ‘Use of IaC’ will ensure that this resource consumption won’t affect the performance of the machine’s other components?

Answer: Resource Isolation

Due to the resource consumption of this new feature, it requires rapid scaling of resources. Which container orchestration software can be used to automate this process?

Answer: Kubernetes