Let's change our instance's name to be hello-updated-instance:

resource "aws_instance" "hello-instance" {
  ami = "ami-9bf712f4"
  instance_type = "t2.micro"
  subnet_id = "subnet-5f22f536"
  tags {
    Name = "hello-update-instance"
  }
}

Before we actually run the update, wouldn't it be useful to see what exactly Terraform would do when we run the terraform apply command again? Luckily, there is the terraform plan command that does exactly the same, that is, it shows you what applying would do by checking the template, state file, and actual state of the resource:

$> terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.
aws_instance.hello-instance: Refreshing state... (ID: i-119a10ac)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.
Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.
~ aws_instance.hello-instance
    tags.Name: "hello-instance" => "hello-update-instance"
Plan: 0 to add, 1 to change, 0 to destroy.

It's a good practice to always run plan before apply. This saves you from accidental deletion or resource updates that you didn't plan to have.

We can also check whether the template file is valid with the terraform validate command. Remove one of (any of) equal signs from your template, then run this command to get a result similar to the following:

$> terraform validate 
Error loading files Error parsing /home/kshirinkin/work/packt-terraform-rewrites
/template.tf: At 9:17: nested object expected: LBRACE got: ASSIGN

Another nice command is terraform fmt. Similar to (and likely inspired by) the Go go fmt command, terraform fmt will format your template file to comply with best practices. If you run it, then your code will be aligned a bit nicer:

# Resource configuration 
resource "aws_instance" "hello-instance" { 
  ami           = "ami-9bf712f4" 
  instance_type = "t2.micro" 
  subnet_id     = "subnet-5f22f536" 
 
  tags { 
    Name = "hello-update-instance" 
  } 
} 

It looks like nothing terrible will happen if we run the terraform apply command, so let's go ahead and do it:

$> terraform apply
aws_instance.hello-instance: Refreshing state... (ID: i-06f88fe6a2b4307b8)
aws_instance.hello-instance: Modifying...
  tags.Name: "hello-instance" => "hello-update-instance"
aws_instance.hello-instance: Modifications complete
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.
State path: terraform.tfstate

Terraform successfully modified our instance. Let's see what happened to our state file:

$> head terraform.tfstate
{
    "version": 3,
    "terraform_version": "0.8.2",
    "serial": 1,
    "lineage": "65a6dc1b-3f42-4f23-8df1-8b2275602aff",
    "modules": [
        {
            "path": [
                "root"
            ],

As expected, Terraform increased the serial key, as it does for every Terraform run. We are not going to need this specific instance any more. We can safely destroy it now.