So we previously pasted the access key value into our set environment. We're gonna go ahead and cut and paste the storage account name value into our terra form file. This has this randomly generated I. D. So yours is gonna look a little bit different. The container name itself TF state tea Estate.
That's fine. We can keep that. As is
the last piece of information is the key. And really, this isn't the access key. This is the name of the Terra form state file. And so we're gonna go ahead and call it a Dev. Terra formed TF State is the name of the file on this where it comes down to having different state files for different environments
and then even putting different access controls around those state files.
One thing you may notice is, hey, why are we hard coating the strings and the values of these variables? It wouldn't really be a good idea to make reference to bar, bar, dot storage, account, name, container, name and so forth. I said it would be a good idea. Um,
and especially when you take into account what we learned about variables and environments and so forth.
But terra form does not support that. Things do need to be string liberals A to this point, the language for for reasons that are a little deep to discuss at this point. But the way the constructs in the parsing process goes, it can't evaluate the variables at this point.
we're just gonna leave these hard coded as is I'm gonna come down to the command prompt. We are in the 05 directory. Gonna just run Terra Form and Mitt. Right? So we have this were initializing this very simplistic. It's It's okay. I've got a remote back end, and all I'm gonna do is define a particular resource group, right? So
I'm running to reform in it. You can see
Look at this, Successfully configured. Hopefully you're seeing something like this. Configure the back end of zero r M. If you don't have a message successful than it's having a tough time accessing that that remote storage back end. So maybe some of the values you put in here are wrong.
Also, double check and make sure you have the environment. Variable arm access key.
At this point, we haven't deployed anything.
We just took a naturalization and made sure that the remote back in is there.
What I want to do is shoot over to the user portal and let's take a look at the resource group that was created during the whole bootstrapping process. And sure enough, here we have our storage container. Oh, our storage accounts And then
you can watch is I'm navigating here. I'm gonna look at the different containers, the blob service,
and there's the TF state file. So these air the blobs that were set up,
um, for us, and this is what's gonna be holding the the remote state file.
As you can see, there are no blobs just yet. We haven't run the actual terra form apply process. We're gonna go ahead and do that right now. So if you can return to the consul, we're gonna run terra form apply Very simplistic, really. Should just say I'm gonna create a resource group. Right? But what we're trying to do here
is go through the whole exercise of
having ah, remote back. And sure enough, it's gonna create the resource group were going to say the value of Yes. So what we're expecting to see here when we look back at that blob is a file called the Deaf Terra Form TF state. So the whole the deployment took place successfully.
And sure enough, there is the tea estate. If we were to examine it,
it would look very akin to the TF state that we were looking on earlier in this lesson.
covers the core things of state.
Hopefully, you feel pretty comfortable about that. The only other note I really want to make about the Terra form state file is you noticed we looked at it. It was a Jason format.
It doesn't encrypt anything. So when you have keys and key values,
they're going to be captured in plain text in the terra Form state file. And when we started out talking about this key and putting some access controls around it,
that is a very important issue to take into account, especially in your higher level environments, because that state file could very well have keys if you're setting up servers, for example, giving him an SS H key or some other sort of private keys, and you don't want people to have access to view those
even if it's not a right access, but just to read only access to your production TF state file. Theoretically, someone can get to it and read the contents of it and then figure out what your keys are. So this is a known shortcoming of the TF state file, something to certainly keep into account
as we close out our conversation regarding the Terra form state file.