1. Overview of Terraform Cloud
Hey everyone, and welcome back. Now in today’s video, we’ll be discussing the TerraForm cloud. Now, TerraForm Cloud manages the TerraForm brands in a consistent and reliable environment with various features like access control, a private registry for sharing modules, policy controls, and others. So, there are multiple features that are part of the TerraForm cloud.
Now, I still remember that in one of the organisations that I was working with, everyone within the team used to have a different TerraForm version. Because the telephone keeps on updating the version here and because of the different TerraForm versions of the team members, there used to be a lot of issues that we used to face. That aspect is now resolved if you use TerraForm cloud, primarily because you have a consistent and reliable environment in which to run your TerraForm-related activities. So again, it’s not just about running the TerraForm activities. There are many other features that are also available in TerraForm cloud. So let’s do one thing: let’s directly jump into the demo so that we can explore how Terraform Cloud looks and also look at the features. So currently I am in the TerraForm cloud, and this is what the GUI looks like. Now, if you see over here, we have one workspace that is running, and the name of that workspace is demo hyphen repository.
So let’s quickly open this up. Now, within this workspace, within the run list, there are two jobs that are primarily available. One is the discarded one, and the second one is still in the need for confirmation stage. So, if you look at the discarded one, you can see exactly what the TerraForm plan produced. Then it also shows you the cost estimate, which is quite a great feature. So, based on the Terraform plan and the resource that has been created, it will show you the monthly and hourly costs that the resource may incur. And then you have the third stage of applying. And here it states that there is a user called azeelbora, and the zeelbora user has discarded the apply state. So this is what the discarded job looks like. So, let’s go back to the demo repository, and you have one more job here. So, if you see one in the current run that requires confirmation, you have one that requires confirmation. So what has happened here?
The plan is finished. It has basically shown you the output of the TerraForm plan. It also shows you the exact TerraForm version. Over here, it shows you the cost estimation. You can now also check the policy here. So what is this policy check here? Does it check to see if the newly created EC to instance has a tag? So that is what the policy check does, and it states that this policy has passed. So if you see that the result is true, that basically means that the instance has the tag. Again, there can be complicated policies, but this is a simple policy check. We are now in the “apply pending” stage, where you can confirm and apply, discard run, and add a comment. So let me confirm and apply, and here you can add your own comment, let’s say verified by Z. Once you have done that, you can confirm.
And now what will happen is that it will go ahead and apply the changes. So currently, as you can see, it is basically in the creating stage of the EC2 instance. Great. So our application was completed in 24 seconds. As a result, the output is very similar to how we would create a Terraform application using the CLI. So this cost estimation as well as the policy check are great features that are available. Now again, any user who is logged in as part of the TerraForm cloud will be able to see your run list, whether the run list is discarded, and if discarded, why it is discarded. Then again, you will have the features that we are discussing here. Let me just maximise this.
So you’ll have a feature where multiple users will be able to comment on your specific run. So this is again very beneficial whenever you have a team and want to quickly get input from them. So this is one aspect here. Now, the next thing I wanted to show you was the state. So basically, the state file is maintained in the cloud itself. So you see, this is basically the state file associated with the error code that we have applied. Now, you also have the option of adding variables, so you can go ahead and do the variables here.
So in my case, I’ve added the access key, the secret key, as well as the default region. You can also include any other variables that you want. So these are part of the environment variables, and these are basically the TerraForm variables over here. Let’s move on to the modules tab, where you can publish a module if you so desire.
Now, do remember that TerraForm Cloud does provide a private registry for sharing the module. So, once again, this is a fantastic feature. The next thing is the settings, where you go ahead and configure the setting. One of the important settings here is the VC provider. This is where you go ahead and configure your TerraForm cloud with the git repository where you will be storing your TerraForm code. So in my case, I have a Git repository, basically on GitHub, where I have stored my TerraForm code. In this case, it is EC 2 TM. So my TerraForm cloud will basically fetch the code that is part of my repository, and I’ll be able to do the TerraForm-related activities here like TerraForm plant, TerraForm apply, and so on.
Now, you again have the feature of cost estimation. This is something we’ve already seen, where it attempts to estimate the cost of the resources that will be created. Now the next interesting feature is basically the sentinel one, where you can go ahead and create the sentinel policies. So as we were discussing that, there was one policy, and this policy is basically to verify whether the instance has tags or not. If the instance does not have a tag, then the run will fail. So again, depending upon the enforcement mode, there are multiple enforcement modes like hard, soft, advisory, and so on. Depending on that, the TerraForm application may or may not fail.
2. Creating Infrastructure with Terraform Cloud
Hey everyone, and welcome back. Now in the earlier video we hada quick demo about the TerraForm cloud. We also looked into some of the features that are part of the TerraForm Cloud offering. Now in today’s video, we will go ahead and set up our own TerraForm Cloud account. We will investigate the steps required for the same. Now, the first and foremost question related to TerraFormCloud is whether it is free or not. The answer is both yes and no.
So basically, TerraForm Cloud has multiple offerings that are available. So you have the free one, you have the team one, you have the team governance, and so on. So, depending on the feature sets that you require, you can choose between the free and paid options. So primarily, the highest number of features that are available are within the self-hosted one. However, you will need to discuss this with the TerraForm sales team. So what we’ll be doing in today’s video is using this free one. So the free one allows unlimited workspaces and allows up to five users. So this is quite good, and we’ll be able to do all the basic things from the free one over here. When you open the TerraForm IO app, you will see something similar to this sign-in screen. To begin, simply click on “Create a free account.” The next thing that you’ll have to supply is the username, email address, and password. So let’s try it out. So the username, which I’ll refer to as “demo Kplabs,” is the email address. I’ll use a test email address I have because the email address associated with the Kplabs was previously used for the demo account.
So let’s do a Zeldor at ratelive.com, and then you can go ahead and supply the password associated. So let’s go ahead and agree to the terms and create the account. So as soon as you have done that, it will basically ask you to confirm the email address. Let’s quickly do that. So the confirmation email has apparently gone to jump. So always verify this. Let’s click here, and let’s click on confirm. Great. So it states that the email address has been confirmed. So now there are two options over here. primarily, which states I am new to Terraform, and second, I have used Terraform before. So you can go ahead and start a fresh Terraform configuration in case that is required. So it will basically show you the documentation on how to get started with the TerraForm cloud, how to integrate TerraFormCloud with your version control system, and so on. So this is also something that you can explore. However, let’s jump into it and create an organization.
So you can also go here, and within the organization, you can create the organization. So for the organisation name, let’s call it Demorg, and for the email address, let’s use the same email address that we had used, and let’s go ahead and create the organisation here. Great. So our organisation is created, and now, as you can see, it has taken us to the Workspace tab. So basically, you can go directly here, and again, you are in the Workspace tab. As a result, no workspaces have been created as of yet. So what you have to do is create a new workspace. Now, whenever you create a new workspace, you have to first connect it to one of the version controls. You also have the option to not do that. However, integrating it with version control is something that is important. So let’s do that. Let’s go to the settings, and you have the VCs provider over here. So let’s go ahead and add our first VC provider. So there are multiple ones that are supported.
Let’s go ahead and use GitHub. So within the name, let’s call it “GitHub,” and here it requires a client ID and client secret that you can get from GitHub. So let’s go to the GitHub page and also sign up for GitHub. So let’s call it the Kplabs demo. The email address is Zeelborated Live, and let’s add a password and click on sign up. So let’s quickly verify the account by solving this puzzle. This is an interesting puzzle, by the way. Now this is a new addition, so let’s go ahead and roll it in the right way, and then let’s click on “Done.” Great. So let’s just deselect the email preference here and join the free plan. So initially, you will have to quickly add these. Let me just select the role of teacher, how much programming, let’s say moderate, and whether you can quickly complete the setup. The next step is to quickly verify, so basically, in my email account, I received a verification email, and let’s click on Verify email address. Great and things are done. Let’s quickly create our first repository.
Let’s call it the “Demo repository,” keep it private, and let’s create a repository. Great. So once the repository is created, let’s do one thing. Let’s go to the settings, and basically what we need to do here is configure the client ID and client secret over here. So basically, you also have the option to register an application on GitHub.com. So if you quickly open this up, it basically shows you a step-by-step guide on how you can do that. So the first step is to open the Settings application and select New. So from the settings, let’s quickly go to the developer settings, and you have the Auth apps over here. All you have to do now is create a new application. Let’s call it the TerraForm cloud. Then it’s the home page URL, so if you go a bit down, you will basically get the home page URL that you can copy it up.
Let’s paste it within the authorization callback URL. This is something that you can skip for now because it has not been generated. So you can just add an example callback URL over here. After that, you can proceed to the Register application. As soon as you do that, you basically get the client ID and the client secret. So this is something that we need. So let’s copy the client ID and paste it over here within the TerraForm Cloud. The same goes for the client’s secret. Let’s paste it over here. Once you have done that, you have to click on “add the VCs provider,” and once you do that, you basically get the callback URL, which you have to add to the GitHub page. So now we’ll replace this callback URL and we’ll update the application. All right. After you’ve updated your application, go ahead and click on the Connect Organization demo at Kplabs Hyphen.org. So let’s click on “authorize,” and that’s about it. You have connected your VCs provider, which is GitHub, to the TerraForm Cloud. Now the next interesting thing that we need to do is upload some files over here. So let’s go back to GitHub, and within that repository, let’s go ahead and add a file.
So you can go ahead and create a new file over here. Let us refer to it as EC 2; TS. And we’ll just copy and paste the EC-2 code over here. Once you have done that, you can go ahead and commit the file. Great, so our file is committed. Now let’s go back to the Terrafirma cloud. We’ll go to workspaces. As a result, no workspace has been created as of yet. Let’s go ahead and create a new workspace. Now within here, we’ll be selecting the GitHub that we have already configured. And within here, you have to select the repository within your GitHub page once, then you can go ahead and click on “create workspace.” Great. So it states that the configuration has been uploaded successfully. Now, the next thing that you have to do is you have to configure the variables here, and primarily you have to configure the environment variables.
Now, if you note over here, we had not configured any provider; we did not configure any access key, secret key, and so on. And we’ll add those items to the TerraForm Cloud environment variable. Now, if you look into the documentation associated with the AWS provider here, they have mentioned various different ways in which you can configure your keys. One of the approaches here is to look at environment variables, and this is what we need. So let’s try it out. So first, let’s copy the access key ID. Now, within the environment variable, I’ll add the access key ID, and then you have to paste the value. So in my case, let me paste the value. You can also mark this as sensitive in case you need it. Let me not do that. I’ll quickly show you how exactly this might look like. Let’s click on Save variable, and if you do not mark it as sensitive, basically you’ll be able to read it outright. Let’s also add one more variable. This time, it would be the AWS secret access key.
So I’ll copy this and paste it within the value. Let me go ahead and paste this. This time I’ll mark it as sensitive. Let’s click on “variable.” And now you see that you do not see that specific variable. The next thing you have to do is add one more variable associated with the region. So you have the AWS default region, and let’s call it as US two once. Then you can go ahead and click on “Save.” Great. So these are the three environment variables that have been configured. So now let’s go back to our demo repository. And now what you can do is click on the queue plan and select the queue plan over here. So now what will happen is that the TerraForm cloud will go ahead and check this EC-dot-TF file, and then it will do a TerraForm plan on the TF file that is part of the repository. So you will see here that it has implemented the TerraForm plan. It is using the AMI ID that we have configured as well as the instance type, which is T2 micro. Once this is done, it takes a little amount of time, then it basically goes to the “apply pending” state.
So basically, there are two primary states that are available. You have the plan running, and you have the Apply Pending state. So let’s quickly wait for a moment here. So now you see that as soon as the plan was finished, it went to the “needs confirmation” state. You can now either confirm, discard, or leave a comment. So all I need is confirmation and application. Let’s quickly do that, and I’ll say “confirm and verify by Z once.” Then you can go ahead and click on “Confirm plan.” So now you have the Apply running state, which will basically show you the output whenever you get an error from apply. Great, let’s actually maximize this.
So our application was completed in about 25 seconds. So basically, our EC2 instance has been created. Now for confirmation, if you go to the Oregon region, you will see that our EC2 instance is now running. So these are the basic steps that are required to go ahead and run your first Terraform through the Terraform cloud. Now, if you’ll see, the entire TerraForm state is basically stored online so that you can quickly verify. So this is basically the remote state that is part of the TerraForm cloud itself. Now, if you go to settings, you can also go to destruction and deletion.
Now from here, you can either destroy a plan or you can even delete it from the TerraForm cloud. So, let’s quickly devise a queue destruction strategy over here. You must essentially provide the namespace. The namespace was “demo repository.” Let’s devise a queue destruction strategy. So now, if you look at the Terraform plan, it says that there is one to destroy. So then would come the “pending” state. So again, it is asking us to confirm and apply. Let’s get this done quickly and confirm the plan. So let’s take a step back. So you’ll see that it is currently destroying the infrastructure here. If you refresh the page, you will see that the instance is shutting down and will be terminated. Great. So our infrastructure that we have created is now destroyed, and if you will see from the console, the instance is terminated.
Now, before we conclude, let me show you one more thing. So, if you click here within the plan and building, you’ll see a free plan with one active user. So basically, with the free plan, there are not all the features that are available over here. So you can always change plans and use this trial plan, which is available for 30 days. As a result, many other features will be available as part of this trial plan. So let’s click on “Start your free trial.” So currently, these are the only options that are available for the free plan. However, when you do a trial, there will be a lot of other options that will be available. So let’s get started right away with a free trial. Now you see that there are a lot of other features that are available, like policies and policy sets. You have cost estimation also, which is quite a good feature that we had already seen in the demo.
So let’s enable this cost estimation over here and within the workspace this time when you do a queue plan. There will be one more stage that will be added, and that stage would be the cost estimation stage. So let’s quickly wait for a moment here. So our planning stage has finished, and then came the cost estimation stage. Now again, the cost estimation stage has ended. So it basically gives you the monthly cost, which is $8.35. You can now either confirm and apply or cancel the run. So let’s say you can do a discard run and say that’s too expensive. All right, so let’s do a discard run. So now it states that the run has been discarded. So now what will happen is that the application will not run. So if you go to the demo repository here, you should see that you have onerun, which is in the discard state. Great. So that’s a high-level overview of TerraForm cloud implementation. We also look into some of the features.
3. Overview of Sentinel
Hey everyone, and welcome back. Now in today’s video, we’ll be discussing the sentinel. Now, Sentinel is an embedded policy with a code framework that is integrated with Hashioki enterprise products. So it enables fine-grained logic-based policy decisions, and it can be extended to use information from external sources. As a result, the overall workflow resembles the Where you have a TerraForm plan, you have a sentinel check. So within the sentinel check, you write policies. So policy will basically verify what exactly your TerraForm is planning to do, whether the ETO instance has appropriate tags, and so on. So, depending on the use case, you can write the sentinel policies.
And then, depending on whether the sentinel checks succeeded or failed, it goes to Terraform. Now, do remember that sentinel policies are a paid feature over here. So, at a high level, remember this specific workflow diagram where you have a policy and within the policy you write a sentinel policy, and you associate the policy with the policy sets, and the policy sets themselves associate with the TerraForm workspace that you may have. So that’s the high-level structure. Let’s quickly go to the TerraForm cloud to look into it and also see how we can enable it. So currently, I am in the TerraForm cloud. Now, if you go to settings, you will see that there are two tabs that are available. The first is policy, and the second is policy sets. Now, one important thing to remember is that, by default, you are on the free plan.
If you have changed to the trial plan, then only you will be able to see this because primarily these are the paid features. If you are still on the free plan, you will not be able to see this. So again, similar to the steps that we had taken in the TerraForm cloud video, I will recommend that you switch to the trial plan, and you can go ahead and play around with the sentinel policies and policy sets. So let’s go ahead and create our policy set. So let’s click on “Connect a new policy” here. You can now connect it to the version control provider or leave it disconnected. Let’s use the simplest one. Let’s say there’s no VCs collection and I’ll say demo policy set, and then you have the option of enforcing the policy across all workspaces or just a few. We’ll be using all workspaces, and we’ll go ahead and create a policy set. So we have a set of policies that are created. The next step is to go ahead and create the policy. Now again, this is the simplest approach. So this is the reason we are exploring it right now.
So let’s go ahead and create a policy. So I say it is simple to tag and verify, and there are three enforcement modes available: hard mandatory, soft mandatory, and advisory. Hard mandatory is something that you cannot override, so let’s select that, and then you have to add the sentinel policy code. Now for our example, we’ll be making use of the sentinel policy that is part of the documentation, and this policy checks whether the instance has a tag or not. So let’s go ahead and copy this demo policy. We’ll add it as part of the policy code, and within the policy set, let’s go ahead and select the demo policy set that we have.
We’ll make an advertisement and a policy. Great. So now we have both the policy as well as the policy set that has been set up. So now let’s go to the workspaces here; we’ll go to the demo repository, and let’s do a queue plan. So now if you see that you have one more tap that has come up that does the policy check, So, first, there are the plan states, then there are the pending costs, and finally, there is the policy check. And, depending on the enforcement mode you chose, you will only be able to go to “pending” after the policy check. So let’s quickly find that out. So our plan is finished. Great. Our cost estimation is also finished. Our policy check is hard-coded over here, and it also shows you the policy, which is easy to tag verified. And now you see, you do not have any option to proceed further, even if you are an administrator over here. So there is no option to go further. This specific run is completely blocked, primarily because of the enforcement mode that we had selected.
4. Overview of Remote Backends
Hey everyone, and welcome back. Now in today’s video, we’ll be discussing the remote backends. Now the remote backend basically stores the TerraForm state and may be used to run the operations within the TerraForm cloud. Now, one important thing to remember is that TerraForm Cloud supports multiple types of back-end operations.
The first is the local one, and the second is the remote backend operation. So if you are making use of a local operation, here it states that the overall state is stored within the TerraForm cloud backend. However, the important and very interesting one is the remote operation type. With the remote operation, the overall operation, such as Terraform plan or TerraForm, can now be executed within the TerraForm clouds environment, with log output streaming to the local terminal. So let’s say you have created a file called “EC dot TF” within your local workstation and you are using remote operations. When you create a TerraForm plan, the entire plan, as well as the TerraForm state file, is saved at the TerraForm cloud level. Please keep in mind that the TerraForm plan and TerraForm application occur in the cloud, but the logs are obtained at the local terminal. So let’s quickly have a look at it to understand how exactly it works.
Now I have a folder called “enhanced backend,” and within this folder I have an IAM TF file that is configured. Now, within this IAM TF, what we have is a simple resource block of an AWS in user, and it is going to create an in user called a remote user. Now if you look into the back end that we have here, the back end that we are making use of is remote, and we have one more file called “backend HCL,” and this file basically gives information about the workspace that we have within the TerraForm cloud as well as the organisation within the TerraForm cloud. So generally, whenever you configure a TerraForm cloud, the first thing that you need to set is the organization, and the next thing that you have to set is the workspace. So both of these things, as well as the basic resource block, are configured.
Now, I also have a token that is configured that will allow me to connect to the TerraForm cloud. So, from now on, whenever I create a TerraForm plan, Looking at the output, you can see that it is basically running the plan in the remote back end. In our case, it is the TerraForm cloud, and it is also saying that if you want to view this plan from the browser, it has also given us the link for the same. So, let us pause for a moment, and it has basically given us the output. Now, if you look over here, the first thing that it is doing is basically giving us a simple plan output. Following that, it provides us with a cost estimate. I hope you know about the feature of cost estimation as part of the TerraForm cloud, and along with that, the overall sentinel policy will also be checked. So currently, if you see that it also looks into the sentinel policy, and if the sentinel policy also succeeds, then at a later stage you will be able to do a TerraForm application. Now all of this data is basically coming from the logs that are generated from the TerraForm plan. So let’s quickly look into this run from the browser. Now, here you see that it states that the plan is finished.
So this is basically the first step, and this entire output is what you were able to see from the CLI of your laptop. The cost estimation came second, and the policy check came third. So all of these were also streamed to the CLI over here. So this is what the remote operation means. So, if you look at the first pointer over here, you’ll see that when using remote operations, operations like TerraForm plan or TerraForm apply can be executed in the TerraForm cloud run environment, with log output streaming in the local terminal. Now, one more important part to remember here is that we have not specified anything like the access key, the secret key, and so on. All of these things are coming from the TerraForm cloud. So if I have to quickly show you, if you look into the variables over here, we have already configured variables like access key ID, secret key ID, as well as the default region.
And with these, we can create the TerraForm plan and successfully complete the TerraForm application. Now, one very important part to remember is that if you are making use of remote operations over here and if you have configured your resource locally, then whenever you create a workspace, you can only make use of a workspace that does not have a VCs connection. So if you are making use of a VCs connection where your workspace is integrated with GitHub and you also have your IAM TF configured over here, then it will not work. Let me quickly show you this: So, when we do a Terraform apply from the CLI, we get an error stating that apply is not allowed for the work workspace with a VCs connection. So what it tries to say is that you should have a single source of truth where your TerraForm files are configured. As a result, you cannot configure one file in GitHub and another locally. So you can either make use of a workspace that is associated with the VCs or maybe use a workspace that is not associated with a VC.
5. Implementing Remote Backend Operations in Terraform Cloud
Hey everyone, and welcome back. Now in the earlier video, we looked at the remote backend and also an interesting feature of remote operations, so in today’s video, we will go ahead and implement it from scratch so that we understand the steps that are involved. The first thing you need to do is set up a workspace. It can be a VC-associated one or a non-VC-associated one. So let’s create a new workspace over here. Let’s use a no-VCS connection and call it workspace for the Kplabs remote back end. We’ll go ahead and create a workspace.
So this is the first step that is required. Now the second important configuration here is the backend HCL. So on the backend, HCL will have the information related to the workspace related to the organisation within the TerraForm cloud as well as the hostname. So the hostname in this case is App TerraForm IO. The organisation is democplabs.org, and the workspace is Kplab Hyphen remote back end, which we have created here. So if you will see, this basically forms the organisation that is demo hyphen Kplabs.org.
As you can see, we have one workspace called Kplabs Hyphen remote Hyphen backend over here. The next thing you need is a local resource, something similar to what we’re talking about, and a TerraForm configuration year, which has a required version of zero point twelve and a remote back end over here. So this basically indicates that we will use the remote back end, so these are the two initial configuration files, and let’s do a Terraform in it. Now, within the documentation associated with the remote backend, you will see the commands that are supported as part of the remote backend, so these are all the commands that are supported. Now the documentation also shows you the basic configuration that is required, something that we have already seen. So you have the back end remote as well as the back end configuration defined in a file called the backend HCL within the main PS.
It also indicates that in order to initialize, you must use back end configuration, which is equivalent to back end HCL, which will basically provide the information associated with the host name so that it can find your organisation as well as the workspace. Now, one important part to remember—in fact, they have not shown it in the example here—is the token. So basically, the token is important if you want to authenticate with the remote back end. So what we can do is make use of the TerraForm login command to manually initiate the token. So let’s quickly look into it. So from the CLI, the first thing that you have to do is do a TerraForm login, so it will say if you want to proceed or not, and it will also say that your token will be stored in this specific file. I’ll say yes, and now it will automatically log you into the TerraForm cloud. So it will say, “What is the name of the API token that you want?” So let’s call it a demo hyphen token.
Let’s click on “Create Token,” and here it will basically give you the API token over here. Let’s copy this, and then simply paste it into this prompt. Once you have done that, remember, you will not see anything over here. Even after you have pasted it, you can press Enter. All right, so it states that the token is invalid. In fact, I suspect that the token was not pasted correctly. So let’s copy this up once again, and this time it works as expected. So, basically, my right mouse click does not work as expected. So even though I do a right-click, sometimes it does not get copied. So this is one of the reasons why it did not work the first time. So anyway, now it says that we have successfully obtained and saved the TerraForm token over here. So if you also want to verify this, you can copy the specific path over here. Let’s copy this and go down that road. And here you have the credential tape. JSON Let’s open this up. And within here, you see that you have the overall token that your remote back end can use.
So, now that you’ve done that, you can go ahead and Terraform it. Let’s copy this command. Let’s clear the screen. I’ll paste it up. Great. So this has been initialized. Now let’s go ahead and do a TerraForm plan. As a result, it will also give you the run. So we can go ahead and replicate this. Let’s quickly wait for a moment here. So now we have an error that states that the argument region is required but not set. Remember that the new back end that we have configured has no explicit variables that we are discussing. The variables can be part of your configuration file. At the TerraForm cloud level, it can also be an environment variable. So what we have to do is add your access secret key as well as the region as part of the environment variable within the TerraForm cloud. So let’s go ahead and quickly do that. Now, from a different workspace of the demo repository that we had used in the earlier demos, we already had our environment variables configured. So let’s go ahead and set these environment variables as part of a new workspace. So let’s go ahead and add a new variable here so we can mark this as sensitive.
Let’s add one more variable. I’ll add the associated secret key, and the last one is the AWS default region. Let’s call it the United States of West. Two, we’ll perform a save variable. All right, let’s clear the screen. Let’s do the TerraForm plan yet again. Great. and it seems to be working perfectly well. Let me copy this specific run URL and make it a part of the browser. All right, so this is the specific run. So now, to quickly verify, let’s also do a Terraform application. Great. So it is asking for a value. So the answer would be yes. Great. So it now says that the application is finished. Now, within the Kplabs remote back end, if you see the run, the run is applied, and it is applied a few seconds back. As you can see, the application is now complete. Now the same can be verified within AWS. You see, we have a new Imuser called the remote user. Great. So I hope, at a high-level overview, you understand the practical aspect of how you can configure remote operations on a TerraForm cloud.
