Terraform keeps track of your infrastructure state. What happens when you manually change a resource outside Terraform?
Which option best describes Terraform's behavior when you run terraform plan after such a manual change?
Think about how Terraform compares the saved state with the real infrastructure.
Terraform compares the saved state file with the real infrastructure. If it finds differences, it shows them as drift in the plan, so you can decide how to handle them.
You want to share Terraform state safely among your team and avoid state conflicts. Which remote backend is the best choice for this purpose?
Think about safe sharing and preventing simultaneous edits.
Using a remote backend like AWS S3 with DynamoDB locking allows safe sharing of state and prevents concurrent changes that could corrupt the state.
Which of the following Terraform backend configurations correctly enables state locking to prevent concurrent modifications?
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "prod/terraform.tfstate"
region = "us-west-2"
# Which option enables locking?
}
}Look for the exact parameter name for DynamoDB locking in S3 backend.
The S3 backend uses a DynamoDB table for locking. The correct parameter is dynamodb_table to specify the lock table.
Your Terraform state contains sensitive information like passwords and API keys. What is the best way to protect this data in the state file?
Think about encryption and backend capabilities.
Encrypting the state file at rest using backend features (like S3 encryption) protects sensitive data from unauthorized access.
After running terraform apply, you manually delete a resource in the cloud provider console. What will happen when you run terraform plan next?
Think about how Terraform compares state with real infrastructure.
Terraform detects that the resource is missing in the real infrastructure but present in the state file, so it plans to recreate it to match the state.