Terraform Cloud Capabilities: free practice questions

When a Terraform Cloud workspace uses Remote execution mode with 'Auto apply' disabled (the default), every run pauses at the 'planned' state after the plan phase and waits for a user with appropriate permissions to click 'Confirm & Apply'. This is the built-in mechanism for requiring human approval before any apply proceeds, regardless of how the run was triggered. — Option A is wrong because enabling 'Auto apply' causes runs to proceed to apply automatically without human confirmation, which is the opposite of what is required. — Option C is wrong because Local execution mode offloads the plan and apply to the engineer's local machine; Terraform Cloud only stores state. It does not provide a centralized approval gate inside the platform for team-based review. — Option D is wrong because Sentinel policies gate applies based on policy logic, not on a blanket 'pause for human review' pattern. Sentinel is a policy-as-code governance tool and cannot be configured to simply require an operator comment as a generic approval mechanism; the correct purpose-built feature for approval gates is disabling Auto apply.

Option B is correct. Terraform Cloud's cost estimation feature calculates a projected monthly cost delta—showing the estimated cost before and after the planned changes—for a supported subset of resource types across AWS, Azure, and Google Cloud. Importantly, it is inserted into the run pipeline after the plan but before Sentinel policy checks, allowing policies to act on cost data (e.g., rejecting plans that exceed a cost threshold). Option A is wrong because coverage is not complete for all resource types and does not use real-time billing API queries; it uses static pricing tables. Option C is wrong because cost estimation is prospective (pre-apply), not retrospective. Option D is wrong because cost estimation supports AWS, Azure, and GCP, and does not require any cloud credentials or IAM roles—it works from the plan's resource definitions.

Option C is correct. A `hard-mandatory` Sentinel policy cannot be overridden by anyone, including organization owners. If the policy fails, the run is permanently blocked from proceeding to apply with no override path. Option A (advisory) is wrong because advisory policies log a warning but never block a run—the apply proceeds regardless. Option B (soft-mandatory) is wrong because soft-mandatory policies can be overridden by users with appropriate permissions (typically organization owners or policy override privileges), which does not meet the requirement of 'no circumstances' override. Option D (strict) is wrong because 'strict' is not a valid Sentinel enforcement level in Terraform Cloud; the three valid levels are advisory, soft-mandatory, and hard-mandatory.

Option C is correct. A soft-mandatory Sentinel policy failure pauses the run and requires a user with the 'Manage Policy Overrides' permission to explicitly override the failure before the apply step is unlocked. The current operator cannot unblock it themselves due to lacking that permission. Option A is wrong because the run is not discarded—it stays in a paused/needs-override state. Option B is wrong because soft-mandatory failures DO block the run; only advisory failures are non-blocking. Option D is wrong because the apply gating is based on the override permission, not on whether the plan produces changes.

Option B is correct. CLI workspaces (backed by a local or remote backend) share the same working directory and backend configuration—they are lightweight named state files within a single configuration. Terraform Cloud workspaces are far richer: each is an independent unit with its own state, variables, run history, team access permissions, and execution environment. Option A is wrong because creating a CLI workspace does not automatically create or sync a Terraform Cloud workspace. Option C is wrong because `terraform workspace` commands do not map to Terraform Cloud workspaces when using the `cloud` block or `remote` backend; you navigate TFC workspaces through the UI, API, or CLI workspace tagging. Option D is wrong because CLI workspaces are not more powerful—they lack governance, RBAC, audit logging, and remote execution that Terraform Cloud provides.