Pass Your HashiCorp Terraform Associate Exam Easy!

HashiCorp Terraform Associate HashiCorp Certified: Terraform Associate exam dumps vce, practice test questions, study guide & video training course to study and pass quickly and easily. HashiCorp Terraform Associate HashiCorp Certified: Terraform Associate exam dumps & practice test questions and answers. You need avanset vce exam simulator in order to study the HashiCorp Terraform Associate certification exam dumps & HashiCorp Terraform Associate practice test questions in vce format.

Deploying Infrastructure with Terraform

6. Understanding Desired & Current States (NEW)

Hey everyone and welcome back. Now in today's video, we will be discussing the desired and current states. Now at a high level overview, TerraForm's primary function is to create, modify, and destroy the infrastructure source to match the desired state, which is described within the TerraForm configuration. For example, let's say that you have the following resource block as part of your TerraForm file. Then the desired state is basically an easy instance with the AMIID, which is defined here with the instance type of T-2 Micro. So this is the desired state, and Terraform's aim is to make sure that the ECTwo instance with the following configuration is present. Now you also have something called a current state. So the current state is the actual state of a resource that is currently deployed. For example, let's say that you have created the instance with this specific configuration. Now someone from your team, maybe after a week, modified the instance type from T-2 Micro to T-2 Medium. So now what is happening is that the desired state, which is part of your configuration file, is different from that of the current state. And this is something that you will see in many of the organisations that are deploying the infrastructure as code-based tools. Now one important part to remember here is that Terraform tries to ensure that the deployed infrastructure is always based on the desired state. If there is a difference between the two, that is, if there is a difference between the desired state, which is specified in the configuration, and the current state of the running infrastructure, TerraFormplan presents a description of the changes that are required to achieve the desired state. So what TerraForm will do is try to change this instance type back from T-2 Medium to the instance type T-2 Micro that is part of the desired state of the configuration. So this is one important thing to understand, especially if you work with infrastructure as code-based tools. So let's jump into practise and look at how this works. So currently, I have an EC2 instance that is running that has been deployed via the TerraForm.Now we already know that the instance type that we have specified within the configuration is T-2 Micro. And yeah, the instance type is T. 2 micro. So everything is fine. The desired state is equal to the current state. So whenever a desired state is equal to the current state, for example, when you do a TerraForm plan, it states no changes, the infrastructure is up to date, everything is fine, and everyone is happy. Now let's do one thing. Let's go ahead and stop this specific instance. Great. So our instance is now stored. So let's go ahead and change the instance type, let's say from T-2 Micro to T-2 Nano, and I'll go ahead and do an apply. Now, from the CLI, whenever you do a TerraForm refresh, this command will fetch the current state of the resource that has been deployed, and then it will also update the state file. Great. So now, let's open up the TerraForm TF state, and under the EC two instance here, you should see that the instance type is T-2 Nano. So, TerraForm refresh has updated the state filewhich represents the current state of infrastructure. Now, since there is a difference between the desired state,which is part of the configuration, and the current statewhich is the actual resource configuration, TerraForm will go aheadand whenever you do a TerraForm plan next it willgo ahead and show you the changes that are requiredto achieve the desired state. So, TerraForm will go ahead and try to restore your infrastructure to the desired state. When you run a TerraForm plan within the changes here, for example, you'll see that it's attempting to change the instance type from T tonano back to T two micro. So, T 2 nano is the current state, and T 2 micro is the desired state. So this seems to be fine. So let's go ahead and do a TerraFormApply, and let's do a "yes, great." So the apply has been completed. Now, when you go to instance, let's quickly refresh. You should see that the one instance that is managed by TerraForm is running, and the instance type is now changed back to T 2 micro. That's great. So, at a high level, I hope you understand the fundamentals of desired state and current state. Now, there are a few more important things that I wanted to show you. Primarily because some of these are also encountered in real-world scenarios. So let's do one thing. Let's go ahead and stop this instance here. Great. So the instance has been stopped. Now, let's go ahead and change the instance type from T 2 micro to, say, T 3 medium. Now, one thing that you would have observed here is that for T-2 micro, the EBS optimised here, it does not have a checkbox. So basically, these are not EBS-optimized instances. However, the higher you go, let's go back to medium. You see, this is check marked.So let's do an k-marked. SoSo you can now assume that if you run a Terraform plan again, Terraform will change the instance type from T-3 medium to T-2 micro. So let's see if that happens. Now, let's clear the screen, and we can do a TerraForm plan. Now, earlier we had run the Terraform refresh explicitly. Even if you do not do this, the TerraForm refresh will occur if you call the TerraForm plan internally. And here you see that within the plan, it is adding one instance and destroying one instance. So let's look into it. So within this specific TerraForm plan, here it is stated that the instance must be replaced. And it also explains why it needs to be replaced. Primarily because the EBSoptimized is equal to true, So this specific block is forcing a replacement here. So always note that whenever you modify the infrastructure based on certain conditions, it can either be modified immediately or many times. At times, Terraform will go ahead and delete and recreate the instance altogether. So here it is, trying to replace the instance altogether. So, if you do a Terraform plan and have sensitive or important data inside this instance, the instance will be terminated and a newer instance will be presented to you. Always read the TerraForm plan thoroughly before submitting a TerraForm application. All right? So, let's go ahead and change our instance. Type back to T-two micro, so that at a later stage we can go ahead and play around with the configuration here. So with this, I will conclude today's.

7. Challenges with the current state on computed values (NEW)

Hey everyone and welcome back. Now in the earlier video, we were discussing the basics of the desired and current states and how Terraform always tries to achieve the desired state. Now whenever you are dealing with production environments, there are a lot of interesting scenarios that you will face, and it is important for us to remember some of them. So let me show you one of the challenges that you might face in production. Specifically, when it comes to this subject. For example, let's say that you have an EC2 instance that is running, and that EC2 instance is running based on this configuration. So the desired state as of now is equal to the current state. So everything is fine. Now let's explore some of the attributes here. So under the security here, you see that this EC2 instance is associated with the security group "default." So now let's go ahead and try changing the security group. So for example, earlier the security group was set to default, and now what we want is to change this security group from default to custom. And now let's see how TerraForm behaves here. So let's go to the security group. Let's create a new security group here. The name is Custom and let's say custom security group. I'll go ahead and create that. Great. So now let's go back to the instance and we'll change the security group associated with the instance from default to custom. So let's do a right click under "Security" and change the security group. I'll select the custom security group here, and I'll remove the default one here. So let's quickly verify. So now under the security tab, you should see that you have a custom security group. Great. So I hope you get the use case that we are trying to achieve. Now one of the questions that comes up is: What will Terraform do now? So the straightforward answer is that generally, Terraform will change the security group from custom to default. So it will change the default security group that we have added now to default.So let's try it out and see if that happens. If you observe the TerraForm TF state file, let's look into the security group here. So the security group as of now is set to "default." So now let's go ahead and do a TerraForm refresh. That's great. Let's open the TF State file yet again. And if you look into the security group, it has changed from default to customer. Now when you try to do a TerraForm plan here,it states no changes, infrastructure is up to date. Now the question is why? So when you discuss the desired state, if you look into this specific first PPT, it states that TerraForm's primary function is to create, modify, and destroy infrastructure resources to match the desired state described within the TerraForm configuration. So the second part is very important. desired state described in a Terraform configuration. Now, in this Terraform configuration, we never described the security group as default. So the security group does not come as part of the desired state at all. So even though for the infrastructure you modify the configurations that are not part of the desired state, next time when you do a TerraForm plan, TerraForm will not show you any details on how to revert those changes. And this is the reason why it is generally recommended that whenever you go ahead and create a resource like an instance, you do not just specify the minimal things; you specify all the important things that are necessary, including the item role, the security groups, and various other areas as part of your TerraForm configuration so that it always matches the desired state whenever you run the TerraForm plan in the future. Great. So I hope at a high level will overviewyou understood the challenge and also the appropriate solution.

8. Terraform Provider Versioning

Hey everyone and welcome back. Now, in today's video, we'll go over provider versioning in depth.So let's first go ahead and discuss a high-level overview of the architecture of how a provider might work. So let's assume that you have a TFfile that goes ahead and creates a resource. So let's assume that we are going ahead and creating a server at a cloud provider called Digital Ocean. Once you've created this TF file with Terraform and Terraform with the underlying provider plugins, it will interact with the back end cloud provider.In this case, it is digitalociation. So for example, let's assume that under the Dodplay TF, you have created a resource that goes ahead and creates the server. So then you do a TerraForm apply. TerraForm, behind the scenes, makes use of the provider plugins that have been initialized. And this provider plugs in; it interacts with the deal provider. So you have an API interaction that is happening. And then within the CLI output, once the server is created, you get the successful message here. So that is the high-level overview of the provider architecture. Now, one important part to remember is that the provider plugins are released separately from Terraform itself. So the first version is TerraForm, and the second is the provider plugin version.So they have a different set of version numbers, and they are developed independently. Assume you have a Digital Ocean provider plugin that is version 1.You might have a Digital Ocean provider plugin version two later on.So, even when a provider plugin is versioned, it continues to update at regular intervals, regardless of the TerraForm version.Now, at a high-level overview, this seems good, but in production, it comes with its own set of challenges. So let's take an example from Microsoft Windows. So you have Windows 7, you have Windows 8, you have Windows 10, and so on. So Microsoft keeps on coming up with the latest version of Windows. Assume you're using Windows Seven and are very familiar with all of its underlying features.So tomorrow Microsoft comes with assuming Windows ten. So if you directly jump to Windows 10, a lot of your existing programs would change and a lot of things behind the scenes would change, due to which you would not be able to work efficiently or your applications would crash. And in a similar way, even for Terraform, it is very important for the production environments to explicitly set the provider version. So generally, if you just do a Terraform, and if the version argument is not specified, then the most recent provider plugin will be used during the initialization phase. So this is the reason why what we dounder the TerraForm, we specify under the required providersthe version of the provider related plugins. So, for hashicop AWS, you have a version 3.0 where the plugins typically range on.Now, one of the questions that comes up is: what exactly is this "till day" mark and this specific symbol? So it is very important for us to understand what the arguments are that you can set along with this specific version. Fielding TerraForm, so there are multiple ways in which we can go ahead and specify a specific version of a provider. So you have more than equal to and less than equal to.Then there's something called a till day here, and you have greater than or less than.So let's quickly look into it. So greater than or equal to 1.0, thiswill ensure that whatever provider plugins that willbe downloaded, it would be greater than equalto this specific version of 10. So you won't see a provider plugin of zero eight, zero nine, and so on. Then you have less than or equal to 1.0. So this is less than equal to the specific version. So now you will not see a providerplugin of say one one so on here. Then you have a birthday date of 20. This basically means any version in the two point x range, so it can be 2.12.22.22 point 25 and so on. And then you also have a greater than equal to two-point-ten as well as a less than equal to 2.30. That basically means download the appropriate plug in rangingbetween the version of two point ten and 2.30. So it will not be something like 2829, nor will it be something like 231, 232, and so on. So it is important for us to practically go ahead and look at how this would work. So for today's video, I have a folder of provider versioning where we have one TF file called providers TF. And under this TF file, we only have the provider block primarily, and in this TerraForm block, we do not have any resources that have been configured. So let's go ahead and discuss more about it. Now, generally, under the registry TerraForm IO, whenever you go ahead and click on "use provider" here, you see that it explicitly comes up with a version. So you have an explicit version that is defined, which is 3.27.0. So if you have this specific code, it will only go ahead and download this specific version here. However, as we're discussing, depending on your requirements, there are lots of other arguments that can also be made. The first one that we are exploring today is this third argument here.So, if you have a till day mark on 3.0, this basically means that you can use any version in the three-point x range.Now, x can be a variable here. Now, do notice that our folder associated with provider versioning only has one file as of now. So let's go ahead and make a terrain out of it.So currently, it is going ahead and installing version 3.27.0. However, maybe at a later stage, let's assume that there is a version of 3.30. Then even the 3.30 version can be installed here, and hence centrally, it is recommended in production environments not to directly use this, primarily because it might happen that the resource that you have written is working perfectly with 3.27. However, at a later stage, if 330 is downloaded, there can be some issues, and hence this kind of approach is also recommended. Now, do note that as we have done, the TerraForm in it contains not only provider-related plugins that were downloaded under the TerraForm directory, but you also have one more file of TerraForm lock HCM. So, if you quickly open this file under the provider, you'll get the exact path of the AWS provider, which is registry TerraForm IO hashicop AWS.Then you have the version, which is 3.27.0, and then you have a constraint of 3.0. So this is the constraint that we have used. Now, do note that since you have this specific lock file available at a later stage, if you try to go ahead and change the specific version, it might not work. Let me give you an example. So let's change this version from 3.0 to 2.0. I'll save it. Let's clear the screen, and let's put a TerraForm in it here and immediately here. You see, you've got an error. So here the error states it could not retake the list of available versions of the provider, and it stays locked. provider, which is 3.27.0, does not match the configured version constraint of 2.0 over here. So this lock file primarily helps a lot to stick to a specific version constraint that is being defined. Even though you have modified your configuration here, if the lock file is present, then it can block it. So let's do one thing. Let's go ahead and delete this file. And now, if you run a Terraform in it, you'll see that it has been successfully initialized, and the version is 2.70.0.That's great. So now let's go ahead and try various other versions of arguments here. So let's try less than equal first. So just by mentioning 2.0, you have a 2.70 version that has been downloaded. So let's go ahead and change this. I'll say it's less than equal to, let's say 2.60. Let's go ahead and save this. Let's also remove the log file. We'll clear the screen, and let's do a terra for a minute. Now, based on this constraint that you have specified, you see that it is installing the version 2.60.0, which matches your constraint over here. Now also note that within the description it states that Terraform has created a log file named "Terraform log HCL" to record the provider selection it has made about.So that was one part. Let's also try the last one, which is greater than or equal to the comma-separated phrase less than or equal to So this time, let's say greater than or equal to 210 and less than or equal to 230. We'll go ahead and save it. Let's make sure to remove the log file as well, and then do another Terraform in it.So now, based on this constraint, you see that TerraForm has selected version 230.0. Great. So I hope, at a high level overview, you understand the basics of version number arguments that you can specify under the required provider clock. So now let's assume that you officially want to go ahead and switch to version three of the provider, primarily because we are playing around with version two as of now. So in such cases, let's say that you have specified something like this, which is 3.0. So since there is a log file, we already know that whenever you do a TerraForm in it, this will be blocked. So, if you want it, you can do a TerraForm with the hyphen of an upgrade flag in it.So now it will go ahead and find the latest version of the provider based on the constraints that you have set. So in my case, as of today, it is using 3.27.0, and your log file will be updated with the version that it has used. So for example, let's now look into the log HCL. So now the lockheel is back to 3.27.0. That's great. So before we go ahead and conclude, let's quickly revise the basics of the dependency lock file. So the TerraForm dependency lock file allows us to lock to a specific version of the provider. Now, do note that this specific file that we are discussing is a newer one. So, if you're using an older version, say 0.70 point twelve, you won't see anything like this year.So the second point states that if a particular provider already has a selection recorded in the log file, TerraForm will always reselect that version for installation, even if a newer version has become available. So currently, you have a 2.7.0. Tomorrow, even if a 3.0 version is available, TerraForm will not go ahead and download the latest version of the provider when you do a TerraForm minute. Also, as previously discussed, you can override this behaviour by including the Hyphen upgrade flag while using the Terraform.Now, before we conclude, one of the questions that comes up is, "Hey, my entire infrastructure is working perfectly with version one of the provider plugin." Do I need to switch to Version Two? And the answer is, "it depends." Many times, let's assume you're currently using Digital Ocean version one as your provider.And after one week, Digital Ocean has launched a new service. So that new service might not be directly supported with Version 1 of the provider. It will be supported with version two of the provider. So if you have to create a resource with the newer service that Digital Ocean has launched After the version one provider is released, you must upgrade to the newer provider version.So in a high-level overview, this is one of the selection criteria. But even with version two, you have to do a proper amount of testing. There have been cases where an organisation directly switched to a newer version of the provider and things broke without reason.

Read, Generate, Modify Configurations

1. Overview of Course Lecture Format

Hey everyone and welcome back.So till now we have been doing somebasic things with TerraForm, like creating servers acrossmultiple providers, like AWS, Digital ocean destroying servers,as well as looking into some some ofthe basic aspects of TerraForm.So till now, I hope you know on howeasy it is to get going with TerraForm.Now, before we go ahead and discuss in moredetail about various features that TerraForm offers, I wouldnow like to reiterate some of the important aspectsof course, specifically related to the lecture format.So let's get started.Now, one important part to remember is thatwe tend to use different folder for eachpractical that we do in the course.So using different folders allows us to be moresystematic and also allows us to easily revisit theolder practicals that we might have done.So, this can be better explained with thistable where you have three lecture names.Let's assume you have first lecturename as create for CC twoinstance Painting, Resource and Conditional Expression.So each one of the TerraForm code associated withthis practical will be in three different folders.So your folder one folder to folder three, and eachone will be associated with a specific lecture name.Again, the folder name are just for theexample, you can have a proper folder namewhich are directly linked with the lecture names.So, let me quickly show youthat from the Windows Explorer.So from here you see that there aremultiple folders that are available and each onehas a unique name like Dynamic Block, dataSources, Count Parameter, Conditional Expression and so on.So, let's say tomorrow I want toreview the code of conditional expression.All I have to do is I have to gointo the Conditional expression folder and I have all thenecessary ta files that are available over here.So this becomes much more easier.And I will really recommend you to follow thisspecific approach where you have a different folder foreach practical, and each folder will have its ownfiles that you can later revisit in case ifyou want to revise it, great.So this is one important format that we need to know.Second important aspect is that you can alsofind the appropriate source code from the GitHub.This is something that we have discussed earlier.However, I just wanted to reiterate one more time.So all of our code which we have donein the practical is arranged within our GitHub repositoryaccording to the sections that are matched to thedomains that are part of the course.And every section within the GitHub haseasy README file for quick navigation.Now in fact, let me quickly show you this.So, this is our TerraForm course, and you see thatthere are multiple lectures that are available over here.Again, the navigation will be little different because I'mlooking into it from an instructor point of view.Now, initially what we had done was in theinitial lectures at the start of the course, Ihad included the links, if you see I haddirectly included the links of a repository.So you would see you directly have the link tothe practical resource that we had done after the lecture.So this was just for ease of use.However, once you progress, we do not reallyadd the practical resource after every lecture.So what is assumed is you go to ourTerraForm beginner to advance GitHub page that I hadshared in the start of the course and herewe have multiple sections that are available.Let's quickly look into one of the sections.So one of the section hereis read generate and Modify Configuration.And the same thing that you can see overhere, you have read Generate and Modify Configuration.So you can quickly navigate based on the section name.So once I click on this specific section, youwill see that you have a nice README fileand each README file basically has the name ofthe video that you need to refer.So for example, one of the Lecternimages understanding attributes and output values.And within year you have one of thelinks which is understanding attributes and output values.So when you click over here youcan directly find the exact configuration thatwe had used within our specific practical.So this is much more easierto go ahead and explore things.Now for certain practicals over here you will see thatthere are multiple files like you have barsdemo TF, youhave variables TF and in that case both of thefiles are part of the same page.So you can directly copy the first one and you canalso copy the second one from the GitHub page directly.Now the third very important pointer isalways destroy the resource after practical.So we have already looked into howwe can destroy the TerraForm resource.So you can run the TerraForm destroy command whichwill go ahead and destroy the resource for you.So after you have done your trial anderror, after you have completed the entire practical,make sure that you destroy the resource beforemoving to the next practical.Otherwise it will become difficult because even if Iforgot to do a TerraForm destroy at the endof the month you will get a bill associatedwith the resource that you had created.So this is one important part.Now TerraForm destroy becomes much more easier ifyou are maintaining separate folder for each practical.And this is one of the precisereason why we had done this approach.

Go to testing centre with ease on our mind when you use HashiCorp Terraform Associate vce exam dumps, practice test questions and answers. HashiCorp Terraform Associate HashiCorp Certified: Terraform Associate certification practice test questions and answers, study guide, exam dumps and video training course in vce format to help you study with ease. Prepare with confidence and study using HashiCorp Terraform Associate exam dumps & practice test questions and answers vce from ExamCollection.