Your organization requires that new AWS S3 buckets be private and encrypted at rest. How can Terraform Enterprise automatically enforce this security control before changes are applied?

Your organization requires that new AWS S3 buckets be private and encrypted at rest. How can Terraform Enterprise automatically enforce this security control before changes are applied?

• A. With a Sentinel policy, which runs before every apply
• B. By adding variables to each TFE workspace to ensure these settings are always enabled
• C. With an S3 module with proper settings for buckets
• D. Auditing cloud storage buckets with a vulnerability scanning tool

Answer: (A)

Enforcing guardrails with policy as code is what ensures security controls are automatically applied before changes go live. In Terraform Enterprise, Sentinel rules are evaluated as part of the run and can veto any plan that would create or modify resources not meeting your standards. Here, a Sentinel policy can inspect the planned AWS S3 bucket configurations and require that buckets are private (proper access control) and encrypted at rest (server-side encryption configured, such as SSE-S3 or SSE-KMS). If the plan would create or alter a bucket without these settings, the policy fails and prevents the apply from running, enforcing the control automatically. Other options don’t provide the same pre-apply enforcement. Adding variables in workspaces relies on manual discipline and can be bypassed or forgotten. A module with proper settings helps, but it’s not a universal gate across all bucket resources or accounts. Auditing with a vulnerability scanner finds issues after resources exist, not before changes are applied, so it won’t automatically stop noncompliant changes at plan time.

Enforcing guardrails with policy as code is what ensures security controls are automatically applied before changes go live. In Terraform Enterprise, Sentinel rules are evaluated as part of the run and can veto any plan that would create or modify resources not meeting your standards. Here, a Sentinel policy can inspect the planned AWS S3 bucket configurations and require that buckets are private (proper access control) and encrypted at rest (server-side encryption configured, such as SSE-S3 or SSE-KMS). If the plan would create or alter a bucket without these settings, the policy fails and prevents the apply from running, enforcing the control automatically.

Other options don’t provide the same pre-apply enforcement. Adding variables in workspaces relies on manual discipline and can be bypassed or forgotten. A module with proper settings helps, but it’s not a universal gate across all bucket resources or accounts. Auditing with a vulnerability scanner finds issues after resources exist, not before changes are applied, so it won’t automatically stop noncompliant changes at plan time.