Use Terraform outside the core workflow →easyMultiple ChoiceObjective-mapped

TF-004 Use Terraform outside the core workflow Practice Question

A DevOps team is integrating Terraform into a CI/CD pipeline using Jenkins. They want to ensure that the pipeline fails if the Terraform plan contains destructive changes. Which approach best achieves this?

⚠ Common exam trap

A common misconception is that `terraform plan -detailed-exitcode` only signals destructive changes; in reality, exit code 2 indicates any changes (additions, modifications, or deletions). However, failing on all changes is often acceptable to prevent unintended infrastructure changes.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Run terraform plan -detailed-exitcode and fail pipeline if exit code is 2.

`terraform plan -detailed-exitcode` returns exit code 2 when there are any changes, including destructive changes. While it does not specifically detect only destructive changes, failing on any changes ensures that destructive changes are caught before apply, which is a common safety practice in CI/CD pipelines. Options A, B, and C are incorrect because A requires applying changes first, B does not detect changes, and C would actually destroy resources.

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 and parse the output for destroy messages.
Why it's wrong here
Using `terraform apply` directly within a CI/CD pipeline will immediately provision, modify, or destroy infrastructure, making it a highly destructive and uncontrolled action without prior review. Attempting to parse its output for specific messages like "destroy" is a reactive and unreliable method for detecting changes, as the infrastructure modifications would have already occurred. This approach bypasses critical planning and approval stages, leading to uncontrolled and potentially disruptive infrastructure changes.
✗
Run terraform validate and check output for errors.
Why it's wrong here
Running `terraform validate` primarily checks the syntax and internal consistency of Terraform configuration files. While essential for catching basic coding errors, it does not interact with the remote state or cloud provider APIs to determine if actual infrastructure changes would occur. Therefore, it cannot detect proposed infrastructure modifications or drift, making it insufficient for preventing unintended changes in a CI/CD pipeline.
✗
Run terraform destroy --target and fail if any resources are destroyed.
Why it's wrong here
The `terraform destroy` command is designed to deprovision all or targeted infrastructure managed by Terraform, actively deleting resources rather than planning or detecting potential changes. Running this command, even with `--target`, would result in the removal of existing infrastructure. It is fundamentally unsuitable for a CI/CD pipeline step aimed at identifying proposed infrastructure modifications or preventing unintended changes, as its purpose is to remove, not to plan or validate.
✓
Run terraform plan -detailed-exitcode and fail pipeline if exit code is 2.
Why this is correct
Executing `terraform plan -detailed-exitcode` is the correct approach because it generates an execution plan and signals the outcome through a specific exit code, ideal for CI/CD automation. An exit code of `2` explicitly indicates that a non-empty plan was generated, meaning there are proposed infrastructure changes. Failing the pipeline on this exit code ensures that any intended or unintended modifications are halted for review before an `apply` operation can proceed.

Go deeper

TF-004 Use Terraform outside the core workflow Practice Question

Why each option matters

Option-by-option breakdown

Related to this question