Understanding IaC Core Concepts
Understanding IaC Core Concepts

Learn how to simplify all of your application infrastructure into just a few configuration files then deploy your code on Google Cloud Platform with this course. We will start by learning the core concepts behind Infrastructure as Code, discussing security best practices when working with IaC, and comparing some popular orchestration and configuration management tools.

After that, we’ll implement version control for our IaC configurations, and learn how we can automate deployment updates using Cloud Build Triggers. Next, we’ll learn how to integrate Google Secret Manager to protect any sensitive data in our source code. Then to tie it all together, we’ll walk through Google Identity and Access Management and learn how to monitor our users and resources on GCP.

After learning the basics, we’ll build our own immutable server images with Google Cloud Build using both Docker and Packer. We’ll then explore a practical usage scenario and build a WordPress deployment with Google Deployment Manager. We’ll also deploy a similar WordPress configuration using Terraform to compare the two methods.

I will be working in Visual Studio Code during the demos for this course, but you are also free to use any other IDE you are comfortable with instead. A demo repository is provided along with this course, and while we will be working with some Python and PHP in our examples, you should still be able to follow along with the demos without any background in either of these languages.

Learning Objectives

  • Build server images from a configuration file using Docker and Packer.
  • Learn to use Google Cloud Build with third-party build steps.
  • Deploy application infrastructure from code using Google Deployment Manager and Terraform.
  • Understand templating systems for Infrastructure as Code.
  • Implement version control for Infrastructure as Code.
  • Learn to protect secret data in IaC configurations using Google IAM role management and Google Secret Manager.

Intended Audience

This course is intended for programmers interested in expanding their knowledge about modern cloud-based DevOps workflows. Learning to manage Infrastructure as Code is beneficial to solo developers who need to focus as much of their time as possible on their application code and not on managing infrastructure. Development teams will also benefit from this course, because implementing IaC provides consistent performance across deployments in multiple environments, which greatly simplifies project collaboration. This course will also help prepare the viewer for the Google Professional Cloud DevOps Engineer certification.


  • You should already have a Google Cloud Platform account.
  • You should have Google Cloud SDK already installed and initialized.
  • You should already have Git installed, and be familiar with its use.
  • Demos will be shown in Visual Studio Code, but you're free to use any IDE they are familiar with.
  • Demos will utilize some Python and PHP, but you're not required to be fluent in either of these languages to follow along with the examples.


Additional Documentation


Getting Started with Infrastructure as Code. Understanding IaC Core Concepts. When deploying a software application, we'll generally need some server and networking infrastructure configured and available to deliver our application to our users for us. Managing all this infrastructure introduces many additional points from outside of our source code for potential failure or compromise into our application. This can often make problems difficult to troubleshoot or even detect.

Deploying Infrastructure as Code resolves all of these problems with a modern DevOps approach. Employing DevOps principles for server infrastructure. The DevOps model, as the name might imply, combines the development and operations roles together. We can speed up development and reduce errors when the development team is also involved with managing the environment their code will operate on.

Infrastructure as Code inherently supports the DevOps model by making infrastructure configuration and management part of our source code. Reducing human error and saving time with automation. This DevOps model sounds like a great idea, but isn't this essentially requiring developers to do two jobs now? How do we manage this extra workload? Infrastructure as Code brings operations into the developer's comfort zone, writing configuration files and scripts to define the operating environment for our application just becomes another part of our source code. By deploying infrastructure from code like this, we can quickly and reliably automate server setup processes that were previously time-consuming manual operations prone to human error.

With Infrastructure as Code, one person can fulfill both development and operations roles more quickly and efficiently than was possible with more traditional models, where these roles often needed to be split into separate job positions in the past because of the time each required on their own.

Working with immutable server deployments. There is a very particular difference when working with Infrastructure as Code compared to more traditional server administration practices. We never want to actually log into the server and make any changes or updates to our system configuration after the server is deployed. All server configuration should only be defined in one place within our source code. Whenever our configuration code changes, we'll deploy a new server with that new configuration to replace the previous server. An analogy you can use here is to consider your servers like livestock rather than pets. With Infrastructure as Code, we are no longer pruning and caring for a single server instance for the life of our application. Instead, servers can be as short-lived as versions of our application code, and replaced every time we make a configuration change. This practice ensures that our application will run consistently whenever we need to deploy additional servers. We never have to worry about missing any custom configuration or update that was manually performed on a pet server.

Immutable servers are also faster to deploy than a server built with a configuration management tool like Puppet, Chef, or Ansible, which we'll discuss in more depth later. This is because these configuration management tools have to wait until a new server is deployed, then connect to it to perform any installation tasks or execute any scripts needed to bring the server up to the desired state. All of these updates are instead already baked into an immutable server image, so the server is ready to go the moment it's deployed without the overhead of an additional tool required to get it there.

Securing and monitoring deployments. While Infrastructure as Code solves many operational problems for us, it has a few security challenges of its own to be aware of. Most often it's the developer who gets tasked with taking on operations, rather than operations taking on development. Infrastructure as Code is logically assumed to be the responsibility of the coders. Developers however are not inherently well versed in matters of server and network security, and are often unaware of the best practices they need to be following in their Infrastructure as Code configurations.

Since IaC blurs the line between development and operations, this can also have the effect of blending passwords and other secret data into our application code during development. We need to be careful and make sure that credentials or environment variables aren't stored in plain text files along with the rest of the IaC configuration anywhere in our source code. Since we have all of our configuration in just one place now, if this single source is compromised, then our entire application becomes compromised. This is also why it's important to define explicit accounts with minimal permissions for use during development and testing, and not just use our admin credentials everywhere because it's more convenient.

Also, since a new server is deployed with every revision of our code, it's important to regularly audit our builds and make sure that old servers are properly spun down and deleted. The last thing you want is to rack up costs from a bunch of test servers that were used for ten minutes then forgotten about but left running. This is an unfortunately easy mistake to make when first starting out with Infrastructure as Code.

About the Author

Arthur spent seven years managing the IT infrastructure for a large entertainment complex in Arizona where he oversaw all network and server equipment and updated many on-premise systems to cloud-based solutions with Google Cloud Platform. Arthur is also a PHP and Python developer who specializes in database and API integrations. He has written several WordPress plugins, created an SDK for the Infusionsoft API, and built a custom digital signage management system powered by Raspberry Pis. Most recently, Arthur has been building Discord bots and attempting to teach a Python AI program how to compose music.