TF-004 Use Terraform outside the core workflow Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Run terraform apply automatically after plan

  Why it's wrong here

  Automatically running terraform apply immediately after terraform plan is generally a poor practice, particularly in production environments. The plan output should always be reviewed by a human or an automated policy engine to ensure the proposed changes align with expectations and do not introduce unintended consequences, security vulnerabilities, or excessive costs. Requiring explicit approval before execution prevents accidental infrastructure modifications and maintains operational control, making this an anti-pattern for robust CI/CD pipelines.

• ✓

  Use version control for configurations

  Why this is correct

  Using version control systems like Git for Terraform configurations is a fundamental best practice for managing infrastructure as code. It provides a complete, auditable history of all infrastructure code changes, enabling teams to track who made what modifications and when. This facilitates seamless collaboration among multiple developers, allows for easy rollback to previous stable states, and supports robust auditing and compliance requirements by maintaining an immutable record of infrastructure evolution.

• ✗

  Store state in the source repository

  Why it's wrong here

  Storing the Terraform state file directly within the source code repository is highly discouraged due to significant security and operational risks. State files often contain sensitive information, such as resource IDs, outputs, and potentially secrets, which should not be exposed in a publicly accessible or easily compromised repository. Furthermore, local state files lack crucial locking mechanisms, making concurrent operations by multiple users prone to conflicts, state corruption, and inconsistent infrastructure deployments.

• ✓

  Use remote state with locking

  Why this is correct

  Utilizing remote state storage, such as AWS S3 with DynamoDB locking or Azure Blob Storage with container-level locks, is a critical best practice for team environments. Remote state centralizes the infrastructure's current configuration, making it securely accessible to all authorized team members. The integrated locking mechanism prevents multiple users from concurrently modifying the same state, thereby avoiding race conditions, state corruption, and ensuring the integrity and consistency of the managed infrastructure.

• ✗

  Use terraform import to manage existing resources

  Why it's wrong here

  The terraform import command is designed for a one-time operation to bring existing, manually created infrastructure resources under Terraform's management. It is not intended as a continuous management strategy or a CI/CD best practice for ongoing resource lifecycle. Terraform's core philosophy is declarative configuration, where resources are defined in HCL and then created or updated by `apply`; `import` merely populates the state file without generating the corresponding HCL, requiring manual configuration writing afterward.

Go deeper

Related to this question