Terraform tracks resources in a state file and only learns about outside changes when it refreshes that state. If you tweak a resource in Azure Portal, Terraform’s view becomes out of sync. When you run the next plan (or apply), Terraform refreshes its state by querying Azure for the current attributes of the resource. This refresh updates the in-memory state to reflect the real-world resource, and the plan will show any drift. When you then apply, the state file itself is updated to match the actual resource, bringing everything back into alignment. So the change is reflected the next time you run plan or apply.

In Terraform, you want to avoid placing secret values directly in configuration files and instead provide them at runtime or via external sources. The only option that would not help with that is a secure string, because it implies embedding the secret value as a literal string in the configuration. That would keep secrets in the code, defeating the goal of externalizing them. Environment variables and the -var flag are common ways to supply secrets without hardcoding them in .tf files, and providers can be configured to read credentials from environment variables or secret stores, further keeping secrets out of the configuration itself.

In Terraform's HCL, indent each nesting level by two spaces. This means the first level inside a block uses two spaces, the next level uses four spaces, and so on. Using two spaces per level keeps code readable and aligns with the official style shown in examples, and avoids the inconsistencies that can come from tabs or other indentation amounts. For example: resource "aws_instance" "web" { ami = "ami-12345678" instance_type = "t2.micro" network_interface { device_index = 0 } } Here, top-level lines inside the resource start with two spaces; the nested block inside has four spaces, showing the two-space-per-level rule. Tabs are discouraged because their width can vary between editors, and options like three or four spaces per level aren’t the standard in Terraform.

Terraform keeps a local state file that tracks what it manages and how resources map to real-world objects. By default, when you don’t configure a different backend, Terraform writes this state to a file named terraform.tfstate in your working directory. This file is JSON and includes resource addresses, IDs assigned by providers, and current attributes and dependencies, which is what allows Terraform to plan changes accurately and reconcile drift. A backup of the previous state is kept as terraform.tfstate.backup. If you configure a remote backend (like S3, Consul, etc.), the state is stored remotely, and there isn’t a local terraform.tfstate file. The other file name options don’t match Terraform’s local-state convention, so terraform.tfstate is the correct choice.