Understand Terraform's purpose →easyMultiple Select

TF-004 Understand Terraform's purpose Practice Question

A small company with no cloud automation today wants to understand what adopting Terraform would give them beyond simply storing infrastructure definitions in Git. Which two outcomes does Terraform's core workflow provide? (Choose two.)

⚠ Common exam trap

The trap here is conflating Terraform's provisioning scope with configuration management and monitoring duties that other tools own.

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

✓

A preview of proposed changes before any are applied, so reviewers can approve or reject them.

Terraform's core workflow is write, plan, and apply, backed by state. The plan step gives a reviewable preview of pending changes, and state maps configuration to real resources so subsequent runs can detect drift and compute targeted updates. In-guest OS remediation, application monitoring, and universal zero-downtime guarantees fall outside the provisioning workflow and are handled by other tooling or by explicit design choices.

Answer analysis

Option-by-option breakdown

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

✗
Continuous runtime monitoring with alerting when application latency exceeds a threshold.
Why it's wrong here
Monitoring and alerting on application metrics are observability concerns handled by dedicated platforms, not by Terraform's plan and apply workflow. Terraform can create the monitoring resources themselves, but it does not evaluate latency thresholds or page anyone. This option describes a capability outside the provisioning workflow, so it does not apply here.
✗
Automatic remediation of misconfigured operating system settings inside running virtual machines.
Why it's wrong here
Terraform provisions and manages infrastructure through provider APIs; it does not enforce in-guest operating system configuration or remediate settings inside a booted VM. That work belongs to configuration management or image-building tooling. Expecting Terraform to fix OS-level drift misstates its scope, so this is not an outcome of its core workflow.
✓
A preview of proposed changes before any are applied, so reviewers can approve or reject them.
Why this is correct
The core workflow includes terraform plan, which compares configuration and state and shows the actions that would be taken without changing real infrastructure. This preview supports peer review and change approval, which is a concrete benefit beyond merely keeping definitions in version control, since Git alone cannot show what an apply would do.
✗
Guaranteed zero-downtime deployments for every resource type without any configuration effort.
Why it's wrong here
Downtime depends on how a provider implements changes; some attribute updates force resource replacement, which can interrupt service unless the configuration supports graceful transitions such as create-before-destroy. Terraform offers no blanket guarantee, and achieving zero downtime requires deliberate design, so this option overstates what the workflow delivers.
✓
A recorded mapping of configuration to real resources that lets later runs detect drift and target updates.
Why this is correct
Terraform maintains state that maps declared resources to real remote objects, including their attributes and dependencies. That record is what allows a later plan to detect that someone changed a resource outside Terraform and to compute precise updates, a capability that plain Git-stored definitions cannot provide on their own.

Go deeper

TF-004 Understand Terraform's purpose Practice Question

Why each option matters

Option-by-option breakdown

Related to this question