An Intro to Infrastructure as Code


Course Introduction
Course Conclusion
An Intro to Infrastructure as Code

This course provides you with the foundational knowledge required to design an infrastructure and configuration management strategy. It starts by looking at hosting infrastructure — IaaS, PaaS, FaaS, and some modern native app options — before moving on to look at Infrastructure-as-Code. You’ll learn what Infrastructure-as-Code means and the tools and technologies that are used to deploy and manage it.

Next, you'll learn about some of the more common Infrastructure-as-Code tools and technologies: Terraform, Azure Resource Manager, Chef, Puppet, and more. You'll also learn about technical debt and how to deal with it in templates. The course then covers transient infrastructure and its role in the delivery lifecycle, before finishing off by looking at the mitigation of infrastructure state drift.

If you have any feedback relating to this course, please contact us at

Learning Objectives

  • Understand the main compute options available to host your infrastructure
  • Have a solid grasp of Infrastructure-as-Code (IaC) and its related tools and technologies 
  • Learn about technical debt and how to deal with it in templates
  • Learn about transient infrastructure and how it can speed up projects and reduce costs

Intended Audience

This course is intended for those preparing for Microsoft's AZ-400 exam, or anybody who wants to learn about designing an infrastructure and configuration management strategy in Azure.


To get the most from this course, you should have a basic understanding of Microsoft Azure and of DevOps concepts.


Hello and welcome to an intro to infrastructure as code. In this lesson we are going to take a look at what infrastructure as code means and what it offers.

So, what exactly is infrastructure as code? In a nutshell, infrastructure as code is the practice of deploying and managing infrastructure, such as networks, VM’s, and other resources in a descriptive model. This is done through the use of versioning, which is not unlike the versioning that DevOps teams use for source code.

In much the same way that a specific set of source code produces the same outcome within an application, whenever the source code is run in an infrastructure as code model, that code will produce the same environment every time it is applied. Because infrastructure as code mitigates environment drift in the release pipeline, it is a key DevOps practice that is typically used in conjunction with continuous delivery.

Infrastructure as code eliminates the need to manually maintain deployment environment settings, which, by the way, usually results in snowflake environments. Snowflake environments are individual environments that each require a unique configuration that is difficult or even impossible to be reproduced automatically. The inconsistencies that arise as a result of snowflake environments will often cause issues during deployments. These snowflake environments also create administration and maintenance headaches because each infrastructure requires manual processes that are not only difficult to track, but also result in errors. Infrastructure as code solves these problems.

A key principle of infrastructure as code is Idempotence, which refers to the concept that a specific deployment command will always set up the target environment in the same configuration, regardless of the starting state. In other words, Idempotence is the ability to run a specific process or command that produces the same exact result each time. You can achieve idempotency in a couple different ways. You can achieve it by automatically configuring an existing target or you can achieve it by discarding the existing target and creating a fresh environment to start from.

Idempotence is important when trying to create consistently configured environments. To achieve this, the DevOps team makes changes to the environment description and version of the configuration model. The configuration model typically exists in a JSON file. The configuration model is executed by the release pipeline, which in turn, configures the target environment. This means that if a change to the target environment is needed, the DevOps team actually makes the change to the source, which is then rerun to produce the changes on the target end.

DevOps teams will often use infrastructure as code early in the development cycle to produce environments that mirror production. These environments are then used to test applications.

Leveraging infrastructure as code rather than deploying environments manually allows teams to provision multiple test environments on an as-needed basis. Infrastructure as code also allows for rapid and scalable deployment delivery. Infrastructures that are deployed using infrastructure as code are easily repeatable and do not suffer from many of the runtime issues or configuration drift that manually deployed infrastructures suffer from.

The too long didn’t read version of infrastructure as code is pretty simple. It is used to deploy consistently configured infrastructure.

About the Author
Learning Paths

Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.

In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.

In his spare time, Tom enjoys camping, fishing, and playing poker.