Hi from Tokyo Japan, and welcome to Jeremy’s IT Lab. In this video we’re covering another recent addition to the CCNA exam, Terraform. The exam blueprint previously listed Ansible, Puppet, and Chef as the configuration management tools you need to know for the exam. Cisco recently changed that to Ansible and Terraform. However I’m keeping Puppet and Chef in the course for two reasons. First, notice the wording of the new exam topic: Recognize the capabilities of configuration management mechanisms, “such as” Ansible and Terraform. For me, the words “such as” imply that there could be others on the exam. Second, Puppet and Chef help illustrate key concepts, like comparing the agentless architecture of Ansible and Terraform to the agent-based architecture of Puppet and Chef. So instead of modifying the previous video, I’m adding this new one to focus on Terraform. Before we get started, let me take a minute to shill my books, Acing the CCNA Exam volumes 1 and 2. These books cover everything on the latest version of the CCNA exam, including the topics of this video. The very final chapter, chapter 25 of volume 2, focuses on Ansible and Terraform, and also includes a bit about Puppet and Chef. I always recommend using books in combination with a video course, so if you want to get my books, check out the links on the screen now to buy them directly from the publisher, or find them on Amazon. Now let’s get started. So, what are we going to cover in this video? Of course, the focus is on Terraform, but I’ll take the opportunity to introduce a few new concepts. Specifically, we’ll talk about the concept of infrastructure as code, IaC; Terraform and the other tools we’ve covered are examples of IaC. Then we’ll compare infrastructure provisioning and configuration management. Whereas Ansible is primarily used for configuration management, Terraform leans toward provisioning. We’ll then cover the concepts of mutable vs immutable infrastructure, and procedural vs declarative approaches. Finally, we’ll shift our focus to Terraform itself and cover its basics. Okay, let’s begin. First let’s look at the concept of infrastructure as code. Actually, we’ve already covered it, I just didn’t use the specific term in the last video. Infrastructure as code, IaC, is the practice of provisioning and managing infrastructure, such as servers, networks, and cloud resources, using machine-readable configuration files, code, instead of manual configuration via CLI or GUI. That probably sounds familiar, because Ansible, Puppet, and Chef are examples of IaC configuration management tools. For example, Ansible manages device configurations using several files that are used by the control node. We covered these in the previous video. Ansible uses playbook, inventory, template, and variable files. Ansible runs on the control node and uses these files to manage the infrastructure. Instead of configuring the devices via the CLI or GUI, their configurations are managed via these code files, hence the term “infrastructure as code”. Terraform, on the other hand, is an IaC-based provisioning tool that automates the creation of infrastructure resources. In the next slide I’ll clarify the difference between configuration management and provisioning, but Terraform is primarily used for provisioning. So, to summarize, infrastructure as code automates infrastructure deployment and management, ensuring consistency, scalability, and repeatability. Basically, the various benefits of automation that we covered in previous videos. So, I mentioned that Ansible, Puppet, and Chef are primarily configuration management tools, whereas Terraform is primarily a provisioning tool. Let’s clarify what the difference is. First, what is configuration management? Tools like Ansible, Puppet, and Chef manage existing infrastructure by installing software, configuring settings, and maintaining system state. This ensures consistency by applying and enforcing configurations across multiple devices. Again, these are the benefits of Ansible, Puppet, and Chef that I covered in the previous video. As for infrastructure provisioning, it creates, modifies, and deletes infrastructure resources such as servers and network infrastructure. For example, creating virtual servers and routers on a cloud platform like AWS. But the focus is on initial setup rather than ongoing configuration management. To summarize, configuration management tools work on already existing systems, whereas provisioning tools build infrastructure from scratch. Of course, these tools can be used together. For example, Terraform, a provisioning tool, and Ansible, a configuration management tool, often work as a pair. Terraform provisions infrastructure, creating VMs, network infrastructure, storage, and other resources, while Ansible provides ongoing configuration and management, maintaining those systems. With all of that said, both Terraform and Ansible have some overlap. Each can perform both provisioning and configuration management to some extent. But their strengths are different, so they’re often used together. One major difference between infrastructure provisioning and management tools is the approach they take with the infrastructure: is the infrastructure mutable or immutable? Configuration management tools typically use a mutable infrastructure approach. This means that infrastructure can be modified after deployment, such as applying updates, patches, or configuration changes. In other words, changes are made in place, meaning existing resources are updated rather than replaced. This is just like when you manually modify a device’s configuration in the CLI. So, when using a mutable approach, if you want to update the config of this VM, Ansible or a similar tool would simply update the config while leaving the VM itself in place. Only the relevant settings are changed. So, what’s the alternative to mutable infrastructure? Provisioning tools like Terraform typically employ an immutable infrastructure approach. This means that infrastructure cannot be changed after deployment. So, any changes you make involve replacing the previous resource with a new one. If you want to update the configuration of this VM, Terraform or a similar tool would have to create an updated instance of the VM with the configuration changes applied, and then destroy the old instance. One benefit of this approach is that there is no configuration drift. Each deployment starts from a fresh, predefined state. There’s no opportunity for individual changes to accumulate with each configuration. Configuration drift isn’t a major issue when Ansible or other mutable infrastructure tools are properly managed. But Terraform’s immutable approach virtually eliminates the risk altogether The final concept we’ll cover before focusing on Terraform itself is the difference between a procedural and declarative approach. Some tools take a procedural approach to managing infrastructure, also called an imperative approach. This means that the tool follows explicit steps in a specific order to achieve the desired outcome. So the user, the engineer using the tool, must define each specific action in the correct order to configure the infrastructure. This provides greater control than the declarative approach we’ll cover next, but is more demanding on the user. They have to know exactly which steps are required to achieve their desired end result, and in which order those steps should be executed. Then there is the declarative approach, which defines the desired end state instead of the specific steps. The tool itself, such as Terraform, figures out the steps needed to achieve the goal. This makes it easier to maintain and ensure consistency across deployments because the user doesn’t have to worry about ordering individual commands and configurations on each platform. They only have to think about defining what they want the final result to be. So, to summarize, A procedural approach focuses on how to make changes with explicit steps. For example, when configuring a new router, configure the router’s hostname with HOSTNAME R1. Configure the IP address of G0/1 with the IP ADDRESS command. Enable the interface with NO SHUTDOWN, , and so on. These are the specific configurations needed on a Cisco router, and the steps would be different if it was a Juniper router, for example. A declarative approach, on the other hand, focuses on what the final state should be. You can tell Terraform “Create a router named R1 with IP address 192.168.1.1/24 on its G0/1 interface, ensuring the interface is enabled”. Terraform should then figure out the necessary steps to achieve that end state. So, I’ve mentioned that Terraform uses a declarative approach, but you’re probably wondering about the others. Here’s a table. I’ve categorized Ansible and Chef as procedural, but it’s worth noting that they do have some declarative elements as well, especially Ansible. People who use Ansible a lot might get angry at me for categorizing Ansible as procedural. But Red Hat, the company that owns and develops Ansible, also says it is procedural, so for your CCNA studies I’d say it’s best to consider Ansible a procedural tool. Meanwhile, Terraform and Puppet use a declarative approach, allowing you to define the desired end state and let the tool figure out the rest for you. Finally let’s move on to Terraform, which is an open-source IaC tool developed by HashiCorp, an American company that was acquired by IBM in 2025. As I’ve mentioned a few times, it is primarily a provisioning tool, focused on deploying infrastructure resources on various cloud and on-prem platforms. In Terraform, these platforms are called providers and include AWS, Azure, GCP, Kubernetes, and many more; it supports over 1000 different providers. For CCNA students, this includes integrations with Cisco platforms like Catalyst Center, ACI, which is Application Centric Infrastructure, Cisco’s data center SDN solution. And IOS XE, which is the type of IOS you’ll find on modern Cisco devices like Catalyst switches. Like Ansible, Terraform uses a push model and is agentless. It doesn’t require a software agent on infrastructure it provisions or manages. Okay, now let’s see how Terraform actually works. At the core of Terraform is Terraform Core; this is the main Terraform software, typically running on a Linux server, that processes configurations and interacts with providers. An engineer creates Terraform configuration files, which specify the desired end state in a declarative fashion. It’s up to Terraform Core to take that desired end state and deploy the necessary infrastructure on the appropriate provider or providers, such as deploying cloud resources on AWS. It does this via each provider’s APIs. And one more key element is the state file, which Terraform uses to track the state of the deployed infrastructure. By comparing the current state of the infrastructure to the desired end state defined in the configuration files, Terraform can identify which actions it needs to take, and in which order, to achieve the desired result. To summarize, these are Terraform’s four key components, all working together to provision and manage infrastructure: Terraform Core, the core software developed by HashiCorp. Configuration files, which an engineer creates to define the desired end state of the infrastructure. The state file, which tracks the current state of the deployed infrastructure. And the providers, the platforms on which the infrastructure is deployed. Let’s cover a few more key points about Terraform. The basic Terraform workflow consists of three main steps. The first is “write”, in which you define the desired end state of your infrastructure resources in configuration files. The second step is “plan,” where Terraform analyzes your configuration files and shows you exactly what changes will be made. This lets you review and confirm the changes before applying them. And the third step is apply, where Terraform executes the plan to provision and manage the infrastructure resources. That’s basically how it works. If you think back to Ansible, hopefully you remember that Ansible itself is written in Python, while its playbooks are written in YAML. So what about Terraform? While Terraform Core is written in Go, the configuration files that define the desired end state are written in HashiCorp Configuration Language, HCL. HCL is an example of a domain-specific language, DSL, which is specialized for a particular purpose, like Puppet’s DSL mentioned in the previous video. Since DSLs are designed for specific tasks, they make complex operations simpler, and they require less effort compared to general-purpose languages like Python or Go. The downside is that HCL is another thing you have to learn specifically to use Terraform, but it’s relatively simple compared to learning a full programming language. So, the key points to remember here are the three steps of the Terraform workflow: write, plan, and apply. And also remember that Terraform Core is written in Go, while the configuration files you make are written in HashiCorp Configuration Language, HCL, which is a Domain Specific Language. Okay, those are the basics of Terraform. Now here’s a one-slide summary before we move on to the quiz. Infrastructure as Code is the practice of provisioning and managing infrastructure using machine-readable configuration files instead of manual configuration. Ansible, Puppet, Chef, and Terraform are all examples of IaC tools. But not all IaC tools are used for the exact same purpose. Configuration management tools like Ansible, Puppet, and Chef focus on managing existing infrastructure, doing things like installing software, configuring settings, and generally maintaining the state of your systems. Infrastructure provisioning tools like Terraform, on the other hand, focus on creating, modifying, and deleting infrastructure resources. That doesn’t mean that Ansible can’t be used to provision resources or Terraform can’t be used to make configuration changes, it’s just that each tool is better fit for a different purpose. We then covered mutable infrastructure, which means that the infrastructure can be modified after deployment. And immutable infrastructure, meaning that it cannot be changed after deployment. Any changes involve replacing the previous resource with a new, updated version, and then deleting the old one. Provisioning tools like Terraform use an immutable approach, whereas management tools like Ansible use a mutable approach to infrastructure. We then compared the procedural and declarative approaches. A procedural, also called imperative, approach follows explicit steps in a specific order to achieve the desired outcome, and these steps must be specified by the engineer using the tool. A declarative approach defines the desired end state, and the IaC tool, such as Terraform, figures out the steps needed to achieve that goal, and in which order they should be executed. Okay, finally we looked at Terraform itself, it’s an open-source IaC tool developed by HashiCorp. It’s primarily a provisioning tool used for deploying infrastructure on providers like AWS, Azure, GCP, Kubernetes, etc. Terraform interacts with these providers via their APIs. Like Ansible, it uses a push model and is agentless. Its main components are Terraform Core, the configuration files where you specify the desired end state, the state file that tracks the current state of the infrastructure, and the providers. The basic workflow consists of three main steps: write, plan, and apply. You could also add a fourth step there: destroy, in which you delete the resources after they are no longer needed. But these three are considered the main steps. Terraform Core is written in Go, and the configuration files are written in HashiCorp Configuration Language, which is a domain-specific language. Alright, that’s what we covered in this video. Just a very high-level overview of Terraform, but as long as you know these basics you should be ready for the CCNA exam. Now let’s do a short quiz to test your understanding. Here’s quiz question 1. Which of the following are characteristics of Terraform? (select two) Pause the video now to think about your answers. Okay, the answers are B, declarative, and C, immutable infrastructure. Terraform uses a declarative approach in which you specify the desired end state and Terraform takes care of the rest for you. It also uses immutable infrastructure, where a particular resource can’t be changed after provisioning. To change a resource, Terraform will deploy a new version of the resource and then delete the old one instead. Okay, next question. Here’s question 2. What are the three main steps of the Terraform workflow? Pause the video now to think about your answer. Okay, the answer is D, write, plan, apply. In the write step, you define the desired state of your infrastructure in configuration files. In the plan step you verify the changes that will be executed before applying them. And then in apply, Terraform applies whatever changes necessary to bring the infrastructure in line with the desired state. Now let’s do one more question. Here’s quiz question 3. Which of the following IaC tools are focused on configuration management? Select three. Pause the video now to think about your answers. Okay, the answers are A, C, and D. Ansible, Chef, and Puppet are primarily used for configuration management, whereas Terraform is a provisioning tool. To take advantage of the strengths of each, it’s fairly common to use a combination, such as Terraform and Ansible. These tools aren’t exclusive and can be used together. Okay, that’s all for this video. We covered some additional concepts related to Infrastructure as Code that weren’t covered in the previous video, and then focused on the basics of Terraform, a very popular IaC provisioning tool. For the CCNA exam, I recommend knowing the basics of Terraform introduced in this video. You should also be able to compare and contrast it with the other tools we covered in the previous video: Ansible, Puppet, and Chef. I hope this video was helpful. Thanks for watching.