You imported an existing AWS S3 bucket named my-bucket using Terraform import. Which configuration correctly represents the imported resource to avoid drift?
terraform import aws_s3_bucket.my_bucket my-bucket
Check the correct attribute name for the bucket identifier and minimal required attributes.
The correct attribute to specify the bucket name is bucket. The acl attribute is often required to match the existing bucket's access control. The region attribute is not valid inside the resource block. The attribute name is invalid for aws_s3_bucket resource. Versioning is optional and may not match the imported bucket's state.
You want to manage an existing AWS EC2 instance with Terraform. The instance ID is i-0abcd1234efgh5678. Which import command correctly imports this resource?
Check the correct Terraform resource type name for EC2 instances.
The correct resource type for an EC2 instance in Terraform AWS provider is aws_instance. The import command requires the resource type and name, followed by the instance ID. Options B and D use invalid resource types. Option C uses the resource name instead of the instance ID.
You imported an existing AWS RDS instance using Terraform import but did not add any resource block in your configuration files. What will happen when you run terraform plan?
Think about how Terraform treats imported resources without configuration.
Terraform tracks resources defined in configuration. If a resource is imported but not declared in configuration, Terraform considers it unmanaged and plans to destroy it if it was previously managed. Since the resource is not in configuration, Terraform plans to destroy it.
You imported several AWS IAM roles into Terraform but did not enable state locking on your backend. What is the main security risk of this setup?
Consider what happens when multiple users modify state files simultaneously.
Without state locking, concurrent Terraform runs can overwrite the state file, causing loss of changes or inconsistent resource states. This can lead to incorrect IAM role permissions or unintended deletions. Options B, C, and D are incorrect because they describe behaviors unrelated to state locking.
After importing a complex AWS VPC with many sub-resources, what is the best practice to ensure your Terraform configuration matches the actual infrastructure?
Think about how Terraform tracks resources and detects changes.
Best practice after importing is to write configuration that fully represents the imported resources. This allows Terraform to track and manage them properly and detect any drift. Ignoring sub-resources or deleting imported resources defeats the purpose of import. terraform refresh updates state but does not add configuration, so it cannot manage resources fully.