Creation-time vs destruction-time in Terraform - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding creation-time and destruction-time in Terraform

Which statement best describes the difference between creation-time and destruction-time in Terraform?

A Creation-time refers to when resources are provisioned, and destruction-time is when resources are deleted during terraform destroy or resource replacement.

B Creation-time is when Terraform validates the configuration, and destruction-time is when Terraform applies changes.

C Creation-time is when Terraform runs the plan command, and destruction-time is when Terraform runs the apply command.

D Creation-time is when Terraform deletes resources, and destruction-time is when Terraform creates resources.

💡 Hint

Think about the lifecycle of a resource from start to end.

Creation-time is when Terraform provisions resources. Destruction-time happens when resources are removed, either by terraform destroy or when replaced.

❓ service_behavior

intermediate

Behavior of resource replacement in Terraform

When a resource attribute change requires replacement, what happens during Terraform apply?

A Terraform pauses and waits for manual approval before any action.

B Terraform creates the new resource first, then destroys the old resource.

C Terraform updates the resource in place without destruction.

D Terraform destroys the old resource first, then creates the new resource.

💡 Hint

What is the default order of operations for resource replacement in Terraform?

By default, Terraform destroys the old resource first, then creates the new resource. This may cause downtime unless create_before_destroy = true is set in the lifecycle block.

❓ Configuration

advanced

Predicting output of Terraform lifecycle block with create_before_destroy

Given the following Terraform resource snippet, what is the effect during resource replacement?

resource "aws_instance" "example" {
  ami           = "ami-123456"
  instance_type = "t2.micro"

  lifecycle {
    create_before_destroy = true
  }
}

A Terraform destroys the old instance before creating the new one, causing downtime.

B Terraform updates the instance in place without replacement.

C Terraform creates the new instance before destroying the old one, ensuring no downtime.

D Terraform ignores the lifecycle block and uses default behavior.

💡 Hint

Check what create_before_destroy does in the lifecycle block.

The create_before_destroy flag tells Terraform to create the new resource before destroying the old one, preventing downtime.

❓ security

advanced

Security implications of destruction-time in Terraform

Which security risk is most relevant during destruction-time of cloud resources managed by Terraform?

A Destruction-time only affects resource billing, not security.

B Sensitive data might be exposed if resource state files are not securely handled during destruction.

C Terraform prevents any data loss during destruction by default.

D Resources are automatically encrypted during destruction, eliminating all risks.

💡 Hint

Think about what happens to resource data and state files when resources are destroyed.

During destruction, sensitive data may be exposed if state files or logs are not properly secured.

❓ Architecture

expert

Designing zero-downtime infrastructure updates with Terraform

You need to update a critical database server managed by Terraform without downtime. Which approach best uses creation-time and destruction-time concepts to achieve this?

A Use lifecycle create_before_destroy to provision a new database instance before destroying the old one, then switch traffic after creation.

B Destroy the old database instance first, then create the new one to ensure clean state.

C Manually delete the database outside Terraform, then run terraform apply to create a new one.

D Update the database instance in place without replacement, ignoring lifecycle settings.

💡 Hint

Consider how to avoid downtime during resource replacement.

Using create_before_destroy ensures the new database is ready before the old one is removed, enabling zero downtime.