Use Terraform outside the core workflow →hardMultiple ChoiceObjective-mapped

TF-004 Use Terraform outside the core workflow Practice Question

A company uses Terraform Cloud and wants to ensure that only approved modules from the private registry are used in configurations. How can they enforce this?

⚠ Common exam trap

HashiCorp often tests the distinction between run tasks (external integrations) and Sentinel (native policy engine), leading candidates to incorrectly choose run tasks for in-plan policy enforcement when Sentinel is the correct answer.

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

✓

Use Sentinel policies to check module sources

Sentinel is HashiCorp's policy-as-code framework that can enforce governance rules on Terraform Cloud runs. By writing a Sentinel policy that inspects the `module` block's `source` attribute, you can restrict configurations to only use modules from the approved private registry, rejecting any run that references external or unapproved sources.

Answer analysis

Option-by-option breakdown

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

✗
Restrict module sources in VCS
Why it's wrong here
Restricting module sources directly within a Version Control System (VCS) like Git, through mechanisms such as pre-commit hooks or branch protection rules, operates at the code submission phase. While these controls can prevent unauthorized module sources from being committed to the repository, they cannot enforce policies at the Terraform Cloud runtime. A developer could potentially bypass these pre-commit checks or use a module source that was not explicitly restricted by the VCS rules, leading to an unapproved module being executed during a Terraform run.
✗
Configure workspace variables to limit module paths
Why it's wrong here
Configuring workspace variables in Terraform Cloud is intended for passing dynamic input values or credentials to a Terraform configuration during a run. These variables, such as TF_VAR_environment or AWS_REGION, are consumed by the Terraform CLI and do not possess any inherent capability to inspect or restrict the `source` attribute of a `module` block within the HCL code. There is no built-in mechanism for a workspace variable to act as a policy engine to validate or block specific module sources, making this approach unsuitable for enforcing module source policies.
✓
Use Sentinel policies to check module sources
Why this is correct
Sentinel policies provide a robust, native policy-as-code framework within Terraform Cloud, designed to inspect the Terraform plan and enforce organizational governance rules before infrastructure changes are applied. By writing a Sentinel policy, an organization can directly access the `tfplan` data, specifically evaluating attributes like `tfplan.module_calls[*].source` to identify and validate all module sources being used. If an unauthorized module source is detected, the policy can be configured to soft-fail (warn) or hard-fail (block) the Terraform run, ensuring only approved modules are deployed.
✗
Use run tasks to scan for module types
Why it's wrong here
Run tasks in Terraform Cloud are designed to integrate external services or scripts into the Terraform run lifecycle, typically for security scanning, cost estimation, or custom validations. While a run task could theoretically invoke an external system to scan for module types, it is an indirect method and not a native policy enforcement mechanism for HCL attributes within Terraform Cloud itself. Run tasks are primarily for integrating external tools that perform checks, rather than directly enforcing policies on the structure or content of the Terraform configuration or plan data in a granular, integrated manner like Sentinel.

Go deeper

TF-004 Use Terraform outside the core workflow Practice Question

Why each option matters

Option-by-option breakdown

Related to this question